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

Bo,

Please see inline (prefixed VPKB)

Regards,
-Pavan

On Mon, Feb 28, 2022 at 6:34 AM Wubo (lana) <lana.wubo@huawei.com> wrote:

> Hi Pavan,
>
>
>
> Thanks for the editorial changes. I think there is still one major issue.
> Renaming the title of 5.1.1  to "Network Resource Partition -
> Flow-Aggregate Selector" does not make the problem going away.
>
> This document references the Diffserv model, Class Selector Codepoint (CS)
> used by transit nodes to apply the PHB. Therefore, the NRP-PHB (5.1.3)
> definition also requires the NRP DP selector.
>

[VPKB]  If you want to provide forwarding treatment only based on
traditional "markings", there is no need to specify the NRP-PHB in the NRP
Policy.

In addition, if an NS service does not need aggregation, the NRP DP
> selector is also required to determine the NRP-PHB's handling of the NS.
>

[VPKB] As noted earlier, the slice-flow aggregate includes traffic streams
from ONE or more connectivity constructs (belonging to one or more IETF
network slices) mapped to a specific NRP.

> Therefore, I still believe the following changes needed:
>
> 1. Leave the name of 5.1.1.  Network Resource Partition Data Plane
> Selector as it is
>
> 2. Add Network slice - Network Resource Partition mapping in new chapter 6 (from 5.3 <https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-08#section-5.3>.Mapping Traffic on Slice-Flow Aggregates). When slicing services do not need aggregation, NS->NRP is required.
>
> [VPKB] As mentioned in our response to Adrian, the relationship between
the SFA and the NRP will be clarified further in the beginning of the
document. That plus the service mapping specific details that we agreed to
make in the new Section 6 should address your concerns.

>
>
> Thanks,
>
> Bo
>
>
>
> *发件人:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
> *发送时间:* 2022年2月26日 7:07
> *收件人:* 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, Hi!
>
>
>
> Good to see that we are down to minor editorial issues (Thanks!).
>
>
>
> Please see inline (prefixed [Beeram]) for responses..
>
>
>
> Regards,
>
> -Pavan (as co-author)
>
>
>
> On Fri, Feb 25, 2022 at 4:37 AM Wubo (lana) <lana.wubo@huawei.com> wrote:
>
> Hi Pavan,
>
>
>
> Thank you for clarifying my question. I still see some minor issues, and
> hope the text could be clearer. Please see in line with [wubo2].
>
>
>
> Regards,
>
> Bo
>
>
>
> *发件人:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
> *发送时间:* 2022年2月24日 17:48
> *收件人:* 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 [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.
>
> *[Bo Wu 2] I agree that service mapping is essential. That is the reason I
> suggest the section title could be changed to Slice Service Mapping. *
>
> *Since  several places in the document  say VPN service mapping to SFA,
> section 3.3 does not describe how to map a NS service to a VPN service,
> then aggregate to SFA.*
>
>
>
>
>
> [Beeram] We'll make the following changes to address this:
>
> - Rename Section 3.3 to "Slice-Flow Aggregation" (this section just
> describes the need for aggregation)
>
> - Add a sentence at the end of Section 3.7 saying: "Steering of traffic
> onto Slice-Flow Aggregate paths is further described in Section 5.3"
>
> - Let Section 5.3  describe how the steering of traffic onto the paths
> gets done.
>
>
>
>
>
> *One more question on section 5.3. It seems that  the name of Section 5.3
> does not look right. Section 5 is about NRP instantiation, maybe  the name
> of section 5.3 better change to Mapping Traffic on NRP?  Looking at current
> text of Section 5.3, it seems not relevant with NRP, or does it mean that
> NRP instantiation must be triggered by an SFA traffic mapping?*
>
>
>
> [Beeram] We'll move this sub-section out of Section 5 (make it Section 6).
>
>
>
>
> 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.
>
>
>
> *[Bo Wu 2] Thank you for clarifying, but  section 5.1.1* *is about the
> Network Resource Partition Data Plane Selector, right?  Could you add more
> text of the NRP Data Plane Selector because the devices in the NRP domain
> needs the NRP-ID and identify the NRP-specific network resources?  It also
> helps if some text can be added to describe when to use the NRP selector
> and when to use the FAS?*
>
>
>
> [Beeram] I believe the following change would remove the confusion --
> Rename Section 5.1.1 to "Network Resource Partition - Flow-Aggregate
> Selector".
>
>
>
>
>
>
> 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
>
>