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

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

* Resending (ignore the previous email; it got clipped somehow)


Adrian,
> Thanks for the follow-up comments! Please see inline for responses
> (prefixed [VPB-TS]).
>
> Regards,
> -Pavan and Tarek
>
> On Wed, Mar 2, 2022 at 5:23 AM Adrian Farrel <[e-mail]> wrote:
>
>> Thanks for all the responses, Tarek and Pavan, progress is being made.
>>
>>
>>
>> Please don’t mistake “you need to fix this before adoption” for “my
>> greatest concern.”
>>
>
>  [VPB-TS]: Got it.
>
>
>>
>> You correctly interpreted my email that said, “There is one thing I
>> think must be fixed as part of adoption,” to mean that there is something
>> that I believe needs to be resolved as part of adopting this document. I’m
>> glad to hear that you will be resolving that by moving a number of
>> references to Informative.
>>
>>
>>
>> On the other hand, I’d say that my greatest concern is failure to align
>> with draft-ietf-teas-ietf-network-slices. I am not comforted by you saying
>> that you intend to be aligned, and I hope you will go ahead and realise
>> your intentions.
>>
>
> [VPB-TS]: As noted previously, we are cognizant of the need to maintain
> alignment with the framework as it goes through changes (the recent changes
> available in -06 do make things easier for us; Thanks for that!). We'll fix
> the specific comments.
>
>
>> More in line…
>>
>>
>>
>> Best,
>>
>> Adrian
>>
>>
>>
>> *From:* Tarek Saad <[e-mail]>
>> *Sent:* 02 March 2022 05:27
>> *To:* [e-mail]; 'Lou Berger' <[e-mail]>; 'TEAS WG' <
>> [e-mail]>
>> *Cc:* 'TEAS WG Chairs' <[e-mail]>;
>> [e-mail]
>> *Subject:* Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
>>
>>
>>
>
> Snipped..
>
>>
>> There is one thing I think must be fixed as part of adoption: the
>> references to draft-bestbar-teas-yang-slice-policy and draft-kompella-
>> mpls-mspl4fa. These are presented as normative references and there is
>> an implication that adopting this document would somehow give credence
>> to those two documents. Fortunately, the references to draft-bestbar-
>> teas-yang-slice-policy are clearly not normative, and are also not
>> particularly relevant so they could be removed completely. Further,
>> since the document purports to be technology-agnostic it would make
>> sense not to make reference to the still-contentious draft-kompella-
>> mpls-mspl4fa: if the authors want to, they could write a separate
>> document called "Applicability of MSPL4FA for carrying the GIS".
>> [See later note for why it is called the GIS.]
>>
>>
>>
>>
>> [TS-VPB]: As noted, we’ll make the references to related ongoing work be
>> informative.
>>
>>
>>
>> [AF] I hope you’ll also look at why you need the references at all and,
>> since you have made a very selective choice of references, either add some
>> more (possibly the solutions you don’t like should also be listed) or
>> remove some of the references you have.
>>
>
> [VPB-TS] Sure.
>
> Snipped..
>
>>
>>
>>
>> It is quite worrying that this document attempts by design or accident
>> to modify the architecture described in draft-ietf-teas-ietf-network-
>> slices. In particular, compare draft-ietf-teas-ietf-network-slices
>> figure 5 with figure 1 in this document. But there are plenty of other
>> examples.
>>
>>
>> [TS-VPB]: The intention is for this document to be aligned with the
>> concepts/architecture defined in the framework document
>> draft-ietf-teas-ietf-network-slices. Figure 1 in this document (and the
>> whole of Section 3) is an attempt to describe how this solution fits into
>> the architecture outlined in Figure 5 of
>> draft-ietf-teas-ietf-network-slices.
>>
>>
>>
>> [AF] Well, at the very least, the text might say that. In other words
>> “While Figure 5 of draft-ietf-teas-ietf-network slices provides an abstract
>> architecture, this section intends to offer a realization of that
>> architecture specific for IP/MPLS packet networks.” However, I still don’t
>> understand why you feel the need to introduce new terms, redefine terms,
>> and introduce new functional elements.
>>
>>
>>
>
> [VPB-TS]: We’ll add a statement to that effect.
>
>
>> ---
>>
>> I am puzzled that this document makes no reference to draft-ietf-teas-
>> enhanced-vpn. That, too, is work that explains how to deliver a network
>> slice over an IP/MPLS network. And since it is already a working group
>> draft, one might expect this document to show how it fits in alongside
>> VPN+. (I fully accept that there may be space for both approaches, but
>> it is peculiar to make no attempt, and I expect the newcomer - this
>> document - to be the one that shows the coexistence.)
>>
>>
>> [TS-VPB]: This is a stand-alone solution document. We believe discussion
>> of the co-existence with other approaches can be tackled in a separate
>> document.
>>
>>
>>
>> [AF] It is clearly not a stand-alone solution document. Look at all of
>> the references you make to other solutions documents (c.f. the discussion
>> on references and email thread with Med).
>>
>
> [VPB-TS]: As noted earlier, we’ll address the concern related to
> references.
>
>
>>
>> [AF] You might look at the VPN+ framework and learn from it about how to
>> separate discussion of a general approach from solution details.
>>
>>
>> ---
>>
>>
>> Please throw out the Abstract and replace it with something coherent.
>> I have read and re-read the current text and can find nothing else
>> useful to say about it!
>>
>>
>>
>> [TS-VPB]: Ouch! How about the following revised text:
>>
>>
>>
>> NEW:
>>
>> Realizing Network slices requires the Service Provider to have the
>> ability to partition a physical network into multiple logical networks of
>> varying sizes, structures, and functions so that each slice can be
>> dedicated to specific services or customers. Multiple network slices can be
>> realized on the same network while ensuring slice elasticity in terms of
>> network resource allocation. The Differentiated Service (Diffserv) model
>> allows for carrying multiple services on top of a single physical network
>> by relying on compliant domains and nodes to provide forwarding treatment
>> (scheduling and drop policy) on to packets that carry the respective
>> Diffserv code point.  This document adopts a similar approach to Diffserv
>> and proposes a scalable solution to realize network slicing in IP/MPLS
>> networks.  This solution does not mandate Diffserv to be enabled in the
>> network to provide a specific forwarding treatment but can co-exist with
>> and complement it when enabled.
>>
>> [AF] This is much better, thank you. You have provided words that it is
>> now possible to parse and debate. Excellent.
>>
>> [AF] Of course, this makes me wonder why it is necessary to describe and
>> discuss Diffserv in this text. I suspect we get to that below as it was a
>> separate comment, but you could write…
>>
>>
>>
>> Realizing Network slices requires the Service Provider to have the
>> ability to partition a physical network into multiple logical networks of
>> varying sizes, structures, and functions so that each slice can be
>> dedicated to specific services or customers. Multiple network slices can be
>> realized on the same network while ensuring slice elasticity in terms of
>> network resource allocation. This document describes a scalable solution to
>> realize network slicing in IP/MPLS networks by supporting multiple services
>> on top of a single physical network by relying on compliant domains and
>> nodes to provide forwarding treatment (scheduling, drop policy, resource
>> usage) on to packets that carry identifiers that indicate the slicing
>> service that is to be applied to the packets.
>>
>>
>
> [VPB-TS]  We can live with not drawing the parallel with DiffServ
> Architecture in the Abstract.
>
> ---
>>
>> The document appears confused about the difference between a network
>> slice service and a logical network. This is important. What is offered
>> to the customer is a service and not a network or logical network. The
>> service is a connectivity matrix with a set of commitments. The logical
>> network is how the service provider may decide to organise their
>> resources to deliver the service: that is, the logical network is part
>> of the solution model and not something that "network slicing provides."
>>
>>
>> [TS-VPB]: Please see revised text in the abstract above.
>>
>>
>>
>> [AF] Well, yes, that is an improvement. I still think that making logical
>> networks is part of **this** solution, not a requirement or realizing
>> network slices.
>>
>>
>>
>
> [VPB-TS] Okay. We will change this to say -- “Realizing Network Slices can
> require ..”
>
> ---
>>
>> The Introduction says that the document provides a path control
>> technology agnostic solution. Why then do we find Section 6 describing
>> the different path control technologies and how they can be used?
>>
>>
>> [TS-VPB]: Med raised a similar point. We intend to make the following
>> change to address it:
>>
>>
>>
>> OLD:
>>
>> This document provides a path control technology (e.g., RSVP, SR, or
>> other) agnostic solution that a Service Provider can deploy to realize
>> network slicing in IP/MPLS networks.
>>
>>
>>
>> NEW:
>>
>> The solution discussed in this document works with any path control
>> technology (such as RSVP, or SR) that can be used by a Service Provider to
>> realize network slicing in IP/MPLS networks.
>>
>>
>>
>> [AF] Here you are saying that this approach to delivering network slices
>> works with any technology that can be used to deliver network slices.
>>
>
> [VPB-TS] Yes.
>
>
>> [AF] BTW “RSVP” or “RSVP-TE”?
>>
>
> [VPB-TS] RSVP-TE.
>
>
>>
>>
>> ---
>>
>> The definition of the Slice-Flow Aggregate is very lacking in clarity.
>> It takes several readings of the document to discover that the only
>> purpose of this construct is to allow path provisioning aggregation
>> within the NRP. This might be a useful scaling aspect depending on the
>> number of slices that it is expected that a network will need to
>> support between any two edge nodes. That means that it could be a
>> good idea. Or it could be a waste of time. It's hard to know from this
>> document. In particular, a modest number of slices and a careful
>> number of NRPs is likely to give rise to no need for the aggregate.
>>
>>
>> [TS-VPB]: As noted earlier on this thread, slice flow aggregation does
>> not preclude having a single network slice flow in the aggregate.
>>
>>
>>
>> [AF] Might help to make it clear in the text early in the document at the
>> same time as making it clear what the purpose of the aggregate is. I.e.,
>> don’t de facto assume the existence of the aggregate, but explain its
>> purpose.
>>
>>
> [VPB-TS] Okay.
>
>
>>
>>
>> Otherwise, you are just introducing an intermediary step such that:
>> - slices can be grouped into slice aggregates
>> - groups of slice aggregates can be grouped/mapped onto NRPs?
>>
>>
>> [TS-VPB]: The document currently states that an NRP is used to support a
>> Slice-Flow Aggregate to meet the requested SLOs/SLEs and does not advocate
>> that groups of slice flow aggregates can be mapped on to NRPs.
>>
>>
>>
>> [AF] So you are saying that there is a one-to-one mapping of slice flow
>> aggregate to NRP?
>>
>
> [VPB-TS] Yes. The Slice-Flow Aggregate comprises traffic streams
> from “one or more connectivity constructs (belonging to one or more IETF
> network slices) mapped to a specific NRP”.
>
>
>> I feel there is also something missing in defining which slices can
>> be grouped into aggregates.
>>
>>
>>
>> [TS-VPB]: The document currently states that policies to aggregate
>> network slice flows are outside the scope, but we can add a statement
>> saying that a policy for slice flow aggregation can be based on common
>> requirements for SLO/SLEs.
>>
>>
>>
>> [AF] Yeah. What it’s fine for the details to be out of scope. What is
>> missing is the strategy. I think “common requirements for SLOs/SLEs”  goes
>> a long way towards that. Not perfect, but a good first step.
>>
>
> [VPB-TS] Okay.
>
>
>>  Snipped..
>>
>>
>> Why does this document feel the need to redefine the Network Resource
>> Partition?
>>
>>
>>
>>
>> [TS-VPB]: The intention is to remove the definition from this document as
>> soon as it gets added to section 2 of draft-ietf-teas-ietf-network-slices.
>>
>>
>>
>>
>> [AF] Nice. Could you start a new thread proposing that all of the
>> definitions of minor terms within subsections of
>> draft-ietf-teas-ietf-network-slices be moved up into section 2. Then we can
>> see whether there is agreement to do that.
>>
>
> [VPB-TS] We'll start a thread.
>
>
>> [AF] Until then, the definition of NRP in your document is different from
>> that in draft-ietf-teas-ietf-network-slices, and that is a problem.
>>
>
> [VPB-TS] The desired alignment should be an automatic outcome of the
> definition getting solidified in draft-ietf-teas-ietf-network-slices and
> getting removed from Section 1.1 of draft-bestbar-teas-ns-packet.
>
>
>>
>>
>> ---
>>
>> While it is fine to observe that DiffServ can be used alongside slice
>> (flow aggregate) identification, there are a couple of chunks of text
>> that describe how DiffServ works and that, while they are very
>> informative, are entirely irrelevant to the document and somewhat
>> confusing for the reader.
>>
>>
>>
>>
>>
>> [TS-VPB]: We believe the text related to Diffserv is relevant, because we
>> are drawing a parallel to the architecture specified in RFC2475.
>>
>>
>>
>> [AF] I disagree that it is relevant and doubt that it is useful. You
>> could, if you must, have one line that says, “The mechanism defined here is
>> conceptually similar to Diffserv [RFC2475], but uses different fields in
>> the message header and different control mechanisms. The mechanism defined
>> in this document can coexist with Diffserv.” But the repeated descriptions
>> of how Diffserv works are a distraction.
>>
>>
>>
> [VPB-TS] Okay.  We do think it is relevant and ’ll add something to that
> effect in the introduction; 'll also cull out the related descriptions from
> most other places.
>
> ---
>>
>>  Snipped ..
>>
> ---
>>
>> What are "NRP Policy selection criteria"?
>>
>>
>>
>> [TS-VPB]:  The phrase “selection criteria” doesn’t seem to be adding
>> much. We’ll make the following change:
>>
>>
>>
>> OLD:
>> a collection of packets that match an NRP Policy selection
>> criteria and are given the same forwarding treatment;
>>
>>
>>
>> NEW:
>>
>> a collection of packets that match an NRP Policy and are given the same
>> forwarding treatment;
>>
>>
>>
>> [AF] Yes, but. Re-reading your definition of “Network Resource Partition
>> Policy” a few lines lower makes it hard to see how a packet matches an NRP
>> Policy. Indeed, that text seems to be about how an NRP is created not how
>> packets are mapped to a slice flow aggregate.
>>
>
> [VPB-TS] The NRP Policy contains classification rules for what to match
> in packets of an SFA. When these rules are absent in the NRP policy
> (control plane mode), the SFA gets the treatment based on
> traditional means. We will clarify this in the definition of the NRP Policy.
>
>
>
>> Snipped..
>>
>> ---
>>
>> Why is 3.5 supposedly about NRP Policies when the text describes
>> policies for handling slice aggregates? Is it because there is no
>> difference between a slice aggregate and an NRP?
>>
>>
>>
>> [TS-VPB]: As noted earlier, the NRP policy is used in this solution to
>> support the slice-aggregate.
>>
>> [AF] That only half answers the question. The section doesn’t mention the
>> NRP. Surely an NRP Policy has some relationship to an NRP.
>>
>
> [VPB-TS]: Indeed. The NRP Policy is used to instantiate the NRP
> (resources) on devices participating in the NRP (we'll add a statement to
> that effect)
>
>
>>
>> ---
>>
>> Reading 3.7, and to be clear, you don't intend your mechanism to be
>> available for CE-terminated slice services?
>>
>>
>>
>> [TS-VPB]: We’ll remove “(PEs)” in the first sentence to remove confusion
>> regarding service endpoints. However, irrespective of where the IETF
>> network slice service endpoints are located, the service mapping will
>> continue to be done at PEs.
>>
>>
>>
>> [AF] When you say “irrespective of where the IETF network slice service
>> endpoints are located, the service mapping will continue to be done at
>> PEs,” do you mean this to apply to **this** solution, or to the whole
>> IETF network slicing architecture? Of course, it may depend on what you
>> mean by “the service mapping” and I think you are describing how
>> tunnel-based (MPLS or SR) approaches might work where, yes, the PE may be
>> the point of encapsulation (although there are approaches where the CE is
>> responsible for tunnel encapsulation especially where the CE is controlled
>> by the provider). A quick reread of section 4.2 of
>> draft-ietf-teas-ietf-network-slices may be helpful.
>>
>>
>>
>> [AF] Note that this is not the only point in the document that calls out
>> PEs.
>>
>>
> [VPB-TS]: Thanks for pointing this out! Yes, a reread of Section 4.2 did
> help. We agree that depending on how CE equipment is managed, the NRP
> resources may extend to include CE and/or the AC. We will update section
> 3.7 (and other occurrences of PE) to reflect this generality.
>
> ---
>>
>> The use of "MAY" in 3.7 implies that you don't expect it to be normal
>> that the node at the edge of the slice (in your case, the PE) will mark
>> traffic to allow the network to determine to which slice, aggregate, or
>> NRP the packet belongs. That seems to be in contradiction with most of
>> the rest of the document.
>>
>>
>>
>>
>>
>> [TS-VPB]: The use of “may” was to indicate that “marking” at the edge is
>> not mandatory. We’ll replace “MAY” with “may” in this sentence. There are
>> couple of scenarios where the edge would not require to add a FAS:
>>
>> 1.              The FAS marking already exists in the arriving packet
>> (e.g, specific destination address – see section 5.1.1.), or
>>
>> 2.                NRP resources are only partitioned in the control
>> plane, I.e. no dataplane NRP PHB is required (see section 4.2).
>>
>>
>>
>> [AF] OK. Definitely worth adding those examples.
>>
>
> [VPB-TS]: Will do.
>
>
>> [AF] May also be worth noting that if the FAS marking already exists in
>> the arriving packet, the edge of the service may be before the PE. (see
>> previous issue).
>>
>>
>>
> [VPB-TS]: Okay.
>
> ---
>>
>>
>>
>> 3.8 seems to have forgotten about the NRP.
>>
>>
>>
>> [TS-VPB]: This section talks about mapping of IETF NS flows onto SFAs.
>> SFAs are placed onto paths that established over NRP resources (described
>> in other sections).
>>
>>
>>
>> [AF] Hey, ho. You are happy for this section to talk about physical
>> networks and policy filter topologies. But not NRPs. Very odd.
>>
>
> [VPB-TS]: We will clarify the relationship with NRP in this section.
>
>>
>>
>> ---
>>
>> 4.1 has another paragraph describing DiffServ. Very interesting, but not
>> relevant to this document.
>>
>>
>>
>> [TS-VPB]: As stated earlier, the intent is to draw the parallel with the
>> DIffServ architecture and point out the similarities where applicable.
>>
>>
>>
>> [AF] But you don’t point out the similarities. And I continue to disagree
>> that this is a good idea. Just tell us how this approach works. Don’t add
>> to the document with stuff that isn’t about this approach.
>>
>>
>>
> [VPB-TS] As noted earlier, we’ll draw the parallel in the introduction and
> cull out the related text from other places.
>
>
>> ---
>>
>> 4.1 has
>>
>>    In this case, a Flow Aggregate
>>    Selector (FAS) MUST be carried in each packet to identify the Slice-
>>    Flow Aggregate that it belongs to.
>>
>>    The ingress node of an NRP domain MAY also add an FAS to each Slice-
>>    Flow Aggregate packet.
>>
>> If the ingress node of the (undefined) NRP domain does not add the FAS,
>> how does it get into the packet? Presumably the nodes outside the domain
>> have no idea what an FAS is (by definition of the NRP domain). So I
>> think you'll find that the ingress to the domain must add the FAS.
>>
>>
>>
>> [TS-VPB]: The intent here is to say that without the FAS being present in
>> the packet, we would not be able provide the necessary treatment as
>> dictated by the NRP policy.
>>
>> And yes, as mentioned earlier, there are some cases where the ingress of
>> the NRP domain may not need to add an FAS to the packet for this to work.
>>
>>
>>
>>
>> We can make this following change:
>>
>>
>>
>> OLD:
>>
>> The ingress node of an NRP domain MAY also add an FAS to each Slice-
>> Flow Aggregate packet. The transit nodes within an NRP domain MAY
>> use the FAS to associate packets with a Slice-Flow Aggregate...
>>
>>
>>
>> NEW:
>>
>> The ingress node of an NRP domain ensures that an FAS field is present
>> (an FAS
>>
>> may be added when necessary) in each Slice-Flow Aggregate packet. The
>> transit nodes within an NRP domain use the FAS to associate packets with a
>> Slice-Flow Aggregate
>>
>>
>> [AF] Sort of OK. Might be even clearer to say “The ingress node of an NRP
>> domain adds a FAS field is one is not already present.”
>>
>
> [VPB-TS]: Okay. We will say that.
>
>
>> Snipped..
>>
>
>> 4.1
>>
>>    The transit nodes within an NRP domain MAY
>>    use the FAS to associate packets with a Slice-Flow Aggregate and to
>>    determine the Network Resource Partition Per Hop Behavior (NRP-PHB)
>>    that is applied to the packet (refer to Section 5.1.3 for further
>>    details).
>>
>> So you're saying that normally the transit nodes will not use the FAS
>> for this purpose or at all?
>>
>>
>>
>> [TS-VPB]: As stated earlier, there are cases where the NRP is realized in
>> the control plane only, and in that case packets will not carry a FAS and
>> transit nodes will not enforce a per NRP PHB.
>>
>>
>>
>> [AF] Right. But wait! You are inside section 4.1. That is dedicated to
>> the data plane mode. Do you still stand by “MAY”? Or is it, “In the data
>> plane NRP mode, the transit nodes within an NRP domain use the FAS to
>> associate packets….”?
>>
>>
>>
>
> [VPB-TS] We will remove the MAY and qualify the statement with “In the
> data plane NRP mode ..”
>
>
>> ---
>> Snipped..
>>
>
>
>> ---
>>
>> 4.1
>>
>>    For example, the Segment-Routing Flexible Algorithm
>>    [I-D.ietf-lsr-flex-algo] may be deployed in a network to steer
>>    packets on the IGP computed lowest cumulative delay path.  An NRP
>>    Policy may be used to allow links along the least latency path to
>>    share its data plane resources amongst multiple Slice-Flow
>>    Aggregates.  In this case, the packets that are steered on a specific
>>    NRP carry the FAS that enables routers (along with the Diffserv CS)
>>    to determine the NRP-PHB to enforce on the Slice-Flow Aggregate
>>    traffic streams.
>>
>> 1. "This document provides a path control technology agnostic solution"
>>    So why the need to reference draft-ietf-lsr-flex-algo?
>>
>>
>>
>> [TS_VPB] The changes in the introduction (earlier in this email) should
>> answer this.
>>
>> [AF] Yup. Although we may come across some more technology-specific
>> solutions we want to add to the document as it progresses through the
>> working group.
>>
>>
>> 2. I feel fairly sure that this paragraph is intended to carry some
>>    useful meaning, but it eludes me.
>>
>>
>>
>> [TS-VPB]: The intent was to explain how the Data plane NRP mode can be
>> realized in a deployment when SR Flex-Algo is used as the path control
>> technology.
>>
>>
>>
>> [AF] Right. Yes. Just that it doesn’t seem to say much (and is a bit
>> garbled).
>>
>>
>>
> [VPB-TS] Okay. We'll elaborate on the example and make it clear.
>
> ---
>>  Snipped..
>>
> ---
>>
>> 4.3
>>
>> So you believe that, in the case of oversubscription, you are actually
>> achieving isolation? Or is it possible that there will be an out-queue
>> of oversubscription traffic that will impede the flow of traffic from
>> another slice?
>>
>>
>> [TS-VPB]: NRP(s) may be assigned dedicated queues. Dataplane policy can
>> be defined to optionally allow leveraging unused resources in other queues.
>>
>>
>>
>>
>> [AF] Yes to all of this, but in the second case, is that actually
>> isolation?
>>
>
> [VPB-TS]: Yes, isolation may include dedicated queues or allowing for
> sharing of resources with safeguards (as described in section 7.2 of draft-
> ietf-teas-ietf-network-slices). We can expand on section 4.3 to describe
> this.
>
>
>> Snipped..
>>
> ---
>>
>> The text on the Global Identified Based Selector in 5.1.1 crosses the
>> line between general explanatory text and a detailed solution. Careful
>> that you technology agnostic document doesn't end up trying to persuade
>> us all to adopt one specific solution.
>>
>> In particular, the reference to draft-kompella-mpls-mspl4fa is highly
>> premature
>>
>>
>>
>> [TS-VPB]: As noted earlier, the intent was to leave pointers to relevant
>> ongoing work; we’ll fix these references.
>>
>>
>> [AF] Moving the references to Informative is a help, but in this case,
>> the text is heavily leaning on a proposal in an individual I-D that is
>> being heavily debated in the MPLS working group and which might or might
>> not make progress there. It is just not necessary to include that reference
>> at this time, and the text and figure demonstrating how the GIS is carried
>> in the label stack is definitely assuming a solution that should be
>> described in another document.
>>
>>
>>
> [VPB-TS] Removing the inconsistency in the references should ensure that
> there is no reliance on any one specific proposal for carrying the G-FAS in
> the packet.
>
>
>> ---
>>
>> 5.1.1
>>
>>    A detailed review of NRP scale considerations is presented in
>>    [I-D.dong-teas-nrp-scalability].
>>
>> What you say is true. However, I am far from convinced that that
>> document means the same thing as you do when it says "NRP". That
>> document does not talk about "slice aggregates". I think you are still
>> lacking a lot of clarity about the difference between a slice aggregate
>> and an NRP.
>>
>>
>>
>> [TS-VPB]: We have a common sub-set of authors in the two documents and
>> are working towards making sure that both the drafts are aligned.
>>
>>
>> [AF] Hurrah for that. And will you also be adding some clarify on the
>> difference between a slice aggregate and an NRP?
>>
>
> [VPB-TS] As noted above, the clarification will be provided in this
> document.
>
>
>> ---
>>
>> 5.1.2
>>
>> Here (and in the other places where you have similar text about resource
>> sharing) you only talk about sharing resources between NRPs (or slice
>> aggregates, as it may be). You don't talk about sharing those resources
>> with non-slice traffic, but presumably you can.
>>
>>
>>
>> [TS-VPB]: the assumption is non slice traffic will be carried over the
>> default queues – which may be configured to share unused NRP resources.
>>
>>
>>
>> [AF] I like an assumption as much as the next person (assuming the next
>> person likes assumptions). Perhaps you need to state the assumptions in the
>> document.
>>
>
> [VPB-TS] We will add text to describe how we envision non slice traffic to
> get handled.
>
>
>>  Snipped..
>>
> ---
>>
>> I think 5.1.2 is predicated on resource reservation on the nodes. That
>> is, oversubscription under the control of central accounting management
>> (such as might be performed for SR-TE) cannot be achieved without
>> risking the SLOs. Thus, you are advocating for putting the state in the
>> network (which is fine by me), and this appears to be per slice
>> aggregate flow state.
>>
>>
>>
>> [TS-VPB]: the reservation state may be maintained on the devices or
>> off-devices (e.g. on a resource reservation manager). In either case, path
>> computation/placement will need to take the NRP link reservation state into
>> account when selecting a feasible path.
>>
>>
>> [AF] Oversubscription can be a planned activity, but only when the
>> oversubscription traffic is also steered. True oversubscription by other
>> best-effort traffic takes place on the node only. Thus, a central
>> controller can only manage oversubscription at a traffic steering level.
>> Furthermore, the back-off from oversubscription is to allow the “primary”
>> traffic to have priority in case of resource contention. That can only
>> happen on the network nodes. Hence my comment.
>>
>>
>> [VPB-TS]: Understand the comment. There are solutions with the
> controller in the loop that can tactically handle congestion caused by
> over-subscription at the node level – but that discussion is for another
> day.
>
>
>> ---
>>  Snipped..
>>
>>
>> ---
>>
>> 5.1.4 reads like the NRP Topology is the same as the Policy Filter
>> Topology (or Filter Topology as it is called in draft-ietf-teas-ietf-
>> network-slices.
>>
>>
>>
>> [TS-VPB]: Yes, it is the Filter Topology.
>>
>>
>> [AF] Ah, wonderful! Is anything gained by using two terms for the same
>> thing? If you must use two terms, then how about sticking something at the
>> top of the document to say “The term ‘NRP Topology’ used in this document
>> is equivalent to the ‘Filter Topology’ described in
>> [I-D.ietf-teas-ietf-network-slices].”
>>
>
> [VPB-TS]: We'll add the statement.
>
> Snipped..
>
>>
>> ---
>>
>> 5.2.3 has a lot of words to say "Tunnel across areas of the network that
>> are not NRP capable."
>>
>> On the other hand, nothing is said about how an NRP-capable node knows
>> that its neighbour is not NRP capable, and where the next on-path NRP-
>> capable node is.
>>
>>
>> [TS-VPB]: the expectation is a node may discover an incapable neighbor
>> NRP node through (e.g.) lack of a node NRP capability advertisement. Such
>> extensions are outside the scope of this draft, but a proposal exists in an
>> individual LSR WG draft.
>>
>>
>>
>> [AF] All good. Just need to set out the high-level structure of what a
>> node needs to know and what it does with the knowledge.
>>
>
> [VPB-TS]: Okay.
>
>
>>
>> ---
>>
>> 6.1
>>
>>    The path selection in the network can be network state dependent, or
>>    network state independent as described in Section 5.1 of
>>    [I-D.ietf-teas-rfc3272bis].
>>
>> You probably mean section 4.1, but you have possibly misunderstood that
>> section which is describing how TE can adapt according to network state.
>> You appear to be mixing TE with non-TE in your text and it is, perhaps,
>> surprising that you think that "normal" SPF routing is not state
>> dependent. I think you are actually describing the difference between
>> TE and non-TE.
>>
>>
>> [TS-VPB]: the term ‘state-dependent routing’ was originally inspired from
>> text in Appendix A of I-D.ietf-teas-rfc3272bis (see below).
>>
>>
>>
>> “In state-dependent routing, routing tables are updated
>> online according to the current state of the network (e.g., traffic
>> demand, utilization, etc.).”
>>
>>
>>
>> [AF] Ah, the telephone network. Yes, I can see how that would be a
>> helpful reference.
>>
>>
>>
>> More accurately, we are distinguishing between path selection that is
>> network utilization aware vs. network utilization non aware. We will update
>> the reference.
>>
>>
>>
>> [AF] OK. Not sure you need a reference. Just clarify what you are
>> describing.
>>
>>
>>
>
> [VPB-TS] Okay.
>
>
>> ---
>>
>> 6.1
>>
>>    To enable TE path placement, the link state is advertised with
>>    current reservations
>>
>> Really? Like a list of which reservations have been made on each link?
>>
>>
>>
>> [TS-VPB]: To be able to do NRP state aware TE, the per link per NRP
>> reservation state needs to be available.
>>
>>
>> [AF] That’s quite a bit more precision that the original statement. But I
>> still wonder whether you need to know what reservations have been made, or
>> how much resource is available.
>>
>>
>> [VPB-TS] If NRP state aware TE is desired, we need to know how much
> resource is available for the NRP per link.
>
>
>> ---
>>
>> 6.1
>>    When the network resource reservations are maintained for NRPs, the
>>    link state can carry per NRP state (e.g., reservable bandwidth).
>>    This allows path computation to take into account the specific
>>    network resources available for an NRP.  In this case, we refer to
>>    the process of path placement and path provisioning as NRP aware TE
>>    (NRP-TE).
>>
>> I think you are proposing that the IGP distributes information of per-NRP
>>
>> resource reservation and availability per link. Do you think this
>> scales?
>>
>>
>>
>> [TS-VPB]: Yes, scaling with traditional means would be a challenge. This
>> would require some innovation – an initial proposal is available in draft
>> form.
>>
>>
>> [AF] OK. Well, I think this document is showing that a lot of changes are
>> needed in the network to support slicing in the form you envisage. I find
>> that disappointing and think it would be nice to be able to support slicing
>> on top of today’s packet networks with minimal changes. Did anyone think
>> about how to do that?
>>
>>
>>
> [VPB-TS]: It should be noted that distributing reservation state is
> optional and specific to certain deployments. And that maintaining
> centralized reservation state is in scope.
>
> [VPB-TS]:  One can certainly claim that existing IETF VPN tools can cater
> to slicing requirements in today's packet networks with no changes (by
> equating an IETF Network Slice to a traditional VPN service). However,
> there are some gaps in the toolkit when stricter SLOs/SLEs need to be
> catered to. The solution in this document proposes three different modes.
> The amount of changes made to the network varies depending on how these
> modes are deployed. The different modes allow you to cater to different
> SLOs, ranging from basic to strict guarantees. The control plane mode with
> centralized reservation can potentially require minimal changes to the
> network.
>
>
>> ---
>>  Snipped..
>>
>
>
>>
>>
>> 7.
>>
>>    The NRP Policy YANG data model is outside the
>>    scope of this document, and is defined in
>>    [I-D.bestbar-teas-yang-slice-policy].
>>
>> :-) It's out of scope, but let's talk about it anyway.
>>
>>
>>
>> [TS-VPB]: It is out of scope as stated. In our opinion it is always
>> useful to call out /reference relevant ongoing work during the early stages
>> of a draft. But as noted earlier, we’ll fix the list of references.
>>
>>
>>
>> [AF] I am sensitized to this kind of statement. It probably has something
>> to do with my childhood, and my analyst is working on it with me. Are you
>> open to authors of other documents having references added as well?
>>
>>
>>
>
> [VPB-TS]: Wish you good luck with your analyst. We’ll fix the list of
> references.
>
>
>> ---
>>
>> Section 9 is a long way short of covering all of the bases. Three
>> immediate things jump out:
>>
>> - Security is an SLE. A Filter Topology may be constructed using only
>>   secure links (e.g., links that use MACsec) resulting in the ability
>>   to provide a secure slice.
>> - An attacker that modifies the FAS may be able to achieve far more
>>   subtle attacks than one that modifies the forwarding label or
>>   destination address. How is this protected against?
>> - The visibility of the FAS within the network is an identifier of the
>>   traffic, and to some extent the customer. This allows someone doing
>>   surveillance to learn about customer traffic use (privacy) and to
>>   attack specific customer traffic (security). What are the mitigations?
>>
>>
>> [TS-VPB]: Points noted. We agree that that Security Section needs more
>> details on mitigation actions.
>>
>>
>>
>> [AF] Noted means “and we will write some text”?
>>
>>
>>
> [VPB-TS] Yes.
>
>
>> ---
>>  Snipped..
>>
>
>
>
>>
>> -----Original Message-----
>> From: Teas <[e-mail]> On Behalf Of Lou Berger
>> Sent: 18 February 2022 13:28
>> To: TEAS WG <[e-mail]>
>> Cc: TEAS WG Chairs <[e-mail]>;
>> [e-mail]
>> Subject: [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-
>>
>>
>> <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas->
>> ns-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]
>> 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
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>