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

["Wubo (lana)" <[e-mail]>]

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:[e-mail]]
> 发送时间: 2022年2月24日 10:10
> 收件人: Wubo (lana) <[e-mail]>; Vishnu Pavan Beeram
> <[e-mail]>
> 抄送: TEAS WG <[e-mail]>
> 主题: 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:[e-mail]]
> > *发送时间:*2022年2月23日22:29
> > *收件人:*Wubo (lana) <[e-mail]>
> > *抄送:*Lou Berger <[e-mail]>; TEAS WG <[e-mail]>; TEAS
> WG
> > Chairs <[e-mail]>; [e-mail]
> > *主题:*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=[e-mail]
> > <mailto:[e-mail]>> 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:[e-mail]
> >     <mailto:[e-mail]>] 代表Lou Berger
> >     > 发送时间: 2022年2月18日21:28
> >     > 收件人: TEAS WG <[e-mail] <mailto:[e-mail]>>
> >     > 抄送: TEAS WG Chairs <[e-mail]
> >     <mailto:[e-mail]>>;
> >     > [e-mail]
> >     <mailto:[e-mail]>
> >     > 主题: [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
> >     > [e-mail] <mailto:[e-mail]>
> >     > https://www.ietf.org/mailman/listinfo/teas
> >     <https://www.ietf.org/mailman/listinfo/teas>
> >     _______________________________________________
> >     Teas mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/teas
> >     <https://www.ietf.org/mailman/listinfo/teas>
> >
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/teas