Re: [Teas] Associating a TE Tunnel/Policy with an NRP

[Vishnu Pavan Beeram <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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 <[e-mail]> *On Behalf Of *Vishnu Pavan Beeram
>> *Sent:* 28 September 2023 14:11
>> *To:* TEAS WG <[e-mail]>
>> *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)
>>
>