Hi Sasha, About your suggestion on 7432bis, it’s kind of implicit, but I see no harm in adding a sentence.
Thanks. Jorge From: Alexander Vainshtein <[email protected]> Date: Sunday, May 28, 2023 at 1:26 AM To: Jorge Rabadan (Nokia) <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: RE: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b 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. Jorge, Lots of thanks for your response. Please see inline below. Regards, Sasha From: Jorge Rabadan (Nokia) <[email protected]> Sent: Tuesday, May 16, 2023 11:42 PM To: Alexander Vainshtein <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Re: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b Hi Sasha, However, neither 7432bis nor any other RFC or standard I am aware of says that the same IP address PE address of the PE MUST (or, at least, SHOULD) be used as the Administrator field of Type 1 RDs in per-ES A-D routes and Type 1 RDs assigned to MAC-VRFs. And this is obviously a precondition for using the solution suggested in Section 3.1.2. [jorge] the example in section 3.1.2 should be enough to clarify that the administrator part of the RD is the same. Let us know if that is not the case please. [[Sasha]] This was a comment about 7432bis. IMHO and FWIW it makes sense to clarify in this document that the Administrator part of Type 1 RDs used in all the EVPN routes advertised by a specific PE SHOULD be the same. What do you think? I also have some doubts regarding solution that is documented in Section 3.1.3 of the EVPN Inter-Domain Option B draft because: · Only implementations that do not use OPTIONAL per EVI EVPN A-D routes can benefit from this solution. In all other cases the per EVI Mass Withdrawal solution (documented in Section 3.1 of the draft) would work exactly as well · Such implementations could not benefit from aliasing and/or backup path EVPN mechanisms (which inherently rely on per EVI EVPN A-D routes) , thus severely compromising any benefits of the Mass Withdrawal mechanisms. [jorge] as discussed earlier, this is documenting viable existing solutions with their trade-offs, not mandating any particular one. Both things you point out are described in 3.1.3 section. If you don’t think so, please let us know. [[Sasha]] I have misspoken – my apologies. I should say that I have some doubts regarding the practical value of the solution documented in Section 3.1.3 of the EVPN Option-B draft. The solution itself is quite clear. Thanks! Jorge From: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Date: Sunday, May 14, 2023 at 10:31 AM To: Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b 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. Jorge, Yubao and all, A couple of comments. The current version of 7432bis<https://clicktime.symantec.com/15t5Zt9SEXGagfrZxwR9z?h=gGcib8S3C26TGyskaohEYo1_njxaFnOgTQKSs6yx1Ww=&u=https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-07> says that: · Per-ES EVPN A-D routes MUST use Type 1 RDs with the Administrator field comprising “an IP address of the PE (typically, the loopback address)” · Per-EVI EVPN A-D routes and EVPN MAC/IP Advertisement routes advertised by an EVPN Instance locally represented by a MAC-VRF use the RD that is assigned to this MAC-VRF, and usage of Type 1 RD with the Administrator field comprising “an IP address of the PE (typically, the loopback address)” is RECOMMENDED. RFC 2119 says that “the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course”. Therefore, I concur with Jorge that people who decide not to assign Type 1 RDs to MAC-VRFs should bear the consequences in mind, including non-applicability of the solution suggested in Section 3.1.2 of the EVPN Inter-Domain Option B draft<https://clicktime.symantec.com/15t5eiLih8xB6cgVWVpJc?h=op8TeX0Vsru5FkDFaRdxWuqgdODq44ba2I1LrFCkDsg=&u=https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b%23section-3.1.2>. However, neither 7432bis nor any other RFC or standard I am aware of says that the same IP address PE address of the PE MUST (or, at least, SHOULD) be used as the Administrator field of Type 1 RDs in per-ES A-D routes and Type 1 RDs assigned to MAC-VRFs. And this is obviously a precondition for using the solution suggested in Section 3.1.2. IMHO and FWIW adding a corresponding RECOMMENDATION to the 7432bis draft would be very much in place. I also have some doubts regarding solution that is documented in Section 3.1.3 of the EVPN Inter-Domain Option B draft because: · Only implementations that do not use OPTIONAL per EVI EVPN A-D routes can benefit from this solution. In all other cases the per EVI Mass Withdrawal solution (documented in Section 3.1 of the draft) would work exactly as well · Such implementations could not benefit from aliasing and/or backup path EVPN mechanisms (which inherently rely on per EVI EVPN A-D routes) , thus severely compromising any benefits of the Mass Withdrawal mechanisms. Hopefully these notes will be useful. Regards, Sasha Regards, Sasha From: BESS <[email protected]<mailto:[email protected]>> On Behalf Of Jorge Rabadan (Nokia) Sent: Friday, May 12, 2023 7:23 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b Hi Yubao, Thanks for reviewing the document. I don’t see any conflicting information: - On one hand the use of type 1 RD for MAC-VRF is RECOMMENDED in rfc7432bis, which means that normally people will have a type 1 RD in MAC-VRFs. If you don’t follow that strong recommendation for the MAC-VRF RD, you can’t use the documented solutions in 3.1.2 or 3.1.3 - On the other hand draft-rabadan-bess-evpn-inter-domain-opt-b is documenting some existing solutions, but not specifying or imposing any in particular.. So I don’t think there is conflicting information. But if you still think we should clarify that in draft-rabadan-bess-evpn-inter-domain-opt-b we’ll be happy to do it. Thanks. Jorge From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Friday, May 12, 2023 at 4:54 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b 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, It seems that draft-rabadan-bess-evpn-inter-domain-opt-b has conflicting discription with rfc7432 about the RD-type of AD per ES routes: Section 3.1.3 of draft-rabadan-bess-evpn-inter-domain-opt-b-00: "If that is the case, now the A-D per ES routes can use the route distinguisher assigned to the EVPN Instance (or VRF), which is the same one used by the routes type 2 or 5 for the EVI." Section 8.2.1 of rfc7432bis: "The Route Distinguisher MUST be a Type 1 RD [RFC4364]. The value field comprises an IP address of the PE (typically, the loopback address) followed by a number unique to the PE." The RD of EVI is not always a Type 1 RD but rfc7432 says that the RD of AD per ES route MUST be a Type1 RD. If it is not necessary to prevent other RD-types from being used in AD per ES routes, is it better for rfc7432bis to change the "MUST" to "MAY" ? I think such change is also compatible. Thanks, Yubao 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
