Hi Gunter, Thanks for your comments and sorry for the late reply. I was taking both Ketan's and your comments into consideration together.
Please find responses inline with [Jie]: -----Original Message----- From: Gunter Van de Velde via Datatracker <[email protected]> Sent: Thursday, June 4, 2026 12:08 AM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Gunter Van de Velde's Discuss on draft-ietf-spring-resource-aware-segments-18: (with DISCUSS and COMMENT) Gunter Van de Velde has entered the following ballot position for draft-ietf-spring-resource-aware-segments-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-resource-aware-segments/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-spring-resource-aware-segments-18 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-spring-resource-aware-segments-18.txt # Many thanks RTGDIR review from Himanshu Shah and he Shepherd writeup from Alvaro Retana # The document reads reasonable well, many thanks for your efforts # I am a bit surprised this is going proposed standard track eventhough explained in the shepherd write-up. It is imposing semantics upon SIDs (sr-mpls or srv6). Adding semantics was already supported prior to this document, Do we need a PS for this information? [Jie] Adding semantics to SR SIDs is supported by the SR architecture, while the conventional SR mechanism does not specify the resource-specific treatment of SR SIDs. This document adds resource semantics to SR SIDs, and also specifies the behavior of resource-aware SIDs in packet forwarding. Thus it is considered that standard track is appropriate for this document. # This document desire to potentially use IGPs as a distributed technology to distribute resource aware properties. It has not been distributed to LSR WG for feedbacks (even if it would be early feedbacks)? [Jie] There were several accompanying IGP documents discussed in LSR WG, and one of them (draft-ietf-lsr-isis-sr-vtn-mt) has passed WG LC. # DISCUSS # ======= GV> [Generic DISCUSS] When reading this document, I got the impression that it describes a broader resource-aware architecture rather than simply defining new SID semantics. While the document starts by focusing on SID semantics, it increasingly presents concepts that appear to require coordinated behavior across nodes and links belonging to a resource group. As a result, the reader may come away with the impression that a more comprehensive solution architecture is being proposed than what is stated in the document's scope. Can the resource aware architectural description be split of from this document, so that the SPRING document only details the imposed semantics for resource-aware SIDs? [Jie] Resource-aware is not something new. With RSVP-TE, the labels of a TE LSP can be associated with specific subset of resources along a path. As described in the abstraction and introduction, this document focuses on introducing resource-semantic to SR segments under the SR architecture. A broad resource-aware architecture is out of the scope of this document. [DISCUSS#1] 97 Without needing to define new SID types, this document extends the SR 98 paradigm by associating SIDs with network resource attributes, so 99 that network resources can be allocated to one or a set of SIDs. GV> RFC8402 mentions in the abstract: " A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. " GV> When looking at this it appears that RFC8402 already has text in place to allow exactly what is described within the introduction of draft-ietf-spring-resource-aware-segments. I am wondering what was missing from the RFC8402 superset description? Does this not justify the document to become informational instead of proposed standard [Jie] As I mentioned the enhancement for resource-awareness is allowed by the SR architecture, while it is not covered in the specifications of existing SR segments or SRv6 behaviors. Thus the specifications in this document are necessary and we believe this document needs to be standard track. [DISCUSS#2] 146 * Resouce group: A group of network resources allocated on a set of 147 network nodes and links, which can be used for forwarding and 148 processing packets with one or multiple resource-aware SIDs. GV> This section appears to be underspecified. It assumes that the term resource is clearly defined, but I could not find such a definition in the document. Throughout the text, terms such as resource, resource group, and subset of resources are used in various contexts, making it difficult to understand their exact meaning and relationship. Clear and precise definitions are important, particularly if future protocol extensions are expected to be developed in other working groups to support this technology. Some issues with current texts: 1) Circularity (Undefined resource term). The definition of resource group relies on the term network resources. If resource is not formally defined elsewhere, readers cannot determine what belongs in a resource group. Is a resource bandwidth? Queue space? CPU? Memory? Buffers? A slice? A TE constraint? The definition does not say. [Jie] The meaning and typical types of resources are described in the introduction section. The terminology section was added during the directorate review. Will adding some description of "network resource" to resource group definition address this comment? 2) "Allocated on" is vague. Resources are typically associated with, available on, or provisioned on nodes and links. 3) Mixes infrastructure and function. The first half defines a resource group as a collection of resources. The second half adds a purpose ("used for forwarding and processing packets"). Definitions are usually clearer when they first define what something is, not what it is used for. 4) Potential ambiguity of scope. "Allocated on a set of network nodes and links" could imply the group spans multiple nodes and links, but it is unclear whether: every node/link must provide all resources, resources may differ per node/link, the group is an abstract identifier or an actual reservation. [Jie] Every node/link in a resource group must allocate some resources to the resource group. There is no restriction the resources are the same on each node. A resource group refers to a real set of resources. As discussed with Ketan, we are considering to replace "resource group" with NRP. [Jie] How about rephrasing the definition of resource group as below: A resource group is a subset of network resources (e.g. bandwidth, buffer, queue and processing resources) on each of a connected set of nodes and links. Now it looks almost the same as an NRP in RFC 9543. [DICUSS#3] 68 A resource-aware SID is considered local resource-aware if the 169 associated network resource is allocated on a specific node in the GV> What confuses me is that the text talks about 'network resource' but it is available on specific node. A specific node is not a network. Can the intent be explained more accurate? [Jie] A resource-aware local SID is associated with the set of local resources on a particular node in the resource group. As indicated by its name, it only has local significance and the associated resource is also local. . We can clarify this further in the text. [DISCUSS#4] 184 hybrid. When resource-aware segments are associated with a virtual 185 network, the control plane for distributing the resource-aware SIDs 186 and the associated topology or Flexible-Algorithm can be based on 187 [RFC4915], [RFC5120] and [RFC9350]. GV> When reading this then i see two aspects to discuss: 1) What is seen here as a 'virtual network'? can a formal description be added or referenced? 2) From reading the document prior text, it seems that the semantics of resource awareness is ortogonal to the distributed multi-topology and RFC4802 algorithms in general (e.g. not constrained to flex-algo only). For example what about strict-spf SIDs? These are not flex-algo. Why not state that resource awareness is fully orthogonal and request no additional extentions to existing technologies in this document because understanding of semantics is not propagated with SIDs? Such claim also removes any interop complications. [Jie] The "virtual network" here is a subset of network resources in a subset of the network topology, so it is a similar concept to NRP. We avoided using the term NRP as this document was already there when NRP is not defined yet. And according to the WG's conclusion on its adoption, was considered this document provides general concept and the SR for enhanced VPN drafts depends on this document. As RFC 9543 and 9732 has been published, maybe "virtual network" can be replaced by NRP and references to those RFCs can be added. [DISCUSS#5] 281 A group of resource-aware Adj-SID and resource-aware Prefix-SIDs can 282 be used to construct the SID lists of an SR Policy, which can be used 283 to steer the traffic to be forwarded along the explicit paths (either 284 strict or loose) and processed using the set of network resources 285 identified by the resource-aware SIDs. GV> This text assumes that the only semantic upon the SID is resource awareness. What if there is other additional future semantics added to a rfc8402 SID? This other semantics may collide with the resource semantics. What is the expected behavior in such situation? [Jie] Resource-awareness is not the only semantic of a SID. As described in the draft, resource-aware SIDs retain their original functionality, with the additional semantics of identifying the set of network resources available for the packet processing action. The resource semantic introduced in this draft does not conflict with the existing semantics. If other semantics will be introduced in future, the documents which specify such semantics are responsible for documenting the interaction and restriction on the combination of the new semantics with the existing ones. [DISCUSS#6] 327 algorithm. Then resource-aware SRv6 SIDs are allocated using the 328 resource-aware SRv6 Locator as the prefix, and the resource-aware 329 SRv6 SIDs are associated with a subset of the local resources which 330 belong to the resource group associated with the resource-aware SRv6 331 Locator. The set of network resources allocated to the resource- GV> There seems to be a disreptancy between the description of SR-MPLS and SRv6 dataplane regarding resources. In SR-MPLS resource-awareness is described as a subset of network resources while in SRv6 it is described as a subset of a resource group. I believe there should be a single description that defines resource awareness and how it correlates with resource groups. [Jie] There is no discrepancy between SR-MPLS SRv6 in general, the only difference is that for SRv6 SIDs which have a routable locator part, the SID is a global resource-aware SID, and can be used to determine the subset of resources on every network node and link in the resource group. I didn't find the use of "a subset of a resource group" in the draft. If there is any, we would fix them to align the description with that in the SR-MPLS section. [DISCUSS#7] 342 For one IGP link, multiple resource-aware SRv6 End.X SIDs can be 343 allocated to identify different sets of link resources allocated on 344 the link. SRv6 SIDs for other types of behaviors MAY also be GV> What is an IGP link? Do existing IGP technologies have to be extended to do this? if yes, please add clarification what is expected from the IGPs? Maybe add that in a split-off resource aware architectural document [Jie] An IGP link is a link on which an IGP adjacency is established and adj SIDs are allocated. Existing IGP mechanisms (e.g. multi-topology, Flex-Algo) can be used for the advertisement of multiple resource-aware SIDs on the same link. For scenarios where the required number of resource group is large, further optional extensions may be introduced to allow N to 1 mapping between resource groups and MT/Flex-Algos. The detailed IGP mechanisms and extensions belong to the IGP documents. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # COMMENTS # ======== 114 centralized controller. Other approaches are possible such as the 115 use of a control plane signaling protocol, but they are out of the 116 scope of this document. GV> Can an example of such protocols be added and how they have to be extended to support this? [Jie] Basically this sentence says the allocation of network resources could be done via local configuration, management plane or control plane. The control plane approach could be centralized controller based or distributed control plane based. For distributed control plane, this may be done via IGP, BGP, or a signaling protocol. The specific control protocol extensions are out of the scope. 118 An SR Policy that requires dedicated network resources can be 119 composed of a list of resource-aware SIDs. This can be useful for 120 service which requires dedicated network resources along the SR path. GV> The definition found earlier in this text "identifying or reserving a set of network resources." does not explicitly exclude that network resources are expected to be dedicated? It simply says reserving a set of resources. These resources may be shared or dedicated. Having an formal definition of what the "resources" means in this document will clarify for the implementors and operators. [Jie] Resource-aware SIDs can be associated with dedicated or shared subset of network resources, it does not exclude the case of dedicated resource. The definition and description of resource is in the introduction section, and can be added to the terminology section. 118 An SR Policy that requires dedicated network resources can be 119 composed of a list of resource-aware SIDs. This can be useful for GV> add reference to SR policy RFC9256 GV> I assume that it is the candidate path of an SR Policy that can be composed of the list of resource-aware SIDs [Jie] OK, will add a reference to RFC 9256, and clarifies that segment lists of SR Policy candidate paths can be composed of a list of resource-aware SIDs. 121 In addition, a subset of the network topology and resources 122 (considered as a "virtual network") can be represented by a group of 123 resource-aware SIDs that meet the connectivity and resource goals. GV> Can be "represented" by what network element? Is this the network controller? if that is correct, then maybe explicitly mention this, or explain which network element does this reprentation [Jie] What this sentence says is that a group of resource-aware SIDs can be used to represent a subset of the network topology and a subset of network resources on the nodes and links which are in the topology. The information of such a group of resource-aware SIDs can be maintained on both a network controller and the network nodes. 124 The resources associated with each segment of the virtual network can 125 be the same or different. GV> Here is written "the same or different" but it is the same or different compared to "what" exactly? [Jie] It should be "the amount of resources (e.g. bandwidth) associated with each segment of the virtual network can be the same or different". 146 * Resouce group: GV> idnit typo in s/resouce/resource/ [Jie] Thanks for catching the typo. 150 * Global resource-aware SID: A resource-aware segment identifier 151 which is associated with a resource group. 152 153 * Local resource-aware SID: A resource-aware segment identifier 154 which is associated with a specific set of resources on a network 155 node or link in the resource group. GV> I support Ketan's DISCUSS's to accuratly describe what these exactly are from SID allocation perspective [Jie] Please see my replies to Ketan: here global and local are used to specify the scope the resource-aware segments take effect. For global resource-aware SIDs, the SID is associated with the resources at the resource-group level. For local resource-aware SIDs, the SID is associated with a specific set of local resources in the resource group. It aligns with the global and local segment as defined in RFC 8402, with additional semantic about the scope of the associated resource. 165 SIDs. A resource-aware SID retains its original functionality, with 166 the additional semantics of identifying a set of network resources 167 allocated in the underlay network for the packet processing action. GV> Is the text talking about 'network resources' or is this 'resources' in general? And is intention of such SID not simply a semantic description how a network element must process the packet when receiving such a SID? I remain unconvinced that this needs to be standardised as proposed standard track document. [Jie] In this document the semantic of resource is limited to network resources, as specified in the introduction section: typical types of network resources include link bandwidth, buffers, and queues that are associated with class of service, scheduling weights or time cycles. It is also possible to associate SR SIDs with other types of resources (e.g., the processing and storage resources), while they are not specified in this document. The semantic is not only the instruction of packet processing, it is about which specific set of resource should be used for the processing. This is another dimension of the semantics of SR segments, and is considered an enhancement to the SR architecture. 168 A resource-aware SID is considered local resource-aware if the 169 associated network resource is allocated on a specific node in the GV> is this a single atomic local 'resource' or a group of local resources that are groups under the term 'network resource'? [Jie] Local means the resource is on a specific node which is in the resource group. A group of local resources may be associated with the same or different resource-aware SID, it depends on whether the group of resources need to be used together for one specific SID instruction. 170 network. A resource-aware SID is considered global resource-aware if 171 the associated network resources are allocated on multiple nodes in 172 the network. A local resource-aware SID may be allocated with a 173 dedicated set of network resources, while for global resource-aware 174 SIDs, a common set of network resources may be allocated to a group 175 of resource-aware SIDs. GV> What i find confusing here is that readers potential mix up two concepts: 1) global and local SIDs: depending on the scope of the SID (global or local significant) the 2) This text may use the wording global/local with different understanding from a resource architectural perspective. Can this be clarified to avoid readers to confused between these two understandings [Jie] As mentioned in one response above, the global and local resource-aware SIDs align with the global and local segments as defined in RFC 8402, with additional semantic about the scope of the associated resource. We will add some clarification text about this in next revision. 194 Segment (Node-SID). It also introduces BGP Peer Adjacency Segment 195 (PeerAdj SID). These types of SIDs can be reused to represent both 196 the topological instructions and the set of network resources 197 allocated for packet processing following the instructions. GV> Not sure this is fully accurate. My understanding is that these type of segments can have resource aware semantics. RFC4802 already allows semantics to be added to SIDs. I do not think the word 'reused' is correct. To me reused means that something is used for a purpose differently as originally intended, but the original rfc8402 purpose allows perfectly fine to add semantics to a SID. [Jie] OK, we will rephrase this by saying: Resource semantic can be added to these types of SIDs, so that they represent... 199 A resource-aware Adj-SID is a local resource-aware segment, it 200 represents a subset of the network resources (e.g., bandwidth, buffer 201 and queuing resources) on a given link, thus each resource-aware Adj- 202 SID is associated with a subset of the link's traffic engineering 203 (TE) capabilities and resources (known as TE attributes [RFC2702]). GV> Do yo want to constrain the understanding of link resources to the what is defined in the TE attribute? i suspect you envision something more if you want to take hardare, buffer and queuing resources etc. GV> also the following idnit: s/each resource-aware Adj-SID is associated with/each resource-aware Adj-SID can be associated with GV> How does this apply to L2 bundle SIDs (rfc8668)? (i support DISCUSS#4 from Ketan about this) [Jie] The link resources can be bandwidth, buffer and queueing resources, some of which can be specified by existing TE attributes. In our opinion it is better that this document gives general description of link resources, so that it can apply to TE link attributes which will be defined in future. [Jie] Thanks for catching the nits. [Jie] L2 bundle SIDs can be considered as resource-aware SIDs which are associated with a subset of the resources on an IGP link (adjacency). 205 For one IGP link, multiple resource-aware Adj-SIDs can be assigned, 206 each of which is associated with a subset of the link resources 207 allocated on the link. For one inter-domain link, multiple BGP GV> it is unclear if these resources are dedicated or could be shared? [Jie] Both cases are allowed, the point is a resource-aware SID is associated with a subset of the link resources, while different resource-aware SIDs may be associated with the same subset of the link resources. 217 Note this per-segment resource allocation complies with the SR 218 paradigm, which avoids introducing per-path state into the network. 219 Several approaches can be used to partition and reserve the link 220 resources, such as [FLEXE], logical sub-interfaces with reserved 221 bandwidth, dedicated queues, etc. The detailed mechanism of link 222 resource partitioning is out of scope of this document. GV> Can this section be removed? It was already stated before that RFC4802 SID types were used and overloaded with resource semantics. This section is implict as consequence. [Jie] The first sentence emphasizes that the introduction of resource-semantic to SIDs does not break the SR paradigm and per-path state for resource reservation is not introduced. I guess this is what you suggest to remove, and that is OK. [Jie] The second sentence gives examples of how resource-aware segments can be associated with link resources. There is no normative language in this text, while it helps people to understand how resource-aware segment can be realized. I'd suggest to keep this as is. 281 A group of resource-aware Adj-SID and resource-aware Prefix-SIDs can 282 be used to construct the SID lists of an SR Policy, which can be used GV> The term used by rfc9256 is Candidate Path and Segment List. [Jie] OK, will use the terms in RFC 9256 in this text. 287 In SR-MPLS packet forwarding, each resource-aware Adj-SID identifies 288 both the next-hop of the node and the set of resources used for 289 packet processing on the outgoing interface. Each resource-aware GV> if this Adj-SID is a L2 Adj-SID then it identifies more as only the next-hop. Can the summary used here be aligned with the rfc8402 and rfc8660? [Jie] To me the L2 Adj-SID can be considered as one special type of resource-aware Adj SID, which identifies both the IGP next-hop and a subset of the resources (the member link). I'd like to hear your opinion on whether L2 Adj-SID should be covered by resource-aware SID or not. 289 packet processing on the outgoing interface. Each resource-aware 290 Prefix-SID identifies the path to the node which the prefix is 291 attached to, and the resource group which consists of a set of 292 network resources to be used for packet forwarding on the transit 293 nodes along the path. The transit nodes use the resource-aware GV> rfc8402 Section3.1 defines this segment differently as paraphased in this section. Can these definitions be aligned? What if the path list has a sequence of prefix-SIDs associated to a single node but steered using different resources that are incompatible? [Jie] We will align with the description in RFC 8402. As for your example where multiple prefix-SIDs point to the same node but using different resources, that would be considered as a provisioning error, while in packet forwarding only the active prefix SID will be processed on the path before reaching the node originating the SID. 307 This mechanism requires the allocation of additional prefix-SIDs or 308 adj-SIDs to identify different sets of network resources. As the 309 number of resource groups increases, the number of SIDs would 310 increase accordingly, while it should be noted that there is still no 311 per-path state introduced into the network. GV> You could use instantiate SRLB based service SIDs if you do not want to burn too many prefix or adj SIDs? has this been considered? [Jie] Which type of service SID are you referring to? In my understanding that means additional SIDs need to be add to the SID list for indicating the set of resources on each hop, which would double the SID list size and is considered unacceptable. 315 [RFC8986] defines the SRv6 SID format (LOC:FUNCT:ARG) and the base 316 set of SRv6 behaviors bound to the SRv6 SIDs. When the LOC (Locator) 317 part of the SRv6 SIDs is routable, it leads to the node which 318 instantiates the SID. GV> What in the case of Locator summarisation? in that case the Locator leads to the A(S)BR [Jie] In this case the summarized locator can also be resource-aware and is used for the inter-domain SRv6 forwarding. In the network domain which the locator is assigned to, the locator of the destination node will be used for forwarding, taking the associated resources into consideration. 320 The approach of introducing resource-awareness to SRv6 is by firstly 321 making the SRv6 Locators resource-aware. For one SRv6 node, multiple GV> Is the locator itself really being made resource-aware? My understanding is that this draft imposes resource-aware semantics on the use of a locator, rather than on the locator itself. When examining the SID, there is no inherent indication that it is resource-aware; from that perspective, it remains a regular Prefix, Adjacency, or Service SID. The locator itself does not carry any awareness of the semantics being imposed, which raises the question of whether "resource-aware locator" is the most accurate characterization. [Jie] The locator needs to be resource-aware to make itself and its SIDs able to be used for resource aware packet forwarding and processing. The resource-awareness is not indicated in the format of the locator, the association between a locator and a resource group is distributed (in control plane or management plane) and obtained by network nodes in the resource group. 336 Similar to the approach used with resource-aware prefix-SIDs in SR- 337 MPLS, it is RECOMMENDED that a common set of network resources are 338 allocated by the network nodes and links participating in a topology 339 and/or algorithm, and this resource group is associated with a group 340 of resource-aware Locators of the same topology and/or algorithm. GV> Could the term "common set" be defined more precisely? It is not entirely clear whether it refers to the intended characteristics of the resources, a specific bandwidth guarantee, or some other shared property. As currently written, the term gives the impression that it may be describing a service, or perhaps a mechanism that provides service or packet-handling isolation. A more explicit definition would help readers understand the intended semantics. [Jie] This description is intentionally made general and only gives a general approach of allocating network resources and associating them with resource-aware SIDs. The purpose is to avoid creating separate resource groups for each prefix and avoid maintaining per-prefix resource states in the network. We will clarify the meaning of common set in next revision. 346 resources allocated by the node for executing the behavior. All 347 resource-aware SRv6 SIDs MUST use a resource-aware locator as its 348 prefix. GV> I'm not sure the distinction is always clear. For example, one could assume that the default locator uses the highest-quality forwarding resources, while a resource-aware SID is associated with best-effort services using reduced processing, queueing, or buffering resources. In that case, the default locator is also effectively associated with a set of resource semantics, even if those semantics are implicit. In addition, RFC 8986 defines an SRv6 SID as LOC:FUNCT:ARG. If a resource-aware SRv6 SID is constructed using a resource-aware locator, is it meaningful to separately describe the SID as resource-aware because it is resource aware due to the construct anyway? Could this phrase be simplified or removed to avoid ambiguity? [Jie] When resource-aware locator is introduced in a network, the default locator would be associated with a default subset of resources, which are shared among all services using the default locator. In other word, the default locator would also become resource-aware implicitly. [Jie] The description of the relationship between resource-aware segment and the resource-aware locator was to indicate that the resources associated with a resource-aware segment is inherited from its resource-aware locator. We believe this is useful for people to understand the introduction of resource-semantic to SRv6. 350 A group of resource-aware SRv6 SIDs can be used to construct the SID 351 lists of an SR Policy, which can be used to steer the traffic to be GV> the terminology used by RFC 9256 is candidate lists and segment lists [Jie] OK, will align the terminology with RFC 9256. 356 In SRv6 packet forwarding, the transit nodes use the resource-aware 357 Locator of the SRv6 SID carried in the destination IPv6 address field 358 to determine the next-hop of the packet, and the resource group which 359 consists of a set of network resources to be used for packet 360 forwarding along the path. On the segment endpoint nodes, the GV> how does a transit router know what resources to impose upon the transit packet? is that manual configuration? [Jie] As described in the draft, the set of local resources allocated on each node (including the transit nodes) can be provisioned via configuration, management plane or control plane. 365 This mechanism requires the allocation of additional SRv6 Locators 366 and SIDs to identify different set of network resources. As the 367 number of resource groups increases, the number of SRv6 Locators and 368 SIDs would increase accordingly, while it should be noted that there 369 is still no per-path state introduced into the network. GV> What is the impact when an A(S)BR deploys algorithm aware locator summarisation? [Jie] The aggregation of SRv6 locator can reduce the amount of locator information advertised across domains. Within a domain the amount of SRv6 locators would still increase. 382 be dynamically allocated by network nodes. The distributed control 383 plane is complementary to the centralized controller. When the 384 resource-aware SIDs are locally configured or dynamically allocated, 385 a distributed control plane can be used for the collection and 386 distribution of the resource-aware SIDs among network nodes, together 387 with the set of associated local network resource information. Then 388 some of the network nodes can distribute the collected information to 389 the centralized controller. The mechanisms as defined in 390 [RFC8665][RFC8667] [RFC9085] [RFC9352] [RFC9513] and [RFC9514] can be 391 reused with possible extensions to improve the efficiency and 392 scalability. GV> Currently there is no work in the LSR WG to propose extensions regarding resource aware SIDs. https://datatracker.ietf.org/wg/lsr/documents/. If existing LSR protocols are intended to be used for distributing semantics, then these protocols must be extended instead of "possible be extended". As mentioned in prior discuss this would need very accurate understanding and definition of the terms introduced within this document for resource aware segments. This work is outside scope of this document. It would avoid expectations when this is mentioned clearly in this document. [Jie] As mentioned above, there are proposals in LSR WG which either reuse or extend IGP protocols for applying resource-aware SIDs to NRPs: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-sr-vtn-mt-12 https://datatracker.ietf.org/doc/html/draft-zhu-lsr-isis-sr-vtn-flexalgo-08 There were also drafts which proposed to extend IGP protocols for N:1 mapping between NRP and MT/Algorithm. 401 The support for a resource group and the SR SIDs or SRv6 locators 402 information to associate packets to it MUST be aligned among the 403 network nodes in that resource group, so as to ensure that packets 404 are processed consistently within a resource group. This task can be GV> to process something consistently means that authors are thinking about overarching resource aware solution architecture. Is there such a architecture? [Jie] RFC 9543 can be seen as the architecture document you asked. In that context the resource group is realized as an NRP. Do you agree with Ketan's proposal of replacing "resource group" with "NRP"? 416 To indicate the support for a given resource group, a node needs to 417 advertise the identifier of the resource group, the associated 418 topology and algorithm, the resource-aware SIDs and the TE attributes 419 representing the resources allocated to the resource-aware SIDs in 420 the resource-group. The TE attributes of a resource group may be 421 used as constraints in path computation. GV> are all resource aware constraints covered by TE attributes? This section seems a requirement for IGPs and should better be in a seperate document so they can get correct attention from the relevant technology specialists. The solution requesting extensions in dynamic routing technologies has to be documented somewhere. This document focusses upon imposing resource aware semantics upon RFC8402 SIDs (sr-mpls or SRv6) and is not a solution description. [Jie] As mentioned earlier, some of the resource attributes can be represented using existing TE attributes, while additional attributes may be introduced in future. In that case the protocol extensions will be documented in separate drafts in the protocol WGs. We can make that more explicit in this section. 423 The controller is also responsible for the centralized computation 424 and optimization of the SR paths taking the topology, algorithm and 425 network resource constraints into consideration. The interaction GV> The use of the word 'also' seems premature. At the moment itthe controller is the only device responsible for resource aware decisions and computations. There is no distributed counterpart, hence the word 'also' seems not appropriate [Jie] The controller is the major entity responsible for resource-aware path computation and optimization. While distributed path computation taking the resource group and its resource information into consideration is also possible, e.g. it can be based on Flex-Algo. How about we add some description to clarify that both distributed and centralized path computation can be done. 431 the scope of this document. Distributed computation of resource- 432 aware SR paths is also possible, the topology, algorithm and/or 433 resource constraints need to be taken into consideration by network 434 nodes. The distributed control plane may be based on [RFC4915], 435 [RFC5120], [RFC9350] with necessary extensions. GV> Before going down the IGP Path for this proposal, there should be consensus about the architecture for network wide resource aware segment routing architecture. [Jie] This document is the architecture document for resource-aware segment routing. 4437 When a network node is instructed to associate a SID with specific 438 resources, its actions will depend on the operational mechanisms of 439 the network. In some cases the association between SIDs and 440 resources is configured on the individual network nodes, and the 441 control plane (e.g. IGP) is used to distribute the SID information 442 and the allocated resource information to the controller and the 443 ingress nodes for TE constraint-based path computation. In network 444 cases with SR and other TE mechanisms (such as RSVP-TE) co-existing 445 in the network, the IGP advertisements of available resources may 446 need to be updated to indicate that there has been a change to the 447 available resources resulting from the instantiation of a new 448 resource-aware SID, it is suggested such updates would be rate- 449 limited to avoid overloading the IGP system using suppression 450 mechanisms as described in [RFC8570] [RFC7471]. In still other cases 451 the association between SIDs and network resources is provisioned by 452 the central controller which is responsible for all TE management, 453 then the distributed control plane does not need to take any 454 additional action. GV> The IGP can currently not advertise resources or resource semantics without new extensions. To avoid wrong expectations to iplementors and readers please take hinting of detailed IGP extensions out-of-scope and add section in an informal appendix or into another solution document. [Jie] OK, we will add a sentence saying that the detailed IGP extensions are out of the scope of this document. Thanks again for the detailed review and valuable suggestions. Best regard, Jie Many thanks for this document, Kind Regards, Gunter Van de Velde Routing AD _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
