Re: [Teas] I-D Action: draft-bestbar-teas-ns-packet-09.txt

[Tarek Saad <[e-mail]>]

Hi Zhibo,

Please see inline..

From: Teas <[e-mail]> on behalf of Huzhibo <huzhibo=[e-mail]>
Date: Thursday, April 28, 2022 at 11:58 AM
To: Tarek Saad <[e-mail]>, TEAS WG <[e-mail]>
Cc: TEAS WG Chairs <[e-mail]>, draft-bestbar-teas-ns-packet <[e-mail]>
Subject: Re: [Teas] I-D Action: draft-bestbar-teas-ns-packet-09.txt
Hi all,

I've read the update version and think there are still issues which could impede correct understanding of the network slice realization and the required functionality on network nodes. It would be good if these issues can be solved in an update version before the adoption.

1. Slice-Flow Aggregate (SFA) and NRP

In my understanding the concept Slice-Flow Aggregate is to describe an optional behavior on the controller or the ingress node which can group multiple network traffic flows together. But the relationship between SFA and NRP is still not clear from the document. During the adoption call discussion, it seems the conclusion is that there is one-to-one mapping of SFA to NRP. If this is the case, it is better to make it explicit in the draft.
[TS]: Yes, clarifying the relation between SFA and NRP is tracked in Section 9, item 2 of the open issues.

My greatest concern is that in several places in the document, the description indicates that transit nodes also need to be aware of the mapping of slice flows to SFA, which apparentely is not true.

For example, section 4.1 says:

   "In the data plane NRP mode, the transit nodes within an NRP domain use the FAS to associate packets with a Slice-Flow Aggregate and to determine the Network Resource Partition Per Hop Behavior (NRP-PHB) that is applied to the packet."

The transit nodes do not need to know how the packet is mapped to an NRP, thus they are not aware of the SFA. What they need to do is to use some identifier in the packet to determine the corresponding NRP and forward the packet according to the NRP's forwarding behavior. Thus Slice-Flow Aggregate does not need to be mentioned in the text about transit nodes behavior.
[TS]: what the text is saying is that a packet that belongs to a specific SFA carries a FAS in it. The FAS is used by nodes in the network to associate the packet to the NRP.

In the document there are many other occurrence of SFA where it was actually talking about NRP. My suggestion is to only use SFA in the description of the traffic aggregation procedure.
[TS]: the SFA resembles the traffic packets. The NRP is the set of network resources. The two are related but are different. As noted above, the clarification of relationship between SFA and NRP is tracked in item 2 of Section 9.


2. Flow Aggregate Selector (FAS) / G-FAS or NRP-ID

During the adoption call, there was comment that NRP-ID is essentially the same as FAS and G-FAS, and it was suggested to simplify the mapping between different terms/components.
[TS]: As responded to during adoption, the FAS can take multiple forms (the document describes several). Carrying a global ID (G-FAS) is just one form of FAS.

Regards,
Tarek (for the co-authors)

According to the example above, the FAS is used by the transit nodes to determine the NRP, thus it makes more sense to call it NRP-ID or NRP specific IDs directly.

thanks

zhibo


________________________________

胡志波 Hu Zhibo
Mobile: [phone]
Email: [e-mail]
发件人：Tarek Saad <[e-mail]>
收件人：TEAS WG <[e-mail]>
抄 送：TEAS WG Chairs <[e-mail]>;draft-bestbar-teas-ns-packet <[e-mail]>
时 间：2022-04-22 21:27:12
主 题：Re: [Teas] I-D Action: draft-bestbar-teas-ns-packet-09.txt

Dear WG and Chairs,

We have made changes to I-D.draft-bestbar-teas-ns-packet to address comments that were received during the working group adoption poll for the revision -08 of this draft.

The changes include:

  *   Removing references to work-in-progress drafts
  *   Moving status of the draft to informational
  *   Adding Section 9 to record non-blocking issues raised during the WG adoption poll
  *   Some editorial nits, including fixing RFC2119 language.

We welcome further review and feedback.

Regards,
Tarek (for co-authors)


From: Teas <[e-mail]> on behalf of [e-mail] <[e-mail]>
Date: Thursday, April 21, 2022 at 5:56 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [Teas] I-D Action: draft-bestbar-teas-ns-packet-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF.

        Title           : Realizing Network Slices in IP/MPLS Networks
        Authors         : Tarek Saad
                          Vishnu Pavan Beeram
                          Jie Dong
                          Bin Wen
                          Daniele Ceccarelli
                          Joel Halpern
                          Shaofu Peng
                          Ran Chen
                          Xufeng Liu
                          Luis M. Contreras
                          Reza Rokui
                          Luay Jalil
        Filename        : draft-bestbar-teas-ns-packet-09.txt
        Pages           : 31
        Date            : 2022-04-21

Abstract:
   Realizing network slices may require the Service Provider to have the
   ability to partition a physical network into multiple logical
   networks of varying sizes, structures, and functions so that each
   slice can be dedicated to specific services or customers.  Multiple
   network slices can be realized on the same network while ensuring
   slice elasticity in terms of network resource allocation.  This
   document describes a scalable solution to realize network slicing in
   IP/MPLS networks by supporting multiple services on top of a single
   physical network by relying on compliant domains and nodes to provide
   forwarding treatment (scheduling, drop policy, resource usage) on to
   packets that carry identifiers that indicate the slicing service that
   is to be applied to the packets.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-09


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas