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

From: Tarek Saad <[email-masked]>
Date: Wed, 2 Mar 2022 05:26:46 +0000

Hi Adrian,

Thanks for the great feedback! Your biggest concern with current version of the draft seems to be with regards to the “references” (normative vs informative). Med had a similar concern and as stated in our response to him earlier in the thread – we acknowledge the inconsistency in the references and will fix it.

Please see inline for more responses prefixed by [TS-VPB].

Regards,
Tarek and Pavan

**

From: Teas <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Date: Monday, February 28, 2022 at 8:11 AM
To: 'Lou Berger' <[email-masked]>, 'TEAS WG' <[email-masked]>
Cc: 'TEAS WG Chairs' <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Hi Lou, all,

I agree that the working group should have a document on this topic.

While I see very many confusions, errors, and open questions, I believe
that the authors could be persuaded to work on and fix these problems
after adoption. However, given how much work is needed and how much the
document will change, it may be pragmatic to produce a new version first
and then see whether that has stabilised.

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.

The comments below are a mixture of concerns and editorial. They give a
flavour of what is wrong with the draft. They do not comprise a full
and detailed review.

One other top level point: what a lot of IPR. Thanks to everyone for
ensuring a timely disclosure, but ouch! With so much IPR, it makes me
wonder whether the WG should look for a different approach that is not
encumbered.

Best,
Adrian

===

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

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.

---

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.

---

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.

---

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.

---

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.

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.

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.

---

The Introduction concludes by saying...
   This document covers different modes of NRPs and discusses how each
   mode can ensure proper placement of Slice-Flow Aggregate paths and
   respective treatment of Slice-Flow Aggregate traffic.
...What is an NRP mode? What is a Slice-Flow Aggregate path? (Yes, I
can look ahead into the document to find out, but then what is the
point of an Introduction?)

[TS-VPB]: We can make the following change to address this narrative nit:
OLD:
This document covers different modes of NRPs and discusses how each
mode can ensure proper placement of Slice-Flow Aggregate paths and
respective treatment of Slice-Flow Aggregate traffic.
NEW:
This document introduces three modes for realizing NRPs in a network, namely data plane NRP mode, control plane NRP mode, and control and data plane NRP mode. The realization of the NRP mode in the network ensures the proper placement of paths associated with a Slice-Flow Aggregate and for the enforcement of the respective forwarding treatment.

---

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.

---

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.

---

a Slice-Flow
Aggregate comprises of one or more IETF network slice traffic
streams;

This is ambiguous as a network slice may comprise multiple traffic
streams, and we are talking about multiple slices.

[TS-VPB]: we will make the following change to address this:
NEW:
a Slice-Flow
Aggregate comprises of traffic streams from one or more IETF network slices.

---

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

What's an "NRP domain"?

[TS-VPB]: The NRP domain is the administrative zone associated with an NRP topology. We’ll add a definition for this in the document.

---

1.2

      FASL: Flow Aggregate Selector Label as described in Section 5.1.1

I don't find any mention of the FASL until 5.2.3

[TS-VPB]: Good catch! We’ll fix this forward reference.

--

Is NRP a Network Resource Partition, or a Network Resource Partition
Policy? Section 1.1 seems unsure.

[TS-VPB]: NRP is Network Resource Partition. We will make the following correction:

OLD:
Network Resource Partition:
Network Resource Partition Policy (NRP):

NEW:
Network Resource Partition (NRP):
  Network Resource Partition Policy:

---

It is no surprise to me that Figure 1 (which, incidentally, I drew for
the authors as part of converging on figure 5 of draft-ietf-teas-ietf-
network-slices) doesn't include the NRP. Perhaps a document that is
claiming to be aligned with draft-ietf-teas-ietf-network-slices should
make some attempt? Further, 3.4 is titled "Path Placement over NRP
Topology" but doesn't actually mention the NRP topology preferring to
talk about placement of paths over the Policy Filtered Topology (that
draft-ietf-teas-ietf-network-slices calls the Filter Topology).

[TS-VPB]: Given that figure 1 (thanks for working with us on this and producing the ASCII cut) is attempting to illustrate how the solution fits into the architecture outlined in draft-ietf-teas-network-slices, we agree that it should include the NRP (we’ll update the illustration). We’ll also fix Section 3.4 to use the term NRP topology instead of the old terminology.

---

3.1 In what way do "resources ... meet specific SLOs"? Perhaps "can be
used such that specific SLOs have a good chance of being met?"

[TS-VPB]: Point taken. We’ll make the change.

---

3.2
   The customer requests an IETF Network Slice Service specifying the
   CE-AC-PE points of attachment, the connectivity matrix, and the SLOs/
   SLEs as described in [I-D.ietf-teas-ietf-network-slices].  These
   capabilities are always provided based on a Service Level Agreement
   (SLA) between the network slice costumer and the provider.
These are not "capabilities".
The SLOs/SLEs *are* the SLA.

[TS-VPB]: Okay. We’ll remove the second line.

---

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.

---

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.

---

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

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

---

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.

---

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

In any case, why "also"? What else are they adding?

[TS-VPB]: We’ll remove the “also”. The ingress may possibly mark the CS field as well.

---

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.

---

4.1
  
   The CS MAY be used to apply a Diffserv PHB on to the
   packet to allow differentiation of traffic treatment within the same
   Slice-Flow Aggregate.

I think you're saying "DiffServ may be used to further qualify the PHB
within the traffic flows belonging to a slice flow aggregate."

[TS-VPB]: Yes.

---

4.1

   When data plane only NRP mode is used, routers may rely on a network
   state independent view of the topology to determine the best paths.

You have switched to lower case "may". In either case, what would the
router do in other cases?

[TS-VPB]: We’ll remove the “may” in this sentence.
---

