Hi Andrew, > 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.
That is correct. The entire idea behind this draft is to provide an alternative to centralized management of network resources for RSVP-TE traffic class. And yes you are absolutely correct that this draft requires manual bw management at least between RSVP-TE and non RSVP-TE pools. Time will tell how practical this will turn out to be. Regards, Robert On Fri, Nov 6, 2026 at 9: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]
