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

[Huzhibo <[e-mail]>]

Hi Tarek,

Thanks for your response. Please see further inline:
From: Tarek Saad [mailto:[e-mail]]
Sent: Saturday, April 30, 2022 12:36 AM
To: Huzhibo <[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 Zhibo,

Please see inline..

From: Teas <[e-mail]<mailto:[e-mail]>> on behalf of Huzhibo <huzhibo=[e-mail]<mailto:huzhibo=[e-mail]>>
Date: Thursday, April 28, 2022 at 11:58 AM
To: Tarek Saad <[e-mail]<mailto:[e-mail]>>, TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>, draft-bestbar-teas-ns-packet <[e-mail]<mailto:[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.

[Zhibo] OK, it would be very useful to clarify the relationship between SFA and NRP in the draft.

Another suggestion is the text needs to clarity that SFA is just one of the mechanisms to the map network slice traffic to NRP. This was also mentioned by others during the adoption call.

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.

[Zhibo]: The problem with this statement is that the transit nodes do not have any information about the Slice Flow Aggregation process, they only maintains NRP states. What they need is simply an identifier which is associated with the NRP.  I’d suggest to make the text straightforward to avoid further confusion.

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.

[Zhibo] Indeed they are related but different. The clarification is needed, and more important is to use the suitable term throughout the document.

Currently there are many places in the draft where both terms appear in the same sentence, these are at least redundant and could also cause confusions to people:

    The SR architecture defines a number of building blocks that can be leveraged to support the realization of NRPs that support Slice-Flow Aggregates in an SR network.

In such case, the same physical network resource capacity is divided among multiple NRPs that support multiple Slice-Flow Aggregates.

The control plane partitioning allows the creation of customized topologies per NRP that each supports a Slice-Flow Aggregate.

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.


[Zhibo] I think you are answering to a different question. My question is whether it is more straightforward to call the identifier NRP ID/Selector (can be either global or local significant), or couple the term with Slice-Flow Aggregation? This is also related to my previous comment: are the transit nodes aware of NRP or Slice-Flow Aggregate?

Best regards,
Zhibo

________________________________

胡志波 Hu Zhibo
Mobile: [phone]
Email: [e-mail]<mailto:[e-mail]>
发件人：Tarek Saad <[e-mail]<mailto:[e-mail]>>
收件人：TEAS WG <[e-mail]<mailto:[e-mail]>>
抄 送：TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>;draft-bestbar-teas-ns-packet <[e-mail]<mailto:[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]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Thursday, April 21, 2022 at 5:56 PM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas