Hi Vishnu, Ok so we are clear on the accounting part now. But this is only one side of the coin - arguably less important one if compared with the other side of the same coin.
Traffic co-existence on a link in no 100% TE networks may result in BW contention on each egress interface during events of congestion. Same Adj-SID or different one is really orthogonal here. Last time I checked Adj-SIDs (just like MPLS labels) are used for forwarding not for QoS. And I have not seen anywhere in the draft a solid section discussing this deployment where there is unaccounted non TE traffic flowing via the same SR-MPLS network. Sure you can deal with this using QoS on each node, but with 3 EXP bits the network QoS design may already be using all of the available classes. Then deploying this TE scheme requires a complete network QoS treatment redesign ... Cheers, R. On Sat, Nov 7, 2026 at 4:31 PM Vishnu Pavan Beeram < [email protected]> wrote: > Hi Robert, > > My earlier response addressed the coexistence question Andrew raised: > SR-native and RSVP-SR traffic using the same Adj-SID. That was a statement > about scope, not a normative "MUST NOT" and not a change to the SR > architecture. If SR-native traffic is steered over the same Adj-SIDs that > RSVP-SR selects, the transit node can't separate the two. That's the RFC > 8426 coexistence problem. > > The draft places no restriction on how Adj-SIDs are used in SR. It only > selects Adj-SIDs for RSVP-SR tunnels. The scope statement describes the > deployment model the current version targets (no SR-native traffic on those > Adj-SIDs), not a constraint on SR deployments. > > A dedicated Adj-SID reserved for RSVP-TE bandwidth engineering will > address this concern, and it is consistent with your suggestion. With > different Adj-SIDs there is no coexistence issue. Traffic on the dedicated > Adj-SID is only the traffic admitted by RSVP-TE, so a per-SID counter > reflects RSVP-TE usage and the reservations stay accurate. > > Regards, > -Pavan > > On Sat, Nov 7, 2026 at 7:03 AM Robert Raszuk <[email protected]> wrote: > >> Hi Vishnu, >> >> You said: >> >> * the traffic on those Adj-SIDs is the traffic admitted by RSVP-TE, so a >> per-label counter reflects RSVP-TE usage, as with RFC 8577 TE link labels; >> * other traffic on the link is not reflected in RSVP-TE reservations. >> Prefix/node-SID shortest-path traffic uses different labels, and transient >> traffic such as TI-LFA repair paths is short-lived. This is accounted for >> as unengineered background traffic through reservable-bandwidth headroom, >> exactly as IGP and LDP traffic is today. >> >> So tell me how does this matter if per adj SID/uSID counter (not per >> label any more) reflects only admitted by ingress traffic ? Interface still >> needs QoS to differentiate TE from non TE traffic to prioritize the TE >> traffic over non TE traffic. >> >> And you said something quite important ... traffic which is not TE >> MUST NOT use adj SIDs. That seems a serious limitation and modification to >> the base SR architecture. I would perhaps go the other way and recommend to >> allocate a new adj SID solely to be used for BW accounted TE purposes. Just >> like you say here: "For deployments that want to run SR-native >> engineered traffic alongside, a natural extension is an IGP-advertised >> Adj-SID carrying a marker that it is reserved for RSVP-TE bandwidth >> engineering." >> >> Thx, >> R. >> >> >> >> On Sat, Nov 7, 2026 at 12:30 AM Vishnu Pavan Beeram < >> [email protected]> wrote: >> >>> Hi Andrew, all, >>> >>> Thank you for the review and the questions. They help clarify the scope >>> and the value of the draft. Responses below. >>> >>> >>> *1. Bandwidth management / RFC 8426* >>> Your analysis of the shared Adj-SID is correct for a deployment where >>> SR-native traffic is also steered over the same Adj-SIDs: the transit node >>> cannot separate the two, so measurement-based options such as RFC 8426 >>> Section 3.3 and Section 3.5 do not apply. This deserves explicit treatment >>> in the document, and we will add it. >>> >>> When we wrote RFC 8426, SR traffic was assumed to be unreserved, and >>> distributed bandwidth engineering was not envisioned as an SR function. The >>> RFC therefore treats SR load as something to be measured around RSVP-TE. >>> This document addresses the different case where distributed bandwidth >>> engineering is provided by RSVP-TE over an SR-MPLS data plane. >>> >>> The deployment model this version targets is the one RFC 8577 is >>> positioned for: SR-MPLS is the forwarding plane for RSVP-TE-signaled >>> tunnels, which provide distributed bandwidth engineering, and no SR-native >>> traffic is steered over the Adj-SIDs selected by this specification. In >>> that model: >>> >>> - the traffic on those Adj-SIDs is the traffic admitted by RSVP-TE, >>> so a per-label counter reflects RSVP-TE usage, as with RFC 8577 TE link >>> labels; >>> - other traffic on the link is not reflected in RSVP-TE >>> reservations. Prefix/node-SID shortest-path traffic uses different >>> labels, >>> and transient traffic such as TI-LFA repair paths is short-lived. This is >>> accounted for as unengineered background traffic through >>> reservable-bandwidth headroom, exactly as IGP and LDP traffic is today. >>> >>> In the next version we will state this scope explicitly in Section 1 and >>> Section 7, and say that where SR-native traffic is steered over the same >>> Adj-SIDs, the coexistence problem described in RFC 8426 arises and is not >>> addressed by this document. >>> >>> For deployments that want to run SR-native engineered traffic alongside, >>> a natural extension is an IGP-advertised Adj-SID carrying a marker that it >>> is reserved for RSVP-TE bandwidth engineering. That restores per-label >>> separation and would be defined in a separate IGP extension document, as we >>> already anticipate for the protection extension in Section 6.2. >>> >>> >>> *2. Section 1 benefits* >>> The motivation is operators who run SR-MPLS as their forwarding plane >>> and need distributed, bandwidth-aware TE. This lets them do so using the >>> Adj-SIDs that the IGP already advertises for each adjacency, without >>> introducing a separate label allocation scheme for RSVP-TE. We will sharpen >>> the benefits in a subsequent version: >>> >>> - Operational simplicity (single label allocation): The value is no >>> separate TE-label allocator for these tunnels, optional persistence via >>> the >>> Adj-SID P-flag, and a label stack identical to what an SR Policy headend >>> would impose. We will drop the wording about label exhaustion and >>> fragmentation, which are not the main driver on current platforms. >>> - IGP-native discovery: You are right that signaling still has to >>> complete and that the RRO remains authoritative (Section 4.1). We >>> will reword the benefit accordingly. Because the Adj-SIDs are in the >>> IGP-learned TED, the ingress's own path computation can determine >>> the label stack, check MSD/ETLD feasibility, identify any delegation hops >>> and, where needed, constrain Adj-SID selection with ERO Label sub-objects >>> before signaling, and can cross-check the RRO against the result. The >>> same >>> applies if an external path computation engine computes the path. >>> - Interoperability: We will reframe this benefit as reuse of >>> existing SR-MPLS capabilities and drop the data-plane-conflict wording. >>> The >>> tunnels use Adj-SIDs that nodes already allocate and advertise, and can >>> leverage SR OAM. >>> >>> These are clarifications to the text and scope of the document; none of >>> them changes the signaling procedures or protocol extensions in the draft. >>> We will handle them in the next version. >>> >>> Thanks again for the thorough review; it will make the document better. >>> >>> Regards, >>> -Pavan >>> >>> On Fri, Nov 6, 2026 at 12:24 PM Andrew Stone (Nokia) <andrew.stone= >>> [email protected]> wrote: >>> >>>> Hi all, authors, >>>> >>>> I have some concerns with some aspects of this draft, with comments and >>>> questions split into two categories. Any clarification appreciated. >>>> >>>> >>>> 1. Bandwidth management - coexistence problem >>>> >>>> Section 7: I don't follow how bandwidth admission control will >>>> function. Unless I'm missing something, the same Adj-SIDs will carry >>>> SR-native traffic pushed from any ingress, and that load never appears in >>>> RSVP-TE reservations, which only account for the signalled LSPs. RSVP-TE >>>> would therefore be reserving bandwidth on links whose actual load it cannot >>>> see or control. >>>> >>>> This looks to be the RSVP-TE and SR coexistence problem described in >>>> RFC 8426 but the shared label makes it harder. >>>> >>>> For example, the options in RFC 8426 Sections 3.3 and 3.5 depend on >>>> measuring SR utilization on each interface, but a transit node can no >>>> longer separate SR traffic from RSVP-TE traffic when both use the same >>>> Adj-SID. The SR traffic measured will contain none, some, or all of the >>>> RSVP-TE signalled traffic on that Adj-SID. Any RSVP-TE traffic counted as >>>> SR utilization reduces RSVP-TE's available bandwidth, creating a feedback >>>> loop. The RSVP-TE related bandwidth may be counted twice. >>>> >>>> The other RFC 8426 options don't help either: static partitioning (RFC >>>> 8426 Section 3.1) gives up shared bandwidth, and centralized management >>>> (RFC 8426 Section 3.2), removes a goal for this draft. >>>> >>>> Section 7 of this document does not seem to address RFC 8426 within >>>> context, which feels light given that Section 1 presents bandwidth >>>> admission control as what RSVP-TE continues to provide. In the context of >>>> bandwidth admission control, I don't see the gains this brings over RFC8577 >>>> or classic RSVP-TE. >>>> >>>> >>>> >>>> 2. Benefits listed in Section 1 >>>> >>>> These benefits don't seem significant to me: >>>> >>>> - Single label allocation: I don't think local label exhaustion is a >>>> risk, since this saves one label per TE link compared to RFC8577. What is >>>> the concern with allocation fragmentation? It also doesn't help general >>>> RSVP-TE scaling, since the per-LSP RSVP-TE state on each node is still >>>> there. >>>> >>>> - IGP-native discovery: Agreed, IGP flooding is useful, but Section 1 >>>> says the ingress doesn't need to wait for Resv processing, while Section >>>> 4.1 says it must still use the labels from the RRO, so it waits anyway. Is >>>> the faster pre-computation really that significant? >>>> >>>> - Interoperability: I agree the same labels serve all data-plane >>>> traffic in this proposal, but given the bandwidth concern in point 1, I'm >>>> not sure this is actually a benefit. For the comment about data-plane >>>> conflict: what data-plane conflict does this avoid, when it is all MPLS >>>> forwarding anyway? >>>> >>>> Thanks >>>> Andrew >>>> >>>> >>>> >>>> >>>> *From: *Tarek Saad <[email protected]> >>>> *Date: *Tuesday, November 3, 2026 at 1:06 PM >>>> *To: *[email protected] <[email protected]>; [email protected] < >>>> [email protected]>; [email protected] < >>>> [email protected]>; spring <[email protected]>; TEAS WG >>>> ([email protected]) <[email protected]> >>>> *Cc: *spring Chairs <[email protected]>; TEAS WG Chairs < >>>> [email protected]> >>>> *Subject: *[spring] Re: Call for adoption: >>>> draft-beeram-mpls-rsvp-sr-01 (Ends 2026-11-17) >>>> >>>> >>>> *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. >>>> >>>> >>>> Also adding TEAS WG for relevance to RSVP-TE protocol. >>>> >>>> Regards, >>>> >>>> *From: *Tarek Saad <[email protected]> >>>> *Date: *Tuesday, November 3, 2026 at 10:03 AM >>>> *To: *[email protected] <[email protected]>; [email protected] < >>>> [email protected]>; [email protected] < >>>> [email protected]>; spring <[email protected]> >>>> *Cc: *spring Chairs <[email protected]> >>>> *Subject: *Re: Call for adoption: draft-beeram-mpls-rsvp-sr-01 (Ends >>>> 2026-11-17) >>>> >>>> Adding the SPRING WG to this thread due to the document's relevance to >>>> Segment Routing. >>>> >>>> Regards, >>>> Tarek (as MPLS WG chair) >>>> >>>> *From: *Tarek Saad via Datatracker <[email protected]> >>>> *Date: *Sunday, November 1, 2026 at 8:35 PM >>>> *To: *[email protected] <[email protected]>; [email protected] < >>>> [email protected]>; [email protected] < >>>> [email protected]> >>>> *Subject: *Call for adoption: draft-beeram-mpls-rsvp-sr-01 (Ends >>>> 2026-11-17) >>>> >>>> This message starts a mpls WG Call for Adoption of: >>>> draft-beeram-mpls-rsvp-sr-01 >>>> >>>> This Working Group Call for Adoption ends on 2026-11-17 >>>> >>>> Abstract: >>>> RFC 8577 introduced the concept of signaling RSVP-TE tunnels on a >>>> shared MPLS forwarding plane using preinstalled "TE link labels". >>>> Those labels are functionally equivalent to Segment Routing (SR) >>>> Adjacency Segment Identifiers (Adj-SIDs) but are allocated and >>>> distributed solely via RSVP-TE signaling. >>>> >>>> This document extends RFC 8577 so that RSVP-TE tunnels can use >>>> Segment Routing over MPLS (SR-MPLS) Adj-SIDs, as specified in RFC >>>> 8402 and RFC 8660, in place of TE link labels. It restricts scope to >>>> Adj-SIDs attached to a single unidirectional adjacency and defines >>>> the signaling procedures and protocol extensions required to couple >>>> the RSVP-TE control plane with the SR-MPLS data plane. >>>> >>>> Please reply to this message and indicate whether or not you support >>>> adoption >>>> of this Internet-Draft by the mpls WG. Comments to explain your >>>> preference >>>> are greatly appreciated. Please reply to all recipients of this message >>>> and >>>> include this message in your response. >>>> >>>> Authors, and WG participants in general, are reminded of the >>>> Intellectual >>>> Property Rights (IPR) disclosure obligations described in BCP 79 [2]. >>>> Appropriate IPR disclosures required for full conformance with the >>>> provisions >>>> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. >>>> Sanctions available for application to violators of IETF IPR Policy can >>>> be >>>> found at [3]. >>>> >>>> Thank you. >>>> [1] https://datatracker.ietf.org/doc/bcp78/ >>>> [2] https://datatracker.ietf.org/doc/bcp79/ >>>> [3] https://datatracker.ietf.org/doc/rfc6701/ >>>> >>>> The IETF datatracker status page for this Internet-Draft is: >>>> https://datatracker.ietf.org/doc/draft-beeram-mpls-rsvp-sr/ >>>> >>>> There is also an HTMLized version available at: >>>> https://datatracker.ietf.org/doc/html/draft-beeram-mpls-rsvp-sr-01 >>>> >>>> A diff from the previous version is available at: >>>> https://author-tools.ietf.org/iddiff?url2=draft-beeram-mpls-rsvp-sr-01 >>>> >>> _______________________________________________ >>> mpls mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
