Re: [Teas] draft-chen-idr-bgp-ls-sr-policy-nrp was just discussed ///Re: Associating a TE Tunnel/Policy with an NRP
Ketan Talaulikar <ketant.ietf@gmail.com> Mon, 18 March 2024 06:48 UTC
Return-Path: <ketant.ietf@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4988C14CE4B; Sun, 17 Mar 2024 23:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LmHiWeFK0o6y; Sun, 17 Mar 2024 23:48:54 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD37C14CF1F; Sun, 17 Mar 2024 23:48:54 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a466e53f8c0so509277566b.1; Sun, 17 Mar 2024 23:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710744532; x=1711349332; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=te++RYooVkAboCPFueCOYWKp1kIhVqtmGofzSqSVcoU=; b=APEXBI9JYDg2yoym3d//140elu52JITbvL20KO9iG0B9rj/VS6+WzA4zwNGaJtlWdT z7MW0DO+7Nseagnkf/AhGKsJT6HWC3i7qgDKcvC0DOig73dIz6/XFZBS1EaHhksHSqrY k0Ta+MVz6TUChT2rcLEhJA8lCRYIjyRCFN2mlSRsTM8owzN6H6a1VoRwDe8lVsXeL4Fe EW8eqy1lacphJ38njfiz6ZwwxuDsbKrtWzC5zow0/HFbAacrUJLCgskomahErFMWP9Nn +f+PZogaMXiPggXTs1WOrhsyqNBT8yQZ1R7VHfoQiSggfJY3Kp24xaEpfJdPsSK4Whp2 Gnng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710744532; x=1711349332; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=te++RYooVkAboCPFueCOYWKp1kIhVqtmGofzSqSVcoU=; b=q5+X50ahFXiz0AqMUfIAz0jXgA78urYBBmk6eHpf+I05NE5zN8vyTnhnqPXpN4/yft 3OXknSXO+39PXIDl1bCa4S0NqDn+3mvBk46QTIMP6CnkVBeBGardYPBlcsDLPFTxuKXX 4JPxM8ZAChR9BxcjFTH08mXMxayPvlzg7zzSU88LTz8fCb8ljlVdWLG1DPrMNh55KLSX 50QhdI4/p10PL3kW1ump1aHwSvH67gIDMX5AHaftgu0E1Z7w6zJyAN4zhy0fQkMr46zC FFRykjYfGvOl91Bnlij5FbwU28Yo5EWUzLmL/4jDi88alM3D0teEsNdx9kZI/FnYm041 CEQw==
X-Forwarded-Encrypted: i=1; AJvYcCUNv/DdpP9AQvFV5ukDlOWn8dicFj9IaEIWDGyN0DIqmtzB8BLRf6ktDR862NOBdLff6BYf3ot5SYKfy0RF2P+FA9/cm91GekbQGq8=
X-Gm-Message-State: AOJu0YytMM6TvMm/QORorkVnLJPmdSp30edB1GLTniDzJZ79qv0jws4y QJKflpatqMFAHLtG/sThCwPvIMItr1nv0M5MlU2hP6gbtyxl3nrKPodpvStUc8dxNTFMsZ8Jbs/ 3TkRqMlJ/JJRQxqiVYtVF4OAojUo=
X-Google-Smtp-Source: AGHT+IHDCqMA3RexETfVeT8BYwizwLVptWQwUYggEE3GNmunT9F2kAaS/ka5ugX+7eN9cNiJ5spUNPWXkvvbSsxgCqE=
X-Received: by 2002:a17:906:b208:b0:a46:938c:2cf2 with SMTP id p8-20020a170906b20800b00a46938c2cf2mr5233530ejz.5.1710744532249; Sun, 17 Mar 2024 23:48:52 -0700 (PDT)
MIME-Version: 1.0
References: <CA+YzgTu_QFmKJ-zUT7U7FWoGgF3uuOLVtPcrQuXFgfOT5chirQ@mail.gmail.com> <202403181226591475323@zte.com.cn> <CA+YzgTt0acyy5RZZAD0L3kbZHGzzy9vjDXhS8midaNGVTfs-pQ@mail.gmail.com>
In-Reply-To: <CA+YzgTt0acyy5RZZAD0L3kbZHGzzy9vjDXhS8midaNGVTfs-pQ@mail.gmail.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Mon, 18 Mar 2024 12:18:40 +0530
Message-ID: <CAH6gdPwHGtcood_ROWvSmCdBCnXhbG1dECt+M3x9q1eGTnLHFw@mail.gmail.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Cc: chen.ran@zte.com.cn, adrian@olddog.co.uk, teas@ietf.org, idr@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002573390613e9c0f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/nt709isYfvtuTDJwM5ZykCR8ihs>
Subject: Re: [Teas] draft-chen-idr-bgp-ls-sr-policy-nrp was just discussed ///Re: Associating a TE Tunnel/Policy with an NRP
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2024 06:48:56 -0000
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 >> >
- [Teas] Associating a TE Tunnel/Policy with an NRP Vishnu Pavan Beeram
- Re: [Teas] Associating a TE Tunnel/Policy with an… Adrian Farrel
- Re: [Teas] Associating a TE Tunnel/Policy with an… Vishnu Pavan Beeram
- Re: [Teas] Associating a TE Tunnel/Policy with an… Vishnu Pavan Beeram
- [Teas] draft-chen-idr-bgp-ls-sr-policy-nrp was ju… chen.ran
- Re: [Teas] draft-chen-idr-bgp-ls-sr-policy-nrp wa… Vishnu Pavan Beeram
- [Teas] NRP related routing protocol extension work Ketan Talaulikar
- Re: [Teas] draft-chen-idr-bgp-ls-sr-policy-nrp wa… Ketan Talaulikar
- Re: [Teas] NRP related routing protocol extension… Vishnu Pavan Beeram
- Re: [Teas] draft-chen-idr-bgp-ls-sr-policy-nrp wa… chen.ran
- Re: [Teas] draft-chen-idr-bgp-ls-sr-policy-nrp wa… Ketan Talaulikar
- Re: [Teas] NRP related routing protocol extension… Ketan Talaulikar
- Re: [Teas] draft-chen-idr-bgp-ls-sr-policy-nrp wa… chen.ran