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

[Dhruv Dhody <[e-mail]>]

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.
- A definition for NRP Domain is needed
- Description of how Slice-Flow aggregate helps in mapping multiple IETF
network slices services to an NRP.
- Multi-domain aspects

Thanks!
Dhruv

On Fri, Mar 4, 2022 at 11:00 PM Tarek Saad <[e-mail]> wrote:

> Hi Dhruv,
>
>
>
> Thanks for the review and comments. Please see inline for responses.
>
>
>
> *From: *Teas <[e-mail]> on behalf of Dhruv Dhody <
> [e-mail]>
> *Date: *Friday, March 4, 2022 at 8:16 AM
> *To: *Lou Berger <[e-mail]>
> *Cc: *TEAS WG Chairs <[e-mail]>,
> [e-mail] <
> [e-mail]>, TEAS WG <[e-mail]>
> *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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
>