Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Tarek Saad <tsaad.net@gmail.com> Wed, 25 May 2022 14:17 UTC

Return-Path: <tsaad.net@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 3DDCEC1D5ACD; Wed, 25 May 2022 07:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 G156ny6NdB3z; Wed, 25 May 2022 07:17:16 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 DC5FEC1B928A; Wed, 25 May 2022 07:17:15 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id v7so1331405ilj.7; Wed, 25 May 2022 07:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=MU0jQXH5q5e3Cr9C4xzF8PmeJMCc7p2/NV3Yd8J+Jh8=; b=f52kOjxi7hMaA1WkPY0NEVAXEGmksiHEw0lj2GrfXtveEWhqhZr98rGBHzPkaecMIs xABMY9usT3wI+E/vjyNxQ41CVzhm3m6K/E7Oi7so4yMkW0dbHpC7Eeic5WAjvr8y19I/ DDiN/jL8NLrYptdsX6rRnmmic1DYODfsr7BotCJwcqZoGeFW50HWMtVBvrM2b4DIjUop o6uS5JHjcccUsJfEkcLhQRH16CeIcWxO6S0aTNVZfQmJkOyq9P1BdjexceReJ04+j5kV RCItqIxTKfgz7+BfA3g9PsjMC8uoxTt8BnIM6Z+kLZakBiVqchdHIoHEfOkA1R5tnEBr ga+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=MU0jQXH5q5e3Cr9C4xzF8PmeJMCc7p2/NV3Yd8J+Jh8=; b=61ifFxQxqifBzTEUswCOTR2oDXpYEodwbGji5u/ebKu0jsTGn4GZJGXrfjg8jGgjTY SZb6RC8aMmDnnv+dyXZF0IGbZiqmIMOC0Pqj6g71bTWm8RZ0y1gS+M0No7/cMMnqP3ez ssUvy09HDi1ClWtwu+zWewVFuxvEi2QfLYP3AMgSqCQcMMPINULUYEHyAYs5VB2tiQ/0 LAbRQUTUbZfPT+PqeG8gLq9x/pO3PsU1QOXUuEGaLHNJQrQ00gYBvz667/o16XjbebS+ +tS+BIKLNPZB1wrogy7Lp0fovow6eANV8iqYpDM52WpV/JTLF+U820AP+69WaJFWfjYo 6A5Q==
X-Gm-Message-State: AOAM531ZHPUq3gn5WlciP0w4a2N9E7fkZkHtrLccNR2DZ6gGSegX6XUz 507ZBq7Qx2yTzD+69caUwh8=
X-Google-Smtp-Source: ABdhPJwhgiSedUTjcaDw+ITSWgKebYMX7voO9VDtGIuxOi7ndSWVvQGSfMPsiaVemwbPQhirPJHUXg==
X-Received: by 2002:a05:6e02:1c2a:b0:2d1:9e4c:203d with SMTP id m10-20020a056e021c2a00b002d19e4c203dmr8858826ilh.235.1653488234567; Wed, 25 May 2022 07:17:14 -0700 (PDT)
Received: from DS0PR19MB6501.namprd19.prod.outlook.com ([2603:1036:5:f::5]) by smtp.gmail.com with ESMTPSA id n25-20020a02a199000000b0032e31eeebc1sm4172006jah.170.2022.05.25.07.17.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 May 2022 07:17:13 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: "Wubo (lana)" <lana.wubo@huawei.com>
CC: Lou Berger <lberger@labn.net>, TEAS WG Chairs <teas-chairs@ietf.org>, "draft-bestbar-teas-ns-packet@ietf.org" <draft-bestbar-teas-ns-packet@ietf.org>, TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Thread-Index: ATFlMjg3XhMgt8cmaPLnZXzf8CwUiWd6NTM9ylmi/xGAVFYUgIAAdcosgA1H+smAAfSFgIACwkGSgAB+qICAAEtQuQ==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 25 May 2022 14:17:13 +0000
Message-ID: <DM5PR1901MB2150C1E1D4DB082A1BA39114FCC69@DM5PR1901MB2150.namprd19.prod.outlook.com>
References: <54263b17-4c97-8fcc-672c-146bed709b01@labn.net> <CAB75xn5pq=pHPKQ-D6K3kTL63mVbB5rVy3Y0yrEznyS+xnDO3g@mail.gmail.com> <DM5PR1901MB215016308E881D398FDE571FFC059@DM5PR1901MB2150.namprd19.prod.outlook.com> <CAB75xn7j+EnXx2SLiX5-FosEmod1YZRB0f2KnKZR_2AX-xkUng@mail.gmail.com> <DM5PR1901MB215059F94FD829DA2E13B888FCFA9@DM5PR1901MB2150.namprd19.prod.outlook.com> <DM5PR1901MB215020B8F5D3B7B90332A610FCC59@DM5PR1901MB2150.namprd19.prod.outlook.com> <45ba83be0fc04f288c0cb800674916a8@huawei.com> <DM5PR1901MB21500FD1EAA26C0234A69189FCC69@DM5PR1901MB2150.namprd19.prod.outlook.com> <028079ea592e4cb4bcb59db20111d094@huawei.com>
In-Reply-To: <028079ea592e4cb4bcb59db20111d094@huawei.com>
Accept-Language: en-US
Content-Language: en-CA
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DM5PR1901MB2150C1E1D4DB082A1BA39114FCC69DM5PR1901MB2150_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/VGuTm3lgy6UHMPC16pZ4hd6hsac>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.34
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: Wed, 25 May 2022 14:17:17 -0000

