Hi WG, I support the publication of this document. I think this is a reasonable method of network slicing implementation which could reuse the existing mechanism. Some editing comments for authors' reference.
Best Xuesong -- 1. Introduction ... This document describes a simplified mechanism to build SR based NRPs in those scenarios. The resource-aware segments can be used with this approach to provide resource guaranteed SR based NRPs, while the normal SR segments may also be used to provide SR based NRPs with shared network resources in the forwarding plane. The proposed approach is to use IS-IS Multi-Topology [RFC5120] with segment routing [RFC8667] to define the independent network topology of each NRP. The network resources and other TE attributes of an NRP can be advertised using IS-IS MT with the Traffic Engineering (TE) extensions defined in [RFC5305] and [RFC8570]. [Xuesong] I recommend to swap the position of these two sentences. It will be easier for readers' understanding: show what is the proposal firstly and then describe this could be used with resource-aware segments to provide resource guaranteed SR based NRPs 2. Advertisement of Topology Attribute for SR based NRP [Xuesong] It will be helpful if there is a summary about what Topology Attribute for SR based NRP is requested before introducing what could be reused in different existing RFCs. 3. Advertisement of Resource Attribute for SR based NRP In order to perform constraint based path computation for each NRP on the network controller or on the ingress nodes, the network resource attributes and other attributes associated with each NRP need to be advertised. [Xuesong] It could be considered to add some explanation for whether this is just for this proposal or also could be used to other resource guaranteed SR based NRPs 5. Scalability Considerations The mechanism described in this document is considered useful for network scenarios in which the required number of NRP is small, as no control protocol extension is required. For network scenarios where the number of required NRP is large, more scalable solution would be needed, which may require further protocol extensions and enhancements. [Xuesong] This is helpful to add some reference for example of more scalable solutions. > -----Original Message----- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem > Sent: Tuesday, January 9, 2024 6:50 AM > To: Lsr <lsr@ietf.org> > Subject: [Lsr] Working Group Last Call for "Applicability of IS-IS > Multi-Topology > (MT) for Segment Routing based Network Resource Partition (NRP)" - > draft-ietf-lsr-isis-sr-vtn-mt-06 > > This begins a two week LSR Working Group last call for the “Applicability of > IS-IS > Multi-Topology (MT) for Segment Routing based Network Resource Partition > (NRP)”. Please express your support or objection prior to Tuesday, January > 23rd, > 2024. > > Thanks, > Acee > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
