Introducing Resource Awareness to SR Segments
draft-ietf-spring-resource-aware-segments-21

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

Also thanks for the discussion and the text updates to address the
concerns raised in my original ballot.

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

#update for v20 - thanks for the document updates to address the concerns raised
in my original ballot. This is now the updated ballot for v20 and I've dropped
all the discussion points and comments which have been addressed. I am retaining
the numbering of the discussion points from my original ballot for tracking.

#Note: I've retained the original idnits from v18 and then used the idnits from
v20, as needed, for the new text. Please look for the tag  at the end.

We are close to converging and concluding this review. I have provided suggestions
for your consideration to help us close this faster.


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.

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?

#updated below for v20:

On my earlier point about logical sub-interfaces and FlexE: where a link is
already partitioned into sub-interfaces or channels with their own
adjacencies, their existing Adj-SIDs already steer to them; resource-aware
Adj-SIDs are needed where one link's resources are shared. Perhaps:

  CURRENT
      Several approaches can be used to partition and reserve the link
      resources, such as [FLEXE], logical sub-interfaces with reserved
      bandwidth, dedicated queues, etc. The detailed mechanism of link
      resource partitioning is out of scope of this document.
  SUGGEST
      Resource-aware Adj-SIDs are associated with subsets of the
      resources of a shared link.  Where a link is instead partitioned
      into sub-interfaces or channels that form separate adjacencies,
      the Adj-SIDs of those adjacencies can be used.  The detailed
      mechanism of link resource partitioning is out of scope of this
      document.

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     tuple changes, the set of network resources
256   allocated on specific nodes and links may need to be adjusted.  When

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?

#updated below for v20:

Thank you — the new text answers what the adjustment is. Perhaps say what it
implies and leave the mechanism out of scope:

  CURRENT
      When the set of nodes and links that participate in an NRP change,
      the set of network resources allocated from specific nodes and
      links may need to be adjusted. When the set of network resources
      are locally configured on the network links, this means that the
      resources allocated to resource-aware Adj-SIDs on those links may
      have to be adjusted, and new TE attributes for the associated
      Adj-SIDs re-advertised.
  SUGGEST
      When the set of nodes and links that participate in an NRP
      changes, resources need to be allocated on the nodes and links
      that join the NRP, and can be released on those that leave it,
      including the resources associated with resource-aware Adj-SIDs.
      Until this is done, the resource guarantees of the NRP do not
      extend to the nodes and links concerned.  The mechanisms for this
      are outside the scope of this document.


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.

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?

#updated below for v20:

Thank you for adding the routed and non-routed SRv6 SID text in response to my
earlier question. Having seen it in place, I do not think non-routed SIDs fit
the model Section 3.2 builds. A resource-aware Locator is associated with an
NRP and transit nodes use it to determine that NRP, so it is advertised; and
all resource-aware SRv6 SIDs "MUST use a resource-aware locator as its
prefix". A non-routed SID is, by definition, one whose prefix is not
advertised:

So the two cannot both hold. One way to resolve it is to remove non-routed
SIDs from the resource-aware SRv6 description:

  CURRENT
      instantiates the SID, and the SID is called SRv6 routed SID.  An SRv6
      SID may be non-routable, which needs to be preceded by another routed
      SID in packet forwarding, and the SID is called SRv6 non-routed SID.
  SUGGEST
      instantiates the SID, and the SID is called SRv6 routed SID.

  CURRENT
      An SRv6 non-routed SID can be associated with a subset of the local
      resources (e.g., bandwidth, buffer and queuing resources) on a given
      node, which make it a local resource-aware segment.  An SRv6 routed
      SID can be associated with the set of network resources of an NRP,
      which makes it a global resource-aware segment.
  SUGGEST
      An SRv6 routed SID can be associated with the set of network
      resources of an NRP, which makes it a global resource-aware segment.


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  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.

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?

#updated below for v20:

Thank you for the text in Sections 4 and 7 placing the control-plane
extensions out of scope. Three things remain.

The second approach in Section 3.1 — several resource-aware Prefix-SIDs for
one prefix "associated with the same  tuple but different
NRPs", told apart by "an additional control plane distinguisher for NRP" —
would identify a Prefix-SID by an NRP as well as by its prefix, topology and
algorithm. That contradicts the document's own statement that "the mechanisms
to identify the forwarding path or network topology with SIDs as defined in
[RFC8402] do not change". It is also not needed: Section 3.2 separates NRPs in
SRv6 by per-NRP Locators, that is, per-NRP prefixes, and SR-MPLS can do the
same. Please consider one of:

  SUGGEST (a)
      For one IGP prefix, multiple resource-aware Prefix-SIDs can be
      allocated, each associated with a different
      tuple.  Alternatively, similar to the resource-aware SRv6 Locators
      described in Section 3.2, a node can advertise a separate prefix
      for each NRP, each with its own resource-aware Prefix-SID, within
      a shared .  See Section 7 for the scalability
      considerations of these options.

  SUGGEST (b)
      For one IGP prefix, multiple resource-aware Prefix-SIDs can be
      allocated, each associated with a different
      tuple; this can raise scalability concerns when the number of NRPs
      is large (see Section 7).  Associating several resource-aware
      Prefix-SIDs of one prefix with the same
      would need an additional NRP identifier for Prefix-SIDs, which is
      not specified by this document and may be explored in the future.

