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.

* 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?

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

* 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?

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

* 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?

* Cleanup of terms -
    * CE-AC-PE points of attachment(?)
    * the connectivity matrix

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.

Thanks!
Dhruv

On Fri, Feb 18, 2022 at 6:58 PM Lou Berger <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
> https://www.ietf.org/mailman/listinfo/teas
>