Dataplane VXLAN HLD #1764
Dataplane VXLAN HLD #1764
Conversation
|
Can we rename the title of this HLD to "static VXLAN HLD"? |
| ### Requirements | ||
|
|
||
| * Static VXLAN Tunnel Configuration: Users should be able to manually specify VXLAN tunnel endpoints. | ||
| * VNI to VLAN Mapping: Users must be able to statically map VNIs to VLANs. |
There was a problem hiding this comment.
Please reword as user/controller configured VLAN extension to remote VTEPs.
VNI to VLAN mapping exists today and is static.
There was a problem hiding this comment.
*VNI to VLAN mapping exists today and is static. - You are correct, we just keeping this requirement to make sure it is clear.
There was a problem hiding this comment.
- VNI to VLAN mapping - This requirement was kept to make sure it is clear.
| * VNI to VLAN Mapping: Users must be able to statically map VNIs to VLANs. | ||
| * L2 learning over local and remote VTEPs. | ||
| * L2 BUM traffic flooding over VNI. | ||
|
|
There was a problem hiding this comment.
Is L3 fwding over static VXLANs supported ?
There was a problem hiding this comment.
Static VXLAN as overlay L2 exists in SONiC. L3 was out of scope.
I'm not clear if L3 overlay can run with BGP without L2 EVPN.
|
|
||
| * Static VXLAN Tunnel Configuration: Users should be able to manually specify VXLAN tunnel endpoints. | ||
| * VNI to VLAN Mapping: Users must be able to statically map VNIs to VLANs. | ||
| * L2 learning over local and remote VTEPs. |
There was a problem hiding this comment.
If the controller driven model is a use-case, configuration of MACs pointing to static VXLAN tunnels would become a requirement?
Distinction should be made between MACs which are static and MACs which can be moved.
There was a problem hiding this comment.
This HLD supports full dynamic learning, especially on remote VTEPs.
The purpose of this HLD wasn't replace BGP with controller. That is why we don't support MAC pointing to static VXLAN.
If we want to support command to configure static MAC with move option, in case of actual mac move, this command will need to be deleted from Config db (not sure if this is acceptable behavior in SONiC).
|
|
||
| Feature will support following configuration: | ||
| 1. Remote VTEP name and IP address configuration. | ||
| 2. Remote VTEP-VNI association. |
There was a problem hiding this comment.
Should the VLAN also be associated here ?
There was a problem hiding this comment.
We are using the existing VNI-to-VLAN mapping.
| #### Configuration | ||
|
|
||
| Feature will support following configuration: | ||
| 1. Remote VTEP name and IP address configuration. |
There was a problem hiding this comment.
Why would Remote VTEP name be required ?
There was a problem hiding this comment.
We wanted to identify remote VTEP by its name, so it will allow to change its IP address without affecting other configurations.
Another reason, when admin configures remote VTEP , he will have human readable string , not just IP.
| ; New table | ||
| ; specifies mapping of remote VTEP to VNI | ||
|
|
||
| key = VXLAN_REMOTE_VTEP_VNI_TABLE|remote_vtep_name|tunnel_map_name |
There was a problem hiding this comment.
Shouldnt the key be
VXLAN_REMOTE_VTEP_VNI_TABLE|vtep_name|Vlanname
The tunnel map name can technically be anything and not reflective of the VLAN and VNI
There was a problem hiding this comment.
Does the key has to be reflective of vlan/vni ? My understanding is that key only has to be unique and since vni (and maybe vlan) is field in the entry it doesn't have to be specified again in the key.
|
|
||
| #### 3. APP_DB Enhancements | ||
|
|
||
| ##### 3.1 VXLAN_DATAPLANE_VTEP_TABLE |
There was a problem hiding this comment.
Corresponding to remote VTEP table in the config DB shouldnt this also be Remote VTEP in the APP DB ?
There was a problem hiding this comment.
This table holds VTEP name that will be used as source VTEP for the tunnel (Similar to EVPN_NVO_TABLE).
| source_vtep = tunnel_name | ||
|
|
||
|
|
||
| ##### 3.2 VXLAN_DATAPLANE_VTEP_VNI_TABLE |
There was a problem hiding this comment.
The existing VXLAN_REMOTE_VNI table can be reused as is.
I am not clear on the need for this table as the VXLAN_REMOTE_VNI table and the OA handling of this
table is sufficient.
VxlanMgr can populate this instead of fdbsyncd for static tunnel cases.
A "creation_source" field can be used to distinguish between VxlanMgr and fdbsyncd populated entries.
This source can be used to infer if this tunnel is static or dynamic.
There was a problem hiding this comment.
I agree, it can be used. Currently, it is used by EvpnRemoteVnip2pOrch/EvpnRemoteVnip2mpOrch classes. Do you think these also can be reused (with naming change) or same table to be referenced again by Dataplane ?
| - BridgePort SAI object with the tunnel oid is created. Learning is disabled for EVPN tunnels and enabled for data plane tunnels. | ||
| - Port object of type Tunnel created in the portsorch. | ||
|
|
||
| The data plane tunnels are created when the remote VTEP is added and will be deleted when the last remote VTEP is removed. |
There was a problem hiding this comment.
I am unclear on the term "last" remote VTEP.
Wouldnt only one remote VTEP configuration be made ?
There was a problem hiding this comment.
There can be several remote VTEPs, each with it name and IP.
| A P2MP tunnel uses a single tunnel termination. Because tunnel termination is utilized for MAC learning, supporting P2MP requires manual MAC configuration, which undermines the goal of dynamic learning. | ||
|
|
||
| #### 4.4 Fdborch | ||
| * FDB entries will be learned over tunnel interface and not configured via APP_VXLAN_FDB_TABLE_NAME(as in BGP-EVPN). So they will be handled as regular MAC entries. |
There was a problem hiding this comment.
MAC provisioned by the controller will be written into the VXLAN_FDB_TABLE.
There was a problem hiding this comment.
Since originally we didn't intended to support controller-added MACs (only dynamiccally-learned), I missed this part. Will add this as part of phase two.
will rename to "Dataplane (static) VXLAN HLD" |
No description provided.