EVPN MultiHoming Fast ReRoute for L3VNI-routed traffic - #2332
EVPN MultiHoming Fast ReRoute for L3VNI-routed traffic#2332manamand2020 wants to merge 1 commit into
Conversation
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
manamand2020
changed the title
manamand2020
changed the title
manamand2020
changed the title
6a392e8 to
406fde9
Compare
Signed-off-by: Manas Kumar Mandal <manamand@cisco.com>
|
|
||
| The route lookup resolves to a RIF/neighbor pair, which in turn resolves to the primary bridge port (`SAI_BRIDGE_PORT_TYPE_PORT`) | ||
| for the ES. That bridge port carries `SAI_BRIDGE_PORT_ATTR_BRIDGE_PORT_PROTECTION_MODE` and | ||
| `SAI_BRIDGE_PORT_ATTR_BRIDGE_PORT_PROTECTION_NEXT_HOP_GROUP_ID`, pointing to a `SAI_NEXT_HOP_GROUP_TYPE_BRIDGE_PORT` |
There was a problem hiding this comment.
Hey Manas, do you know why the next hop type being bridge port? The next hop id is vxlan tunnel, so this sounds a bit inconsistent (I am aware that this is somehow allowed in the SAI, but not sure why)
There was a problem hiding this comment.
This is following the existing section 3.2.1, :
A new nexthop type which will be part of groups of the above group type.
typedef enum _sai_next_hop_type_t
...
/** Next hop group is for bridge port */
SAI_NEXT_HOP_TYPE_BRIDGE_PORT,
} sai_next_hop_type_t;
Maybe the question is why SAI_NEXT_HOP_TYPE_TUNNEL_ENCAP is not being used instead. I think using the SAI_NEXT_HOP_TYPE_BRIDGE_PORT is only allowed for bridge nexthop group case as the comment mentions and implementation can distinguish this clearly.
/** Next hop group is for bridge port */
| SAI_BRIDGE_PORT_PROTECTION_MODE_HARDWARE, | ||
|
|
||
| /** Hardware switchover. Does not switch back to the bridge port once it recovers */ | ||
| SAI_BRIDGE_PORT_PROTECTION_MODE_HARDWARE_NON_REVERTIVE, |
There was a problem hiding this comment.
Will need to make sure the recovery path of non-revertive flavor is more clear.
There was a problem hiding this comment.
Do we need an attribute for delayed recovery when the port is up again?
There was a problem hiding this comment.
Intentionally kept this out of the scope here. I think delay/debouncing should be handled by the Port object itself. Like Link UP and Link Down debouncing. We already have attributes like SAI_PORT_ATTR_LINK_UP_DEBOUNCE_TIMEOUT and there is a proposal for link down in #2284.
For link damping as well we should extend the existing https://github.com/sonic-net/SONiC/blob/master/doc/link_event_damping/Link-event-damping-HLD.md
I see that this defines as switch level attribute to update the oper status using SAI_SWITCH_HOSTIF_OPER_STATUS_UPDATE_MODE_SAI_ADAPTER.
manamand2020
changed the title
2 participants
Adds SAI support for hardware-driven fast reroute (FRR) of L3VNI-routed traffic to a cross-switch multihomed bridge port, extending the existing software-driven EVPN Multihoming fast-failover mechanism (autonomous ASIC switchover + async NOS notification, instead of NOS-driven SET_SWITCHOVER).
Changes
inc/saibridge.h: sai_bridge_port_protection_mode_t (SOFTWARE/HARDWARE/HARDWARE_NON_REVERTIVE) + SAI_BRIDGE_PORT_ATTR_BRIDGE_PORT_PROTECTION_MODE; sai_bridge_port_protection_state_t + read-only SAI_BRIDGE_PORT_ATTR_BRIDGE_PORT_PROTECTION_STATE; sai_bridge_port_protection_event_t, notification data struct, and callback typedef for HW switchover events.
inc/saiswitch.h: SAI_SWITCH_ATTR_BRIDGE_PORT_HW_PROTECTION_SWITCHOVER_NOTIFY to register the callback (mirrors the existing next-hop-group HW protection notify attribute).
inc/saitunnel.h: SAI_TUNNEL_ATTR_VXLAN_TUNNEL_MAC — inner DMAC for routed traffic re-encapsulated onto a P2P VXLAN tunnel after switchover.
doc/tunnel/SAI-Proposal-EVPN-Multihoming.md: new §3.2.6 spec, §4.6 workflow, Figure 7 object-model diagram.