I may have misunderstood this email. You seem to have highlighted the
contradiction between the two set of texts (and the two sets of
solutions) but not explained how this draft deals with that contradiction.
Yours,
Joel
On 7/4/2024 6:53 AM, Dongjie (Jimmy) wrote:
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
