Hi Joel,
So sorry that I missed this mail in the whole June.
I assume you are talking about the following text in
draft-ietf-teas-nrp-scalability-04:
Assuming that an external mechanism can deal with path calculation
and selection, it is desirable that in the calculated path
information, the NRP identification should be decoupled from the
information for path identification.
My understanding of this statement is that, for a scalable NRP solution, it is
suggested that the NRP identification to be decoupled from the path
identification information.
Please note the draft also has the following text in the design principles:
4. Three separate things need to be identified by information
carried within a packet:
* Forwarding path (e.g. the next-hop)
* NRP
* Topology (i.e., filtered topology)
How this information is encoded (using separate fields, same
field, or overloading existing fields) forms part of the
solution work.
Thus IMO the mechanism as specified in draft-ietf-spring-resource-aware-segment
can be one option (overloading existing fields) for NRP realization.
The resource-aware segments should not be used with a separate NRP ID in the
same packet. As you said that will cause conflict or duplication.
There is some text about these two approaches in the introduction of
https://datatracker.ietf.org/doc/draft-dong-spring-sr-policy-with-nrp/.
Best regards,
Jie
> -----Original Message-----
> From: Joel Halpern [mailto:j...@joelhalpern.com]
> Sent: Wednesday, May 29, 2024 10:16 PM
> To: t...@ietf.org
> Cc: SPRING WG List <spring@ietf.org>
> Subject: [spring] Spring-Teas NRP inconsistency:
> draft-ietf-teas-nrp-scalability
>
> Looking at drafts, I noticed that draft-ietf-teas-nrp-scalability says that
> one is
> required (? expected? needs to?) use an NRP separate from the path control
> information.
>
> However, the Spring adopted draft
> draft-ietf-spring-resource-aware-segments puts the NRP selection in the
> segment identifier(s).
>
> If you tried to do both, you would have two conflicting representations for
> the NRP to be used in the same packet. That seems problematic.
>
> We need to somehow resolve this.
>
> Yours,
>
> Joel
>
>
> _______________________________________________
> spring mailing list -- spring@ietf.org
> To unsubscribe send an email to spring-le...@ietf.org
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
