Add SONiC VPP IPinIP tunnel HLD - #222
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
lolyu
left a comment
lolyu
left a comment
There was a problem hiding this comment.
✅ Review — Thorough HLD
Excellent coverage of both decap (P2MP/P2P) and encap (P2P) paths. The SAI↔VPP semantic mismatch analysis (Section 7) is particularly valuable — clearly explains why VPP's TEIB-based allowlist doesn't match SAI's permissive P2MP model, and the adaptation (P2MP wildcard fallback patch) is well-justified.
Minor:
- Section numbering gap: 6.2 → 6.5 (missing 6.3, 6.4)
- Consider noting IPv6 scope (in/out for this phase)
- The P2MP permissive decap security trade-off could use a one-liner about underlay ACL/routing being the security boundary
LGTM 🚀
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| IPIP->>VPP: 3. vpp_ipip_tunnel_add(&req) | ||
| VPP-->>IPIP: sw_if_index (e.g. ipip1) | ||
|
|
||
| IPIP->>VPP: 4. refresh_interfaces_list() |
There was a problem hiding this comment.
vpp_ipip_tunnel_add already returns sw_if_index. Do we still need refresh_interfaces_list?
There was a problem hiding this comment.
yes, we need to refresh the interface list to get intf name to used by interface_set_state
| 2. Iterating each interface individually, sending `IP_ADDRESS_DUMP` per interface. | ||
| 3. The reply handler (`vl_api_ip_address_details_t_handler`) compares the dumped address against the search target; on match it records the `sw_if_index`. | ||
|
|
||
| --- |
There was a problem hiding this comment.
Please add ipinip tunnel config in CONFIG_DB/APP_DB. It is also helpful to list vpp binary APIs for ipinip tunnel so we know from top to down how sonic maps to vpp
There was a problem hiding this comment.
Good point, will add the APPL_DB section
| ok["Decap → deliver inner pkt to ipip0"] | ||
|
|
||
| subgraph patch["SONiC-VPP patch"] | ||
| p2mp["Lookup: {P2MP, src=outer_dst, dst=0.0.0.0}"] |
There was a problem hiding this comment.
I think we should not reuse existing P2MP entry and adds P2MP lookup. This breaks existing P2MP + TEIB design, which wants to drop the packet if it doesn't match TEIB entries. Instead, I think we should introduce a new mode, for example, MP2P. It can be created the same way: create ipip tunnel src 10.0.0.1 mode mp2p. This creates a new entry for ipip tunnel lookup. You can then insert the lookup action after p2p or 6rd. If it is existing p2mp+teib, it won't hit the mp2p lookup because the entry is not there. I think this can be upstream to fd.io because it is a useful feature.
There was a problem hiding this comment.
Great idea, we sure can add a new tunnel type for our purpose. But naming it MP2P is pretty misleading here as P2MP means local is single-point and remote is multi-point, MP2P should means local is multi-point and remote is single-point.
How about name it P2ANY?
There was a problem hiding this comment.
I asked gemini.
The difference between MP2P (Multipoint-to-Point) and P2MP (Point-to-Multipoint) comes down to the direction of the traffic flow and how the network handles the duplication or aggregation of packets.
In short:
MP2P is Many-to-One (N:1). It is used for traffic aggregation.
P2MP is One-to-Many (1:N). It is used for traffic distribution or replication.
Here is a detailed comparison of the two concepts in the context of networking and tunneling:
1. MP2P (Multipoint-to-Point)
Traffic Flow: Many senders $\rightarrow$ One receiver.
How it works: Multiple remote endpoints send tunneled traffic to a single, centralized destination. The receiving node uses a single interface to accept and decapsulate traffic from all of these different sources.
Key Characteristic: Aggregation. The network paths merge as they get closer to the destination. The receiver does not need to maintain strict state for every sender; it just processes the incoming packets.
Common Use Cases:
Standard Unicast Routing: In MPLS or Segment Routing, traffic from all over the network destined for a specific router naturally merges into an MP2P flow.
Hub-and-Spoke VPNs: Spoke routers sending their internet or corporate traffic to a central Hub router (e.g., DMVPN Spokes sending to the Hub).
2. P2MP (Point-to-Multipoint)
Traffic Flow: One sender $\rightarrow$ Many receivers.
How it works: A single source sends a packet, and the network is responsible for delivering that exact same packet to multiple destinations. To do this efficiently, the network performs packet replication—copying the packet only when the path splits, rather than the sender transmitting individual copies to every receiver.
Key Characteristic: Replication (Multicast). The sender or the network fabric must maintain state about who the receivers are so it knows where to replicate and forward the packets.
Common Use Cases:
Multicast Traffic: Live video streaming, IPTV, or financial stock ticker feeds where one server broadcasts to thousands of viewers.
Routing Protocol Updates: A Hub router sending OSPF or EIGRP hello packets/updates to all of its Spoke routers simultaneously.
MPLS Traffic Engineering (RSVP-TE P2MP): Used to build a strict, engineered path from a single headend router to multiple tail-end routers, specifically to carry Multicast VPN (mVPN) traffic.
I think our use case fits MP2P. It describes sender->receiver relationship, not local->remote.
There was a problem hiding this comment.
Hi @yue-fred-gao, for decap, the receiver is local, the sender is remote; as p2mp means the sender is mp while the receiver is p, mp2p means the sender is p and the receiver is mp. This is not our situation, right?
There was a problem hiding this comment.
Hi @lolyu , from explanation from gemini, "2" is the direction of traffic ("2" is to). The role before "2" is sender and after is receiver. so p2mp means one sender to multiple receiver. mp2p means multiple sender to one receiver. Having said that, I am not particularly clinging to any term.
Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Hi @yue-fred-gao, could you please help review again? Few updates:
As for this PR: #221, can we do this in two step, first let's unblock the SONiC decap with this hacky solution, and add a new ipip tunnel flag to support this afterwards? |
Thanks for the update. I think new ipip tunnel flag is not very complicated so I prefer you use the same commit to complete it. The reason is that for each new update to vpp (new patch or new version), we need to upload the prebuilt debs to buildkite so they are not rebuilt again. We want to minimize the versions in buildkite to limit the space usage. |
Hi @yue-fred-gao, thanks, one question: we only patches the downstream version, right? why do we need to upload debs to buildkite? |
|
Add VPP ipinip tunnel encap/decap support. Please refer to HLD to design details: sonic-net/sonic-platform-vpp#222. ``` tests/decap/test_decap.py::test_decap ✓ 100% ``` Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
* Add SONiC VPP IPinIP tunnel HLD Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
Approach What is the motivation for this PR? Work item tracking Microsoft ADO (number only): 38423472 As the subject. Signed-off-by: Longxiang Lyu lolv@microsoft.com How did you do it? Please refer to the HLD: sonic-net/sonic-platform-vpp#222 How did you verify/test it? Run test_decap on vpp testbed and pass. Any platform specific information? Supported testbed topology if it's a new test case?
Approach What is the motivation for this PR? Work item tracking Microsoft ADO (number only): 38423472 As the subject. Signed-off-by: Longxiang Lyu lolv@microsoft.com How did you do it? Please refer to the HLD: sonic-net/sonic-platform-vpp#222 How did you verify/test it? Run test_decap on vpp testbed and pass. Any platform specific information? Supported testbed topology if it's a new test case? Signed-off-by: selldinesh <dinesh.sellappan@keysight.com>
Approach What is the motivation for this PR? Work item tracking Microsoft ADO (number only): 38423472 As the subject. Signed-off-by: Longxiang Lyu lolv@microsoft.com How did you do it? Please refer to the HLD: sonic-net/sonic-platform-vpp#222 How did you verify/test it? Run test_decap on vpp testbed and pass. Any platform specific information? Supported testbed topology if it's a new test case? Signed-off-by: selldinesh <dinesh.sellappan@keysight.com>
Approach What is the motivation for this PR? Work item tracking Microsoft ADO (number only): 38423472 As the subject. Signed-off-by: Longxiang Lyu lolv@microsoft.com How did you do it? Please refer to the HLD: sonic-net/sonic-platform-vpp#222 How did you verify/test it? Run test_decap on vpp testbed and pass. Any platform specific information? Supported testbed topology if it's a new test case? Signed-off-by: ssithaia-ebay <ssithaian@ebay.com>
3 participants
Add IPinIP tunnel encap/decap support to SONiC VPP.
Signed-off-by: Longxiang Lyu lolv@microsoft.com