Hi Sasha, Thanks for your comments. Please refer to my responses below marked with “AS>”
From: BESS <bess-boun...@ietf.org> on behalf of Alexander Vainshtein <alexander.vainsht...@rbbn.com> Date: Monday, November 14, 2022 at 1:36 AM To: draft-ietf-bess-evpn-lsp-p...@ietf.org <draft-ietf-bess-evpn-lsp-p...@ietf.org> Cc: bess@ietf.org <bess@ietf.org>, Alexander Ferdman <alexander.ferd...@rbbn.com>, Dmitry Valdman <dmitry.vald...@rbbn.com>, Ron Sdayoor <ron.sday...@rbbn.com>, Nitsan Dolev <nitsan.do...@rbbn.com> Subject: [bess] A question pertaining to validation of LSP Ping Echo requests in draft-ietf-bess-evpn-lsp-ping-08 Hi all, My colleagues and I have a question about the validation rules for LSP Ping Echo Requests associated with EVPN Type 2 routes in draft-ietf-bess-evpn-lsp-ping-08<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-lsp-ping-08>. The problematic text in Section 4.1 of the draft says: The LSP Echo Request is sent using the EVPN MPLS label(s) associated with the MAC/IP Advertisement route announced by a remote PE and the MPLS transport label(s) to reach the remote PE. When remote PE processes the received LSP Echo Request packet, the remote PE validates the MAC state if the MAC/IP Sub-TLV contains only MAC address. If the MAC/IP Sub-TLV contains both MAC and IP address, the PE validates the ARP/ND state. AS> The 2nd part of the above paragraph (2nd sentence onward) should be modified as follow: “ In EVPN, MAC/IP Advertisement has multiple personality and it is used for the following cases: 1. This route with only MAC address and MPLS Label1 is used for populating MAC-VRF and performing MAC forwarding. 2. This route with MAC and IP addresses and only MPLS Label1 is used for populating both MAC-VRF and ARP/ND tables (for ARP suppression) as well as for performing MAC forwarding 3. This route with MAC and IP addresses and both MPLS Label1 and Label2 is used for populating MAC-VRF and IP-VRF tables as well as for both MAC forwarding, and IP forwarding in case of symmetric IRB When the remote PE receives MAC/IP Sub-TLV containing only MAC address, then the remote PE validates the MAC state and forwarding. When the remote PE receives MAC/IP Sub-TLV containing both MAC and IP addresses and if the EVPN label points to a MAC-VRF, then it validates the MAC state and forwarding. If the remote PE is not configured in symmetric IRB mode, then it validates ARP/ND state as well. However, if the EVPN label points to an IP-VRF, then it validates IP state and forwarding. Any other combinations, such as remote PE receiving MAC/IP Sub-TLV containing only MAC address but with EVPN label pointing to an IP-VRF, should be considered invalid and LSP Echo response should be sent with the appropriate return code. Here are our questions: 1. Suppose that some MAC address: * Has been learned by the intended egress PE from the Data Plane from an All-Active MH ES and advertised in a MAC-only route EVPN Type 2 route * An EVPN Type 2 route for some IP→MAC pair with the same MAC address has been advertised by another PE attached to the same All-Active MH ES * An LSP Ping Echo request with the IP→MAC pair in question and the label that has been advertised by the intended egress PE in the Label1 field of an EVPN Type 2 route for the MAC address in question is received What is the expected result of the validation taking into account that the egress PE has not ever advertised an EVPN Type 2 route for the IP→MAC pair in question? AS> Baseline EVPN (RFC 7432) describes how a MAC address or <MAC, IP> pair is synched up among multi-homing PEs. So, if PE1 (but not PE2) advertises M1 or <M1, IP1>, PE2 will synch up with PE1 and programs M1 or (M1,IP1> in its tables as if it has received M1 or <M1,IP1> via its local ESI. So, in your example, when PE3 send lsp ping request to PE2 (either for M1 for <M1,IP1>), then PE2 can validate it even though PE2 never advertised M1 or <M1,IP1>. Of course, this assumes aliasing is enabled. If aliasing is not enabled, then PE3 doesn’t have the right MPLS label to send the LSP Ping request. 1. Suppose that: * Some MAC address as been learned by the egress PE only via the control plane (ARP/ND) and advertised In an EVPN Type 2 route for an IP→MAC pair * A MAC-only LSP Ping request for the MAC address in question with the label advertised in the Label1 field of the EVPN Type 2 route for an IP→MAC pair in question has been received What is the expected result of the validation taking into account that the egress PE has not advertised any MAC-only routes for the MAC address in question? AS> I believe the updated text should take care of this scenario. 1. Suppose that: * We are dealing with a BD that is used by a Symmetric EVPN IRB * Some MAC address as been learned by the egress PE only via the control plane (ARP/ND) and has been advertised In an EVPN Type 2 route for an IP→MAC pair with Label2 field present * A MAC-only LSP Ping request for the MAC address in question with the label advertised in the Label2field of the EVPN Type 2 route for an IP→MAC pair in question has been received What is the expected result of the validation? AS> The updated text should take care of this scenario. If you think no, then tell us what part and we can elaborate further. 1. Same as #3 above, but the LSP Ping request is for the IP→MAC pair in question and with the label advertised in the Label2 field of the EVPN Type 2 route for an IP→MAC pair in question? AS> Again the updated text, should cover this scenario. Cheers, Ali >From my POV the simplest way to answer all these questions would be to say >that the information and the label in the LSP Ping Echo request should be >validated vs. the set of EVPN Type 2 routes advertised by the egress PE and >succeed (yielding return code 3) only in the case of an exact match. Scenarios >described in #1, #2 and #3 above could be treated as partial matches and >yielding some new return codes while scenario 4 would be treated as success. Your timely feedback would be highly appreciated. Regards, and lots of thanks in advance, Sasha Notice: 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 https://www.ietf.org/mailman/listinfo/bess
