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

[[e-mail]]

Hi Jie, 

Thank you for the follow-up.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Dongjie (Jimmy) <jie.dong=[e-mail]>
> Envoyé : mercredi 10 juin 2026 12:11
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> The IESG <[e-mail]>
> Cc : [e-mail]; draft-ietf-spring-resource-aware-
> [e-mail]; [e-mail]; [e-mail]
> Objet : [iesg] Re: Mohamed Boucadair's Discuss on draft-ietf-
> spring-resource-aware-segments-18: (with DISCUSS and COMMENT)
> 
> 
> 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]; draft-ietf-spring-resource-aware-
> [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.)
> 
> 
> ------------------------------------------------------------------
> 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.

[Med] Thanks

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

[Med] Hope you can grab some examples (with the various SIDs) from that version.

> 
> # 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.
[Med] ACK 

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

[Med] ACK

 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.

[Med] Yes, but having some text to explain why CoS identifiers wouldn't be sufficient here. 

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

[Med] ACK.

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

[Med] Please consider adding some text to explain the relationship.

> 
> ## Please add a reference for NRPs. RFC9543 would be OK.
> 
> [Jie] OK, we will add a reference to RFC9543.

[Med] Thanks. 

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

[Med] Can we please have this elaborated in the draft?

> 
> 
> # There might be multiple controllers
> 
> Please s/The centralized controller/A centralized controller
> 
> [Jie] OK, will fix this in next revision.

[Med] ACK.

> 
> Best regards,
> Jie
> 
> 
> Cheers,
> Med
> 
> 

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.