Section 7 still steers operators in the same direction as the old text.
Perhaps replace its analysis, quoted above from "Although with the SR
paradigm" to "done in relevant WGs.", with a pointer:

  SUGGEST
      As with SR in general, no per-path state is introduced in the
      network.  The scalability considerations of NRPs, including those
      of resource-aware SIDs, and possible optimizations are discussed
      in [I-D.ietf-teas-nrp-scalability].

And, to keep the control-plane material clearly out of scope and to keep
WG organizational aspects out of specifications:

s/The association between the SR SIDs and an NRP can be provisioned
using the management plane or a control plane./The association between
the SR SIDs and an NRP, and the provisioning of that association, are
outside the scope of this document.

s/The detailed control plane mechanisms belong to the documents in
the corresponding protocol working groups./The detailed control plane
mechanisms are outside the scope of this document.

s/The control plane mechanisms and extensions to advertise the
association between resource-aware SIDs and the corresponding NRP
resource attributes needs to be developed in the relevant protocol
WGs and are out of the scope of this document./The control plane
mechanisms and extensions to advertise the association between
resource-aware SIDs and the corresponding NRP resource attributes
are out of the scope of this document and would require separate
specification.

s/[I-D.ietf-lsr-isis-sr-vtn-mt] provides one approach for advertising
the association between SR SIDs and resource-specific TE
attributes./[I-D.ietf-lsr-isis-sr-vtn-mt] provides one approach for
advertising the association between SR SIDs and resource-specific TE
attributes using multi-topology (MT) identifiers.

with [I-D.ietf-teas-nrp-scalability] added as an informative reference.

[Ballot comment]

The comments are updated for v20 and the first one is related to the remaining
issues with the corresponding first comment in my original ballot.

96   available with DiffServ QoS.  Some mechanisms to identify the service
97   flows on each hop and map them to specific set of resources is
98   needed.  This may be done by classifying flows based on the
99   combination of multiple fields in the packet, while a more concise
100   and consistent approach would be preferred.

On my earlier comment about the comparison with DiffServ, perhaps
point to the TEAS work on mapping traffic to NRPs:

  CURRENT
      Some mechanisms to identify the service flows on each hop and map
      them to specific set of resources is needed. This may be done by
      classifying flows based on the combination of multiple fields in
      the packet, while a more concise and consistent approach would be
      preferred.
  SUGGEST
      Some mechanisms to identify the service flows on each hop and map
      them to a specific set of resources are needed.  This document
      describes resource-aware SIDs for this purpose;
      [I-D.ietf-teas-ns-ip-mpls] describes other approaches, including a
      dedicated NRP Selector in the packet that is independent of the
      forwarding identifiers and so does not require additional SIDs per
      NRP.

with [I-D.ietf-teas-ns-ip-mpls] added as an informative reference.

167   *  Local resource-aware segment: A resource-aware segment which is
168       only associated with a specific set of local resource on a network
169       node or link participating in an NRP.  It aligns with the
170       topological local segment as defined in [RFC8402], with additional
171       resource semantics.

Section 2 defines resource-aware, global and local resource-aware
segments, while the rest of the document mostly speaks of resource-aware SIDs.
Perhaps add, after the last definition in Section 2:

  NEW
      The SID of a resource-aware segment is referred to as a
      resource-aware SID, and likewise for global and local
      resource-aware SIDs.

228   In the scope of this document, the inter-domain link MUST be between
229   network domains managed by the same administrative entity and aligns
230   with the trust model described in [RFC8402].  The resource-aware Adj-

Line 228 attaches a BCP 14 keyword to a statement of this document's
scope. Perhaps keep the requirement and drop the scope clause:

s/In the scope of this document, the inter-domain link MUST be/Such an inter-domain link MUST be/

312   When the set of network resources allocated from the egress node also
313   needs to be determined, it is RECOMMENDED that Penultimate Hop
314   Popping (PHP) [RFC3031] be disabled, otherwise the inner service
315   label needs to be used to infer the set of resources to be used for
316   packet processing on the egress node of the SR path, which would
317   over-complicate the assignment of the service label and potentially
318   require multiple service labels to be assigned for the same service
319   to identify the different NRPs.  According to the control plane
320   mechanisms defined in [RFC8665] and [RFC8667], PHP can be disabled
321   for resource-aware SIDs only.

