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

From: "Wubo (lana)" <[email-masked]>
Date: Thu, 24 Feb 2022 02:02:49 +0000

Hi Pavan,

Thanks for your reply. Please see inline for my further comments.

Thanks,
Bo

发件人: Vishnu Pavan Beeram [mailto:[email-masked]]
发送时间: 2022年2月23日 22:29
收件人: Wubo (lana) <[email-masked]>
抄送: Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; TEAS WG Chairs <[email-masked]>; [email-masked]
主题: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Bo,

Please see inline for responses (prefixed VPB)..

Regards,
-Pavan (on behalf of the authors)

On Wed, Feb 23, 2022 at 6:39 AM Wubo (lana) <lana.wubo=[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

I have read the draft and have some questions with the text and terms.

1. This document seems only define SFA (slice-flow aggregation) based mapping solution, that is, slice services mapping to SFAs, and SFAs to NRP(Network Resource Partition)s.
If this draft is supposed to be a generic slicing realization document, I think, it should allow more options. For example, the slice services could be mapped to VPNs, and
VPNs mapped to underlying resources with method described in draft-ietf-teas-te-service-mapping-yang.

[VPB] Please refer to section 5.3 (https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-08#section-5.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-08*section-5.3__;Iw!!NEt6yMaO-gk!RKgzM9K5I6Crs9-9OkxWcIvs0atMYM1O1zZWrRa009HkrnmqRqcVdrJg4EU6Aib-$>). It does note that the usual techniques for steering service traffic onto paths are applicable -- the example that you cite is certainly allowed. We can add a reference to draft-ietf-teas-te-service-mapping-yang in this section and make it explicit.

[Bo Wu] Thanks for the clarification, but my concerns are not just about Section 5.3. Taking Section 3.3 as an example,  Slice-Flow Aggregation Mapping, there are also multiple sections titled with SFA. I hope that the name can be changed to  "slice service mapping”  or “slice service flow mapping" and the options described in section 5.3 can also be reflected in those sections. Otherwise, as Med suggested, maybe the draft name could be changed to “Realizing Network Slices in IP/MPLS Networks supporting SFA”.

2. This draft refers to draft-bestbar-teas-yang-slice-policy, but the following definition are not consistent:
1) SFA is not defined in draft-bestbar-teas-yang-slice-policy, but is seems relevant from the definition. And I can't find NRP Policy selection Criteria in the model definition.
Slice-Flow Aggregate: a collection of packets that match an NRP Policy selection criteria and are given the same forwarding treatment ;

2) draft-bestbar-teas-yang-slice-policy defines Slice Selector, but apart from Slice Selector, this draft also defines FAS and FASL. It is recommended that the terms be consistent.
FAS: Flow Aggregate Selector; FASL: Flow Aggregate Selector Label.

[VPB] The last two comments above are for the NRP policy data model draft (Thanks for bringing it up!). We agree that the NRP policy data model draft needs to be updated to be in sync with the current terminology used in draft-bestbar-teas-ns-packet. This should get done in the next few days. But please note that the NRP policy data model draft is not the one that is currently being polled for adoption.
[Bo Wu] I'm sorry my question is not clear. Let me rephrase it. As described in the document, the SFA is maintained by the controller, which means that the data plane within the device is not SFA aware. Then could you explain the reason of defining  FAS and FASL? And what are the differences between them and Network Resource Partition Data Plane Selector?

Thanks,
Bo
> -----邮件原件-----
> 发件人: Teas [mailto:[email-masked]<mailto:[email-masked]>] 代表 Lou Berger
> 发送时间: 2022年2月18日 21:28
> 收件人: TEAS WG <[email-masked]<mailto:[email-masked]>>
> 抄送: TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>
> 主题: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
>
> 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-n
> s-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
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Feb 2022 21:09:55 -0500

I am not understanding your concern Wubo.  Apologies.
Please allow me to explain where it seems I am missing, and maybe you 
can clarify.

We refer to the construct in teh draft as a slice flow aggregate so as 
to emphasis and remind all readers that this component can carry 
multiple external slices.

Having said that, as a deployment option, it is always possible for an 
operator to use one slice flow aggregate for each external network slice 
(of whatever kind).  While I am concerned about the scaling of such an 
approach, it is clearly permitted and supported by the approach describe 
in the draft.

Yours,
Joel

