Hi Yubao, Can you please clarify what you mean by “another way to construct A-D per ES route has been in sight”?
From my POV using Type 1 RDs in all types of EVPN routes has multiple advantages – starting from the fact that it prevents RRs suppressing routes advertised by different PEs as part of the BGP path selection process. (The same actually applies for VPN-IP routes as well). IMHO and FWIW the operators should be discouraged from using other RD types even when it is not already prohibited. The bottom line: For the record I strongly oppose the proposal to relax the limitation on RDs in EVPN per ES Ethernet A- (Type 1) routes that exists from the -00 revision of the EVPN draft<https://datatracker.ietf.org/doc/html/draft-ietf-l2vpn-evpn-00#section-10.1.2>. Regards, Sasha From: [email protected] <[email protected]> Sent: Monday, May 15, 2023 3:56 PM To: Alexander Vainshtein <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [EXTERNAL] Re:[EXTERNAL] Re: [bess] Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b Hi Sasha, Thanks for your helpful notes. There is only one method to determine the RD of A-D per ES routes in the original years of RFC7432, but now there are at least two methods to determine the RD of A-D per ES routes. If it is the only reason why RFC7432 restrict the RD of A-D per ES route to type 1 RD, maybe it is a good chance for the restriction to be relaxed, because another way to construct A-D per ES route has been in sight. The original way can still be “RECOMMENDED”while other ways don't have to be forbidden. Maybe we can say that it is out of the scope of rfc7432bis (but not forbidden). If RFC7432 is not revised, 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/15siFALMfJ21KxF7rKwJX?h=a68vMaID3OjatSV90lFuCgmEvl0FrxLZtiXQdb2gyNY=&u=https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b%23section-3.1.2>, as you point out in another mail. But when RFC7432 is revised and rfc7432bis is still a draft, I think it will be better to take new scenarios into account. Especially on a RR node, according to RFC7432 or current rfc7432bis, a RR has to discard the A-D per ES routes which don't have a type 1 RD, but a RR is not responsible for selecting different RD for different set of route-targets at all. A RR has no difficulty to permit a A-D per ES route with other RD-type to pass through, while it has to discard it according to current rfc7432bis. Thanks, Yubao 原始邮件 发件人：AlexanderVainshtein 收件人：王玉保10045807; 抄送人：[email protected];[email protected];[email protected];[email protected]<mailto:[email protected];[email protected];[email protected];[email protected]>; 日 期 ：2023年05月15日 16:09 主 题 ：RE: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b Yubao, Please note that an EVPN PE that s attached to a MH ES, generally speaking, has to generate multiple per-ES A-D routes with the ESI of this MH ES in their NLRI. This happens because: · The set of these routes, in its entirety, must carry the Route Targets of all the EVI that are local attached to this MH ES · The number of Route Targets that can be caried in a single BGP Update message is limited. For BGP path selection process not to suppress some of these routes, these routes in this set must include different RDs in their NLRI. Since the set of these routes changes dynamically as new EVIs are attached to/detached from the MS EH in question, these RDs have to be auto-generated by the PE itself. This, in its turn requires usage of Type 1 RDs because these can be auto-generated by the PEs while remaining globally unique. The bottom line: Restriction of RDs used in the NLRI of per-ES Ethernet A-D routes cannot be relaxed. Hope this helps. Regards, Sasha From: BESS <[email protected]<mailto:[email protected]>> On Behalf Of [email protected]<mailto:[email protected]> Sent: Monday, May 15, 2023 10:40 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [EXTERNAL] Re: [bess] Discussion on rfc7432bis and draft-rabadan-bess-evpn-inter-domain-opt-b Hi Jorge, I think the description in draft-rabadan-bess-evpn-inter-domain-opt-b is OK. But I don't know why the RD of AD per ES route is limited to type 1 RD. That's why I talk about this together with rfc7432bis. If the scenario from draft-rabadan-bess-evpn-inter-domain-opt-b has shown out that it will be useful for the RD-type of AD per ES route being consistence with MAC-VRF RD, I think maybe it is not necessary for rfc7432bis to keep these restraints unchanged. I notice that you are also a co-author of rfc7432bis, how do you think from the viewpoint of rfc7432bis? Thanks, Yubao 原始邮件 发件人：JorgeRabadan(Nokia) 收件人：王玉保10045807;[email protected];[email protected]; 抄送人：[email protected]<mailto:[email protected]>; 日 期 ：2023年05月13日 00:23 主 题 ：Re: 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: 1. 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 2. 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