4.1

   The FAS field carried in each packet
   determines the specific NRP-PHB treatment along the selected path.

You have already said this.

[TS-VPB]: We’ll remove this sentence.

---

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.

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

4.2

   To perform NRP state aware Traffic Engineering (NRP-TE), the resource
   reservation on each link needs to be NRP aware.

Do you mean "on" or "for"? There's a substantial difference in how that
is implemented.

[TS-VPB]: reservation state may be managed on or off the box depending on the path control technology used. In this case, can change it to say “for” if it makes it clearer.

---

4.2

   The same physical link may be member of multiple slice policies that
   instantiate different NRPs.

What is a slice policy?

[TS-VPB]: Thanks for catching this! This will be replaced with “NRP policy”.

---

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

5.

The word "intent" is very cool, but it is wrong in this context. The
slice customer does not express an intent, but a set of requirements.

[TS-VPB]: We don’t quite get why it is wrong in this context. But we’ll go ahead and remove the usage of “intent”.
---

5.1.1

Why "Global Identifier FAS (GIS)"?

[TS-VPB]: If this is about the abbreviation, we are open to better suggestions (GI-FAS, maybe).

---

5.1.1

   A router MUST be able to identify a packet belonging to a Slice-Flow
   Aggregate before it can apply the associated dataplane forwarding
   treatment or NRP-PHB.  One or more fields within the packet MAY be
   used as an FAS to do this.

So you are saying that the FAS provides the NRP-ID? Or that the NRP
policy includes a list of applicable FAS values?

[TS-VPB]: The NRP policy will specify (in the modes where the FAS is required) the selector details. If a range of FAS values map to the same NRP, then this range is specified in the NRP policy. An implementation may choose to use the NRP-ID as a FAS (if there is only one selector option), but architecturally we would like to keep these fields separate.

---

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.

---

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.

---

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.

In fact, this section highlights the confusion between slice aggregate
and NRP. You essentially have a set of slice aggregates within an NRP
that share the resources of the NRP allowing for oversubscription etc.
And you also have NRPs sharing resources or the network. It's all
perfectly functional, but seems to have one too many layers of
abstraction.

[TS-VPB]: you seem to be hinting that a name for the aggregate of network slice traffic streams is not necessarily needed. However, we believe it is useful to distinguish the chunk of traffic that will use the set of resources identified by the NRP.

---

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.

---

5.1.3 is off into DiffServ description again.
You can probably cut this section down to two paragraphs (2 and 3) and
one line saying "you can also use DiffServ as a subcategory of the
NRP-PHB.

[TS-VPB]: Okay.

---

5.1.3 has

   The Slice-Flow Aggregate traffic may be identified at NRP ingress
   boundary nodes by carrying a FAS to allow routers to apply a specific
   forwarding treatment that guarantee the SLA(s).

There is some passive voice here that makes it unclear whether you
expect the packets to already include the FAS when they arrive at the
domain. Additionally, the use of "may" is vague.

[TS-VPB]: as noted earlier, it may be possible that the packet may arrive at the NRP boundary node carrying a field that maps to a FAS (e.g. destination address or MPLS LSP label).

---

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.

--

5.2

   A network slice originates at the edge nodes of a network slice
   provider.

It is not helpful to contradict draft-ietf-teas-ietf-network-slices.

[TS-VPB]: Agree. We will correct this to align to endpoint boundary of an IETF network slice service.

---

5.2

   The
   network provider is responsible for ensuring that adequate network
   resources are provisioned and/or reserved to support the SLAs offered
   by the network end-to-end.

"end-to-end" is a big ask especially given that the previous text is
clear that the slice is edge-to-edge.

[TS-VPB]: Okay. We’ll remove end-to-end.
---

5.2.1 is either contradicting draft-ietf-teas-ietf-network-slices or
specifically limiting the whole document to a subset of the possible
deployment models. It's OK for the document to constrain itself to a
subset (although I recall it was the network operators who were keen
to extend slices to include the ACs), but it needs to make this very
clear in the Abstract, Introduction, and probably title.

[TS-VPB]: we distinguish between the NRP boundary (provider domain) and the IETF network slice service endpoint boundaries (which may extend to CE). We highlight that Figure 5 in also makes such possible boundary demarcations. We think that the NRP boundary can continue to be residing within the provider network, but we are open to the discussion (e.g. to allow CE-PE links to be part of the NRP too).

---

5.2.2

   and MAY be able to

That's a lower case "may"

[TS-VPB]: Okay.

---

5.2.2

   be able to
   identify the packets belonging to a specific Slice-Flow Aggregate by
   inspecting the FAS field carried inside each packet, or by inspecting
   other fields within the packet that may identify the traffic streams
   that belong to a specific Slice-Flow Aggregate.  For example, when
   data plane NRP mode is applied, interior nodes can use the FAS
   carried within the packet to apply the corresponding NRP-PHB
   forwarding behavior.

I expected the example to be an example of using other fields to
identify the traffic streams (because, obviously, the FAS is an example
of using the FAS). What other fields have you in mind that can identify
the slice flow aggregate (and how does that work if the traffic is
encrypted)?

[TS-VPB]: thanks, we will update this statement to clarify the intention. Depending on the choice of dataplane, the FAS may take different forms. For example, in MPLS we reference options, including the use of FAI, and ELI for extending MPLS header to carry the FAS. In IPv6, it may be possible to carry the FAS in a hop-by-hop option IPv6 EH. We expect to address impact of encryption of the transport headers in another revision of this document.

---

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

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.).”

More accurately, we are distinguishing between path selection that is network utilization aware vs. network utilization non aware. We will update the reference.

---

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.

---

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.

---

6.2.2 is missing a statement about how resource reservation works in
this type of network.

[TS-VPB]: Okay, we can add this.

---

7.
   Routing protocols may need to be extended to carry additional per NRP
   link state.

