Re: [Teas] NRP related routing protocol extension work

Thanks Pavan for that context/status - it is helpful and I will catch up
with the documents you indicate.

Thanks,
Ketan

On Mon, Mar 18, 2024 at 1:32 PM Vishnu Pavan Beeram <vishnupavan@gmail.com>
wrote:

> Ketan,
>
> I would encourage you to go through the following:
>
>    - draft-ietf-teas-ns-ip-mpls discusses options for realizing network
>    slices using NRPs.
>    - draft-ietf-teas-nrp-scalability discusses the scalability
>    considerations for each of the realization options.
>    - draft-ietf-teas-nrp-yang discusses the data model for NRP.
>
> All three documents are interrelated. As these documents evolve, the gaps
> (if any) in existing (control-plane/data-plane) protocols should become
> apparent. IMHO, the WG hasn't reached that stage yet. As stated earlier,
> the only protocol extension (for which explicit feedback was sought) that
> has been deemed okay so far by TEAS is the one related to associating a TE
> Tunnel/Policy with an NRP.
>
> Regards,
> -Pavan
>
> On Mon, Mar 18, 2024 at 11:52 AM Ketan Talaulikar <ketant.ietf@gmail.com>
> wrote:
>
>> 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)
>>>>>
>>>>
>>>