[Teas] NRP related routing protocol extension work

Hi All,

It has been a bit challenging for me to keep pace with the overlap across
the multiple WG drafts when it comes to NRP. I could use some help with
some directions.

Besides RFC9543 that introduced the term NRP, there have been several other
related documents:

1) https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/
2) https://datatracker.ietf.org/doc/draft-ietf-teas-nrp-scalability/
3) https://datatracker.ietf.org/doc/draft-ietf-teas-ns-ip-mpls/

All of these are informational and all of them touch upon control plane
protocol aspects related to NRP. My understanding is that (3) is the
authoritative document that brings out requirements for work in control
plane protocols and covers the need as well as considerations for the same.
Is my understanding correct?

Thanks,
Ketan

On Mon, Mar 18, 2024 at 9:57 AM <chen.ran@zte.com.cn> wrote:

> Hi ketan,
>
> NRP-related protocol extensions were previously discussed in the TEAS WG. The
> inline email is for the TEAS WG to discuss protocol extensions for
> associating a TE Tunnel/Policy with an NRP.  Have your concerns been
> resolved?
>
>
> To TEAS chairs and WG,
>
> we have done the presentations in IDR WG  for
> <https://datatracker.ietf.org/doc/draft-chen-idr-bgp-ls-sr-policy-nrp/>
> <https://datatracker.ietf.org/doc/draft-chen-idr-bgp-ls-sr-policy-nrp/>
> <https://datatracker.ietf.org/doc/draft-chen-idr-bgp-ls-sr-policy-nrp/>
> https://datatracker.ietf.org/doc/draft-chen-idr-bgp-ls-sr-policy-nrp/ .
> This document defines a new TLV which enable the headed to report the
> configuration and the states the NRP which the SR Policy candidate path is
> associated with.
>
> and in the new version of the draft:
>
>    -
>
>    Update the "Scalability Considerations" section to be consistent with
>    draft-ietf-idr-sr-policy-nrp-00.
>
> We would like to request for  IDR WG adoption. Any comments are welcome.
>
>
> Best Regards,
>
> Ran
>
>
> Original
> *From: *VishnuPavanBeeram <vishnupavan@gmail.com>
> *To: *adrian@olddog.co.uk <adrian@olddog.co.uk>;
> *Cc: *TEAS WG <teas@ietf.org>;
> *Date: *2023年12月11日 00:53
> *Subject: **Re: [Teas] Associating a TE Tunnel/Policy with an NRP*
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
> There have been no objections (on the list or during the WG session) to
> defining protocol extensions for associating a TE Tunnel/Policy with an
> NRP.
>
> Please do note that the relevant protocol (BGP, PCEP) extensions would be
> discussed and progressed in other WGs.
> Regards,
> -Pavan (on behalf of the co-chairs)
>
> On Fri, Nov 10, 2023 at 3:00 PM Vishnu Pavan Beeram <vishnupavan@gmail.com>
> wrote:
>
>> Just realized that this thread was left hanging.
>>
>> For all NRP specific protocol extension documents, the request from the
>> TEAS WG chairs is the the following (nothing more, nothing less):
>>
>>    -
>>
>>    Add a “Scalability Considerations” section.
>>    -
>>
>>    Keep the TEAS WG updated about the progress of the document
>>    (especially during WG adoption and WGLC)
>>
>>
>> With regards to draft-dong-idr-sr-policy-nrp for which this thread was
>> initiated, it is on the agenda in today's WG session. The expectation is
>> that this would trigger a discussion on the utility of the protocol
>> extension defined in this draft.
>>
>> Regards,
>> -Pavan
>>
>> On Thu, Sep 28, 2023 at 7:34 PM Adrian Farrel <adrian@olddog.co.uk>
>> wrote:
>>
>>> Hi Pavan,
>>>
>>>
>>>
>>> Thanks for starting this thread. It’s a fine thing to talk about.
>>>
>>>
>>>
>>> I don’t think the TEAS working group would be in a position to stop
>>> other working groups picking up and working on protocol extensions that
>>> they think are necessary. But it might be good to have an overview
>>> perspective of how NRPs might be constructed in different protocol
>>> environments so that those working groups can go ahead and make the
>>> protocol changes with confidence.
>>>
>>>
>>>
>>> It’s probable that TEAS was a bit premature adopting
>>> draft-ietf-teas-ns-ip-mpls while other working groups were holding back
>>> waiting for the slicing framework to stabilise and be approved for
>>> publication. But we don’t need to go there. What is important now is to
>>> recognise that it is open for people to work out how they want to develop
>>> solutions to support NRPs. TEAS can certainly coordinate that work, but I
>>> don’t think it can constrain it because slicing is a broad concept and
>>> there are plenty of protocols and service architectures that can deliver
>>> “slices.”
>>>
>>>
>>>
>>> What do you propose (maybe you could put your hat back on?) as a way
>>> that we could act to coordinate this work?
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Adrian
>>>
>>>
>>>
>>> *From:* Teas <teas-bounces@ietf.org> *On Behalf Of *Vishnu Pavan Beeram
>>> *Sent:* 28 September 2023 14:11
>>> *To:* TEAS WG <teas@ietf.org>
>>> *Subject:* [Teas] Associating a TE Tunnel/Policy with an NRP
>>>
>>>
>>>
>>> There are a couple of control-plane protocol extension documents that
>>> have been proposed outside TEAS WG for associating a TE Tunnel/Policy with
>>> an NRP.
>>>
>>>    -
>>>
>>>    draft-dong-idr-sr-policy-nrp proposes extensions to BGP for
>>>    associating an SR policy with an NRP
>>>    -
>>>
>>>    draft-dong-pce-pcep-nrp proposes extensions to PCEP for associating
>>>    a TE LSP with an NRP
>>>
>>> The motivation behind this association is to ensure that the TE paths
>>> are computed, placed and maintained within the topology associated with the
>>> specified NRP (discussed briefly in draft-ietf-teas-ns-ip-mpls).
>>>
>>>
>>>
>>> We have had some discussion/debate in the past in TEAS on whether or not
>>> there should be any NRP specific control-plane protocol extensions defined
>>> at all. Most of that debate has been focused around extensions to
>>> link-state protocols. AFAIR, we (in TEAS) haven't discussed the specific
>>> type of protocol extension discussed in the aforementioned drafts.
>>>
>>>
>>>
>>> I'm starting this thread to get some feedback from the WG on this
>>> specific type of protocol extension.
>>>
>>>
>>>
>>> Regards,
>>>
>>> - Pavan (as a WG contributor)
>>>
>>
>