Hi Alvaro, Thanks. This would be very helpful.
Jie, in the interest of converging quickly on the other important topic (global vs local), please check below with follow-up with KT2. 150 * Global resource-aware SID: A resource-aware segment identifier 151 which is associated with a resource group. 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. <discuss-3> I am having some difficulty in understanding the above definitions of global and local. Looking further in this document, I get the sense that Global is tied to allocations from the SRGB (for SR-MPLS) or GIB (for SRv6) while local is from the dynamic range or SRLB (for SR-MPLS) or LIB (for SRv6). Am I correct? In either case, can these definitions be made more precise by using SR terminologies? Please refer to RFC8402 and for SRv6 also perhaps RFC8986 and RFC9800. [Jie] 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. KT> I am not sure I understand this aspect. Are you saying there is a local resource group and a global resource group? Since NRP realizes the resource group, can you please try to explain this in terms of NRP? It may help me understand this better so I can suggest ways to clarify this. Jie-2> *No the resource group is always global *as it covers a group of network nodes and links, similar to NRP. The global and local resource-awareness is about the significance of a SID in term of resource-awareness. In the context of an NRP, a global resource-aware SID can be used to identify a subset of resources on every node and link in the NRP, while a local resource-aware SID can only identify a subset of resources on one node or link in the NRP. This aligns with the global and local segment terms. KT2> That clarification helps. Along with the use of NRP, this then reduces local/global to nothing more than existing SR concepts of global/local SIDs. For SR-MPLS, this means SRGB vs SRLB/dynamic labels. For SRv6, this means SIDs allocated from under routable vs non-routable locators. If this is correct, clarifying this in the document would help address that discussion point as well. Thanks, Ketan On Tue, Jun 23, 2026 at 10:02 PM Alvaro Retana <[email protected]> wrote: > Ketan: > > Hi! > > When the authors publish an update, we will explicitly confirm with the WG > that there are no objections. > > Thanks! > > Alvaro. > > On June 23, 2026 at 9:51:39 AM, Ketan Talaulikar ([email protected]) > wrote: > > Hi Jie, > > Thanks for your responses and clarifications. Leveraging the NRP construct > instead of a new 'resource group' would indeed clarify many discussion > points. Can the WG consider this? Can the shepherd/chairs help the authors > with this? > > It would be best to pause this discussion thread while we wait for that > point to conclude. > > Thanks, > Ketan > > > On Mon, Jun 22, 2026 at 9:16 PM Dongjie (Jimmy) <[email protected]> > wrote: > >> Hi Ketan, >> >> >> >> Thanks for your further comments and suggestions. Please see replies >> inline with Jie-2>: >> >> >> >> *From:* Ketan Talaulikar <[email protected]> >> *Sent:* Monday, June 15, 2026 4:51 PM >> *To:* Dongjie (Jimmy) <[email protected]> >> *Cc:* The IESG <[email protected]>; [email protected]; >> [email protected]; >> [email protected]; [email protected] >> *Subject:* Re: Ketan Talaulikar's Discuss on >> draft-ietf-spring-resource-aware-segments-18: (with DISCUSS and COMMENT) >> >> >> >> Hi Jie, >> >> >> >> Thanks for your responses. Please see my clarifications, suggestions and >> follow-up questions inline below. >> >> >> >> In my mind, the two high-level concepts to clarify and focus discussion >> on are: >> >> >> >> 1) Resource Groups vs NRP >> >> 2) Local vs Global Resource Groups >> >> >> >> Based on this, I believe, clarity will emerge on many of the discussion >> points and comments below. >> >> >> >> Jie-2> Agree these two concepts are related to several discussion points >> below, and it would be good to converge on them. >> >> >> >> >> >> On Mon, Jun 15, 2026 at 8:08 AM Dongjie (Jimmy) <[email protected]> >> wrote: >> >> Hi Ketan, >> >> Thanks for your review and sorry for the late response. Please find >> replies inline with [Jie]: >> >> -----Original Message----- >> From: Ketan Talaulikar via Datatracker <[email protected]> >> Sent: Tuesday, June 2, 2026 11:38 PM >> To: The IESG <[email protected]> >> Cc: [email protected]; >> [email protected]; >> [email protected]; [email protected] >> Subject: Ketan Talaulikar's Discuss on >> draft-ietf-spring-resource-aware-segments-18: (with DISCUSS and COMMENT) >> >> Ketan Talaulikar 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: >> ---------------------------------------------------------------------- >> >> Thanks to the authors and the WG for their work on this document. >> >> This review uses the idnits output of v18 of this document for the text >> snippets quoted. >> Please look for the tag <EoRv18> at the end to ensure you have received >> the full review. >> >> There are a few points that I would like to discuss with the authors and >> the WG. >> >> <discuss-1> Is the concept of Resource Group that is introduced by this >> document >> specified in any other document? How is a Resource Group different from >> an NRP? >> I remember this work started as "SR for enhanced VPNs" and then was split >> into >> this PS document and its companion informational document. In the >> meantime, TEAS >> WG published rfc9732 which is NRP-based Enhanced VPN. This makes me >> wonder if >> Resource Group is not the same as NRP. This then allows this document to >> ride >> on the base work done by TEAS WG. If not, then I am missing what is a >> Resource >> Group and pointer to some base TE work on it. >> >> [Jie] Yes you know the history of this document. At the beginning there >> was one single document: draft-dong-spring-sr-for-enhanced-vpn, in which >> the resource-aware segment was specified only in the enhanced-vpn/network >> slicing context. During its adoption, the WG's feedback was that >> resource-aware segment is generic enhancement to SR, and NRP is one of its >> use cases, hence they were split into two drafts. Thus resource group is >> considered a general concept, and NRP is one of its realization. The point >> is that resource-aware segment may be used for cases other than NRP/network >> slicing. >> >> >> >> KT> Yes, I remember the history. The enhanced VPN work evolved to >> leverage and build upon the NRP construct defined in the TEAS WG. This way >> NRP is not just about network slicing but also for other uses. And thanks >> for confirming that NRP is a realization of your resource group >> concept. Therefore, I strongly recommend using the NRP construct here and >> leveraging all that work as the base for this document. If this document >> introduces a new (generic) concept of "resource groups," it will need to be >> fully defined somewhere. Resource groups and things like bandwidth, >> topology, and constraints are TE concepts and will need foundational work >> done in the TEAS WG to build upon. That seems like a lot of work, whereas >> this work can progress much faster by using the NRP construct. This is much >> the same as how the enhanced VPN work progressed using NRP as the base. >> >> >> >> Jie-2> Thanks for your suggestion, we (the authors) agree that converging >> on the term NRP would make things simpler, although the resource group >> concept could be more generic than the current NRP definition. This >> document has taken a long path since the beginning of the enhanced >> VPN/network slicing work in IETF. If there is no objection, we can make >> that change to this draft. >> >> >> >> >> >> >> >> >> >> >> 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. >> 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. >> 124 The resources associated with each segment of the virtual >> network can >> 125 be the same or different. The proposed mechanism is >> applicable to SR >> >> <discuss-2> What is this "virtual network" in the context of >> resource-aware SIDs? >> From further reading (section 3), I get the impression that it is >> Multi-Topology >> or Flex-Algorithm, but I could be misinterpreting things. Since this >> seems to be >> critical for the semantics of resource-aware SIDs, can the document >> specify >> what it is exactly? >> >> [Jie] The "virtual network" here is a subset of the network topology >> together with a subset of network resources, so it is a similar concept to >> NRP. We avoided using the term NRP as it is 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 it can be replaced >> by NRP and references to those RFCs can be added. >> >> >> >> KT> Based on the previous follow-up, please consider using NRP as it >> would solve/address this point as well. >> >> >> >> Jie-2> This sounds reasonable to me. >> >> >> >> >> >> >> 150 * Global resource-aware SID: A resource-aware segment >> identifier >> 151 which is associated with a resource group. >> >> 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. >> >> <discuss-3> I am having some difficulty in understanding the above >> definitions >> of global and local. Looking further in this document, I get the sense >> that >> Global is tied to allocations from the SRGB (for SR-MPLS) or GIB (for >> SRv6) >> while local is from the dynamic range or SRLB (for SR-MPLS) or LIB (for >> SRv6). >> Am I correct? In either case, can these definitions be made more precise >> by >> using SR terminologies? Please refer to RFC8402 and for SRv6 also perhaps >> RFC8986 and RFC9800. >> >> [Jie] 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. >> >> >> >> KT> I am not sure I understand this aspect. Are you saying there is a >> local resource group and a global resource group? Since NRP realizes the >> resource group, can you please try to explain this in terms of NRP? It may >> help me understand this better so I can suggest ways to clarify this. >> >> >> >> Jie-2> No the resource group is always global as it covers a group of >> network nodes and links, similar to NRP. The global and local >> resource-awareness is about the significance of a SID in term of >> resource-awareness. In the context of an NRP, a global resource-aware SID >> can be used to identify a subset of resources on every node and link in the >> NRP, while a local resource-aware SID can only identify a subset of >> resources on one node or link in the NRP. This aligns with the global and >> local segment terms. >> >> >> >> >> >> We can add references to global and local segment in RFC 8402, with >> specification about the additional semantics. >> >> >> >> KT> Thanks. This would at least clarify one aspect. >> >> >> >> >> >> >> 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. >> >> <discuss-4> Taking example of logical sub-interfaces, are each of them L3 >> or L2? >> If they are L3 then I would expect each of them to have their own L3 >> Adj-SID >> and if they are L2 (then they would have L2 Adj-SID as in bundle >> members)? Can >> you clarify these aspects? The case of FlexE, these are separate channels >> on >> the underlying link and so the resource-aware SID seems like actually an >> indication to steer over a specific channel which is different from an >> Adj-SID >> of RFC8402 which is an instruction to steer over a L3 adjacency. My point >> is >> that the need resource-aware SIDs arises when we need separate resource >> context for a shared L3/L2 link. If there are other means to steer them >> over different sub-interfaces/channels or such, then the existing L3/L3 >> adj-SIDs seem sufficient. Am I missing something? >> >> [Jie] As specified in the beginning of this draft, resource-awareness can >> be introduced to existing SID types. Resource-awareness means the set of >> resources is guaranteed. An L3 or L2 Adj-SID may not be resource-aware if >> it shares the same set of network resources with other Adj-SIDs. And your >> point about the cases where resource-aware SIDs are needed is correct. >> Resource-aware SIDs can be realized by associating the SID with a subset of >> resources allocated on a shared L3/L2 link. >> >> >> >> KT> My point was that the text cites FlexE and logical sub-interfaces as >> ways to partition link resources. If those concepts are used for >> partitioning, we can assign L2/L3 Adj-SIDs to those partitions and nothing >> else is needed. However, if the single L3 interface is partitioned without >> these concepts, we need multiple Adj-SIDs and those SIDs must distinguish >> between the partitions on the shared link. Am I correct? If so, things can >> be simplified by removing these other references to FlexE and >> sub-interfaces. >> >> >> >> Jie-2> For L3 physical interfaces, each of which can be identified by an >> L3 Adj-SID, and the set of resources is determined. For L3 logical >> sub-interfaces, each of which can be identified by an L3 Adj-SID, while >> there may be no resource reserved for the sub-interface, and the resources >> of the physical interface may be shared by all its sub-interfaces. For L2 >> sub-interfaces, each of which can be identified by an L2 Adj-SID, while the >> resources may still be shared among all sub-interfaces. Thus it is >> considered that logical sub-interfaces which is associated with a subset of >> the link resources can be represented by resource-aware Adj-SIDs. FlexE is >> one of the technologies which can create logical sub-interfaces with a >> dedicated subset of link resources. And resource-aware SID does not mandate >> how resource is partitioned, it is just that the associated resource is a >> subset of the resource on the link. >> >> >> >> >> >> >> >> >> 251 The recommendation above helps to reduce the dynamics in >> per-prefix >> 252 resource allocation and adjustment, so that the network >> resource can >> 253 be allocated based on planning and does not have to rely on >> dynamic >> 254 signaling. When the set of nodes and links that participate >> in a >> 255 <topology, algorithm> tuple changes, the set of network >> resources >> 256 allocated on specific nodes and links may need to be >> adjusted. When >> >> <discuss-5> What does "need to be adjusted" mean here? Does it mean that >> say a >> particular link gets removed from a flex-Algo or MT topology then the >> provisioning >> of resources for a particular resource-group needs to be cleaned up? >> Similarly, >> if a link becomes part of a flex-Algo or MT topology, then the particular >> resource-group needs to be provisioned on that link? And all of this >> dynamically >> whenever the IGP topology changes? >> >> [Jie] Yes, the adjustment to the set of network resources (the resource >> group) is needed when there is change to the set of nodes and links in the >> <topology, algorithm> tuple of the resource group, so that the topology and >> resources are always aligned. >> >> >> >> KT> OK. Let us park this point until we get clarity on whether this is >> NRP or something else. For NRP, I think there was something about this >> covered in one of the TEAS documents. >> >> >> >> Jie-2> OK, then we can simplify things by changing the term to NRP. >> >> >> >> >> >> >> >> >> 313 3.2. SRv6 >> >> 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. >> >> 320 The approach of introducing resource-awareness to SRv6 is by >> firstly >> 321 making the SRv6 Locators resource-aware. For one SRv6 node, >> multiple >> 322 resource-aware SRv6 Locators can be assigned. A resource-aware >> 323 Locator is associated with a network topology and/or algorithm >> in >> 324 which the originating node participates, as well as a set of >> network >> 325 resources (e.g., bandwidth, buffer, and queueing resources) on >> each >> 326 node and the attached links participating in the same topology >> and/or >> 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- >> 332 aware SRv6 Locators and SRv6 SIDs are used for forwarding >> packets in >> 333 which the resource-aware SRv6 SIDs are encoded as the >> destination >> 334 IPv6 addresses. >> >> <discuss-6> I note the absence of any reference to global and local >> resource-aware >> SIDs in the SRv6 context. Is this because all resource-aware SIDs in SRv6 >> are >> allocated out of routable SRv6 Locators and therefore 'global'? What about >> non-routable SRv6 SID specified in RFC8986? Would be good to describe >> both in >> SRv6 context? >> >> [Jie] Yes the difference in SRv6 is that a routable resource-aware >> locator makes all the resource-aware SID under the locator prefix routable, >> and the locator part can be used by transit node to determine the >> associated resource group, which makes the SIDs global resource-aware. The >> non-routable SRv6 SID was not described in the current draft, some brief >> description about non-routable SRv6 SID as local resource-aware SIDs can be >> added. >> >> >> >> KT> Thanks, covering both global (routable) and local (non-routable) >> would be good. This is then the same as SRGB and SRLB/dynamic for SR-MPLS. >> So, the only remaining open item is the question that I asked in discuss-3. >> >> >> >> Jie-2> Good progress! >> >> >> >> >> >> >> 525 network. The scalability of the deployed solution may also >> depend on >> 526 the control plane solution that is available in >> implementations. If >> 527 no additional control plane features are available, the only >> choice >> 528 is to use different <topology, algorithm> tuples to >> distinguish the >> 529 resource-aware prefix-SIDs of the same prefix. This approach >> may be >> 530 suitable for small numbers of resource groups (less than ten >> or so), >> 531 but with more resource groups, this approach will require more >> 532 topologies or Flex-Algorithms, each of which requires separate >> 533 management and can stress operational systems. If a larger >> number of >> 534 resource groups are required, then operators should use the >> alternate >> 535 method to allocate additional prefix-SIDs or adj-SIDs to >> identify the >> 536 resource groups, but must utilize additional control plane >> mechanisms >> 537 (see Section 3) to distribute the association of SIDs to >> resource >> 538 groups. Operators need to be aware of the additional cost of >> 539 introducing resource-aware segments, and provide careful >> planning of >> 540 the resource groups, so that the resource-aware segments can >> meet the >> 541 service requirements without introducing unacceptable >> complexity to >> 542 network operation and management. >> >> <discuss-7> This document seems to expect that the control plane >> extensions for >> signaling of additional prefix/adj-SIDs that are tied to the resource >> group >> context and with many to one association with MT/Topology as alluded to in >> Section 3 is a given. However, I don't see any such control plane >> extensions >> (notably in the IGPs) being adopted by the LSR WG. So, can this document >> offer operators such a choice where IETF consensus has not been >> established >> for such control plane extensions? >> >> [Jie] The many to one mapping between resource group and >> Topology/Algorithm is one optional optimization and would require IGP >> extensions. There were IGP drafts proposed in LSR WG for such mechanisms. >> Some text can be added to the operational considerations section to clarify >> that if the approach with many to one mapping is considered, control plane >> extensions need to be done in relevant protocol WGs. >> >> >> >> KT> For the many to one mapping to existing MT/FlexAlgo topologies, will >> there be proposals now for both NRP and this new resource group notion? >> This seems redundant. Let's park this until we clarify the first discussion >> point. >> >> >> >> Jie-2> There is no plan to introduce separate protocol extensions for >> resource-group. As mentioned earlier resource-group is one general concept, >> while NRP is its realization. >> >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I also have some comments, questions and suggestions to share: >> >> 85 into the network. The base SR specifications do not have the >> 86 capability of identifying or reserving a set of network >> resources. >> 87 Although a centralized controller can have a global view of >> network >> 88 state and can provision different services using different SR >> paths, >> 89 in data packet forwarding it still relies on the DiffServ QoS >> 90 mechanism [RFC2474] [RFC2475] to provide coarse-grained traffic >> 91 differentiation in the network. While such a mechanism may be >> 92 sufficient for some types of services, others may require a >> set of >> 93 dedicated network resources to achieve resource isolation in >> the same >> 94 network. Also, the number of such services could be larger >> than the >> 95 number of traffic classes available with DiffServ QoS. >> >> <major> Can you please check for more suitable reference than those >> DiffServ QoS >> RFCs. In the SR context, this is about using the MPLS EXP or IPv6 TC >> where the >> marking is done at the edge and then routers in the core leverage those >> markings >> for giving the desired PHB. That said, there is also the option to do >> classification >> and giving the desired PHB at each hop that allows for mapping flows to >> specific >> resources and can support a larger set than DiffServ classes. Please >> consider if >> the document really needs to compare with DiffServ and if so, also >> include the >> other ways in which similar treatment can be achieved without the use of >> resource-aware SIDs. >> >> [Jie] These references were used because there was no explicit mentioning >> of QoS in SR-MPLS and SRv6 architecture RFCs. To my understanding the >> DiffServ QoS mechanism specified applies to SR data plane, the marking and >> PHB are still based on the MPLS traffic class or IPv6 DSCP field in the >> packet. As for the references, how about adding RFC 3270 (MPLS support for >> DiffServ) which also applies to SR-MPLS? This draft can simplify the >> description about DiffServ QoS. As for "other ways in which similar >> treatment can be achieved", do you mean the approach with additional data >> plane IDs (e.g. NRP selector ID) in the packet? >> >> >> >> KT> I meant classifying the packet to match the resource group (or NRP) >> based on whatever is in the packet (NRP Selector could be one, but it could >> be a 5-tuple, or based on label-range, etc.). The other way to look at it >> is that base SR specifications do not refer to these aspects because they >> are orthogonal to each other. This should not be interpreted as meaning >> that none of those concepts apply to SR. They do apply, and using >> DSCP/EXP/TOS are examples. >> >> >> >> Jie-2> OK I got your point. A resource group (or NRP) may also be >> identified by a combination of fields in the packet. We can relax the text >> and indicate that there can be other options in addition to using TC/DSCP >> or resource-aware SIDs. >> >> >> >> >> >> >> >> >> 146 * Resouce group: A group of network resources allocated on a >> set of >> >> <nit> s/Resouce/Resource ... but there are more spelling errors that can >> be >> easily fixed by running through a spell check >> >> [Jie] Thanks for catching the typo. We will fix all the nits in next >> revision. >> >> >> 168 A resource-aware SID is considered local resource-aware if the >> 169 associated network resource is allocated on a specific node in >> the >> 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. >> >> <major> This is where I get confused between global and local. This text >> seems >> to indicate that the global/local is not got anything to do with the SID >> but >> if it is configured on multiple or a single node. This is related to the >> discussion point #3. >> >> [Jie] It is about both the SID and the resources associated. We will >> rephrase the text to align with the definition of global and local >> resource-aware SIDs. >> >> >> 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]). >> >> <major> Is it local because it not allocated from the SRGB (though >> RFC8402 allows >> the allocation of adj-sid from SRGB even if no one seems to do that >> really)? >> >> [Jie] The essence is that it is associated with a local set of resources >> on a given link, so that its instruction and resource are defined at a >> local link level. >> >> >> >> KT> All resources are local on a given link. In my mind, the question is >> if it is referenced using a global or a local SID. Beyond this, I don't >> seem to understand what global and local resource groups are. >> >> >> >> Jie-2> The difference is that a local resource-aware SID is only >> associated with a local set of resource on one given node or link, which is >> in the resource group (or NRP), while a global resource-aware SID is >> associated with a set of resources on every node and link in the resource >> group (or NRP). >> >> >> >> >> >> >> >> 224 A resource-aware prefix-SID is a global resource-aware >> segment, it is >> 225 associated with a network topology and/or an algorithm which >> the >> 226 attached node participates in. In addition, a resource-aware >> prefix- >> >> <major> In other words, it global because it is allocated from the SRGB? >> >> [Jie] The essence is that it is associated with a set of resources on the >> network nodes and links in the resource group, so that its instruction and >> resources are defined at the resource group level. >> >> >> >> KT> So, is a global resource group about resources on a group of links >> and if the global resource group contains only one link then it becomes >> local? It seems complicated due to mixing the global/local Segment ID with >> this notion. Perhaps I will wait for the discussion on the NRP vs resource >> group to conclude first. >> >> >> >> Jie-2> As mentioned earlier, a resource group always covers a group link >> and nodes. The global and local significance are the characteristics of >> resource-aware SIDs. >> >> >> >> >> >> >> >> 266 prefix-SIDs of the same prefix. In another case, for one IGP >> prefix, >> 267 multiple resource-aware prefix-SIDs may be associated with the >> same >> 268 <topology, algorithm> tuple but different resource groups. >> Then an >> 269 additional control plane distinguisher needs to be introduced >> to >> 270 distinguish different resource-aware prefix-SIDs associated >> with the >> 271 same <topology, algorithm> but different resource groups. The >> first >> 272 approach is simpler and does not require extensions to control >> plane >> 273 protocols, while there can be scalability concerns when the >> number of >> 274 resource groups is large, as it would require a large number of >> 275 topologies or Flex-Algorithms. The second approach is more >> scalable, >> 276 while it requires additional extensions to the control plane >> 277 protocols. The exact control plane extensions are out of the >> scope >> 278 of this document, but see Section 7 for more discussion of the >> 279 scalability concerns. >> >> <major> So, this document is introducing a need for IGPs to now have a >> new concept >> called resource-group, that is not been fully and formally defined in this >> document? This is related to the discuss point #7. >> >> [Jie] The second approach is specified as an option if a larger number of >> resource group is needed, and the draft indicates that control plane >> extension would be needed if that option is chosen. The specific IGP >> extensions are out of the scope of this document, and any suitable >> mechanism can be used to realize the resource group concept. For example, >> there was proposals to realize this extension by introducing NRP specific >> extensions to IGPs. >> >> >> >> KT> Yes, I remember those NRP-specific extensions. Now, will we also need >> Resource Group-specific extensions? >> >> >> >> Jie-2> No, we don’t need to duplicate the extensions. >> >> >> >> Best regards, >> >> Jie >> >> >> >> Thanks, >> >> Ketan >> >> >> >> >> >> >> 685 11.2. Informative References >> >> <minor> Unused references to be removed: 'RFC3209' 'RFC5440' 'RFC9086' >> 'RFC9087' 'RFC9552' >> >> [Jie] Thanks, will remove the unused references from this document. >> >> Best regards, >> Jie >> >> >> <EoRv18> >> >> >>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
