Hi Jorge, I completely understand that IP AD per EVI route should carry the IP-VRF RD. But with IP-aliasing, we are creating case where-in:
1. an attached ES is leveraged for both MAC-aliasing and IP-aliasing (host routes) via MAC routes and /32 routes respectively a. Both are being published via the same NLRI in RT-2 as MAC/IP and L2VNI and L3VNI There should be an common association (other than the ES.) between IP AD per EVI and the Host routes which are absorbed for IP-aliasing, 1. The common denominator should also include RD (configured on the EVI mapped to the vrf) on the send side It’s confusing that RD carried in MAC/IP is the VLAN RD (as per EVPN standards, cannot content that). 1. But we are also signaling host-routes for layer-3 multi-homing and leveraging it RD as an index on the receive side. a. Even though the corresponding IP-AD per EVI is signaled with vrf configured RD (and rightly so) 2. Somehow this is not coming together organically We should call out the above mismatch (and/or absorption procedure for the IP-aliasing of host routes) in the draft. Regards, Saumya. From: Jorge Rabadan (Nokia) [mailto:jorge.raba...@nokia.com] Sent: Tuesday, March 5, 2024 7:53 PM To: Dikshit, Saumya <saumya.diks...@hpe.com>; Allu, Ramaprasad <ramprasad...@hpe.com>; bess@ietf.org; draft-sajassi-bess-evpn-ip-alias...@ietf.org Cc: bess-cha...@ietf.org Subject: Re: Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html Hi Saumya, This spec does not change anything for the advertisement of MAC/IP Advertisement routes or IP Prefix routes, it only introduces IP A-D per EVI/ES routes. If you are using the same ES for the stretched Broadcast Domain and the IP-VRFs (Ethernet aliasing for layer-2 and IP Aliasing for layer-3), MAC/IP Advertisement routes are advertised with the RD of the MAC-VRF of origin and so are Ethernet A-D per EVI routes for the ES. IP A-D per EVI routes are advertised with the IP-VRF RD. Hope it helps. Thanks. Jorge From: Dikshit, Saumya <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>> Date: Monday, March 4, 2024 at 6:40 PM To: Dikshit, Saumya <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>>, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Allu, Ramaprasad <ramprasad...@hpe.com<mailto:ramprasad...@hpe.com>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-sajassi-bess-evpn-ip-alias...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org> <draft-sajassi-bess-evpn-ip-alias...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org>> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>> Subject: RE: Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Just to elaborate further, Below might be the scenario where both MAC aliasing (MAC routes) and IP-aliasing (for /32 host routes) is needed in mixed deployment of Symmetric IRB fabric. Fabric may have mixed-bag of PEs, where-in, some of them have VRF-extended (/32 routes) while others have only subnet extended (MAC). Regards, Saumya. From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Dikshit, Saumya Sent: Tuesday, March 5, 2024 7:53 AM To: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia....@dmarc.ietf.org<mailto:jorge.rabadan=40nokia....@dmarc.ietf.org>>; Allu, Ramaprasad <ramprasad...@hpe.com<mailto:ramprasad...@hpe.com>>; bess@ietf.org<mailto:bess@ietf.org>; draft-sajassi-bess-evpn-ip-alias...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> Subject: Re: [bess] Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> Hi Jorge, Is this the same RD for IP VRF (uniquely defined for IP-AD per EVI route), that should be leveraged for host routes in Route Type-2 and Prefix Routes in Route Type-5 ? Is that the safe assumption (as per rfc9135/9134) ? In case yes, then If we have a unique RD for the IP-VRF, what RD should be used for the NLRI in the Route-Type-2 carrying MAC/IP for tied to MAC-VRF and IP-VRF ? Should it be MAC-VRF RD or IP-VRF RD. Regards, Saumya. From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jorge Rabadan (Nokia) Sent: Tuesday, March 5, 2024 1:57 AM To: Allu, Ramaprasad <ramprasad...@hpe.com<mailto:ramprasad...@hpe.com>>; bess@ietf.org<mailto:bess@ietf.org>; draft-sajassi-bess-evpn-ip-alias...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; Dikshit, Saumya <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>> Subject: Re: [bess] Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> Hi Ramaprasad, About this: “If MPLS label field is not considered for BGP route key, then BGP RIB will have only one route entry at any given point of time. That is, IP A-D per EVI route overwrites Ethernet AD per EVI and vice-versa if same RD is used for IP-VRF and MAC-VRF.” The Ethernet AD per EVI route and IP AD per EVI routes must use different RDs. It was sort of implicit, since the former one uses the RD of the MAC-VRF and the latter the RD of the IP-VRF, but we added this in rev 01 to make sure there is no misunderstanding: * The Route-Distinguisher is for the corresponding IP-VRF. The Route-Distinguisher allocated for the IP-VRF MUST be unique in the PE. Hope it helps. Thank you, Jorge From: Allu, Ramaprasad <ramprasad...@hpe.com<mailto:ramprasad...@hpe.com>> Date: Sunday, March 3, 2024 at 10:04 PM To: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-sajassi-bess-evpn-ip-alias...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org> <draft-sajassi-bess-evpn-ip-alias...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org>> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, Dikshit, Saumya <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>> Subject: Re: Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> You don't often get email from ramprasad...@hpe.com<mailto:ramprasad...@hpe.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Authors, Gentle reminder. Can you please take a look at it and respond to below query? Thanks, Ramaprasad From: Allu, Ramaprasad <ramprasad...@hpe.com<mailto:ramprasad...@hpe.com>> Date: Wednesday, 21 February 2024 at 5:40 PM To: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-sajassi-bess-evpn-ip-alias...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org> <draft-sajassi-bess-evpn-ip-alias...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-alias...@ietf.org>> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, Dikshit, Saumya <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>> Subject: Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> Hi Authors of draft https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html> I have a following query on the draft. Please help with your response. Context of section https://www.ietf.org/archive/id/draft-sajassi-bess-evpn-ip-aliasing-09.html#section-3.1<https://www.ietf.org/archive/id/draft-sajassi-bess-evpn-ip-aliasing-09.html#section-3.1>, In the section, it is mentioned that the construction of the IP A-D per EVI route is same as that of the Ethernet A-D per EVI route. The NLRI consists of the following, +---------------------------------------+ | Route Distinguisher (RD) (8 octets) | +---------------------------------------+ |Ethernet Segment Identifier (10 octets)| +---------------------------------------+ | Ethernet Tag ID (4 octets) | +---------------------------------------+ | MPLS Label (3 octets) | +---------------------------------------+ And as per https://www.rfc-editor.org/rfc/rfc7432.html#section-7.1<https://www.rfc-editor.org/rfc/rfc7432.html#section-7.1>, “ for the purpose of BGP route key processing, only the Ethernet Segment Identifier and the Ethernet Tag ID are considered to be part of the prefix in the NLRI. The MPLS Label field is to be treated as a route attribute as opposed to being part of the route” If MPLS label field is not considered for BGP route key, then BGP RIB will have only one route entry at any given point of time. That is, IP A-D per EVI route overwrites Ethernet AD per EVI and vice-versa if same RD is used for IP-VRF and MAC-VRF. Is there any reason for explicit mention of not using MPLS label field as key for BGP route or not carrying two labels one for Ethernet A-D per EVI and another for IP-AD per VRF? In this case, I see only MPLS Label (VNI in case of VXLAN) is the distinguisher if same RD is used for both IP-VRF and MAC-VRF. And to keep two separate routes in BGP RIB, we need to use MPLS label also one of the keys in addition to RD, ESI and ETAG fields. Or Carry both the labels and extended communities as part of single A-D per EVI route and store single route in the global BGP RIB. Please let me know what you think. Thanks, Ramaprasad
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
