Hi Luc, Kindly help close on my understanding or lack-of-it.
Regards, Saumya. From: Dikshit, Saumya <saumya.dikshit=40hpe....@dmarc.ietf.org> Sent: Wednesday, December 4, 2024 9:35 PM To: Luc André Burdet <laburdet.i...@gmail.com>; Dikshit, Saumya <saumya.diks...@hpe.com>; bess@ietf.org Cc: Devarajan, Venkatavaradhan <venkatavaradhan.devara...@hpe.com> Subject: RE: Query related to rfc7432, multihoming : https://datatracker.ietf.org/doc/html/rfc7432#section-14.1.2 Hi Luc, Thanks for your response. I did considered Aliasing before posting the question. In the context of my query, are you referring to the following statement in section 8.4.1. https://datatracker.ietf.org/doc/html/rfc7432#section-8.4.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7432*section-8.4.1__;Iw!!NpxR!iqfVrFsLnWWJHvsJl3BL46z8SuGxQYZvBYegH2-t9Yyk-wgH7UUnh2QYG-alXHLDPUkd_tZcRZXHGTam6JmWyRFsYj3Ct9m-Dg$> "This section describes the procedures used to construct the Ethernet A-D per EVPN instance (EVI) route, which is used for aliasing (as discussed above). Support of this route is OPTIONAL." What I infer from "OPTIONAL" is that the "Aliasing" feature is optional or it implies that with ONLY "A-D per ESI" route, aliasing can be realized. And that can be done by trusting the EVI mapping (VNI/Label) published with RT-2 ? Thought that does not ensures the association of EVI to ESI on the publishing PE. Regards, Saumya From: Luc André Burdet <laburdet.i...@gmail.com<mailto:laburdet.i...@gmail.com>> Sent: Wednesday, December 4, 2024 7:51 PM To: Dikshit, Saumya <saumya.dikshit=40hpe....@dmarc.ietf.org<mailto:saumya.dikshit=40hpe....@dmarc.ietf.org>>; bess@ietf.org<mailto:bess@ietf.org> Cc: Devarajan, Venkatavaradhan <venkatavaradhan.devara...@hpe.com<mailto:venkatavaradhan.devara...@hpe.com>> Subject: [bess] Re: Query related to rfc7432, multihoming : https://datatracker.ietf.org/doc/html/rfc7432#section-14.1.2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7432*section-14.1.2__;Iw!!NpxR!iqfVrFsLnWWJHvsJl3BL46z8SuGxQYZvBYegH2-t9Yyk-wgH7UUnh2QYG-alXHLDPUkd_tZcRZXHGTam6JmWyRFsYj1wsTlF4w$> Saumya, That's not what the section says, please read it together with section 8.4 (aliasing). Regards, Luc André Luc André Burdet | Cisco | laburdet.i...@gmail.com<mailto:laburdet.i...@gmail.com> | Tel: +1 613 254 4814 From: Dikshit, Saumya <saumya.dikshit=40hpe....@dmarc.ietf.org<mailto:saumya.dikshit=40hpe....@dmarc.ietf.org>> Date: Tuesday, December 3, 2024 at 22:06 To: Dikshit, Saumya <saumya.dikshit=40hpe....@dmarc.ietf.org<mailto:saumya.dikshit=40hpe....@dmarc.ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>> Cc: Devarajan, Venkatavaradhan <venkatavaradhan.devara...@hpe.com<mailto:venkatavaradhan.devara...@hpe.com>> Subject: [bess] Re: Query related to rfc7432, multihoming : https://datatracker.ietf.org/doc/html/rfc7432#section-14.1.2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7432*section-14.1.2__;Iw!!NpxR!nQ2KLFuPoNiMjeSLwZf4spUyHXL1x_sDI_irSP9X1TflXPXAoCHwSiI21dvlT3HwUGDYayqJxqZ5XyIVxqs7jG3r$> Any one from the rfc7432 authors, members, and/or chairs, if they can help on below. A response will surely help establish logic behind behavior observed across vendors. Regards, Saumya. From: Dikshit, Saumya <saumya.dikshit=40hpe....@dmarc.ietf.org<mailto:saumya.dikshit=40hpe....@dmarc.ietf.org>> Sent: Tuesday, December 3, 2024 5:52 PM To: bess@ietf.org<mailto:bess@ietf.org>; bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> Cc: Devarajan, Venkatavaradhan <venkatavaradhan.devara...@hpe.com<mailto:venkatavaradhan.devara...@hpe.com>> Subject: [bess] Query related to rfc7432, multihoming : https://datatracker.ietf.org/doc/html/rfc7432#section-14.1.2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7432*section-14.1.2__;Iw!!NpxR!nQ2KLFuPoNiMjeSLwZf4spUyHXL1x_sDI_irSP9X1TflXPXAoCHwSiI21dvlT3HwUGDYayqJxqZ5XyIVxqs7jG3r$> Hello All, I have question in context of multiple path reachability to a MAC route published with an ESI in an RT-2. Are both "Ethernet A-D per EVI route" and "Ethernet A-D per ES route" mandated to determine/establish reachability via more than one paths to the advertised MAC ? Or Just "Ethernet A-D per ES route" should suffice to determine the same ? The RFC seems to mandate both for determining more than one path.s The related excerpts from the rfc7432 https://datatracker.ietf.org/doc/html/rfc7432#section-14.1.2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7432*section-14.1.2__;Iw!!NpxR!mMMrO31ZsVA-Ltu3w56iNZRxb9pX92bqk6XiOshUPcitwhZ9LCeGgJKn5bJYYfVpUraEGr-gSaoZ3fx9K1eHungZa5WIuQrEUg$> "A remote PE that receives a MAC/IP Advertisement route with a non-reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address's EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet tag, if applicable) AND an Ethernet A-D per ES route for that ES." Regards, Saumya.
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
