[spring] Re: Mohamed Boucadair's Discuss on draft-ietf-spring-resource-aware-segments-18: (with DISCUSS and COMMENT)

["Dongjie (Jimmy)" <[e-mail]>]

Hi Med,

Thanks a lot for your review and comments, we are working on a new revision to incorporate them. 

And please see some replies inline with [Jie]: 


-----Original Message-----
From: Mohamed Boucadair via Datatracker <[e-mail]> 
Sent: Tuesday, June 2, 2026 4:30 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Mohamed Boucadair's Discuss on draft-ietf-spring-resource-aware-segments-18: (with DISCUSS and COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-spring-resource-aware-segments-18: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-resource-aware-segments/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.

[Jie] OK, we can rephrase and make this approach an option. 

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

[Jie] There were examples in early versions of the SR for enhanced VPN draft, while during the adoption call the example was split out as one usage of resource-aware segments for NRP-based enhanced VPN case. 


# Please delete “proposed” (several occurrences)

[Jie] OK.


# 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”?

[Jie] Sure, a reference to RFC 8402 will be added.


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

[Jie] We will add a reference to RFC 9543.  


# 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

[Jie] OK with the proposed change. The resource-aware segments comply with the SR paradigm, and introduce additional semantics to SR segments. 


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

[Jie] We will check all the use of "paradigm", and see if any of them needs to be replaced. For example, the statement in sentence "this per-segment resource allocation complies with the SR paradigm" is correct and does not need to be changed. 


# 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?

[Jie] Resources associated with class of service is just one example. As mentioned there are other types which require different granularity of resource allocation and identification. 

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

[Jie] OK, will fix it. 

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

[Jie] OK, we will add a reference to RFC9543. 


# …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?

[Jie] The controller knows when the resource group is fully provisioned, after that services will be provisioned to the resource group by the controller. This is similar to how a physical network is provisioned and brought into production. 


# There might be multiple controllers

Please s/The centralized controller/A centralized controller

[Jie] OK, will fix this in next revision. 

Best regards,
Jie


Cheers,
Med