Hi Sasha, I can work on some clarifications in the text based on your feedback.
About whether the draft updates RFC9136, I’m hesitant to add it to the header, since this spec is obviously optional. Thanks. Jorge From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Date: Monday, April 3, 2023 at 5:51 AM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> Cc: bess@ietf.org <bess@ietf.org> Subject: RE: Question and comments on the EVPN IP Aliasing draft CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/ext for additional information. Hi Jorge, Lots of thanks for a prompt response. I have explained my position with regard to IP Aliasing for RT-5 in Interface-less IP-VRF-to-IP-VRF model in my previous email. I only can add that the neither the metadata of the IP Aliasing draft nor its text specify an update to RFC 9136. Regards, Sasha From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Sent: Monday, April 3, 2023 4:17 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org Cc: bess@ietf.org; Dmitry Valdman <dmitry.vald...@rbbn.com>; Nitsan Dolev <nitsan.do...@rbbn.com>; Michael Gorokhovsky <michael.gorokhov...@rbbn.com>; Ron Sdayoor <ron.sday...@rbbn.com>; Egon Haparnass <ehaparn...@rbbn.com>; Shell Nakash <shell.nak...@rbbn.com>; Marina Fizgeer <marina.fizg...@rbbn.com>; Orly Kariv <orly.ka...@rbbn.com>; Moti Morgenstern <moti.morgenst...@rbbn.com>; Rotem Cohen <rotem.co...@rbbn.com> Subject: [EXTERNAL] Re: Question and comments on the EVPN IP Aliasing draft Hi Sasha, Please see in-line with [jorge]. Thanks for the good questions/points. Jorge From: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Date: Sunday, March 26, 2023 at 11:16 PM To: draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org> <draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing.auth...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, Dmitry Valdman <dmitry.vald...@rbbn.com<mailto:dmitry.vald...@rbbn.com>>, Nitsan Dolev <nitsan.do...@rbbn.com<mailto:nitsan.do...@rbbn.com>>, Michael Gorokhovsky <michael.gorokhov...@rbbn.com<mailto:michael.gorokhov...@rbbn.com>>, Ron Sdayoor <ron.sday...@rbbn.com<mailto:ron.sday...@rbbn.com>>, Egon Haparnass <ehaparn...@rbbn.com<mailto:ehaparn...@rbbn.com>>, Shell Nakash <shell.nak...@rbbn.com<mailto:shell.nak...@rbbn.com>>, Marina Fizgeer <marina.fizg...@rbbn.com<mailto:marina.fizg...@rbbn.com>>, Orly Kariv <orly.ka...@rbbn.com<mailto:orly.ka...@rbbn.com>>, Moti Morgenstern <moti.morgenst...@rbbn.com<mailto:moti.morgenst...@rbbn.com>>, Rotem Cohen <rotem.co...@rbbn.com<mailto:rotem.co...@rbbn.com>> Subject: Question and comments on the EVPN IP Aliasing draft CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See https://clicktime.symantec.com/15t5Zsu7ZPvvXHNzW589B?h=3ceHKr8YVLM3UOko-NyIuMmvVO2HwRp1fi1RLBdLkNo=&u=http://nok.it/ext for additional information. Hi all, A few questions and comments on the EVPN IP Aliasing draft<https://clicktime.symantec.com/15t5ei6Q21cWwECv3dXHo?h=hLCOzcf5t8oR3LIGwDra1wBHCN4UcxyL3SN_N-D7vPY=&u=https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-06>: 1. Section 3 of the draft states that a PE that is attached to a MH ES shall advertise a set of IP per ES A-D routes, and Section 4.1 says that these routes shall be tagged with Export RTs of all IP-VRFs attached to this MH ES. The following is not mentioned: a. Should the ESI Label Extended Community be attached to these routes? My guess (FWIW) is that this is necessary, since this is the only way to let the remote PEs to know the MH mode of the MH ES in question. [jorge] correct b. Assuming an affirmative answer to the previous question, what should the ESI Label Extended Community attached to these routes carry in its Label field? My guess (FWIW) is that his field is not relevant and should be set to all zeroes. [jorge] yes. We can add a sentence to that respect. The label field SHOULD be set to 0 and MUST be ignored on reception. 2. Section 3 of the draft says that “a remote PE that receives an EVPN MAC/IP Advertisement route or an IP Prefix route with a non-reserved ESI and the RT of a particular IP-VRF SHOULD consider it reachable by every PE that has advertised an IP A-D per ES and IP A-D per EVI route for that ESI and IP-VRF”: a. Is the statement above applicable in the case of a MH ES in Single-Active MH Mode? My guess is that it is only applicable to MH Es in All-Active MH mode [jorge] same as in rfc7432bis, both modes i. If the answer to the previous question is negative, should the PE that receives an EVPN Type 2 route for an IP→MAC pair treat the IP address in this pair reachable only via he PE that has advertised this route and treating other PEs as “backup PEs” (similar to what is defined in Section 14.1.1 of RFC 7432<https://clicktime.symantec.com/15t5pNUxwEyhm7rm8kKb3?h=m9ESlNFEXlL5s4xyn-g6bmr0dWvx9li2FHAjKrC16c0=&u=https://www.rfc-editor.org/rfc/rfc7432.html%23section-14.1.1>)? [jorge] yes, assuming that PE the has received the AD routes. ii. The suggestion to attach the Layer 2 Attributes Extended Community to the per EVI IP A-D route in Section 3.1 of the draft seems to support my guesses above iii. I also think that if the MH ES in Single-Active mode is attached o more than 2 PEs, the Layer 2 Attributes Extended Community MUST be attached to EVPN per EVI IP A-D routes. [jorge] at the moment the addition of the L2 Attr ext community is a SHOULD. I have no problem in making it a MUST assuming my co-authors are ok. 3. I have to admit that I do not understand how IP Aliasing should work for EVPN IP Prefix routes in the Interface-less IP-VRF-to-IP-VRF scenario mentioned in Section 1.2 of he draft: a. Table 1 in RFC 9136<https://clicktime.symantec.com/15t5jYHgUdJ7MB2qbBvSR?h=3pwOHmxhy4P_vmCrfN-Bzd29Fz_PC1o-KGYWe1eTTfY=&u=https://datatracker.ietf.org/doc/html/rfc9136%23fields_overlay_table> states that a non-zero ESI value in the NLRI of IP Prefix routes is used as an Overlay index for recursive resolution, while that the Label value in such a NLRI is “Don’t Care”. b. At the same time, section 4.1.1 of this RFC states that the ESI field of the NLRI f these routes is set to all zeroes in the Interface-less IP-VRF-to-IP-VRF scenario while the Label field in the NRLI of these routes identifies the IP VRF in question. c. Can you please explain how can, in this scenario, the receiving PE associate received EVPN IP Prefix routes with a specific MH ES? [jorge] section 1.2 illustrates an RFC9136 interface-less model since there is no SBD. However, this draft modifies the interface-less model by using non-zero ESI on the IP Prefix routes and a recursive resolution to A-D per ES/EVI routes. Your timely feedback would be highly appreciated. Regards, and lots of hanks 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. 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