The sentence added in this revision — "According to the control plane
mechanisms defined in [RFC8665] and [RFC8667], PHP can be disabled for
resource-aware SIDs only" — relies on the per-Prefix-SID No-PHP flags in those
two documents, which an implementor needs in order to act on the RECOMMENDED
before it. Suggest making them normative references.

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-spring-resource-aware-segments-20

Thank you for the changes made in revision -20. I went through the updated draft and the diff against -19 and find that my observations are resolved.
Many thanks for this nice update.

Original blocking DISCUSS Ballot:
https://mailarchive.ietf.org/arch/msg/spring/49UfF7zsb85rlvx4LOTW3IMXpbA/

Final Ballot Resolution:
https://mailarchive.ietf.org/arch/msg/spring/XIeFb9UqOUTLZlc1IYZK5WmXrpE/

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-spring-resource-aware-segments-19

Thank you for the changes made in revision -19. I went through the updated draft and the diff against -18.

The document has improved considerably. In particular, replacing the previously undefined “resource group” and “virtual network” concepts with the NRP terminology helps a lot. The distinction between local and global resource-aware segments is also clearer, and the descriptions of the SR-MPLS and SRv6 cases are now better aligned. I consider my points #3 and #6 resolved. While #2, #4, and #7 are partial; #5 and the overarching scope concern is unresolved.

See full response at:
https://mailarchive.ietf.org/arch/msg/spring/cOfuj6fV9UahX3CPAb6p9RLYTvA/

Original blocking DISCUSS Ballot:
https://mailarchive.ietf.org/arch/msg/spring/49UfF7zsb85rlvx4LOTW3IMXpbA/

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-spring-resource-aware-segments-19

Thank you for the changes made in revision -19. I went through the updated draft and the diff against -18.

The document has improved considerably. In particular, replacing the previously undefined “resource group” and “virtual network” concepts with the NRP terminology helps a lot. The distinction between local and global resource-aware segments is also clearer, and the descriptions of the SR-MPLS and SRv6 cases are now better aligned. I consider my points #3 and #6 resolved. While #2, #4, and #7 are partial; #5 and the overarching scope concern is unresolved.

See full response at:
https://mailarchive.ietf.org/arch/msg/spring/cOfuj6fV9UahX3CPAb6p9RLYTvA/

[Ballot 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 implementors 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

[Ballot comment]
Hi Jie, Takuya, Yongqing, Fengwei, and Zhenqiang,

Thank you for the discussion and changes made in -19 [1]. These address almost all points raised in my previous ballot [2].

I think RFC9543 need to be listed as normative as both Global/Local resource-aware segment concepts depend on NRP, which is defined in that RFC. Please fix that.

CURRENT:
  *  Network Resource Partition (NRP): refer to the definition in
      [RFC9543].

  The following terms are introduced by this document.

  ...

  *  Global resource-aware segment: A resource-aware segment which is
      associated with the full set of the resources allocated to an NRP.
      ...
  *  Local resource-aware segment: A resource-aware segment which is
      only associated with a specific set of local resource on a network
      node or link participating in an NRP....

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-spring-resource-aware-segments-18&url2=draft-ietf-spring-resource-aware-segments-19&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/spring/io1SZQ2wW1I5U-tEOiYps0RsLDo/

[Ballot comment]
Thanks for the interesting document.

Thanks to Derrell P. for the SECDIR review.

I support Deb Cooley's comment about responding to the SECDIR suggestions.

[Ballot 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

[Ballot 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

[Ballot comment]
Thank you to Ines Robles for the GENART review.

idnits reports these issues with the references:
  == Unused Reference: 'RFC3209' is defined on line 731, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC5440' is defined on line 747, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC9086' is defined on line 800, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC9087' is defined on line 806, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC9552' is defined on line 832, but no explicit
    reference was found in the text

[Ballot comment]
Thanks to Derrell Piper for their (multiple) secdir reviews.  I strongly encourage the authors to consider their telechat review. (I'm confident this will happen since their previous comments were reviewed and responded to.)

General:  There are multiple cases of 'naked SHOULD (NOT)s', where the SHOULD is stated without stating the consequences of ignoring it, or the alternatives where ignoring it is acceptable.  I see 2 in Section 8 and 1 in Section 7.

Section 2, global vs local:  I support Ketan's discuss for these.  It wasn't clear to me what the difference was for global vs local resource-aware SID.

[Ballot discuss]
Note, in addition to my own DISCUSS, I support the two DISCUSS points that Ketan has on the control plane completeness question and SRv6 non-routable SID gap; this review does not duplicate those.

Section 3.1, paragraph 7
>    In SR-MPLS packet forwarding, each resource-aware Adj-SID identifies
>    both the next-hop of the node and the set of resources used for
>    packet processing on the outgoing interface.  Each resource-aware
>    Prefix-SID identifies the path to the node which the prefix is
>    attached to, and the resource group which consists of a set of
>    network resources to be used for packet forwarding on the transit
>    nodes along the path.  The transit nodes use the resource-aware
>    Prefix-SIDs to determine the next-hop of the packet and the set of
>    local resources in the identified resource group, then forward the
>    packet to the next-hop using the set of local resources.

This section and Section 3.2 make an equivalent statement when it comes
to "use the resource-aware Prefix SID to determine the next-hop of the
packet and the set of local resources in the identified group". Both
require that the transit node have prior knowledge of the resource
group associated with a given SID or Locator.

The document does not specify what a transit node MUST do when it
encounters a resource-aware SID for which no resource group association
has been configured locally. Section 7 addresses the case of
detected inconsistency across nodes, but does not cover a
transit node that was simply never provisioned with the resource
group binding.

If a transit node silently forwards a packet using best-effort
resources upon encountering an unrecognized resource-aware SID,
the resource isolation guarantee is violated with no indication
of failure — the exact outcome the mechanism is designed to
prevent. Without a required fallback behavior (e.g., MUST drop;
or MUST forward but MUST log/report), implementations will diverge
and silent SLA violations will be undetectable.

[Ballot comment]
Section 3.1, paragraph 2
>    For one IGP link, multiple resource-aware Adj-SIDs can be assigned,
>    each of which is associated with a subset of the link resources
>    allocated on the link.  For one inter-domain link, multiple BGP
>    PeerAdj SIDs may be assigned, each of which is associated with a
>    subset of the link resources allocated on the inter-domain link.  The
>    inter-domain link is between network domains managed by the same
>    administrative entity and aligns with the trust model described in
>    [RFC8402].  The resource-aware Adj-SIDs may be associated with a
>    specific network topology and/or algorithm, so that it is used only
>    for resource-aware SR paths computed within the topology and/or
>    algorithm.

The sentence "The inter-domain link is between network domains
managed by the same administrative entity." restricts resource-aware
BGP PeerAdj SIDs to single-operator deployments. If this restriction
is intentional, it should be stated as a normative constraint (MUST)
rather than a descriptive statement. If cross-domain scenarios
with different administrative entities are also intended to be in scope,
the security and trust requirements for those scenarios are not addressed.

Section 3.1, paragraph 7
>    When the set of network resources allocated on the egress node also
>    needs to be determined, it is RECOMMENDED that Penultimate Hop
>    Popping (PHP) [RFC3031] be disabled, otherwise the inner service
>    label needs to be used to infer the set of resources to be used for
>    packet processing on the egress node of the SR path, which would
>    over-complicate the assignment of the service label and potentially
>    require multiple service labels to be assigned for the same service
>    to identify the different resource groups.

This section recommends disabling PHP when egress resource assignment
is required. This recommendation lacks the operational context needed
for operators to safely act on it:

- It is unclear whether this applies per-SID (via explicit-null in
  prefix-SID advertisement) or per-node globally.
- The impact on non-resource-aware traffic transiting the same path is
  not discussed.
- No guidance is given for environments where PHP cannot be disabled
  due to interoperability constraints with legacy equipment.

The RECOMMENDED behavior should be accompanied by guidance sufficient to
evaluate its deployment implications.

Section 4, paragraph 4
>    When a network node is instructed to associate a SID with specific
>    resources, its actions will depend on the operational mechanisms of
>    the network.  In some cases the association between SIDs and
>    resources is configured on the individual network nodes, and the
>    control plane (e.g.  IGP) is used to distribute the SID information
>    and the allocated resource information to the controller and the
>    ingress nodes for TE constraint-based path computation.  In network
>    cases with SR and other TE mechanisms (such as RSVP-TE) co-existing
>    in the network, the IGP advertisements of available resources may
>    need to be updated to indicate that there has been a change to the
>    available resources resulting from the instantiation of a new
>    resource-aware SID, it is suggested such updates would be rate-
>    limited to avoid overloading the IGP system using suppression
>    mechanisms as described in [RFC8570] [RFC7471].  In still other cases
>    the association between SIDs and network resources is provisioned by
>    the central controller which is responsible for all TE management,
>    then the distributed control plane does not need to take any
>    additional action.

The sentence "it is suggested such updates would be rate-limited to
avoid overloading the IGP system using suppression mechanisms as
described in [RFC8570] [RFC7471]." This is a normative recommendation
but uses informal language. Given the explicit citations to
standards-track suppression specifications, this should use
RECOMMENDED (BCP 14 language).

Section 6.1, paragraph 0
>    Huawei Technologies reported the following implementations of the
>    resource-aware segments (Section 2).  The resource-aware segments are
>    used to build SR based Network Resource Partitions (NRPs) and
>    resource guaranteed SR Policies.

The document does not cite RFC 9732 at all. The draft introduces
"resource group" as its foundational concept; RFC 9732's NRP maps
directly to the same construct. The authors should either explain
the distinction between "resource group" (this document) and "NRP"
(RFC 9732), or use the term already established in RFC 9732 and
cite it accordingly. I also support Ketan's DISCUSS on this point.

Section 11.2, paragraph 0
> 11.2.  Informative References

The following entries appear in the informative reference list but are
not cited in the document body: [RFC3209], [RFC5440], [RFC9086], [RFC9087],
[RFC9552]. The shepherd write-up acknowledges this. These should be removed
before publication.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "traditionally"; alternatives might be "classic", "classical",
  "common", "conventional", "customary", "fixed", "habitual", "historic",
  "long-established", "popular", "prescribed", "regular", "rooted",
  "time-honored", "universal", "widely used", "widespread"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2, paragraph 2
>    *  Resouce group: A group of network resources allocated on a set of
>      network nodes and links, which can be used for forwarding and
>      processing packets with one or multiple resource-aware SIDs.

s/Resouce/Resource/

Section 7, paragraph 2
>    The consistency in the binding between resource-aware segments and
>    resource groups across all participating nodes in the network is
>    crucial for correct and consistent treatment to packets so as to meet
>    the resource guarantee and SLA requirements.  If this is not the
>    case, it may cause problems including service quality degradation or
>    packet drop.  Such issues could be detected and diagonosed using
>    performance measurement or packet trace mechanisms with the same
>    resource-aware segments as in the data packets used for forwarding.
>    Control plane mechanisms need to include consistency checks to allow
>    the configured state of resource allocation in network nodes to be
>    verified against the intended state.  If inconsistency in resource
>    binding is detected by a network node, by default the impacted
>    resource-aware SIDs MUST NOT be used for traffic forwarding, and an
>    error SHOULD be logged and reported.

s/diagonosed/diagnosed/

Section 8, paragraph 1
>    The allocaton of network resources, the association of resource-aware
>    SIDs with the allocated network resources, and the distribution of
>    information of the resource-aware SIDs together with the associated
>    TE attributes MUST be done via control or management protocol
>    channels with proper mechanisms for authentication, authorization,
>    integrity or replay-protection.  The specifications of the control or
>    managment plane protocols for resource-aware segments SHOULD specify
>    how these security properties are provided.  When the control plane
>    of resource-aware segments is based on Flex-Algo, the security
>    threats described in [RFC9350] need to be considered, as the hijack
>    of a Flex-Algo which associates with an resource group would
>    compromise not just path selection but also resource isolation
>    correctness.

s/allocaton/allocation/
s/managment/management/
s/an resource group/a resource group/

Section 6, paragraph 4
> Resource-aware segments require to introduce additional SR-MPLS SIDs or SRv6
>                                ^^^^^^^^^^^^
Did you mean "introducing"? Or maybe you should add a pronoun? In active voice,
"require" + "to" takes an object, usually a pronoun.

Section 7, paragraph 2
> ic, lower the priority and treat it in best effort, etc. 8. Security Consider
>                                    ^^^^^^^
A determiner may be missing.

Section 7, paragraph 2
> of a Flex-Algo which associates with an resource group would compromise not
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

[Ballot 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  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.

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

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.

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.

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     tuple changes, the set of network resources
256   allocated on specific nodes and links may need to be adjusted.  When

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.

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  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.

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?

[Ballot 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.

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

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.

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]).

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-

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     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  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.

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

Unused references to be removed: 'RFC3209' 'RFC5440' 'RFC9086' 'RFC9087' 'RFC9552'

[Ballot discuss]
Hi Jie, Takuya, Yongqing, Fengwei, and Zhenqiang,

Thank you for the effort put into this document. I found it well-written with good discussion (especially) the control plane requirements and ops considerations. Not sure how the control plane MUSTs out there can be used for compliance (e.g., as claimed in the implem section),  but I'm not commenting on that.

I have one DISCUSS point that I think can be easily fixed by simply providing the options:

# Out of place

CURRENT:
  It is RECOMMENDED that a
  common set of network resources be allocated by the network nodes and
  links participating in the topology and/or algorithm, and this common
  set of network resources is associated with a group of resource-aware
  Prefix-SIDs. 

and

  Similar to the approach used with resource-aware prefix-SIDs in SR-
  MPLS, it is RECOMMENDED that a common set of network resources are
  allocated by the network nodes and links participating in a topology
  and/or algorithm, and this resource group is associated with a group
  of resource-aware Locators of the same topology and/or algorithm.

The behavior depends on the service, local deployment guidance, SLAs, etc. and other considerations that are local to the operator.

Although this may seem common sense, I don’t think this document has to include a deployment recommendation about resource-aware SIDs.

[Ballot comment]
# The document would be better if it includes one or few examples to illustrate the use (preferably with global/local resource-aware SIDs).

# Please delete “proposed” (several occurrences)

# Base specs

CURRENT:
  The base SR specifications do not have the
  capability of identifying or reserving a set of network resources.

Can we add references for these “base SR specifications”?

# Can we please cite some examples for the “other” part of the sentence?

CURRENT:
  While such a mechanism may be
  sufficient for some types of services, others may require a set of
  dedicated network resources to achieve resource isolation in the same
  network. 

An easy example to cite is Network Slicing (RFC9543).

# Extend a paradigm: What does that mean?!

OLD:
  Without needing to define new SID types, this document extends the SR
  paradigm by

NEW:
  Without needing to define new SID types, this document extends the SR
  mechanism by

I would delete all “paradigm” thing from the document.

# Local CoS Identifier

CURRENT:
  Typical types of network resources
  include link bandwidth, buffers, and queues that are associated with
  class of service, scheduling weights or time cycles, and it is also
  possible to associate SR SIDs with other types of resources (e.g.,
  the processing and storage resources).

## If these are associated with a CoS, why the identification of a CoS wouldn’t be sufficient to infer those locally?

# nits

OLD:
  This can be useful for
  service which requires dedicated network resources along the SR path.


NEW:
  This can be useful for
  services that require dedicated network resources along an SR path.

# NRPs

CURRENT:
  [I-D.ietf-teas-nrp-yang] provides
  some guidance on the provisioning of resource-aware segments for
  network resource partitions (NRPs). 

## Readers may not familiar with NRPs and would not easily see the link between the discussion and NRP mention. I suggest to add some text to explain why NRPs are cited here.

## Please add a reference for NRPs. RFC9543 would be OK.

# …concretely

CURRENT:
  A resource group SHOULD NOT be used until it
  is fully provisioned. 

How this concretely done/implemented? Is this about waiting for a controller action or this is a local state that is controlled at the node level?

# There might be multiple controllers

Please s/The centralized controller/A centralized controller

Cheers,
Med

Request for IETF Last Call review by OPSDIR Completed: Has Issues. Reviewer: Fung Lim. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2026-04-07):

From: The IESG
To: IETF-Announce
CC: aretana.ietf@gmail.com, draft-ietf-spring-resource-aware-segments@ietf.org, james.n.guichard@futurewei.com, spring-chairs@ietf.org, spring@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Introducing Resource Awareness to SR Segments) to Proposed Standard


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'Introducing Resource
Awareness to SR Segments'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-04-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a mechanism to allocate network resources to
  one or a set of Segment Routing Identifiers (SIDs).  Such SIDs are
  referred to as resource-aware SIDs.  The resource-aware SIDs retain
  their original forwarding semantics, with the additional semantics to
  identify the set of network resources available for the packet
  processing and forwarding action.  The proposed mechanism is
  applicable to both segment routing with MPLS data plane (SR-MPLS) and
  segment routing with IPv6 data plane (SRv6).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-resource-aware-segments/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4114/
  https://datatracker.ietf.org/ipr/4890/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong
  concurrence of a few individuals, with others being silent, or did
  it reach broad agreement?

  The agreement was as broad as it gets in spring.  In general, a good
  number of participants have expressed their opinion during the life
  of the document.

2. Was there controversy about particular points, or were there
  decisions where the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme
  discontent? If so, please summarize the areas of conflict in
  separate email messages to the responsible Area Director. (It should
  be in a separate email because this questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the
  contents of the document? Have a significant number of potential
  implementers indicated plans to implement? Are any existing
  implementations reported somewhere, either in the document itself (as
  [RFC 7942][3] recommends) or elsewhere (where)?

  The document contains an "Implementation Status" section which documents
  one implementation.


## Additional Reviews

5. Do the contents of this document closely interact with technologies
  in other IETF working groups or external organizations, and would it
  therefore benefit from their review? Have those reviews occurred? If
  yes, describe which reviews took place.

  The mpls and srv6ops WGs have been cc'd on the WGLC.

  The teas and 6man WG Chairs have been given a head-up about the WGLC and
  asked to forward the information to their WGs if they believe it necessary.
  Neither did.

  No external organizations needed.

6. Describe how the document meets any required formal expert review
  criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
  type reviews.

  N/A

7. If the document contains a YANG module, has the final version of the
  module been checked with any of the [recommended validation
  tools][4] for syntax and formatting validation? If there are any
  resulting errors or warnings, what is the justification for not
  fixing them at this time? Does the YANG module comply with the
  Network Management Datastore Architecture (NMDA) as specified in
  [RFC 8342][5]?

  N/A

8. Describe reviews and automated checks performed to validate sections
  of the final version of the document written in a formal language,
  such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion
  that this document is needed, clearly written, complete, correctly
  designed, and ready to be handed off to the responsible Area
  Director?

  It is the opinion of the Shepherd that this document is ready.  The
  contents are clear and the work is needed.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been
    identified and addressed? For which does this still need to happen
    in subsequent reviews?

    The list has been reviewed.  No specific issues have been identified.

11. What type of RFC publication is being requested on the IETF stream
    ([Best Current Practice][12], [Proposed Standard, Internet
    Standard][13], [Informational, Experimental or Historic][14])? Why
    is this the proper type of RFC? Do all Datatracker state attributes
    correctly reflect this intent?

    Proposed Standard.

    This is the proper type because the document specifies a mechanism to
    enhance the SR Architecture for resource-aware segments and virtual
    networks.

    The datatracker state attributes reflect the intent.

12. Have reasonable efforts been made to remind all authors of the
    intellectual property rights (IPR) disclosure obligations described
    in [BCP 79][7]? To the best of your knowledge, have all required
    disclosures been filed? If not, explain why. If yes, summarize any
    relevant discussion, including links to publicly-available messages
    when applicable.

    Yes.  The authors and contributors have been reminded and polled during
    WGLC.  All have responded indicating that no undisclosed IPR exists.

    https://mailarchive.ietf.org/arch/msg/spring/n3E9YmoDZfAXVTbbt50qxJY7520/
    https://mailarchive.ietf.org/arch/msg/spring/UpUFWpHuMFEcp-YPbJhUhcd7BEE/

13. Has each author, editor, and contributor shown their willingness to
    be listed as such? If the total number of authors and editors on
    the front page is greater than five, please provide a justification.

    This document has been a WG item since 2020 and there have been no
    complaints from any author or contributor.  All authors and contributors
    openly replied to the IPR polls, which indicates knowledge of their role.

14. Document any remaining I-D nits in this document. Simply running
    the [idnits tool][8] is not enough; please review the ["Content
    Guidelines" on authors.ietf.org][15]. (Also note that the current
    idnits tool generates some incorrect warnings; a rewrite is
    underway.)

    -17 shows some unused references.  The authors are aware and will include
    -the changes in the next revision.

15. Should any informative references be normative or vice-versa? See
    the [IESG Statement on Normative and Informative References][16].

    No, the references have been categorized adequately.

16. List any normative references that are not freely available to
    anyone. Did the community have sufficient access to review any such
    normative references?

    N/A

17. Are there any normative downward references (see [RFC 3967][9] and
    [BCP 97][10]) that are not already listed in the [DOWNREF
    registry][17]? If so, list them.

    No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an
    unclear state? If so, what is the plan for their completion?

    N/A

19. Will publication of this document change the status of any existing
    RFCs? If so, does the Datatracker metadata correctly reflect this
    and are those RFCs listed on the title page, in the abstract, and
    discussed in the introduction? If not, explain why and point to the
    part of the document where the relationship of this document to
    these other RFCs is discussed.

    No.

20. Describe the document shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document. Confirm that all aspects of the document requiring
    IANA assignments are associated with the appropriate reservations
    in IANA registries. Confirm that any referenced IANA registries
    have been clearly identified. Confirm that each newly created IANA
    registry specifies its initial contents, allocations procedures,
    and a reasonable name (see [RFC 8126][11]).

    This document makes no request to IANA.

21. List any new IANA registries that require Designated Expert Review
    for future allocations. Are the instructions to the Designated
    Expert clear? Please include suggestions of designated experts, if
    appropriate.

    N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong
  concurrence of a few individuals, with others being silent, or did
  it reach broad agreement?

  The agreement was as broad as it gets in spring.  In general, a good
  number of participants have expressed their opinion during the life
  of the document.

2. Was there controversy about particular points, or were there
  decisions where the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme
  discontent? If so, please summarize the areas of conflict in
  separate email messages to the responsible Area Director. (It should
  be in a separate email because this questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the
  contents of the document? Have a significant number of potential
  implementers indicated plans to implement? Are any existing
  implementations reported somewhere, either in the document itself (as
  [RFC 7942][3] recommends) or elsewhere (where)?

  The document contains an "Implementation Status" section which documents
  one implementation.


## Additional Reviews

5. Do the contents of this document closely interact with technologies
  in other IETF working groups or external organizations, and would it
  therefore benefit from their review? Have those reviews occurred? If
  yes, describe which reviews took place.

  The mpls and srv6ops WGs have been cc'd on the WGLC.

  The teas and 6man WG Chairs have been given a head-up about the WGLC and
  asked to forward the information to their WGs if they believe it necessary.
  Neither did.

  No external organizations needed.

6. Describe how the document meets any required formal expert review
  criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
  type reviews.

  N/A

7. If the document contains a YANG module, has the final version of the
  module been checked with any of the [recommended validation
  tools][4] for syntax and formatting validation? If there are any
  resulting errors or warnings, what is the justification for not
  fixing them at this time? Does the YANG module comply with the
  Network Management Datastore Architecture (NMDA) as specified in
  [RFC 8342][5]?

  N/A

8. Describe reviews and automated checks performed to validate sections
  of the final version of the document written in a formal language,
  such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion
  that this document is needed, clearly written, complete, correctly
  designed, and ready to be handed off to the responsible Area
  Director?

  It is the opinion of the Shepherd that this document is ready.  The
  contents are clear and the work is needed.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been
    identified and addressed? For which does this still need to happen
    in subsequent reviews?

    The list has been reviewed.  No specific issues have been identified.

11. What type of RFC publication is being requested on the IETF stream
    ([Best Current Practice][12], [Proposed Standard, Internet
    Standard][13], [Informational, Experimental or Historic][14])? Why
    is this the proper type of RFC? Do all Datatracker state attributes
    correctly reflect this intent?

    Proposed Standard.

    This is the proper type because the document specifies a mechanism to
    enhance the SR Architecture for resource-aware segments and virtual
    networks.

    The datatracker state attributes reflect the intent.

12. Have reasonable efforts been made to remind all authors of the
    intellectual property rights (IPR) disclosure obligations described
    in [BCP 79][7]? To the best of your knowledge, have all required
    disclosures been filed? If not, explain why. If yes, summarize any
    relevant discussion, including links to publicly-available messages
    when applicable.

    Yes.  The authors and contributors have been reminded and polled during
    WGLC.  All have responded indicating that no undisclosed IPR exists.

    https://mailarchive.ietf.org/arch/msg/spring/n3E9YmoDZfAXVTbbt50qxJY7520/
    https://mailarchive.ietf.org/arch/msg/spring/UpUFWpHuMFEcp-YPbJhUhcd7BEE/

13. Has each author, editor, and contributor shown their willingness to
    be listed as such? If the total number of authors and editors on
    the front page is greater than five, please provide a justification.

    This document has been a WG item since 2020 and there have been no
    complaints from any author or contributor.  All authors and contributors
    openly replied to the IPR polls, which indicates knowledge of their role.

14. Document any remaining I-D nits in this document. Simply running
    the [idnits tool][8] is not enough; please review the ["Content
    Guidelines" on authors.ietf.org][15]. (Also note that the current
    idnits tool generates some incorrect warnings; a rewrite is
    underway.)

    -17 shows some unused references.  The authors are aware and will include
    -the changes in the next revision.

15. Should any informative references be normative or vice-versa? See
    the [IESG Statement on Normative and Informative References][16].

    No, the references have been categorized adequately.

16. List any normative references that are not freely available to
    anyone. Did the community have sufficient access to review any such
    normative references?

    N/A

17. Are there any normative downward references (see [RFC 3967][9] and
    [BCP 97][10]) that are not already listed in the [DOWNREF
    registry][17]? If so, list them.

    No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an
    unclear state? If so, what is the plan for their completion?

    N/A

19. Will publication of this document change the status of any existing
    RFCs? If so, does the Datatracker metadata correctly reflect this
    and are those RFCs listed on the title page, in the abstract, and
    discussed in the introduction? If not, explain why and point to the
    part of the document where the relationship of this document to
    these other RFCs is discussed.

    No.

20. Describe the document shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document. Confirm that all aspects of the document requiring
    IANA assignments are associated with the appropriate reservations
    in IANA registries. Confirm that any referenced IANA registries
    have been clearly identified. Confirm that each newly created IANA
    registry specifies its initial contents, allocations procedures,
    and a reasonable name (see [RFC 8126][11]).

    This document makes no request to IANA.

21. List any new IANA registries that require Designated Expert Review
    for future allocations. Are the instructions to the Designated
    Expert clear? Please include suggestions of designated experts, if
    appropriate.

    N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Request for posting confirmation emailed to previous authors: Fengwei Qin , Francois Clad , Jie Dong , Stewart Bryant , Takuya Miyasaka , Yongqing Zhu , Zhenqiang Li

Request for posting confirmation emailed to previous authors: Fengwei Qin , Francois Clad , Jie Dong , Stewart Bryant , Takuya Miyasaka , Yongqing Zhu , Zhenqiang Li

Request for posting confirmation emailed to previous authors: Fengwei Qin , Francois Clad , Jie Dong , Stewart Bryant , Takuya Miyasaka , Yongqing Zhu , Zhenqiang Li

Request for posting confirmation emailed to previous authors: Fengwei Qin , Francois Clad , Jie Dong , Stewart Bryant , Takuya Miyasaka , Yongqing Zhu , Zhenqiang Li