Dash-Sonic - Update for Scaling/Underlay Routing/ST/PL encoding #309
Conversation
prsunny
changed the title
|
How is overlay encoding interpreted by the destination (shared resource)? Once we have done the 4to6 transposition, we have, for service tunnel, overlay_sip+underlay_sip encoded as one v6 address and overlay_dip+underlay_dip encoded as another. How does a destination use this for reverse routing? |
@mhanif , interpretation of the encoding at destination is upto the provider of the service. Expectation is, they can encode the fields of their interest, say vnet-id, region-id etc to the transformed ipv6 address and should have some contract with the destination resource. For ST, underlay sip/dip are ipv4. only overlay is transformed from 4to6. Overlay v6 has the source/dst address embedded to last 32 bits which destination use for reverse routing. |
| @@ -952,7 +974,7 @@ For the example configuration above, the following is a brief explanation of loo | |||
| c. Next lookup is in the mapping table and mapping table action here is "privatelink" | |||
| d. First Action for "privatelink" is 4to6 transposition | |||
| e. Packet gets transformed as: | |||
| For Overlay SIP, using ENI's "pl_sip_encoding": "field:11:1:0x1:field:48:48:0x0a0b0c0d0a0b" -> Overlay SIP fd30:108:0:0a0b:0c0d0:0a0b:a01:102; | |||
| For Overlay SIP, using ENI's "pl_sip_encoding": "0x0020000000000a0b0c0d0a0b/0x002000000000ffffffffffff" -> Overlay SIP fd30:108:0:0a0b:0c0d:0a0b:a01:102; | |||
| Overlay DIP 2603:10e1:100:2::3402:206 (No transformation, provided as part of mapping) | |||
| f. Second Action is Static NVGRE encap with GRE key '100'. | |||
| g. Underlay DIP shall be 50.2.2.6 (from mapping), Underlay SIP shall be 55.1.2.3 (from ENI) | |||
There was a problem hiding this comment.
All of this explains processing in the outbound direction. As discussed in the community meeting, please add the inbound processing details for both the ST and PL. Thanks!
There was a problem hiding this comment.
Yes, it is updated in section 2.3, tagged as ST/PL Inbound flow
There was a problem hiding this comment.
@prsunny Sorry that this inbound processing explanation doesn't answer my question. I was looking more from the point of view how you describe the VNET-to-VNET. Specifically, in order to determine the packet-direction, we look at the "VNI" and then to the inner MAC to find the ENI to which the packet belongs to. For ST/PL, in your example, if we are using NVGRE then the "key" is perhaps used to determine whether the packet is from Host or Network? Correct? If that is the case, the VNET definition should be modified to introduce the concept of NVGRE "key". Currently it only talks about VNI. Should we make those clarifications? Thanks!
There was a problem hiding this comment.
@mhanif , it is already captured in section 2.1
"The pipeline shall parse the VNI, and for VM traffic, the VNI shall be a special reserved VNI. Everything else shall be treated as as network traffic(RX)."
| @@ -952,7 +974,7 @@ For the example configuration above, the following is a brief explanation of loo | |||
| c. Next lookup is in the mapping table and mapping table action here is "privatelink" | |||
| d. First Action for "privatelink" is 4to6 transposition | |||
| e. Packet gets transformed as: | |||
| For Overlay SIP, using ENI's "pl_sip_encoding": "field:11:1:0x1:field:48:48:0x0a0b0c0d0a0b" -> Overlay SIP fd30:108:0:0a0b:0c0d0:0a0b:a01:102; | |||
| For Overlay SIP, using ENI's "pl_sip_encoding": "0x0020000000000a0b0c0d0a0b/0x002000000000ffffffffffff" -> Overlay SIP fd30:108:0:0a0b:0c0d:0a0b:a01:102; | |||
There was a problem hiding this comment.
In this example, since the mapping is vnet_direct, all packets destinations in 10.2.0.0/16 subnet will use the same mapping entry - 10.2.0.6, with the same DIPi overwrite. Is this a valid case for PL ?
There was a problem hiding this comment.
addressed. its not a valid case for PL.
Update Sonic HLD for: