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

chen.ran@zte.com.cn Mon, 18 March 2024 14:21 UTC

Return-Path: <chen.ran@zte.com.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2469C151991; Mon, 18 Mar 2024 07:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlb3i1Cqz648; Mon, 18 Mar 2024 07:21:27 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0C1C151553; Mon, 18 Mar 2024 07:21:25 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4TyxqM6B1zz8XrRD; Mon, 18 Mar 2024 22:21:19 +0800 (CST)
Received: from njb2app05.zte.com.cn ([10.55.22.121]) by mse-fl1.zte.com.cn with SMTP id 42IELHwP074756; Mon, 18 Mar 2024 22:21:17 +0800 (+08) (envelope-from chen.ran@zte.com.cn)
Received: from mapi (njy2app08[null]) by mapi (Zmail) with MAPI id mid203; Mon, 18 Mar 2024 22:21:21 +0800 (CST)
Date: Mon, 18 Mar 2024 22:21:21 +0800
X-Zmail-TransId: 2b0065f84de1ffffffff8d5-6d8b3
X-Mailer: Zmail v1.0
Message-ID: <202403182221218943435@zte.com.cn>
In-Reply-To: <CAH6gdPwHGtcood_ROWvSmCdBCnXhbG1dECt+M3x9q1eGTnLHFw@mail.gmail.com>
References: CA+YzgTu_QFmKJ-zUT7U7FWoGgF3uuOLVtPcrQuXFgfOT5chirQ@mail.gmail.com, 202403181226591475323@zte.com.cn, CA+YzgTt0acyy5RZZAD0L3kbZHGzzy9vjDXhS8midaNGVTfs-pQ@mail.gmail.com, CAH6gdPwHGtcood_ROWvSmCdBCnXhbG1dECt+M3x9q1eGTnLHFw@mail.gmail.com
Mime-Version: 1.0
From: chen.ran@zte.com.cn
To: ketant.ietf@gmail.com
Cc: vishnupavan@gmail.com, adrian@olddog.co.uk, teas@ietf.org, idr@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 42IELHwP074756
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 65F84DDF.000/4TyxqM6B1zz8XrRD
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZHvSzxRam6U8XTBHTBfoNLqmZXA>
Subject: Re: [Idr] [Teas] draft-chen-idr-bgp-ls-sr-policy-nrp was just discussed ///Re: Associating a TE Tunnel/Policy with an NRP
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2024 14:21:31 -0000

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/  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/ . 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