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

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

Hi Joel, 

Thank you for your reply. In my opinion, what you're saying is different from the reply of Pavan about aggregating multiple NS services.
Your view is:             NS (n:1) -> slice flow aggregate (SFA) (n:1) -->NRP
Section 5.3 (from Pavan):   NS -> VPN-> SFA -->NRP
My understanding, and Med also pointed out:  NS (n:1) -> VPN (n:1) -> TE-topology/TE-tunnel/SR-policy/NRP etc.

And the document also says:
The mechanisms used by the controller to determine the mapping of one or more IETF network slice to a Slice-Flow Aggregate are outside the scope of this document.

Therefore, slice flow aggregate does not appear to be a necessary for NS realization. As the draft is intended as a general solution document, I think the SFA is not needed, and it could cause some misunderstanding.

Thanks,
Bo
> -----邮件原件-----
> 发件人: Joel M. Halpern [mailto:[email-masked]]
> 发送时间: 2022年2月24日 10:10
> 收件人: Wubo (lana) <[email-masked]>; Vishnu Pavan Beeram
> <[email-masked]>
> 抄送: TEAS WG <[email-masked]>
> 主题: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
> 
> 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:
> > 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-best
> bar-teas-ns-packet-08*section-5.3__;Iw!!NEt6yMaO-gk!RKgzM9K5I6Crs9-9Ok
> xWcIvs0atMYM1O1zZWrRa009HkrnmqRqcVdrJg4EU6Aib-$>).
> > 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/
> >     <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
> >
> <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
> >     <https://www.ietf.org/mailman/listinfo/teas>
> >     _______________________________________________
> >     Teas mailing list
> >     [email-masked] <mailto:[email-masked]>
> >     https://www.ietf.org/mailman/listinfo/teas
> >     <https://www.ietf.org/mailman/listinfo/teas>
> >
> >
> > _______________________________________________
> > Teas mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/teas

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 24 Feb 2022 13:40:10 -0600

Bo, Hi!

I hope my previous email (addressed to you) would have helped clarify
the questions on "service mapping".

Please see inline (prefixed [Vishnu]) for point responses to your latest
email.

Regards,
- Pavan (as co-author)

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

> Hi Joel,
>
> Thank you for your reply. In my opinion, what you're saying is different
> from the reply of Pavan about aggregating multiple NS services.
>

[Vishnu] I'm in complete agreement with Joel's responses (I don't see how
any of my responses contradict what he said).

> Section 5.3 (from Pavan):   NS -> VPN-> SFA -->NRP

[Vishnu]  You seem to have made some incorrect inferences from Section 5.3
and I hope the previous responses would have helped clarify this. Section
5.3 does discuss multiple examples of how existing techniques for steering
service traffic onto underlay paths (TE tunnel / SR policy) can be used.
These underlay paths may carry traffic associated with multiple Slice-Flow
Aggregates.

> The mechanisms used by the controller to determine the mapping of one or
> more IETF network slice to a Slice-Flow Aggregate are outside the scope of
> this document.
>
> Therefore, slice flow aggregate does not appear to be a necessary for NS
> realization. As the draft is intended as a general solution document, I
> think the SFA is not needed, and it could cause some misunderstanding.
>
> Thanks,
> Bo
> > -----邮件原件-----
> > <
> https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-best
> > <
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-
> > n>
> > >     > s-packet
> > >     >