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
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
