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

[Vishnu Pavan Beeram <[e-mail]>]

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) <[e-mail]> 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).


> Your view is:             NS (n:1) -> slice flow aggregate (SFA) (n:1)
> -->NRP
> 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.


> 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
>