Got your point. I am still of the opinion that SID (and for that matter any MPLS label) is implicitly ‘aware’ to whatever the user wants it to be aware of. Unless and until the procedures to on how that awareness is utilized in a meaningful way, it is not useful.
There is added responsibility for the SID, since it is ‘global’ MPLS label, one has to complete the associated work to justify the newly introduced ‘awareness’. IMHO. Thanks, Himanshu From: Dongjie (Jimmy) <[email protected]> Date: Thursday, October 9, 2025 at 11:09 AM To: Shah, Himanshu <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [**EXTERNAL**] RE: draft-ietf-spring-resource-aware-segments-15 early Rtgdir review Hi Himanshu, Thanks for your review and comments. Please see some replies inline: > -----Original Message----- > From: Himanshu Shah via Datatracker <[email protected]> > Sent: Thursday, October 9, 2025 4:58 PM > To: [email protected] > Cc: [email protected]; [email protected] > Subject: draft-ietf-spring-resource-aware-segments-15 early Rtgdir review > > Document: draft-ietf-spring-resource-aware-segments > Title: Introducing Resource Awareness to SR Segments > Reviewer: Himanshu Shah > Review result: Has Issues > > Following text can be improvised for better reading – “Although a centralized > controller can have a global view of network > state and can provision different services using different SR paths, > in data packet forwarding it still relies on the DiffServ QoS > mechanism [RFC2474] [RFC2475] to provide coarse-grained traffic > differentiation in the network.” > -- > Although a centralized controller can have a global view of network > state and can provision different services using different SR paths. > However, in data packet forwarding it still relies on the DiffServ QoS > mechanism [RFC2474] [RFC2475] to provide coarse-grained traffic > differentiation in the network. > -- We will revisit the text and improve the readability. > In general, my view of this draft is that it mainly proposes using multiple > SIDs, > each SID associated with some TE resource that can be taken advantage > mostly by controller for desired traffic engineering. So, it introduces the > ‘high level’ concept (similar to L-LSP) without any other associated details > (IGP extensions, link attributes, etc) that are necessary to make it work as a > solution. But since this work is approved by the working group, it should be > categorized, perhaps as informational rather than standardized track. It also > appears that since one vendor has implemented the solution, this draft is > more of an effort to legitimize that as standards track but without the > associated details, there may or may not ever be an interoperable solution > that IETF is chartered to provide. This document introduces the concept of resource-aware segments, which is an extension to the existing SR mechanism. Thus it is considered that standard track is more appropriate. The complete solution is built from the mechanisms defined in this draft together with the related control plane extension drafts, which belongs to the corresponding control protocol WGs. Regarding your concern about interoperability, according to the SR paradigm, the specific behavior associated with a segment only needs to be realized by the originator of the SID, thus interoperability can be achieved even if some nodes in the network does not understand the meaning of the resource-aware SIDs allocated by other nodes. That said, it would be beneficial to have all nodes in a network to support resource-aware segments, so as to achieve end-to-end resource guarantee with segment routing. Hope this helps. Best regards, Jie > >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
