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? # 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)? # 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? [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 [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. 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. [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? [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. [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? [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. [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 ---------------------------------------------------------------------- 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? 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. 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 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 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? 146 * Resouce group: GV> idnit typo in s/resouce/resource/ 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 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. 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'? 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 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. 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) 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? 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. 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. 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? 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? 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? 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 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. 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. 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? 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 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? 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? 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. 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? 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. 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 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. 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. 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]
