Hi Andrew, Let me provide my comments on your comments ...
- On the suggested title change: can the authors clarify what tunnel > construct is intended to be used at the headend? My understanding so far is > that this would be an RSVP-TE tunnel (a TE tunnel with RSVP-TE signaling), > not an SR Policy. This may be more of a TEAS or SPRING question than an > MPLS one, but it ties into the points below. > IMO what they are proposing does not touch data plane. So it will be SR Policy (with some level of BW accountability). I am saying it vaguely as that level depends on what is in the network. > - I understand the scope statement is not intended as a normative "MUST > NOT". However, the existing text says "a single set of Adj-SID labels > serves both SR-native and RSVP-TE-signaled traffic", and it would need to > change to say that a coexistence problem arises when SR-native traffic is > steered over the same Adj-SID. Since there is no defined solution yet for > coexistence in that scenario, the practical effect is the "MUST NOT" Robert > pointed to. > The fundamental point is that coexistence of TE and non TE traffic even if vanilla MPLS RSVP-TE has the very same issue. Dealing with congestion is required by QoS. > Architecturally, this feels off to me. Adj-SIDs were designed to be usable > by any SR headend, and restricting what traffic they can carry to > accommodate a new extension is closer to a redefinition than an extension. > Would this not break the existing understanding and interoperability of > Adj-SIDs? If there is already a recognized need for a dedicated Adj-SID to > distinguish this use case, it seems inevitable that Adj-SIDs will need to > be extended with a new type or behavior, in which case RSVP-TE tunnels > should use that dedicated Adj-SID rather than the existing Adj-SIDs. > Yes I think Pavan introduced some confusion here :) Sorry Pavan :) But his intentions were very good ... He wanted to include advertisements of traffic stats going via adj SIDs. I don't think this is really needed as those counters would still be an aggregate of all ingress SR paths traversing given adj-SID so after all not very useful. Instead you may get the same advertising real BW traversing Adj-SID minus reserved BW from the control plane counter. > - Related to redefinition, the headend construct, and the identical label > stack: I think it is fair for existing implementations to assume that SR > Adj-SIDs are used only by SR constructs such as SR Policies or SR-TE LSPs, > and that RSVP-TE tunnels use RSVP-TE allocated labels (or RFC 8577 TE link > labels). I'm concerned that having RSVP-TE signaled traffic use SR Adj-SIDs > breaks that existing interpretation, and with it existing implementation > behavior. > That is why I do believe those would be still SR Policies on ingress. This document is not proposing a new data plane construct. - On IGP-native discovery and pre-computation: how does a headend know > which SR-advertising nodes support RSVP-TE tunnels over SR Adj-SIDs? As > written, it only finds out from a PathErr after attempting to signal. > It would know per link state TE advertisements. I think the hope is that there is no more real MPLS RSVP-TE running there :) Thx, R. > > Thanks > Andrew > > > > *From: *Robert Raszuk <[email protected]> > *Date: *Saturday, November 7, 2026 at 12:20 PM > *To: *Barth, Colby <[email protected]> > *Cc: *Robert Raszuk <[email protected]>; Vishnu Pavan Beeram < > [email protected]>; Andrew Stone (Nokia) <[email protected]>; > [email protected] <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; > spring <[email protected]>; TEAS WG ([email protected]) <[email protected]>; spring > Chairs <[email protected]>; TEAS WG Chairs <[email protected]> > *Subject: *Re: [spring] Re: [mpls] 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. > > > Hi Colby, > > Glad you agree ! But pls trust me I am still meeting people who do try to > convince me that RSVP-TE reservations are done in the data plane and > packets (after admission control) into their TE-LSPs will magically never > compete for BW on any link with non TE traffic. We know this is not how it > works. > > Here with this draft you are entering a new TE model territory ... > partially same (control plane wise) and vastly different data plane wise > running on shared SR-MPLS or SRv6 underlay. > > I have no objections to adopting this document - perhaps as experimental > for the time being, but irrespective of how it will progress in IETF I > would encourage authors to add an Operational section discussing how to > deal with potential congestion caused by non-TE traffic. Irrespective if > that non-TE traffic is planned, unplanned (example transient loops), if it > is unicast or multicast etc ... > > Kind regards, > Robert > > > On Sat, Nov 7, 2026 at 6:03 PM Barth, Colby <jonathan.barth= > [email protected]> wrote: > > Robert, > > Your concerns, while valid, are no different than any other current > network deployment. We have certain tools available for operators to use > to handle potential congestion (strategic and tactical). What we propose > in this draft does not appreciably change them or prevent their use. > > In a 100% SR network where there are both native-SR and RSVP-SR forwarding > there already exist tools that can be used so-as to ensure the procedures > in RFC 8426 coexistence are still applicable and relevant. If one chooses > not to use those tools, then it is not applicable. > > As Pavan stated, we can certainly tighten up the wording in a few places > to clarify things and I do like the suggested title change. > > Thnx, > > -- Colby > > > *From: *Robert Raszuk <[email protected]> > *Date: *Saturday, November 7, 2026 at 10:44 AM > *To: *Vishnu Pavan Beeram <[email protected]> > *Cc: *Andrew Stone (Nokia) <[email protected]>; [email protected] < > [email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; > spring <[email protected]>; TEAS WG ([email protected]) <[email protected]>; spring > Chairs <[email protected]>; TEAS WG Chairs <[email protected]> > *Subject: *Re: [mpls] Re: Call for adoption: draft-beeram-mpls-rsvp-sr-01 > (Ends 2026-11-17) > > 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 > <https://urldefense.com/v3/__http://nok.it/ext__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wEcmnS9O$> > 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/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp78/__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wALTyg6y$> > [2] https://datatracker.ietf.org/doc/bcp79/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp79/__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wHFQxtTj$> > [3] https://datatracker.ietf.org/doc/rfc6701/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc6701/__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wMz8NU88$> > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-beeram-mpls-rsvp-sr/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-beeram-mpls-rsvp-sr/__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wM6I_BvH$> > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-beeram-mpls-rsvp-sr-01 > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-beeram-mpls-rsvp-sr-01__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wI89Fm_R$> > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-beeram-mpls-rsvp-sr-01 > <https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-beeram-mpls-rsvp-sr-01__;!!NpxR!iLHQaOYHnCMC_Y7zK1pjnlnHUMB7aH3LLq-ru5wV4ilCuCg-sfmUjwUFvv31THKIvqGbyxn8wL8KYrTa$> > > _______________________________________________ > 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] > >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