Well, do they or don't they? Per my comment on 6.1, it looks like you
are saying that this extension is needed.

---

7.

Need a reference for gRPC.

[TS-VPB]: Will add it.

---

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.

---

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

10.

Interesting that you thank one of the authors for reviewing the
document 😊

[TS-VPB]: Thanks for spotting this! We’ll fix it.

---

10.

Thanks to the authors for acknowledging me for the "detailed discussions
that led to Section 3" of this document. On the other hand, no thanks for
failing to acknowledge the material I wrote and that has been included
in this document. This is poor behaviour that should be an embarrassment
to all with their names on the front page. It really makes one think
about who to have conversations with and who to try to help.

[TS-VPB]: We are sorry that you feel this way and we will respond to this allegation on the list using a separate cover (the allegation should be directed to just the pair of us who have had detailed discussions with you and not to all those whose names are on the front page). Let’s keep this thread just for the technical aspects of the document.

---

On the subject of the front page: why is a document being put forward
for adoption with 12 names on the front page.

[TS-VPB]: We understand and acknowledge that this needs to be sorted at some point before we reach the publication stage.
---

Is draft-ietf-teas-ietf-network-slices really not a normative reference?

[TS-VPB]: As noted earlier, we’ll fix the references.

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Lou Berger
Sent: 18 February 2022 13:28
To: TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>;
[email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

<https://www.ietf.org/mailman/listinfo/teas>_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 2 Mar 2022 11:23:17 -0000

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

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.

More in line…

Best,

Adrian

From: Tarek Saad <[email-masked]> 
Sent: 02 March 2022 05:27
To: [email-masked]; 'Lou Berger' <[email-masked]>; 'TEAS WG' <[email-masked]>
Cc: 'TEAS WG Chairs' <[email-masked]>; [email-masked]
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hi Adrian, 

Regards, 

Tarek and Pavan 

** 

From: Teas <[email-masked] <mailto:[email-masked]> > on behalf of Adrian Farrel <[email-masked] <mailto:[email-masked]> > 
Date: Monday, February 28, 2022 at 8:11 AM 
To: 'Lou Berger' <[email-masked] <mailto:[email-masked]> >, 'TEAS WG' <[email-masked] <mailto:[email-masked]> > 
Cc: 'TEAS WG Chairs' <[email-masked] <mailto:[email-masked]> >, [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > 
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08 

Hi Lou, all, 

 

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

 
Best, 
Adrian 
 
=== 

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

--- 

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

[AF] You might look at the VPN+ framework and learn from it about how to separate discussion of a general approach from solution details.

--- 

NEW: 

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

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

--- 

OLD: 

NEW: 

[AF] Here you are saying that this approach to delivering network slices works with any technology that can be used to deliver network slices.

[AF] BTW “RSVP” or “RSVP-TE”?

--- 

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

[AF] So you are saying that there is a one-to-one mapping of slice flow aggregate to NRP?

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

--- 

 

OLD: 

NEW: 

 [AF] Better, thanks.

--- 

 

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

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

--- 

 

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

--- 

a Slice-Flow 

 

NEW: 
a Slice-Flow 

[AF] Good

--- 

OLD: 

NEW: 

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

--- 
 
What's an "NRP domain"? 

 [AF] OK. You might try to find words that are a little less vague. (My NRP topology is in Atlanta, so my administrative zone is the State of Georgia!)

--- 
 
1.2 

 

[AF] OK

--- 

 

OLD: 

NEW: 

 

[AF] OK

--- 

[AF] I look forward to seeing the changed version

--- 

[AF] OK

--- 
 
3.2 

[AF] OK

--- 

[AF] That only half answers the question. The section doesn’t mention the NRP. Surely an NRP Policy has some relationship to an NRP. 

--- 

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

--- 

 

[AF] OK. Definitely worth adding those examples.

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

--- 

[AF] Hey, ho. You are happy for this section to talk about physical networks and policy filter topologies. But not NRPs. Very odd.

--- 

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

--- 
 
4.1 has 

 

OLD: 

NEW: 

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

[AF] OK

--- 
 
4.1 

[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….”?

--- 
 
4.1 
    

[TS-VPB]: Yes. 

[AF] Good. Then say it 😊

--- 
 
4.1 

[AF] OK

--- 
 
4.1 

[AF] OK

--- 
 
4.1 

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

[AF] Right. Yes. Just that it doesn’t seem to say much (and is a bit garbled).

--- 
 
4.2 

[AF] Well, that was precisely the point. Using “on” means the resource reservation is “on the link”. So using “for” doesn’t make it clearer so much as making it right.

--- 
 
4.2 

What is a slice policy? 

[AF] OK

--- 
 
4.3 

[AF] Yes to all of this, but in the second case, is that actually isolation?

--- 
 
5. 

[AF] OK

--- 
 
5.1.1 

[AF] Probably, the “Identifier” is superfluous. After all, the FAS is not the Flow Aggregate Identifier Selector. So you might have a GFAS. Or, since the it is the selector that is global not the flow, you have a FAGS. But it is possibly the least important thing.

--- 
 
5.1.1 

 

[AF] Lovely. Say it in the draft.

[AF] Interesting to consider how this scales as the network must now have state for all of the flow aggregates.
 
--- 

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

--- 
 
5.1.1 

[AF] Hurrah for that. And will you also be adding some clarify on the difference between a slice aggregate and an NRP?

--- 
 
5.1.2 

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

 
--- 

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

--- 

[TS-VPB]: Okay. 
 
--- 
 
5.1.3 has 

 

[AF] Lovely. So just clean up the text.

--- 

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

-- 
 
5.2 

[AF] OK

--- 
 
5.2 
 
   The 

[AF] OK

--- 

[AF] OK

--- 
 
5.2.2 
 
   and MAY be able to 

[TS-VPB]: Okay. 
 
--- 
 
5.2.2 
 
   be able to 

[AF] That clarifies, thanks. You are saying that the FAS may be carried in other fields, not that “inspecting other fields within the packet may identify the traffic streams”. That needs some tidying in the text.

--- 

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

--- 
 
6.1 

[AF] Ah, the telephone network. Yes, I can see how that would be a helpful reference.

[AF] OK. Not sure you need a reference. Just clarify what you are describing.

--- 
 
6.1 

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

--- 
 
6.1 

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

--- 

[AF] OK

--- 
 
7. 

--- 
 
7. 

[TS-VPB]: Will add it. 
 
--- 
 
7. 

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

--- 

[AF] Noted means “and we will write some text”?

--- 
 
10. 

 
--- 
 
10. 

[AF] OK. See other thread.

--- 

 

 
-----Original Message----- 
From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of Lou Berger 
Sent: 18 February 2022 13:28 
To: TEAS WG <[email-masked] <mailto:[email-masked]> > 
Cc: TEAS WG Chairs <[email-masked] <mailto:[email-masked]> >; 
[email-masked] <mailto:[email-masked]>  
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 

Thank you, 
Lou (as Co-chair) 
 
_______________________________________________ 
Teas mailing list 
[email-masked] <mailto:[email-masked]>  
 <https://www.ietf.org/mailman/listinfo/teas> https://www.ietf.org/mailman/listinfo/teas 
 
_______________________________________________ 
Teas mailing list 
[email-masked] <mailto:[email-masked]>  
 <https://www.ietf.org/mailman/listinfo/teas> https://www.ietf.org/mailman/listinfo/teas

---

From: <[email-masked]>
Date: Wed, 2 Mar 2022 13:32:24 +0000

Hi all,

Focusing on this important point which should BTW be linked to the IPR point raised in one of my reviews + Adrian’s review.

Other approaches that do not require major changes were already called out in this thread. I hope a balanced approach will be adopted to discuss/document them.

The more I read draft-bestbar-teas-ns-packe, the more I’m convinced that it should not be in Standards Track, but Informational.

Cheers,
Med

De : Teas <[email-masked]> De la part de Adrian Farrel
Envoyé : mercredi 2 mars 2022 12:23
À : 'Tarek Saad' <[email-masked]>; 'Lou Berger' <[email-masked]>; 'TEAS WG' <[email-masked]>
Cc : 'TEAS WG Chairs' <[email-masked]>; [email-masked]
Objet : Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

[snip]

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Abhishek Deshmukh <[email-masked]>
Date: Wed, 2 Mar 2022 15:20:39 +0000

I support WG adoption.

Thanks
Abhishek

From: Teas <[email-masked]> on behalf of Lou Berger <[email-masked]>
Date: Friday, February 18, 2022 at 6:58 PM
To: TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>, [email-masked] <[email-masked]>
Subject: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
[External Email. Be cautious of content]

Hello,

This email begins a 2-week adoption poll for:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!W3DX9e3JEqikABudCYXgkRMX8tx6RECA6G4BaAB7TQdZ3j86B_tLdE_dIEF_Qp99ww$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!W3DX9e3JEqikABudCYXgkRMX8tx6RECA6G4BaAB7TQdZ3j86B_tLdE_dIEF_Qp99ww$>

Please note that IPR has been disclosed on this document:
https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!W3DX9e3JEqikABudCYXgkRMX8tx6RECA6G4BaAB7TQdZ3j86B_tLdE_dIEGTLw_vCw$<https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!W3DX9e3JEqikABudCYXgkRMX8tx6RECA6G4BaAB7TQdZ3j86B_tLdE_dIEGTLw_vCw$>

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
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!W3DX9e3JEqikABudCYXgkRMX8tx6RECA6G4BaAB7TQdZ3j86B_tLdE_dIEFEQXQmjg$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!W3DX9e3JEqikABudCYXgkRMX8tx6RECA6G4BaAB7TQdZ3j86B_tLdE_dIEFEQXQmjg$>

Juniper Business Use Only

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 3 Mar 2022 02:41:21 +0000

Hi Lou, 

As a coauthor I would like to see this document moving forward. The recent revisions reflect the joint effort in improving the document. 

Although the comments indicate that there are issues to be solved in framework alignment, terminology, and the balance between a general approach and the technology details, the discussion shows that the authors have started to resolve the issues, and we will align it with both the IETF network slice draft and VPN+ framework. Thanks.

Best regards,
Jie

> From: Lou Berger [mailto:[email-masked]]
> Sent: Friday, February 18, 2022 9:28 PM
> Subject: WG adoption poll: draft-bestbar-teas-ns-packet-08
> 
> Hello,
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 4 Mar 2022 02:59:08 -0600

Adrian,
Thanks for the follow-up! Please see inline for responses (prefixed
[VPB-TS]).

Regards,
-Pavan and Tarek

> Please don’t mistake “you need to fix this before adoption” for “my

 [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 <[email-masked]>
> *Sent:* 02 March 2022 05:27
> *To:* [email-masked]; 'Lou Berger' <[email-masked]>; 'TEAS WG' <
> [email-masked]>
> *Cc:* 'TEAS WG Chairs' <[email-masked]>;
> *Subject:* Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
>
>
>

Snipped..

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

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

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

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

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

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

[VPB-TS] Yes. 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”.

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

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

> Snipped..
> [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 enforcement of the NRP Policy instantiates the NRP.
We'll clarify the relationship in the document.

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

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

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

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

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

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

> [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.
>
>
> [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.
>
>
>
[VPB-TS] Okay. We'll elaborate on the example and make it clear.

---
>  Snipped..
---
> [TS-VPB]: NRP(s) may be assigned dedicated queues. Dataplane policy can be
> defined to optionally allow leveraging unused resources in other queues.
>
>
>

[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 this in Section 4.3.

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

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

[VPB-TS] As noted above, the clarification will be provided in this
document.

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

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

> [TS-VPB]: the term ‘state-dependent routing’ was originally inspired from
> text in Appendix A of I-D.ietf-teas-rfc3272bis (see below).
>
>
>
> More accurately, we are distinguishing between path selection that is
> network utilization aware vs. network utilization non aware. We will update
> the reference.
>
>
>

[VPB-TS] Okay.

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

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

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

> [AF] Noted means “and we will write some text”?
[VPB-TS] Yes.

>  Snipped..

> <https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/>Please
> note that IPR has been disclosed on this document:
>
> <https://www.ietf.org/mailman/listinfo/teas>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 4 Mar 2022 03:08:30 -0600

* 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
>
>> 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.
>>
>>
>>
>> [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).
>>
>
>> 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.
>>
>> 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.
>>
>>
>
>> [TS-VPB]: As noted earlier on this thread, slice flow aggregation does
>> not preclude having a single network slice flow in the aggregate.
>>
>>
>>
> [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”.
>
>
>> [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.
>>
>>
>>
> [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..
>>
>> ---
>>
> [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)
>
>
>>
>> ---
>>
> [VPB-TS]: We will clarify the relationship with NRP in this section.
>
>>
>>
>> ---
>>
>> [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
>>
>> [TS-VPB]: NRP(s) may be assigned dedicated queues. Dataplane policy can
>> be defined to optionally allow leveraging unused resources in other queues.
>>
>>
>>
>>
> ietf-teas-ietf-network-slices). We can expand on section 4.3 to describe
> this.
>
>
>> Snipped..
>>
> ---
>>
>> [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.
>>
>>
>>
>> [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.
>>
>>
>> [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
> optional and specific to certain deployments. And that maintaining
>> [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.
>>
>>
>>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 4 Mar 2022 03:15:58 -0600

Med, Hi!

>> The more I read draft-bestbar-teas-ns-packe, the more I’m convinced that
it should not be in Standards Track, but Informational.

We (authors) would be okay with whatever the WG consensus is on this.

Regards,
-Pavan

On Wed, Mar 2, 2022 at 7:32 AM <[email-masked]> wrote:

> Hi all,
>
>
>
> Focusing on this important point which should BTW be linked to the IPR
> point raised in one of my reviews + Adrian’s review.
>
>
>
> Other approaches that do not require major changes were already called out
> in this thread. I hope a balanced approach will be adopted to
> discuss/document them.
>
>
>
> The more I read draft-bestbar-teas-ns-packe, the more I’m convinced that
> it should not be in Standards Track, but Informational.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Teas <[email-masked]> *De la part de* Adrian Farrel
> *Envoyé :* mercredi 2 mars 2022 12:23
> *À :* 'Tarek Saad' <[email-masked]>; 'Lou Berger' <[email-masked]>;
> 'TEAS WG' <[email-masked]>
> *Cc :* 'TEAS WG Chairs' <[email-masked]>;
> *Objet :* Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
>
>
>
>
>
> *[snip]*
>
>
>

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 4 Mar 2022 18:45:42 +0530

Hi WG,

This is a viable work for the WG but I do have concerns with the current
document. On the high level -

* More work is needed to align terms between NRP, NRP Policy, NRP Topology,
NRP Domain(?), Filter topology, Policy Filtered Topology. Some of this
needs to be simplified and definitions made crisp and usage consistent.
    *  Also reference to ietf-teas-ietf-network-slices if these terms are
meant to be first defined there rather than redefining and changing them.

* Figure 1 in this I-D and figure 5 in draft-ietf-teas-ietf-network-slices
are similar but with some major differences -
    * What you show as SFA, is shown as NRP (which IMHO is the correct
representation)
    * How the controller's functionality are demarcated in the two figures
    * Concept of Path Placement
    * What is in the controller view and what is on the devices
    * This alignment needs to be taken care of or suitable text added on
why these changes are needed?

* I understand that we need to allow multiple IETF network slice services
to be mapped to an NRP. I am not fully sure how the concept of Slice Flow
Aggregate makes this easier. Since this is a new term, we should also think
about adding motivation to why this is added and not just what it is.

* Filter topology - includes the identification of an existing sub-topology
(via MT, FlexAlgo) as well as the creation of a new one by specifying the
filter action. The term "topology filters" is not very clear here. Other
names such as "Policy Filtered Topology" add to the confusion.
    * Also, this confusion leads to -
        * Is NRP itself a topology? - I think so, that would make the path
placement on NRP makes more sense!
        * Or No! The filter topology is the NRP topology?

* NRP Policy - the scope of NRP Policy is claimed to be one instantiated at
the device but also claimed to global network-wide. Could there not be a
need to have different attributes such as bandwidth setting on a specific
link or node in the NRP? Also, section 5.2.4 describe a case where some
part of the network is data-plane and the other is control-plane/data-plane
combined and thus we would need to have a mechanism to identify those
specific nodes. I see the need for node and link-specific NRP
attributes apart from the global ones.

* Multi-domain handling - it is not entirely clear how things would work in
a multi-domain, multiple controllers world. Is it in scope or not?

* Cleanup of terms -
    * CE-AC-PE points of attachment(?)
    * the connectivity matrix

Others

* I agree with others that the Abstract needs some cleaning up.
* I agree with Med that currently there is an uncomfortable mix of
high-level architecture and deep solution dive only for some sections such
as GIS.

Thanks!
Dhruv

On Fri, Feb 18, 2022 at 6:58 PM Lou Berger <[email-masked]> wrote:

> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-ns-packet
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 4 Mar 2022 14:33:52 +0000

Hi Med, Pavan,

Provided that I share concerns about the number of IPRs, I don’t think that the draft as is today can be considered informational.
Probably some work might be done to turn it into informational but the real question, do we want yet another informational draft or do we want one documents that says: “if you want to do network slicing in packet technologies, this is what you MUST do” ? it doesn’t have to be THE only solution but is should be one of the FEW solutions.

Cheers,
Daniele

From: Vishnu Pavan Beeram <[email-masked]>
Sent: den 4 mars 2022 10:16
To: [email-masked]
Cc: [email-masked]; Tarek Saad <[email-masked]>; Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; TEAS WG Chairs <[email-masked]>; [email-masked]
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Med, Hi!

Regards,
-Pavan

On Wed, Mar 2, 2022 at 7:32 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Cheers,
Med

De : Teas <[email-masked]<mailto:[email-masked]>> De la part de Adrian Farrel
Envoyé : mercredi 2 mars 2022 12:23
À : 'Tarek Saad' <[email-masked]<mailto:[email-masked]>>; 'Lou Berger' <[email-masked]<mailto:[email-masked]>>; 'TEAS WG' <[email-masked]<mailto:[email-masked]>>
Cc : 'TEAS WG Chairs' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

[snip]

Thank you.
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: <[email-masked]>
Date: Fri, 4 Mar 2022 15:00:23 +0000

Hi Daniele,

I don’t think that an IETF document can mandate how a network can implement a slice.

We can of course document approaches that are likely to be implemented. We can hint some preference, e.g., leverage existing solutions with very minor changes. But all that is still informational in nature.

Cheers,
Med

De : Daniele Ceccarelli <[email-masked]>
Envoyé : vendredi 4 mars 2022 15:34
À : Vishnu Pavan Beeram <[email-masked]>; BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]; Tarek Saad <[email-masked]>; Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; TEAS WG Chairs <[email-masked]>; [email-masked]
Objet : RE: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hi Med, Pavan,

Cheers,
Daniele

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Sent: den 4 mars 2022 10:16
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Tarek Saad <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Med, Hi!

Regards,
-Pavan

Cheers,
Med

[snip]

Thank you.

---

From: Tarek Saad <[email-masked]>
Date: Fri, 4 Mar 2022 17:30:26 +0000

Hi Dhruv,

Thanks for the review and comments. Please see inline for responses.

From: Teas <[email-masked]> on behalf of Dhruv Dhody <[email-masked]>
Date: Friday, March 4, 2022 at 8:16 AM
To: Lou Berger <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>, [email-masked] <[email-masked]>, TEAS WG <[email-masked]>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Hi WG,

This is a viable work for the WG but I do have concerns with the current document. On the high level -

* More work is needed to align terms between NRP, NRP Policy, NRP Topology, NRP Domain(?), Filter topology, Policy Filtered Topology. Some of this needs to be simplified and definitions made crisp and usage consistent.
    *  Also reference to ietf-teas-ietf-network-slices if these terms are meant to be first defined there rather than redefining and changing them.

[TS-VPB]: some of these definitions (including NRP and Filter Topology) are starting to get solidified in draft-ietf-teas-ietf-network-slices (and that is great!). The draft-bestbar-teas-ns-packet will be aligned with those definitions and terms. For other terms (like NRP policy, NRP Topology and NRP Domain) that do not show up in draft-ietf-teas-ietf-network-slices and are needed for the draft-bestbar-teas-ns-packet solution, we have agreed to start an email thread to discuss them further on the list. The term "Policy Filtered Topology" is the same as Filter Topology and shall go away.

* Figure 1 in this I-D and figure 5 in draft-ietf-teas-ietf-network-slices are similar but with some major differences -
    * What you show as SFA, is shown as NRP (which IMHO is the correct representation)
    * How the controller's functionality are demarcated in the two figures
    * Concept of Path Placement
    * What is in the controller view and what is on the devices
    * This alignment needs to be taken care of or suitable text added on why these changes are needed?

[TS-VPB]: yes, as noted in our response to Adrian, there will be alignment to incorporate the high-level constructs presented in the framework. We will add text to illustrate specifics on how the solution is proposing to realize them.

* I understand that we need to allow multiple IETF network slice services to be mapped to an NRP. I am not fully sure how the concept of Slice Flow Aggregate makes this easier. Since this is a new term, we should also think about adding motivation to why this is added and not just what it is.

[TS-VPB]: some text already exists in the draft, but we will expand it to make it clear.

* Filter topology - includes the identification of an existing sub-topology (via MT, FlexAlgo) as well as the creation of a new one by specifying the filter action. The term "topology filters" is not very clear here. Other names such as "Policy Filtered Topology" add to the confusion.
    * Also, this confusion leads to -
        * Is NRP itself a topology? - I think so, that would make the path placement on NRP makes more sense!
        * Or No! The filter topology is the NRP topology?

[TS-VPB]: No, NRP is not a topology. We are aligned with the text proposed from Adrian that clarifies this relationship. Extracted from Adrian's email:
"An NRP is simply a collection of (reserved) resources extracted from the underlying physical network.
The process of determining the NRP may be made easier if the physical network topology is first filtered into a Filter Topology in order to be aware of the subset of network resources that are suitable for specific NRPs."

* NRP Policy - the scope of NRP Policy is claimed to be one instantiated at the device but also claimed to global network-wide. Could there not be a need to have different attributes such as bandwidth setting on a specific link or node in the NRP? Also, section 5.2.4 describe a case where some part of the network is data-plane and the other is control-plane/data-plane combined and thus we would need to have a mechanism to identify those specific nodes. I see the need for node and link-specific NRP attributes apart from the global ones.

[TS-VPB]: indeed, the NRP Policy allows for different attributes to be provisioned on specific network-elements within the NRP through an override option. The draft draft-bestbar-teas-yang-slice-policy (to be renamed to draft-bestbar-teas-yang-nrp-policy) covers this.

* Multi-domain handling - it is not entirely clear how things would work in a multi-domain, multiple controllers world. Is it in scope or not?
[TS-VPB]: yes, the NRP may span multiple domains and it is in scope. We will expand on this in section 5.

* Cleanup of terms -

[TS-VPB]: yes, will do.

Others

* I agree with others that the Abstract needs some cleaning up.
* I agree with Med that currently there is an uncomfortable mix of high-level architecture and deep solution dive only for some sections such as GIS.

[TS-VPB]: please see previous responses on list.

Regards,
Tarek

Thanks!
Dhruv

On Fri, Feb 18, 2022 at 6:58 PM Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

Thank you,
Lou (as Co-chair)

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 4 Mar 2022 17:40:09 +0000

Hi Med,

If nothing new is defined and just existing tools are re-used I agree with you, but any addition that requires a different behavior in a node, like parsing differently the label stack or adding a new field to a packet requires a standard track.

Cheers
Daniele

From: [email-masked] <[email-masked]>
Sent: den 4 mars 2022 16:00
To: Daniele Ceccarelli <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Cc: [email-masked]; Tarek Saad <[email-masked]>; Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; TEAS WG Chairs <[email-masked]>; [email-masked]
Subject: RE: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hi Daniele,

Cheers,
Med

De : Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>
Envoyé : vendredi 4 mars 2022 15:34
À : Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>; Tarek Saad <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : RE: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hi Med, Pavan,

Cheers,
Daniele

Med, Hi!

Regards,
-Pavan

Cheers,
Med

[snip]

Thank you.

Thank you.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 4 Mar 2022 17:51:12 -0000

Hi Daniele,

I think Med’s point is that a document can say “If you implement this document, this is what you MUST do” but not “You MUST implement this document in order to achieve a general function.”

You actually said this (“it doesn’t have to be THE only solution”) but that was contradicted when you said “if you want to do network slicing in packet technologies, this is what you MUST do”.

Cheers,

Adrian

From: Daniele Ceccarelli <[email-masked]> 
Sent: 04 March 2022 17:40
To: [email-masked]; Vishnu Pavan Beeram <[email-masked]>
Cc: [email-masked]; Tarek Saad <[email-masked]>; Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; TEAS WG Chairs <[email-masked]>; [email-masked]
Subject: RE: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hi Med,

Cheers

Daniele 

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > 
Sent: den 4 mars 2022 16:00
To: Daniele Ceccarelli <[email-masked] <mailto:[email-masked]> >; Vishnu Pavan Beeram <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Tarek Saad <[email-masked] <mailto:[email-masked]> >; Lou Berger <[email-masked] <mailto:[email-masked]> >; TEAS WG <[email-masked] <mailto:[email-masked]> >; TEAS WG Chairs <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hi Daniele, 

Cheers,

Med

De : Daniele Ceccarelli <[email-masked] <mailto:[email-masked]> > 
Envoyé : vendredi 4 mars 2022 15:34
À : Vishnu Pavan Beeram <[email-masked] <mailto:[email-masked]> >; BOUCADAIR Mohamed INNOV/NET <[email-masked] <mailto:[email-masked]> >
Cc : [email-masked] <mailto:[email-masked]> ; Tarek Saad <[email-masked] <mailto:[email-masked]> >; Lou Berger <[email-masked] <mailto:[email-masked]> >; TEAS WG <[email-masked] <mailto:[email-masked]> >; TEAS WG Chairs <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Objet : RE: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hi Med, Pavan,

Cheers,
Daniele  

From: Vishnu Pavan Beeram <[email-masked] <mailto:[email-masked]> > 
Sent: den 4 mars 2022 10:16
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> ; Tarek Saad <[email-masked] <mailto:[email-masked]> >; Lou Berger <[email-masked] <mailto:[email-masked]> >; TEAS WG <[email-masked] <mailto:[email-masked]> >; TEAS WG Chairs <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Med, Hi!

Regards,

-Pavan

On Wed, Mar 2, 2022 at 7:32 AM <[email-masked] <mailto:[email-masked]> > wrote:

Hi all,

Cheers,

Med

De : Teas <[email-masked] <mailto:[email-masked]> > De la part de Adrian Farrel
Envoyé : mercredi 2 mars 2022 12:23
À : 'Tarek Saad' <[email-masked] <mailto:[email-masked]> >; 'Lou Berger' <[email-masked] <mailto:[email-masked]> >; 'TEAS WG' <[email-masked] <mailto:[email-masked]> >
Cc : 'TEAS WG Chairs' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Objet : Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

[snip]

---

From: <[email-masked]>
Date: Mon, 7 Mar 2022 08:49:01 +0000

Hi Danielle, all,

These missing pieces are not specified in this draft but in each of the many individual drafts that are cited there. These individual drafts will have to be in Standards Track if the WGs owning these documents accept to publish them.

I checked the various IPR disclosures to see if there are specific sections that are indicated, but unfortunately there is nothing helpful out there. Only one disclosure indicates a reference to specific sections, but provides 2-6 (which is the full document!!).

For what we are doing in teas, I’m tempted to suggest that a ** new draft ** is edited with less details and dependency on these specific solutions. The document should be more architecture-oriented with a balanced discussion on the viable approaches to realize the slices. The document can identify the missing functionalities, of course.

Cheers,
Med

De : Daniele Ceccarelli <[email-masked]>
Envoyé : vendredi 4 mars 2022 18:40
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Cc : [email-masked]; Tarek Saad <[email-masked]>; Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; TEAS WG Chairs <[email-masked]>; [email-masked]
Objet : RE: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hi Med,

Cheers
Daniele

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: den 4 mars 2022 16:00
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Tarek Saad <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hi Daniele,

Cheers,
Med

Hi Med, Pavan,

Cheers,
Daniele

Med, Hi!

Regards,
-Pavan

Cheers,
Med

[snip]

Thank you.

Thank you.

---

From: Lou Berger <[email-masked]>
Date: Tue, 8 Mar 2022 10:10:02 -0500

WG,

This adoption poll is now closed. Thank you all for the very good 
responses and discussion!

To me, I read the discussion as saying the document is very close to 
being a good starting point as a WG document.  To get us there, I think 
we need the following:

1) That the authors issue an update covering their planned/discussed 
changes

2) Add a section that lists the open issues that should be addressed 
prior to the WG Last Call and being submitted to the IESG for publication

3) Change the document to Informational -- as there are currently no 
interop or defined external behaviors required by the document

Once this is done, I ask the WG to review this version and re-raise any 
issue that they raised during the adoption call that is not addressed or 
captured in the new Open Issues section.

Once all adoption issues are addressed or documented, the document will 
be republished as a -00 WG document.

Thank you all for your contribution to the WG!

Lou (as Co-chair)

---

From: <[email-masked]>
Date: Tue, 8 Mar 2022 15:30:12 +0000

Hi Lou,

I'm not sure how the IPR issue will be fixed by maintaining this same document as starting point. 

The authors can go with a clean document that addresses the various comments received so far. That's the only way I see to formally rechallenge the applicability of the disclosures. 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Teas <[email-masked]> De la part de Lou Berger
> Envoyé : mardi 8 mars 2022 16:10
> À : TEAS WG <[email-masked]>
> Cc : TEAS WG Chairs <[email-masked]>; draft-bestbar-teas-ns-
> [email-masked]

---

From: <[email-masked]>
Date: Wed, 9 Mar 2022 07:18:21 +0000

Hi all, 

I received some offline messages asking to clarify the concern. I was also kindly asked to send the clarification to the list. 

The root issue is that there are many requested changes in the document, while it is not evident that we need something new. The document has to justify the real need for any change it proposes. That’s what I want to be challenged. I won't care if it happens that there will be ipr after we have done that exercise appropriately.  

Starting with a new document would be a good signal in that direction. 

Thank you.

Cheers,
Med

> De : Teas <[email-masked]> De la part de
> [email-masked]
> Envoyé : mardi 8 mars 2022 16:30
> À : Lou Berger <[email-masked]>; TEAS WG <[email-masked]>
> The authors can go with a clean document that addresses the various
> comments received so far. That's the only way I see to formally
> rechallenge the applicability of the disclosures.
> 
> Thank you.
> 
> Cheers,
> Med
> 
> > De : Teas <[email-masked]> De la part de Lou Berger Envoyé :
> > mardi 8 mars 2022 16:10 À : TEAS WG <[email-masked]> Cc : TEAS WG
> > Chairs <[email-masked]>; draft-bestbar-teas-ns- [email-masked]
> > being a good starting point as a WG document.  To get us there, I
> > think we need the following:
> >
> > Once this is done, I ask the WG to review this version and re-raise
> > any issue that they raised during the adoption call that is not
> > addressed or captured in the new Open Issues section.
> >
> > Once all adoption issues are addressed or documented, the document
> > will be republished as a -00 WG document.
> >
> > > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestb
> > > ar
> > > -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)
> > >
> >
> ________________________________________________________________________
> _________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be
> distributed, used or copied without authorisation.

---

From: Lou Berger <[email-masked]>
Date: Wed, 9 Mar 2022 07:17:21 -0500

Hi,

Thank you for the clarification.  My "reading of the room" was there was 
sufficient support to warrant bringing a modified version of this 
document into the WG as a *starting point* for a WG document on this 
topic.  This said, and as always, a WG document is subject to change/the 
consensus of the WG.  Finally, we are contribution driven, so if an 
alternate document is brought forward we can discuss that document and 
it's relationship to existing WG documents.

See you (virtually) soon,

Lou

---

From: <[email-masked]>
Date: Wed, 9 Mar 2022 13:18:37 +0000

Re-,

There are already some interesting alternate documents, e.g.,:

* Instantiation of IETF Network Slices in Service Providers Networks: https://datatracker.ietf.org/doc/draft-barguil-teas-network-slices-instantation/
* IETF Network Slice Service Mapping YANG Model: https://datatracker.ietf.org/doc/html/draft-dhody-teas-ietf-network-slice-mapping-00

I hope the authors of these drafts can be able to present their work.

Cheers,
Med

> De : Lou Berger <[email-masked]>
> Envoyé : mercredi 9 mars 2022 13:17
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; TEAS WG
> <[email-masked]>
> > I received some offline messages asking to clarify the concern. I was
> also kindly asked to send the clarification to the list.
> >
> > The root issue is that there are many requested changes in the
> document, while it is not evident that we need something new. The
> document has to justify the real need for any change it proposes. That’s
> what I want to be challenged. I won't care if it happens that there will
> be ipr after we have done that exercise appropriately.
> >
> >> [email-masked] Envoyé : mardi 8 mars 2022 16:30 À : Lou
> >> Berger <[email-masked]>; TEAS WG <[email-masked]> Cc : TEAS WG
> >>> Chairs <[email-masked]>; draft-bestbar-teas-ns-
> >>> [email-masked] Objet : Re: [Teas] WG adoption poll:
> >>> draft-bestbar-teas-ns-packet-08
> >>>
> >>> WG,
> >>>
> >> _____________________________________________________________________
> >> ___ _________________________________________________
> >>
> >> exploites ou copies sans autorisation. Si vous avez recu ce message
> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> >> que les pieces jointes. Les messages electroniques etant susceptibles
> >> This message and its attachments may contain confidential or
> >> privileged information that may be protected by law; they should not
> >> be distributed, used or copied without authorisation.
> >> If you have received this email in error, please notify the sender
> >> and delete this message and its attachments.
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.