Hi Joel, The dedicated NRP ID approach has better scalability thanks to the decouple of the NRP and path information. While the resource-aware segment approach is easy to implement as it does not require extension in data plane encapsulation (at the cost of less scalable)
What I said is the two mechanisms (resource-aware segment and dedicated NRP ID) are independent options for NRP realization. They should not be used together. Hope this makes it clear. Best regards, Jie > -----Original Message----- > From: Joel Halpern [mailto:j...@joelhalpern.com] > Sent: Thursday, July 4, 2024 11:39 PM > To: Dongjie (Jimmy) <jie.d...@huawei.com>; t...@ietf.org > Cc: SPRING WG List <spring@ietf.org> > Subject: [Teas] Re: [spring] Spring-Teas NRP inconsistency: > draft-ietf-teas-nrp-scalability > > 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 > > _______________________________________________ > Teas mailing list -- t...@ietf.org > To unsubscribe send an email to teas-le...@ietf.org _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
