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. 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? 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. 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? 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? 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? 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? ---------------------------------------------------------------------- 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. 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 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. 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)? 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? 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. 685 11.2. Informative References <minor> Unused references to be removed: 'RFC3209' 'RFC5440' 'RFC9086' 'RFC9087' 'RFC9552' <EoRv18> _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
