Re: [Teas] NRP related routing protocol extension work

Vishnu Pavan Beeram <vishnupavan@gmail.com> Mon, 18 March 2024 08:02 UTC

Return-Path: <vishnupavan@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 706C8C15199A for <teas@ietfa.amsl.com>; Mon, 18 Mar 2024 01:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 IE3qsD1N-YKD for <teas@ietfa.amsl.com>; Mon, 18 Mar 2024 01:02:58 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 7A785C151990 for <teas@ietf.org>; Mon, 18 Mar 2024 01:02:58 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-6e622b46f45so2930333b3a.1 for <teas@ietf.org>; Mon, 18 Mar 2024 01:02:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710748978; x=1711353778; 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=BuBmdpbev+IRRmIrSVBoIO6pAvbjkC+65RN5W2lFAB0=; b=AAObe3S12rtKggLFeZ/1T+QNqFUAGbX4XRteEhrzNEgcTWV9quk0j4YN65ZhwXUf9z MJtRLFSIEI88Xdv1AIrexuN4whJ7nwfckjXeF/i8cLe6rJbCmLVLFrsLGg4d7KxnSQw8 gAWx+YBzER0+0U3D47sxLr0SFWRCKS7VZzimfveLEGdgkSXEfmNZ1YMCwcrvwNCIJoqT 2mjBbBdpgYgsw84sBEEa2OSjkWW6P0Cx58BwHz3KANGcHKuhJhzRnpdmUgQY4tWxFtd7 aSl73iRtvNEAJBEIXSnj4M4GakOBTv9NHKFqGGGj3xptDyejCXRz4moNkwoowX0usLl5 QR8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710748978; x=1711353778; 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=BuBmdpbev+IRRmIrSVBoIO6pAvbjkC+65RN5W2lFAB0=; b=OQDCIF3aIDH7ARjDRLLSCudK5bvr4LdGjfvJa95Rp+O24nhgQJItJrdSTIjJdC32g6 L1p42dCMRN4JphipxUiPj7Op4rt8RtyYkKToe4TB+bS1Pi5ZFCfWT/buheotGKwxhtUZ 3tsWgNWXtUVXEFmFkID5bLuhuS5YzopZxctWWegsyxvf0q84lgJKNZfIdf5PUVQLFA2g TERh3KqfA+P6z9Sb8p+FCVHIuZ20Ccy4lBeJWhi4zE132qD47vav/PFWZ7OjrLbiq1Qw d5Q30Uwr7JFBgtSh+yU9xVAeftAs3LGi8t0EGBPaohaHYq1IBfkdZE89V8D7fVS3b7iO 6BHA==
X-Gm-Message-State: AOJu0YzlmcBG5Rw7pFcMQ6VMNqacHEpJRNNXbi/3L7VBmzjU37c0dAvC i3CIppQlRiDmVQC19Qk6RvUmhbDBze5eFVEq/sbmB9TCuI470jFwkouxDjxQ7ulvO0VKmo2DN3O z1vxvCOSZV6KyruIuTbCYhgfA6RxXSP6qqYbAog==
X-Google-Smtp-Source: AGHT+IFtvtoOny2wVo+XQkdT0FSxpquGQK/K0qxqhlntbB7ykDKgfRMHVy+o9RQoHtXDlr7wuOmn0Dk5T6UC7wLLAKM=
X-Received: by 2002:a05:6a00:2da2:b0:6e7:34f5:f0d8 with SMTP id fb34-20020a056a002da200b006e734f5f0d8mr315631pfb.30.1710748977626; Mon, 18 Mar 2024 01:02:57 -0700 (PDT)
MIME-Version: 1.0
References: <CA+YzgTu_QFmKJ-zUT7U7FWoGgF3uuOLVtPcrQuXFgfOT5chirQ@mail.gmail.com> <202403181226591475323@zte.com.cn> <CAH6gdPxfnh2WbsPuyYZgkN5LNmOT2dU+upF9k=_=L6kkfy1RUw@mail.gmail.com>
In-Reply-To: <CAH6gdPxfnh2WbsPuyYZgkN5LNmOT2dU+upF9k=_=L6kkfy1RUw@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Mon, 18 Mar 2024 13:32:46 +0530
Message-ID: <CA+YzgTtTpyEc9LF6GWLu6Kd24hfBZJZ2U=yzTmEfB_w4bU7dgw@mail.gmail.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: teas@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, chen.ran@zte.com.cn
Content-Type: multipart/alternative; boundary="0000000000001c845c0613eac9f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/-yZ9iBx604IZLNbXpTXFN6DyGcg>
Subject: Re: [Teas] NRP related routing protocol extension work
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 08:02:59 -0000

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)
>>>>
>>>
>>