On 2/23/2022 9:02 PM, Wubo (lana) wrote:
> *发件人:*Vishnu Pavan Beeram [mailto:[email-masked]]
> *发送时间:*2022年2月23日22:29
> *收件人:*Wubo (lana) <[email-masked]>
> *抄送:*Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; TEAS WG 
> Chairs <[email-masked]>; [email-masked]
> *主题:*Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
> 
> Bo,
> 
> On Wed, Feb 23, 2022 at 6:39 AM Wubo (lana) 
> <lana.wubo=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi all,
> 
>     1. This document seems only define SFA (slice-flow aggregation)
>     based mapping solution, that is, slice services mapping to SFAs, and
>     SFAs to NRP(Network Resource Partition)s.
>     If this draft is supposed to be a generic slicing realization
>     document, I think, it should allow more options. For example, the
>     slice services could be mapped to VPNs, and
> [VPB] Please refer to section 5.3 
> (https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-08#section-5.3 
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-08*section-5.3__;Iw!!NEt6yMaO-gk!RKgzM9K5I6Crs9-9OkxWcIvs0atMYM1O1zZWrRa009HkrnmqRqcVdrJg4EU6Aib-$>). 
> It does note that the usual techniques for steering service traffic onto 
> paths are applicable -- the example that you cite is certainly 
> allowed. We can add a reference to 
> draft-ietf-teas-te-service-mapping-yang in this section and make it 
> explicit.
> 
> */[Bo Wu] Thanks for the clarification, but my concerns are not just 
> about Section 5.3. Taking Section 3.3 as an example,  Slice-Flow 
> Aggregation Mapping, there are also multiple sections titled with SFA. I 
> hope that the name can be changed to  "slice service mapping”  or “slice 
> service flow mapping" and the options described in section 5.3 can also 
> be reflected in those sections. Otherwise, as Med suggested, maybe the 
> draft name could be changed to “Realizing Network Slices in IP/MPLS 
> Networks supporting SFA”./*
> 
> 
>     2. This draft refers to draft-bestbar-teas-yang-slice-policy, but
>     the following definition are not consistent:
>     1) SFA is not defined in draft-bestbar-teas-yang-slice-policy, but
>     is seems relevant from the definition. And I can't find NRP Policy
>     selection Criteria in the model definition.
>     Slice-Flow Aggregate: a collection of packets that match an NRP
>     Policy selection criteria and are given the same forwarding treatment ;
> 
>     2) draft-bestbar-teas-yang-slice-policy defines Slice Selector, but
>     apart from Slice Selector, this draft also defines FAS and FASL. It
>     is recommended that the terms be consistent.
> [VPB] The last two comments above are for the NRP policy data model 
> draft (Thanks for bringing it up!). We agree that the NRP policy data 
> model draft needs to be updated to be in sync with the current 
> terminology used in draft-bestbar-teas-ns-packet. This should get done 
> in the next few days. But please note that the NRP policy data model 
> draft is not the one that is currently being polled for adoption.
> 
> */[Bo Wu] I'm sorry my question is not clear. Let me rephrase it. As 
> described in the document, the SFA is maintained by the controller, 
> which means that the data plane within the device is not SFA aware. Then 
> could you explain the reason of defining  FAS and FASL? And what are the 
> differences between them and Network Resource Partition Data Plane 
> Selector? /*
> 
> 
>     Thanks,
>     Bo
>     > -----邮件原件-----
>     > 发件人: Teas [mailto:[email-masked]
>     <mailto:[email-masked]>] 代表Lou Berger
>     > 发送时间: 2022年2月18日21:28
>     > 收件人: TEAS WG <[email-masked] <mailto:[email-masked]>>
>     > [email-masked]
>     <mailto:[email-masked]>
>     <https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/>
>     > 
>     <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-n>
>     > s-packet
>     > 
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
> 
> 
> [email-masked]

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 24 Feb 2022 03:48:26 -0600

Bo,

Please see inline for responses (prefixed [Pavan]).

Regards,
-Pavan (as co-author)

On Wed, Feb 23, 2022 at 8:02 PM Wubo (lana) <[email-masked]> wrote:

> *发件人:* Vishnu Pavan Beeram [mailto:[email-masked]]
> *发送时间:* 2022年2月23日 22:29
> *收件人:* Wubo (lana) <[email-masked]>
> *抄送:* Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; TEAS WG
> *主题:* Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
>
>
>
> Bo,
>
>
>
> On Wed, Feb 23, 2022 at 6:39 AM Wubo (lana) <lana.wubo=
> [email-masked]> wrote:
>
> Hi all,
>
> 1. This document seems only define SFA (slice-flow aggregation) based
> mapping solution, that is, slice services mapping to SFAs, and SFAs to
> NRP(Network Resource Partition)s.
> If this draft is supposed to be a generic slicing realization document, I
> think, it should allow more options. For example, the slice services could
> be mapped to VPNs, and
> [VPB] Please refer to section 5.3 (
> https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-08#section-5.3
> paths are applicable -- the example that you cite is certainly allowed. We
> can add a reference to draft-ietf-teas-te-service-mapping-yang in this
> section and make it explicit.
>
> *[Bo Wu] Thanks for the clarification, but my concerns are not just about Section 5.3. Taking Section 3.3 as an example,  Slice-Flow Aggregation Mapping, there are also multiple sections titled with SFA. I hope that the name can be changed to  "slice service mapping”  or “slice service flow mapping" and the options described in section 5.3 can also be reflected in those sections. Otherwise, as Med suggested, maybe the draft name could be changed to “Realizing Network Slices in IP/MPLS Networks supporting SFA”.*
>
>
>

[Pavan] Service Mapping (mapping service traffic to the underlay path) is
an essential component in the slice service realization process that is
administered at the edge points. This is introduced in Section 3.7 in the
current version of the document and is further described in Section 5.3. As
mentioned earlier, Section 5.3 allows for all existing service mapping
techniques (and any new ones if/when proposed) to be employed. The existing
techniques allow the mapping of service traffic to underlay paths to be
done directly or with some level of indirection.

[Pavan] What is discussed in Section 3.3 is the need to aggregate multiple
IETF network slice traffic streams for better scaling. The definition of
the SFA allows it to comprise traffic from just one IETF network slice, but
the expectation (as has been stated before) is that this wouldn’t be the
norm.

> 1) SFA is not defined in draft-bestbar-teas-yang-slice-policy, but is
> seems relevant from the definition. And I can't find NRP Policy selection
> Criteria in the model definition.
> Slice-Flow Aggregate: a collection of packets that match an NRP Policy
> selection criteria and are given the same forwarding treatment ;
>
> 2) draft-bestbar-teas-yang-slice-policy defines Slice Selector, but apart
> from Slice Selector, this draft also defines FAS and FASL. It is
> recommended that the terms be consistent.
> [VPB] The last two comments above are for the NRP policy data model draft
> (Thanks for bringing it up!). We agree that the NRP policy data model draft
> needs to be updated to be in sync with the current terminology used in
> draft-bestbar-teas-ns-packet. This should get done in the next few days.
> But please note that the NRP policy data model draft is not the one that is
> currently being polled for adoption.
>
> *[Bo Wu] I'm sorry my question is not clear. Let me rephrase it. As
> described in the document, the SFA is maintained by the controller, which
> means that the data plane within the device is not SFA aware. Then could
> you explain the reason of defining  FAS and FASL? And what are the
> Selector? *

[Pavan] For the deployment scenarios where the device needs to provide
specific treatment for the slice flow aggregate traffic, the packets are
classified and “marked” at the edge nodes and the interior nodes rely on
these “markings” to provide the necessary treatment. We are using the term
Flow Aggregate Selector (FAS) to denote this marking (which is independent
of any other traditional marking -- like TC in an MPLS packet).  An
interior node that is providing the necessary treatment based on the FAS
does NOT need to know which specific IETF network slice traffic streams
have been mapped onto the aggregate. But it does need to know what specific
marking to look for in the packet and what specific treatment to provide
for the SFA. This information is provided by the NRP policy (supporting the
SFA) available on the device. Section 5.1.1 (the title of which you are
referring to) discusses the component in the NRP policy definition which
specifies the FAS. And, Section 5.1.3 discusses the component in the NRP
policy definition which specifies the treatment. Also, please do note that
the use of the FAS is not mandatory; the document also discusses deployment
scenarios (Section 4.2) where the FAS is not used.

>
> Thanks,
> Bo
> > -----邮件原件-----
> > 发件人: Teas [mailto:[email-masked]] 代表 Lou Berger
> > 发送时间: 2022年2月18日 21:28
> > 收件人: TEAS WG <[email-masked]>
> > 抄送: TEAS WG Chairs <[email-masked]>;