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

Hi Dhruv,

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

From: Teas <teas-bounces@ietf.org> on behalf of Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Friday, March 4, 2022 at 8:16 AM
To: Lou Berger <lberger@labn.net>
Cc: 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 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