Hi Sacha, Use of multiple RTs is actually explicit in the case of inter-as segmentation in RFC6514 itself when the C-multicast routes are propagated along the reverse path of the Inter-AS I-PMSI (Type-2) routes. Two RTs are used – one targeting at the ingress PE (used after the C-multicast route reaches the source AS), and one targeting at the immediate upstream ASBR (who re-advertised the active type-2 route) – used to direct the route towards the upstream ASBR. The second one changes ASBR-by-ASBR.
11.1.3. Constructing the Rest of the C-Multicast Route .. From the selected UMH route, the local PE extracts (a) the ASN of the upstream PE (as carried in the Source AS Extended Community of the route), and (b) the C-multicast Import RT of the VRF on the upstream PE (the value of this C-multicast Import RT is the value of the VRF Route Import Extended Community carried by the route). The Source AS field in the C-multicast route is set to that AS. The Route Target Extended Community of the C-multicast route is set to that C-multicast Import RT. .. If the local and the upstream PEs are in different ASes, then the local PE finds in its VRF an Inter-AS I-PMSI A-D route whose Source AS field carries the ASN of the upstream PE. The RD of the found Inter-AS I-PMSI A-D route is used as the RD of the advertised C-multicast route. The local PE constructs an IP-based Route Target Extended Community by placing the Next Hop of the found Inter-AS I- PMSI A-D route in the Global Administrator field of this Community, with the Local Administrator field of this Community set to 0; it then adds this Community to the Extended Communities attribute of the C-multicast route. (Note that this Route Target is the same as the ASBR Import RT of the ASBR identified by the Next Hop of the found Inter-AS I-PMSI A-D route.) 11.2. Propagating C-Multicast Routes by an ASBR … If the ASBR is the ASBR that originated the found Inter-AS I-PMSI A-D route, then before re-advertising the C-multicast route into IBGP, the ASBR removes from the route the Route Target that matches one of the ASBR Import RTs (auto-)configured on the ASBR. If the ASBR is not the ASBR that originated the found Inter-AS I-PMSI A-D route, then before re-advertising the C-multicast route, the ASBR modifies the Extended Communities attribute of the C-multicast route by replacing the Route Target of the route that matches one of the ASBR Import RTs (auto-)configured on the ASBR with a new Route Target constructed as follows. The new Route Target is an IP-based Route Target that has the Global Administrator field set to the Next Hop of the found Inter-AS I-PMSI A-D route, and Local Administrator field of this Community set to 0. Note that this newly constructed Route Target is the same as the ASBR Import RT of the ASBR identified by the Next Hop of the found Inter-AS I-PMSI A-D route. The rest of the Extended Communities attribute of the route SHOULD be passed unmodified. Jeffrey Juniper Business Use Only From: Alexander Vainshtein <[email protected]> Sent: Wednesday, August 20, 2025 10:11 AM To: Mankamana Mishra (mankamis) <[email protected]> Cc: BESS <[email protected]>; [email protected] Subject: RE: A question about Section 11.1.3 of draft-zzhang-bess-rfc6514bis [External Email. Be cautious of content] Mankamana, Lots of thanks for a prompt response. I fully agree with the marked. But C-multicast routes are supposed to be delivered to just one PE and one MVPN-enabled VRF in this PE… Regards, Sasha From: Mankamana Mishra (mankamis) <[email protected]<mailto:[email protected]>> Sent: Wednesday, August 20, 2025 4:52 PM To: Alexander Vainshtein <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: BESS <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] Re: A question about Section 11.1.3 of draft-zzhang-bess-rfc6514bis Hi Sasha, Having multiple RT in a BGP update is usual BGP procedures. I do not think we need to have anything explicit with respect to mVPN procedures. But I will let Jeffery comment if he thinks otherwise. Mankamana From: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Date: Wednesday, August 20, 2025 at 6:42 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: BESS <[email protected]<mailto:[email protected]>> Subject: A question about Section 11.1.3 of draft-zzhang-bess-rfc6514bis Jeffrey and Mankamana, I have a question regarding Section 11.3 of the 6514bis draft<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-zzhang-bess-rfc6514bis-00*section-11.1.3__;Iw!!NEt6yMaO-gk!DJdy343wGPXfz2Nk28fiZkMDHiYe3qebU2C_HdnD13alQ1Kq7A-y8OZadiEVVf4TDBLTpp2xp5OzDkjMKCXEPH-zFmM$>. The last but one para of this section says (the relevant text is highlighted): From the selected UMH route, the local PE extracts (a) the ASN of the upstream PE (as carried in the Source AS Extended Community of the route), and (b) the C-multicast Import RT of the VRF on the upstream PE (the value of this C-multicast Import RT is the value of the VRF Route Import Extended Community carried by the route). The Source AS field in the C-multicast route is set to that AS. The Route Target Extended Community of the C-multicast route is set to that C-multicast Import RT. I wonder if there are any situations in which more than one Route Target is attached to the C-multicast route? And if such a route is received, how should this situation be handled? Regards, and lots of thanks in advance, Sasha Disclaimer 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] To unsubscribe send an email to [email protected]
