Hi all , I would like to share with you my serious concerns regarding the EVPN Network Layer Fault Management<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bfd-07> draft.
These concerns are closely related to the email exchange with the authors of the draft that can be found here<https://mailarchive.ietf.org/arch/msg/bess/VfGN6fLORF9dylzoFjCmKLINjDM/>. I have decided to present them now because the WG Chairs have said yesterday that the draft is going to the WG LS. 1. Section 3 of the draft says that "In addition to detecting link failures in the EVPN network, BFD sessions at the network layer can be used to monitor the successful setup, such as label programming, of MP2P and P2MP EVPN tunnels transporting Unicast and BUM traffic. The scope of reachability detection covers the ingress and the egress EVPN PE (Provider Edge) nodes and the network connecting them". IMHO and FWIW this statement actually contradicts the OAM layering scheme: * The underlay failures such as link failures, P and PE node failures etc.) should be monitored by their own monitoring mechanisms and should be quite aggressive for fast detection of failure and activation of the relevant protection mechanisms * The OAM mechanisms used for the EVPN network layer should be separated from the mechanisms used in the underlay and should not be over-aggressive in order to avoid multiple instances of false detection of failures at the network layer. E.g., failure of the link in the undelay network that is detected by fast single-op IP BD (TFV 5880) and triggers appropriate local protection action (e.g., SR TI-LFA) should not be reported by the EVPN Network layer OAM mechanisms. * The above means that the EVPN Network Layer OAM should be limited to detecting failures in programming the labels/VNI advertised in various EVPN routes. Such failures can occur, but hardly require fast monitoring mechanisms: i. EVPN LSP Ping (RFC 9489) already provides an on-demand OAM mechanism for detecting such failures ii. It is worth noting that BFD has never been proposed as the Network Layer OAM mechanism for BGP/MPLS IP/VPN (RFC 4364) in the 20+ years period in which both mechanisms have been available and widely deployed. 1. IMHO and FWIW: * BFD sessions should be set up in accordance with the procedures defined in RFC 5882: i. Set up by some "client entity" thar listens to the session state transitions ii. Each BFD flavor defines the session uniqueness rules, and multiple client entities can listen to the same existing session if a new session cannot b set up without violating these rules iii. When the session exits its UP state (e.g., fails) , listening clients take appropriate actions * When a new BFD "flavor" is defined, explicit definition of potential client entities and actions they take upon failure of the session in question is highly- RFC 7130 provides a good example. However, such definitions are missing in the draft in question. In particular: i. It is not clear when a specific BFD session is set up, and at what granularity (per MAC address? Per EVI? Per EVI Ethernet Tag> for EVI that implements VLAN-aware Bundle service interface ?) ii. Should BFD sessions be activated for EVI/BD that are not attached to any MH ES? In this case EVI/BD would not advertise any per EVI Ethernet A-D routes, and only MAC/IP Advertisement routes carry the information MAC addresses and the labels associated with them, iii. What, if anything, should be done if a specific "EVPN BFD" BFD session fails? In particular, how should the customer traffic presumably affected by the failed session should be restored? 1. Encapsulation of the BFD packets defined in Sections 6.1.1 and 6.2.1 include a VAN ID field, but the draft does not specify how the value of this VLAN ID is defined. Please consider these notes as my WG LC comments if/when this LC is announced. Regards, Sasha Closely Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
