Hi Sasha, Jorge and all Consider the simplistic scenario of BGP-EVPN-Peers (and Vteps), PE1 and PE2 (might be in different/same fabrics/sites/pods), wherein,
* PE1 supports both IP A-D and MAC A-D whereas * PE2 supports legacy of MAC A-D. PE1 publishes: * MAC A-D with Route-Target1 (for EVI-1/VNI-1/Bride-domain-1) and * IP A-D (for EVI-2/VNI-2/local-VRF-x) with Route-Target2 indicating MAC aliasing and IP aliasing respectively. Whereas, PE2 is configured for * (EVI-1/VNI-1/Bridge-domain-1) for importing with Route-Target1, and * (EVI-2/VNI-2/Bridge-domain-2) for importing with Route-Target2 PE2 can surely mistake IP A-D published by PE1 for a MAC A-D and establishes it's next-hop database (ecmp or otherwize) accordingly against the Bridge-domain-2 instead of ignoring the IP A-D advertisement. The difference between IP A-D/MAC A-D (Route type-1) and the Route Type-2 is that * in Route Type-2, the second label and the second route-target imply that its being carried for IP-VRF * whereas , in Route Type-1, it comes down to configuration and operators prerogative to take care of it. https://www.rfc-editor.org/rfc/rfc9135.html#section-5.2 If the receiving PE receives this route with both the MAC-VRF and IP-VRF Route Targets and the MAC/IP Advertisement route includes the MPLS Label2 field but the receiving PE only supports asymmetric IRB mode, then the receiving PE MUST ignore the MPLS Label2 field and install the MAC address in the corresponding MAC-VRF and (IP, MAC) association in the ARP table for that tenant (identified by the corresponding IP-VRF Route Target). For above reasons, we should have an explicit flagging off and/or atleast a dedicate section in the draft for calling-out this scenario, as we don't have an organic/implicit way of distinguishing between IP-VRF and MAC-VRF related attributes being carried in Route-Type-1, unlike a Route-Type-2. Regards, Saumya. From: Alexander Vainshtein [mailto:[email protected]] Sent: Saturday, March 25, 2023 6:43 AM To: Jorge Rabadan (Nokia) <[email protected]>; Dikshit, Saumya <[email protected]> Cc: [email protected] Subject: Re: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt Saumya, Jorge and all, FWIW I concur with Jorge. The draft states than an IP per EVI EVPN A-D route: 1. Includes RD of IO-VEF in its NLRI 2. Carries RT of IP-VRF. Assuming that Import RTs of MAC-VRFs and IP-VRFs in any given PE are different, I do not see any potential for wrong mapping. My 2c, Sasha Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>> Sent: Friday, March 24, 2023, 23:26 To: Dikshit, Saumya <[email protected]<mailto:[email protected]>>; Alexander Vainshtein <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] Re: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt Hi Saumya, I don't think there is any need for especial flagging and the route-target will identify in which VRF the route needs to be imported. We have other cases in which a route type can be imported into a MAC-VRF or IP-VRF (see RFC9135) and there is no especial 'flag' for it. This has not caused any issues so I don't see why A-D routes would create issues either, to me it is the same thing. Thanks. Jorge From: Dikshit, Saumya <[email protected]<mailto:[email protected]>> Date: Friday, March 24, 2023 at 6:50 AM To: Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>>, Alexander Vainshtein <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See https://clicktime.symantec.com/15siFA3PedCRuwP2WEnEr?h=E0vKoxusvwRmg-2Wi4QRWfCEVPf2V0B7GpSJdjOAu1Q=&u=http://nok.it/ext<https://clicktime.symantec.com/15siFA3PedCRuwP2WEnEr?h=E0vKoxusvwRmg-2Wi4QRWfCEVPf2V0B7GpSJdjOAu1Q=&u=http://nok.it/ext> for additional information. Thank You Jorge. Since it's already on the field, I have few follow up queries related to "Interworking with BGP-Peers capable of ONLY MAC-aliasing": As I understand that the draft does not proposes any new PDU constructs and leverages existing ones (as defined for MAC-aliasing in rfc7432) to publish IP A-D per ES and IP A-D per EVI (EVPN Route Type 1) for IP-aliasing and fast-convergence respectively. For interworking with "BGP-EVPN peers" that comply only to MAC-aliasing and not to IP-aliasing, are there any explicit procedures defined in the draft ? As it's expected to be Route-Target based absorption/dropping of the IP A-D (per ES or EVI) NLRI, is the ONLY implicit way for receive-side BGP-EVPN-Peers (only expecting MAC-aliasing in network) to ignore the IP A-D routes. If "a" is true, then is there a possibility that EVI mappings (MPLS Labels, VNIs and corresponding Route-Targets) sent in IP A-D is being leveraged by MAC-Aliasing for an Layer-2 configuration (Bridge-domain and corresponding Route Targets) and can lead to error in processing. Instead, will it apt to call out the IP A-D from MAC A-D via an explicit flagging in the route itself. It will save the receive side BGP-EVPN peer (only doing MAC-aliasing) from processing the IP A-D with no avail. Thus saving some processing cycles which may lead to an error state. It will be great to have a section for "backward compatibility with MAC-aliasing ONLY peers". Regards, Saumya. From: Jorge Rabadan (Nokia) [mailto:[email protected]] Sent: Thursday, March 23, 2023 3:58 PM To: Dikshit, Saumya <[email protected]<mailto:[email protected]>>; Alexander Vainshtein <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt Hi Saumya, Yes, there are implementations deployed in networks. For the vendor I'm aware of, it includes pretty much all transport tunnels - vxlan, mpls, sr-mpls, SRv6... The use cases in the draft are agnostic of the transport. Thx Jorge ________________________________ From: Dikshit, Saumya <[email protected]<mailto:[email protected]>> Sent: Thursday, March 23, 2023 09:51 To: Alexander Vainshtein <[email protected]<mailto:[email protected]>>; Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/ext<https://clicktime.symantec.com/15siFA3PedCRuwP2WEnEr?h=E0vKoxusvwRmg-2Wi4QRWfCEVPf2V0B7GpSJdjOAu1Q=&u=http://nok.it/ext> for additional information. Hello Authors of draft-sajassi-bess-evpn-ip-aliasing, If there is an implementation reference from any Vendor for this draft https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ip-aliasing/<https://clicktime.symantec.com/15siKzEg7Et2KtCx3oBPU?h=wNU3T3Cevp1QqxepBtv7LOJDxf-F4f7-WvODlSy5Hos=&u=https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ip-aliasing/>. It will be good to know if the reference fabric for the implementation. Does it includes Vxlan, if not others ? Regards, Saumya. From: BESS [mailto:[email protected]] On Behalf Of Alexander Vainshtein Sent: Tuesday, January 10, 2023 9:14 PM To: Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [bess] New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt Jorge and all, I have read the latest revision of the draft and I agree that it is ready for the WG adoption call. >From my POV it meets the two conditions that, IMHO, define WG adoption: It addresses a real problem It provides a reasonably good start for solution of this problem. My 2c, Sasha From: BESS <[email protected]<mailto:[email protected]>> On Behalf Of Jorge Rabadan (Nokia) Sent: Tuesday, January 10, 2023 3:52 PM To: [email protected]<mailto:[email protected]> Subject: [EXTERNAL] [bess] FW: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt FYI We just updated this draft based on the comments made by Sasha on the list. We also fixed some nits and updated references. We'd like to reiterate that document is ready for WG adoption call. Thanks. Jorge From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Tuesday, January 10, 2023 at 2:40 PM To: A. Sajassi <[email protected]<mailto:[email protected]>>, G. Badoni <[email protected]<mailto:[email protected]>>, J. Drake <[email protected]<mailto:[email protected]>>, Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>>, L. Krattiger <[email protected]<mailto:[email protected]>>, P. Warade <[email protected]<mailto:[email protected]>>, S. Pasupula <[email protected]<mailto:[email protected]>>, Ali Sajassi <[email protected]<mailto:[email protected]>>, Gaurav Badoni <[email protected]<mailto:[email protected]>>, John Drake <[email protected]<mailto:[email protected]>>, Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>>, Lukas Krattiger <[email protected]<mailto:[email protected]>>, Priyanka Warade <[email protected]<mailto:[email protected]>> Subject: New Version Notification for draft-sajassi-bess-evpn-ip-aliasing-06.txt A new version of I-D, draft-sajassi-bess-evpn-ip-aliasing-06.txt has been successfully submitted by J. Rabadan and posted to the IETF repository. Name: draft-sajassi-bess-evpn-ip-aliasing Revision: 06 Title: EVPN Support for L3 Fast Convergence and Aliasing/Backup Path Document date: 2023-01-10 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/archive/id/draft-sajassi-bess-evpn-ip-aliasing-06.txt<https://clicktime.symantec.com/15siVeDMbsp2p1wKgTxN4?h=Bx1_zlXLVe5CXSl4uPQinOw4O-VdjSd1bRQf_MxBmjQ=&u=https://www.ietf.org/archive/id/draft-sajassi-bess-evpn-ip-aliasing-06.txt> Status: https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ip-aliasing/<https://clicktime.symantec.com/15siKypngeSqz8HUbMA4p?h=izZF6rfMzUeFiWQGKAhvgPS53_OWNi_PQUtGVJSJxQo=&u=https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ip-aliasing/> Htmlized: https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing<https://clicktime.symantec.com/15siQp259G8SQ57Q8uZDS?h=oAVtm-7JQjfNt-rdM331nh6a308FM7ntGGsF4o4NBws=&u=https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing> Diff: https://author-tools.ietf.org/iddiff?url2=draft-sajassi-bess-evpn-ip-aliasing-06<https://clicktime.symantec.com/15siF9dWE2mFaBTZ3nkvC?h=tpILk5e82UtksHG0WfCcO2FrK_oHNes6kqzFmThK-S8=&u=https://author-tools.ietf.org/iddiff?url2=draft-sajassi-bess-evpn-ip-aliasing-06> Abstract: This document proposes an EVPN extension to allow several of its multihoming functions, fast convergence and aliasing/backup path, to be used in conjunction with inter-subnet forwarding. The extension is limited to All-Active and Single-Active redundancy modes. The IETF Secretariat 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. 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 [email protected] https://www.ietf.org/mailman/listinfo/bess
