Re: [Idr] [Teas] draft-chen-idr-bgp-ls-sr-policy-nrp was just discussed ///Re: Associating a TE Tunnel/Policy with an NRP

Hi Ran,

Thanks for that clarification and responding to my first question. Could
you please also respond to my other two questions?

Thanks,
Ketan

On Mon, Mar 18, 2024 at 7:51 PM <chen.ran@zte.com.cn> wrote:

> Hi Ketan,
>
> It can be used as a path calculation constraint. When used in SR-based NRP
> solutions(
> <https://datatracker.ietf.org/doc/draft-ietf-teas-nrp-scalability/>
> https://datatracker.ietf.org/doc/draft-ietf-teas-nrp-scalability/
> section 6), it can be used as a path calculation constraint. When used
> in NRP-ID-based mechanism,it is mainly used to report the onfiguration and
> the states the NRP which the SR Policy candidate path is associated with.
>
>
> Best Regards,
>
> Ran
>
>
> Original
> *From: *KetanTalaulikar <ketant.ietf@gmail.com>
> *To: *Vishnu Pavan Beeram <vishnupavan@gmail.com>;
> *Cc: *陈然00080434;adrian@olddog.co.uk <adrian@olddog.co.uk>;teas@ietf.org <
> teas@ietf.org>;idr@ietf.org <idr@ietf.org>;
> *Date: *2024年03月18日 14:49
> *Subject: **Re: [Teas] draft-chen-idr-bgp-ls-sr-policy-nrp was just
> discussed ///Re: Associating a TE Tunnel/Policy with an NRP*
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
> Hi Pavan,
> That thread seems to have escaped my attention.
>
> Hi Ran,
>
> Based on Pavan's description below, I understand that the NRP is in the
> form of a topology constraint for the path computation of the SR Policy.
> Can you or your co-authors confirm or correct me? I am not able to
> precisely find this in the draft-ietf-teas-ns-ip-mpls.
>
> I assume that the constraints associated with the NRP are specified in
> terms of underlying IGP mechanisms (e.g., MT or FlexAlgo) or TE constraint
> (e.g., link affinities/color, etc.)?
>
> So then, is NRP essentially a "template" or a "profile" for path
> constraints?
>
> I am trying to understand these details to see if we can use existing
> mechanisms in the protocols over introducing new ones.
>
> Thanks,
> Ketan
>
> On Mon, Mar 18, 2024 at 11:39 AM Vishnu Pavan Beeram <
> vishnupavan@gmail.com> wrote:
>
>> Ran, Ketan,
>> The only NRP specific protocol extension that has been endorsed by TEAS
>> so far is the one related to associating a TE Tunnel/Policy 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. There was no objection raised by the WG for such an
>> extension (defined in PCEP or BGP). It is my understanding that
>> ietf-idr-sr-policy-nrp was adopted in IDR based on this guidance.
>>
>> Since, draft-chen-idr-bgp-ls-sr-policy-nrp is being positioned as a
>> companion document for ietf-idr-sr-policy-nrp (for policy state
>> reporting), the same guidance as earlier should apply to this document
>> (imho).
>>
>>
>> TEAS WG,
>>
>> Please provide feedback on the draft.
>>
>>
>> Regards,
>>
>> -Pavan
>>
>> 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)
>>>>>
>>>>
>>> _______________________________________________
>>> Teas mailing list
>>> Teas@ietf.org
>>> https://www.ietf.org/mailman/listinfo/teas
>>>
>>
>