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. 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? 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? cheers, Eduard ________________________________ From: Dhillon, Param Preet <[email protected]> Sent: Friday, July 17, 2026 18:36 To: Metz, Eduard <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: Shah, Himanshu <[email protected]>; [email protected] <[email protected]>; [email protected] <[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] <[email protected]> Sent: Wednesday, July 15, 2026 9:32 PM To: [email protected]; [email protected] Cc: Shah, Himanshu <[email protected]>; Dhillon, Param Preet <[email protected]>; [email protected]; [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<https://datatracker.ietf.org/doc/html/rfc9252> 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]