Hi Bo,


  1.  Align the architecture with IETF network slice framework draft
Alignment with the IETF network slice framework does not need to be explicitly mentioned as an Open Item. The draft should maintain alignment as it (addresses the open items and) progresses through the WG process..


  1.  Add text to clarify the relationship with VPN+ (draft-ietf-teas-enhanced-vpn)
As stated earlier in the adoption thread, the authors believe that the coexistence with other solution architectures for realizing IETF Network slices is outside the scope of this document. This can be tracked with a separate document.

3. Add text to clarify the difference and relationship between NRP topology, (NRP) filter topology and topology filter
Addressing the items 2 and 7 listed in Section 9 will take care of this.

Regards,
Tarek (on behalf of co-authors)

From: Wubo (lana) <lana.wubo@huawei.com>
Date: Monday, May 9, 2022 at 6:40 AM
To: Tarek Saad <tsaad.net@gmail.com>
Cc: Lou Berger <lberger@labn.net>, TEAS WG Chairs <teas-chairs@ietf.org>, draft-bestbar-teas-ns-packet@ietf.org <draft-bestbar-teas-ns-packet@ietf.org>, TEAS WG <teas@ietf.org>
Subject: RE: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Hi Tarek,

Thanks for your reply. These are comments raised during the adoption call. I don't see them covered in the current section 9.

Or could you please elaborate how they are covered by the existing issue items?

Thanks,
Bo
From: Tarek Saad [mailto:tsaad.net@gmail.com]
Sent: Monday, May 9, 2022 12:56 PM
To: Wubo (lana) <lana.wubo@huawei.com>; Dhruv Dhody <dhruv.ietf@gmail.com>
Cc: Lou Berger <lberger@labn.net>; TEAS WG Chairs <teas-chairs@ietf.org>; draft-bestbar-teas-ns-packet@ietf.org; TEAS WG <teas@ietf.org>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hi Bo,

Thanks for your feedback.
The points below have already been captured in Section 9 of the document.

Regards,
Tarek (for the co-authors)

From: Wubo (lana) <lana.wubo@huawei.com<mailto:lana.wubo@huawei.com>>
Date: Saturday, May 7, 2022 at 4:59 AM
To: Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>>, Dhruv Dhody <dhruv.ietf@gmail.com<mailto:dhruv.ietf@gmail.com>>
Cc: Lou Berger <lberger@labn.net<mailto:lberger@labn.net>>, TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>, draft-bestbar-teas-ns-packet@ietf.org<mailto:draft-bestbar-teas-ns-packet@ietf.org> <draft-bestbar-teas-ns-packet@ietf.org<mailto:draft-bestbar-teas-ns-packet@ietf.org>>, TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Subject: RE: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Hi Tarek, all,

