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

Bo,

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

Regards,
-Pavan (as co-author)

On Wed, Feb 23, 2022 at 8:02 PM Wubo (lana) <lana.wubo@huawei.com> wrote:

> Hi Pavan,
>
>
>
> Thanks for your reply. Please see inline for my further comments.
>
>
>
> Thanks,
>
> Bo
>
>
>
> *发件人:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
> *发送时间:* 2022年2月23日 22:29
> *收件人:* Wubo (lana) <lana.wubo@huawei.com>
> *抄送:* Lou Berger <lberger@labn.net>; TEAS WG <teas@ietf.org>; TEAS WG
> Chairs <teas-chairs@ietf.org>; draft-bestbar-teas-ns-packet@ietf.org
> *主题:* 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=
> 40huawei.com@dmarc.ietf.org> 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”.*
>
>
>

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

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

[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:teas-bounces@ietf.org] 代表 Lou Berger
> > 发送时间: 2022年2月18日 21:28
> > 收件人: TEAS WG <teas@ietf.org>
> > 抄送: TEAS WG Chairs <teas-chairs@ietf.org>;
> > draft-bestbar-teas-ns-packet@ietf.org
> > 主题: [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
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
>