[spring] Re: [Teas] Re: Spring-Teas NRP inconsistency: draft-ietf-teas-nrp-scalability

["Dongjie (Jimmy)" <[e-mail]>]

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:[e-mail]]
> Sent: Thursday, July 4, 2024 11:39 PM
> To: Dongjie (Jimmy) <[e-mail]>; [e-mail]
> Cc: SPRING WG List <[e-mail]>
> 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:[e-mail]]
> >> Sent: Wednesday, May 29, 2024 10:16 PM
> >> To: [e-mail]
> >> Cc: SPRING WG List <[e-mail]>
> >> 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 -- [e-mail] To unsubscribe send an email
> >> to [e-mail]
> 
> _______________________________________________
> Teas mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]