There are several other open issues which need to be tracked with this document:
1. Align the architecture with IETF network slice framework draft
2. Add text to clarify the relationship with VPN+ (draft-ietf-teas-enhanced-vpn)
3. Add text to clarify the difference and relationship between NRP topology, (NRP) filter topology and topology filter

Thanks,
Bo
From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Tarek Saad
Sent: Friday, May 6, 2022 11:12 AM
To: Dhruv Dhody <dhruv.ietf@gmail.com<mailto:dhruv.ietf@gmail.com>>
Cc: Lou Berger <lberger@labn.net<mailto:lberger@labn.net>>; TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>; draft-bestbar-teas-ns-packet@ietf.org<mailto:draft-bestbar-teas-ns-packet@ietf.org>; TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hi Dhruv/WG,

- A definition for NRP Domain is needed
[TS]: OK, will add this to the list in the next revision.

- Multi-domain aspects
[TS]: OK, will add this to the list in the next revision.

A new revision (-10) for draft-bestbar-teas-ns-packet has been posted. Item 11 in Section 9 was added to cover the points above.

Regards,
Tarek (for the co-authors)

From: Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>>
Date: Wednesday, April 27, 2022 at 12:33 PM
To: Dhruv Dhody <dhruv.ietf@gmail.com<mailto:dhruv.ietf@gmail.com>>
Cc: Lou Berger <lberger@labn.net<mailto:lberger@labn.net>>, TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>, draft-bestbar-teas-ns-packet@ietf.org<mailto:draft-bestbar-teas-ns-packet@ietf.org> <draft-bestbar-teas-ns-packet@ietf.org<mailto:draft-bestbar-teas-ns-packet@ietf.org>>, TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Thanks Dhruv. See inline.

From: Dhruv Dhody <dhruv.ietf@gmail.com<mailto:dhruv.ietf@gmail.com>>
Date: Wednesday, April 27, 2022 at 5:17 AM
To: Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>>
Cc: Lou Berger <lberger@labn.net<mailto:lberger@labn.net>>, TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>, draft-bestbar-teas-ns-packet@ietf.org<mailto:draft-bestbar-teas-ns-packet@ietf.org> <draft-bestbar-teas-ns-packet@ietf.org<mailto:draft-bestbar-teas-ns-packet@ietf.org>>, TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Hi Tarek,

Thanks for the update. Based on the previous comments, in the open issue list, consider also adding -

- Clear definition and difference between the terms - NRP, NRP topology, and NRP policy is needed.
[TS]: this is covered in Section 9, item 2 and item 7.

- A definition for NRP Domain is needed
[TS]: OK, will add this to the list in the next revision.

- Description of how Slice-Flow aggregate helps in mapping multiple IETF network slices services to an NRP.
[TS]: covered in Section 9, item 2 and item 5.

- Multi-domain aspects
[TS]: OK, will add this to the list in the next revision.

Regards,
Tarek (for co-authors)



Thanks!
Dhruv

On Fri, Mar 4, 2022 at 11:00 PM Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>> wrote:
Hi Dhruv,

Thanks for the review and comments. Please see inline for responses.

From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> on behalf of Dhruv Dhody <dhruv.ietf@gmail.com<mailto:dhruv.ietf@gmail.com>>
Date: Friday, March 4, 2022 at 8:16 AM
To: Lou Berger <lberger@labn.net<mailto:lberger@labn.net>>
Cc: TEAS WG Chairs <teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>>, draft-bestbar-teas-ns-packet@ietf.org<mailto:draft-bestbar-teas-ns-packet@ietf.org> <draft-bestbar-teas-ns-packet@ietf.org<mailto:draft-bestbar-teas-ns-packet@ietf.org>>, TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Hi WG,

This is a viable work for the WG but I do have concerns with the current document. On the high level -

* More work is needed to align terms between NRP, NRP Policy, NRP Topology, NRP Domain(?), Filter topology, Policy Filtered Topology. Some of this needs to be simplified and definitions made crisp and usage consistent.
    *  Also reference to ietf-teas-ietf-network-slices if these terms are meant to be first defined there rather than redefining and changing them.

