Hi Eduard, Pls find the response to your queries inline.
Thanks Param From: [email protected] <[email protected]> Sent: Friday, July 31, 2026 7:08 PM To: Dhillon, Param Preet <[email protected]>; [email protected]; [email protected] Cc: Shah, Himanshu <[email protected]>; [email protected]; [email protected] Subject: [**EXTERNAL**] Re: [BESS] New Draft: Dual MPLS and SRv6 Service Advertisement in the Absence of Transposition Hello Param, Thanks for the clarifications. RFC9252 indeed point to mechanism to control the advertisement of SRv6-based BGP service routes. If I understand correctly, the mechanism proposed in the new draft supports a per node granularity - at least in combination with SRv6/MPLS nodes that do not support the draft. These nodes will receive either MPLS or SRv6 information (for all services). If they would support the draft they receive both and can select SRv6 or MPLS path per service (at the receiving/ingress node). Is this correct? Maybe good to include some text on applicability to transition scenarios. PARAM>> Yes, it is correct. We can add something like this in the draft “Since RFC 9252 point to mechanism to control the advertisement/receipt of SRv6-based BGP service routes, then on originating/Egress side, user will need to enable the advertisement of both the paths(SRV6 and MPLS) for that RR BGP neighbor and on receiving/ingress side, user will need to enable the receiving of both the paths(SRV6 and MPLS) for RR BGP neighbor.” In the document some considerations on next-hop are included. For IPv4 nodes it is proposed to represent it as an IPv4 mapped IPv6 address (the text states SR-MPLS, but I assume it applies similarly to LDP/MPLS). Is this always backwards compatible ? Or should existing MPLS, IPv4 only nodes be adapted to support this? PARAM>> Yes, it applies similarly for LDP/MPLS. This new draft comes into picture only if Neighbor comes up with new Open capability which makes it backward compatible. But if IPv4 only nodes(Egress/Ingress) are sitting behind RRs, then there can be two scenarios as described in the draft +------------------------+ | +----+ | | | RR | | | +/--\+ | | / \ | | +----+ +----+ | | |PE-1| |PE-2| | | +----+ +----+ | | Egress Ingress | +------------------------+ Figure 1: Route Reflector Topology Example The following rules apply when reflecting routes between clients: 1. Both clients support the Dual Service Encoding Capability: The RR MUST reflect the route without modification. It MUST preserve the MPLS Label and SRv6 Service SID exactly as received. 2. Egress PE supports the capability; ingress PE does not: The RR MUST ensure compatibility with the ingress PE. It SHALL reflect the route in a form compliant with [RFC9252], which results in SRv6-only semantics. In practice, this means the MPLS Label field SHOULD be set to the Implicit NULL label. If the Ingress PE is IPV4 only neighbor, then RR will be changing the nexthop to IPv4 address and will advertise the update with MPLS label only. 3. Ingress PE supports the capability; egress PE does not: The route received by the RR is compliant with [RFC9252]. The RR MUST reflect the route without modifying the MPLS Label field or SRv6 Service SID. If the Egress PE is IPv4 only neighbor, then it will not originate/advertise the VPN service prefix with both MPLS label and SRV6 Sid in a single update, it will only send MPLS label with Nexthop set to IPv4 address. RR will reflect the same to Ingress PE. In all cases, the RR MUST NOT introduce ambiguity in the encoding and MUST preserve correct forwarding semantics. Is it intended that the at the receiving/ingress nodes the updates result in two RIB entries (SRv6 and MPLS), to which policy can be applied to select the preferred path to the egress? PARAM>> Yes, Ingress Node RIB table will have two paths(SRV6 and MPLS) for the same service prefix and User can apply local policy on Ingress Node to select the desired transport out of MPLS and SRV6. cheers, Eduard ________________________________ From: Dhillon, Param Preet <[email protected]<mailto:[email protected]>> Sent: Friday, July 17, 2026 18:36 To: Metz, Eduard <[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]>> Cc: Shah, Himanshu <[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: [BESS] New Draft: Dual MPLS and SRv6 Service Advertisement in the Absence of Transposition Hi Eduard, Thanks for reviewing the draft. Pls find the response to your queries inline. Pls let us know if you have any further questions. Regards Param From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Wednesday, July 15, 2026 9:32 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: Shah, Himanshu <[email protected]<mailto:[email protected]>>; Dhillon, Param Preet <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [**EXTERNAL**] Re: [BESS] New Draft: Dual MPLS and SRv6 Service Advertisement in the Absence of Transposition Hello Siva, and others, While the idea of enabling simultaneous advertisement of MPLS label and SRv6 SID is interesting, I'm a bit concerned about the role of the RR in this solution and its operation in a transition case. The concern is that modification of label information may lead to loss of connectivity. "If the RR does not support this capability, it MUST continue to operate according to standard BGP route reflection procedures." In this case, advertising peers/clients will not encode their updates according to this draft? Param>> Yes, If RR does not support this capability, then advertising/egress peer/client will not encode both MPLS service label and SRV6 SID into the update. Figure 1 distinguishes ingress / egress PE, maybe change this to advertising / receiving (relative to the RR)? Param>> As per Figure, Egress PE is the one originating/advertising the Service prefix and Ingress is the one receiving the prefix. Yes, if needed this can be changed it to: +------------------------+ | +----+ | | | RR | | | +/--\+ | | / \ | | +----+ +----+ | | |PE-1| |PE-2| | | +----+ +----+ | | Egress/ Ingress/ | | Advertising Receiving | +------------------------+ In a transition scenario, different types of PEs, in different stages of transition may be connected to the RR MPLS only => should receive the MPLS label * not support draft Param>> MPLS only case: · If Ingress/Receiving PE does not support the draft(it means capability is not negotiated with RR), then RR will send only MPLS label if knob(mentioned above) is set to advertise MPLS only. The RFC 9252 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc9252__;!!OSsGDw!OIP52WwOJCQuwyv6zExI0XCA1NzYE2MNzjFxZnoyHbVHbFcvEclJT5xsGdCzioticY3H5BwLQt_yP5LZzA$> specifies that implementations MUST provide a mechanism (a knob) to control the advertisement of SRv6-based BGP service routes. This is required on a per-neighbor and per-service basis to prevent SRv6 service routes from being sent to legacy MPLS-only PEs. SRv6/MPLS => should receive both ? * not supporting draft * supporting draft Param>> SRv6/MPLS case: * If Ingress/Receiving PE does not support the draft(it means capability is not negotiated with RR), then RR will send either MPLS label or SRV6 SID based on the knob mentioned in last comment. * If Ingress/Receiving PE support the draft(it means capability is negotiated with RR),then RR will send both MPLS and SRV6 SID if that knob is set for that peer to advertise both MPLS label and SRV6 SID. For this Draft RFC to work, the knob should be set for a BGP peer to advertise both MPLS label and SRV6 SID. SRv6 only => should receive SRv6 SID * not supporting draft * supporting draft Param>> SRV6 only case * If Ingress/Receiving PE does not support the draft(it means capability is not negotiated with RR), then RR will send only SRV6 SID if knob is set to advertise SRV6. * If Ingress/Receiving PE support the draft(it means capability is negotiated with RR), again then RR will send only SRV6 SID if knob is set to advertise SRV6. If the RR rewrites the MPLS label to Implicit NULL, SRv6 SID remains. A receiving RR client will no longer receive the MPLS label information, correct? Param>> Yes correct. Couldn't this be a problem for some of the SRv6/MPLS PEs that require both to be present? Param>> This is a case where New OPEN capability is not negotiated between RR and Receiving/Ingress PE. If RR has a Service Prefix with both MPLS label and SRV6 SID, then RR will be sending either MPLS service label or SRV6 SID along with implicit NULL label to receiving/Ingress PE based on the knob to be set to MPLS or SRV6 on RR for Receiving/ingress PE. If Receiving/Ingress PE require both MPLS service label and SRV6 SID for a given service prefix to be present, it will need to be negotiated with this New OPEN capability mentioned in draft. cheers, Eduard ________________________________ From: Sivabalan, Siva <[email protected]<mailto:[email protected]>> Sent: Monday, July 06, 2026 17:35 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: Shah, Himanshu <[email protected]<mailto:[email protected]>>; Dhillon, Param Preet <[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: [bess] [BESS] New Draft: Dual MPLS and SRv6 Service Advertisement in the Absence of Transposition You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important [aka.ms]<https://urldefense.com/v3/__https:/aka.ms/LearnAboutSenderIdentification__;!!OSsGDw!KcEjYfBRmzKzKK0PBOudgz9NC0mFVYkLWjhQHXm2nLBYhzjt23__vOz2lJKD1fNNe-Q0mFZOldnM5lMSPA$> Hi, We have submitted a new Internet-Draft: Title: Dual MPLS and SRv6 Service Advertisement in the Absence of Transposition Filename: draft-many-bess-rfc9252-dual-sid-00 URL: https://datatracker.ietf.org/doc/draft-many-bess-rfc9252-dual-sid/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-many-bess-rfc9252-dual-sid/__;!!OSsGDw!KcEjYfBRmzKzKK0PBOudgz9NC0mFVYkLWjhQHXm2nLBYhzjt23__vOz2lJKD1fNNe-Q0mFZOldlMsvrZYQ$> The draft proposes a backward-compatible extension to RFC 9252 allowing advertisement of both an MPLS Service Label and an SRv6 Service SID within a single route. Comments and feedback are welcome. Thanks, Authors
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
