On July 14, 2025 at 5:12:48 AM, Dongjie (Jimmy) wrote:

Hi Jie!

Thanks for the update!

I have a couple of remaining points below.

Thanks!

Alvaro.



...
> (1) According to the WG Policies, please add an Implementation Description
> section.
>
> https://wiki.ietf.org/en/group/spring/WG_Policies
>
> [Jie] We will check and provide this information in a later version.

ACK



...
> 216 Although it is possible that each resource-aware prefix-SID is
> 217 allocated with a set of dedicated resources on every node and link in
> 218 the associated topology and/or algorithm, the overhead of per-prefix
> 219 resource reservation is usually considered unacceptable in both
> 220 control plane signaling and data plane states, and it is likely some
> 221 of the allocated resources will be wasted. A more practical resource
> 222 allocation approach is RECOMMENDED in this document, which is that a
> 223 common set of network resources is allocated by the network nodes and
> 224 links participating in the topology and/or algorithm, and this common
> 225 set of network resource is associated with a group of resource-aware
> 226 prefix-SIDs. Such a common set of network resources constitutes a
> 227 network resource group. For a given tuple,
> 228 there can be one or multiple network resource groups. This way, a
> 229 group of resource-aware prefix-SIDs which are associated with the
> 230 same tuple can share the set of network
> 231 resources in a resource group. The association between the SR SIDs
> 232 and a resource group can be provisioned using the management plane or
> 233 a control plane.
>
...
> [major] "Such a common set of network resources constitutes a network
> resource group."
>
> The set is defined here as a "network resource group", but "resource
group" is mostly used later in the text. Please be consistent!
>
>
> [Jie] OK, in this version “resource group” is used consistently.

One instance remains...in the paragraph above.



...
> 245 For one IGP prefix, multiple resource-aware prefix-SIDs can be
> 246 allocated. Each resource-aware prefix-SID may be associated with a
> 247 unique tuple, in this case different >
> 248 algorithm> tuples can be used to distinguish the resource-aware
> 249 prefix-SIDs of the same prefix. In another case, for one IGP prefix,
> 250 multiple resource-aware prefix-SIDs may be associated with the same
> 251 tuple but different resource groups, then an
> 252 additional control plane distinguisher needs to be introduced to
> 253 distinguish different resource-aware prefix-SIDs associated with the
> 254 same but different resource groups.
>
>
> [major] This paragraph presents two options: "resource-aware prefix-SID
may
> be associated with a unique tuple", or, "multiple resource-aware
prefix-SIDs
> may be associated with the same tuple but different resource groups".
Please
> settle on one!
>
> IMO, the first option is "cleaner" because it doesn't require "an
additional control plane distinguisher" (which would also be out of scope).
>
>
> [Jie] Yes the first option is simpler, while the second option can
provider
> better scalability (require less topologies or algorithms) thus it is also
> mentioned here. The control plane extension is out of the scope of this
> document.

If you want to keep both, then please include some text explaining the
operational pros and cons of each.  Maybe add a subsection (§2.1.1:
Operational Considerations).  Also, be explicit about the suggested
extension being out of scope.
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to