[TS-VPB]: some of these definitions (including NRP and Filter Topology) are starting to get solidified in draft-ietf-teas-ietf-network-slices (and that is great!). The draft-bestbar-teas-ns-packet will be aligned with those definitions and terms. For other terms (like NRP policy, NRP Topology and NRP Domain) that do not show up in draft-ietf-teas-ietf-network-slices and are needed for the draft-bestbar-teas-ns-packet solution, we have agreed to start an email thread to discuss them further on the list. The term "Policy Filtered Topology" is the same as Filter Topology and shall go away.


* Figure 1 in this I-D and figure 5 in draft-ietf-teas-ietf-network-slices are similar but with some major differences -
    * What you show as SFA, is shown as NRP (which IMHO is the correct representation)
    * How the controller's functionality are demarcated in the two figures
    * Concept of Path Placement
    * What is in the controller view and what is on the devices
    * This alignment needs to be taken care of or suitable text added on why these changes are needed?

[TS-VPB]: yes, as noted in our response to Adrian, there will be alignment to incorporate the high-level constructs presented in the framework. We will add text to illustrate specifics on how the solution is proposing to realize them.


* I understand that we need to allow multiple IETF network slice services to be mapped to an NRP. I am not fully sure how the concept of Slice Flow Aggregate makes this easier. Since this is a new term, we should also think about adding motivation to why this is added and not just what it is.

[TS-VPB]: some text already exists in the draft, but we will expand it to make it clear.


* Filter topology - includes the identification of an existing sub-topology (via MT, FlexAlgo) as well as the creation of a new one by specifying the filter action. The term "topology filters" is not very clear here. Other names such as "Policy Filtered Topology" add to the confusion.
    * Also, this confusion leads to -
        * Is NRP itself a topology? - I think so, that would make the path placement on NRP makes more sense!
        * Or No! The filter topology is the NRP topology?
[TS-VPB]: No, NRP is not a topology. We are aligned with the text proposed from Adrian that clarifies this relationship. Extracted from Adrian's email:
"An NRP is simply a collection of (reserved) resources extracted from the underlying physical network.
The process of determining the NRP may be made easier if the physical network topology is first filtered into a Filter Topology in order to be aware of the subset of network resources that are suitable for specific NRPs."


* NRP Policy - the scope of NRP Policy is claimed to be one instantiated at the device but also claimed to global network-wide. Could there not be a need to have different attributes such as bandwidth setting on a specific link or node in the NRP? Also, section 5.2.4 describe a case where some part of the network is data-plane and the other is control-plane/data-plane combined and thus we would need to have a mechanism to identify those specific nodes. I see the need for node and link-specific NRP attributes apart from the global ones.
[TS-VPB]: indeed, the NRP Policy allows for different attributes to be provisioned on specific network-elements within the NRP through an override option. The draft draft-bestbar-teas-yang-slice-policy (to be renamed to draft-bestbar-teas-yang-nrp-policy) covers this.


* Multi-domain handling - it is not entirely clear how things would work in a multi-domain, multiple controllers world. Is it in scope or not?
[TS-VPB]: yes, the NRP may span multiple domains and it is in scope. We will expand on this in section 5.

* Cleanup of terms -
    * CE-AC-PE points of attachment(?)
    * the connectivity matrix
[TS-VPB]: yes, will do.

Others

* I agree with others that the Abstract needs some cleaning up.
* I agree with Med that currently there is an uncomfortable mix of high-level architecture and deep solution dive only for some sections such as GIS.

[TS-VPB]: please see previous responses on list.

Regards,
Tarek


Thanks!
Dhruv


On Fri, Feb 18, 2022 at 6:58 PM Lou Berger <lberger@labn.net<mailto:lberger@labn.net>> wrote:
Hello,

This email begins a 2-week adoption poll for:
https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/

Please note that IPR has been disclosed on this document:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-ns-packet

Please voice your support or objections to adoption on the list by the end of the day (any time zone) March 4.

Thank you,
Lou (as Co-chair)

_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas