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

From: Lou Berger <[email-masked]>
Date: Fri, 18 Feb 2022 08:28:10 -0500

Hello,

This email begins a 2-week adoption poll for:
https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/

Please note that IPR has been disclosed on this document:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-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)

---

From: Chandrasekar Ramachandran <[email-masked]>
Date: Mon, 21 Feb 2022 11:03:20 +0000

I support WG adoption (as a contributor).

Chandra.

> -----Original Message-----
> From: Teas <[email-masked]> On Behalf Of Lou Berger
> Sent: Friday, February 18, 2022 6:58 PM
> To: TEAS WG <[email-masked]>
> Cc: TEAS WG Chairs <[email-masked]>; draft-bestbar-teas-ns-
> [email-masked]
> Subject: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
>
> [External Email. Be cautious of content]
>
>
> Hello,
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bestbar-
> teas-ns-packet/__;!!NEt6yMaO-gk!V_TqAc07IKN8QocPaEvnRpeXjJpcJ2-
> C9rWL5ffKVgLoLv6phI_1Waamd8eWAF4$
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/search/?submi
> t=draft&id=draft-bestbar-teas-ns-packet__;!!NEt6yMaO-
> gk!V_TqAc07IKN8QocPaEvnRpeXjJpcJ2-
> C9rWL5ffKVgLoLv6phI_1WaamoknDMkI$
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;
> !!NEt6yMaO-gk!V_TqAc07IKN8QocPaEvnRpeXjJpcJ2-
> C9rWL5ffKVgLoLv6phI_1WaamFtpPmxA$

Juniper Business Use Only

---

From: Srihari Sangli <[email-masked]>
Date: Mon, 21 Feb 2022 11:10:02 +0000

Hi, Lou:

I support the WG adoption (as a contributor)

Thanks & Regards,

srihari…

On 18/02/22, 6:58 PM, "Teas on behalf of Lou Berger" <[email-masked] on behalf of [email-masked]> wrote:

    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!Q5jcG_4QIIndHt6kYMUEfGfJ0I6P2tYIU_Yl82I0XWm5pShQyU7nL7H-gJSUz94$

    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!Q5jcG_4QIIndHt6kYMUEfGfJ0I6P2tYIU_Yl82I0XWm5pShQyU7nL7H-lK1X2n4$

    Thank you,
    Lou (as Co-chair)

    _______________________________________________
    Teas mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Q5jcG_4QIIndHt6kYMUEfGfJ0I6P2tYIU_Yl82I0XWm5pShQyU7nL7H-1BX9atg$

---

From: Colby Barth <[email-masked]>
Date: Mon, 21 Feb 2022 07:12:40 -0500

—Colby

> On Feb 18, 2022, at 8:28 AM, Lou Berger <[email-masked]> wrote:
> 
> Hello,
> 
> https://www.ietf.org/mailman/listinfo/teas

---

From: <[email-masked]>
Date: Mon, 21 Feb 2022 21:07:24 +0800 (CST)

Hi Lou,

Support as a co-author.
Thanks to the joint efforts of WG, we have converged to a single scheme and focused on improving it.

Regards,
PSF

------------------原始邮件------------------
发件人：LouBerger
收件人：TEAS WG;
抄送人：TEAS WG Chairs;[email-masked];
日 期 ：2022年02月18日 21:35
主 题 ：[Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Hello,
This email begins a 2-week adoption poll for:
https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/
Please note that IPR has been disclosed on this document:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 21 Feb 2022 13:34:05 +0000

+1/support.

Thanks
Daniele  

> From: [email-masked] <[email-masked]>
> Sent: den 21 februari 2022 14:07
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re:[Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
> 
> Hi Lou,
> 
> Support as a co-author.
> 主 题 ：[Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08 Hello, This
> email begins a 2-week adoption poll for:

---

From: "Jalil, Luay" <[email-masked]>
Date: Mon, 21 Feb 2022 14:29:54 -0600

I support WG adoption (as a contributor)

Regards,
*Luay*

On Fri, Feb 18, 2022 at 7:28 AM Lou Berger <[email-masked]> wrote:

> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbestbar-2Dteas-2Dns-2Dpacket_&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=7e6BZvxfFDSTTna9ab2Ydr_OMvetTnPkcEa_b18N68D94I-0plfSKxfn-pIS-FhX&s=c806kukhTc3y28qN-bbR3o46ukKCcWiwwQOPcyWlNwE&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_search_-3Fsubmit-3Ddraft-26id-3Ddraft-2Dbestbar-2Dteas-2Dns-2Dpacket&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=7e6BZvxfFDSTTna9ab2Ydr_OMvetTnPkcEa_b18N68D94I-0plfSKxfn-pIS-FhX&s=J3gb5YVb7MHbotm_W4-3BD_1WwIFJqO_j18GmVjWgsU&e=
>

---

From: <[email-masked]>
Date: Tue, 22 Feb 2022 09:51:07 +0800 (CST)

Hi lou and WG,

I think the draft is very valuable, so I support  as co-author. 

Best Regards,

Ran

原始邮件

发件人：LouBerger
收件人：TEAS WG;

Hello,

 
 
Thank you,
Lou (as Co-chair)

---

From: <[email-masked]>
Date: Tue, 22 Feb 2022 09:52:04 +0800 (CST)

Hi lou and WG,

Best Regards,
Ran

------------------原始邮件------------------
发件人：LouBerger
收件人：TEAS WG;

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 21 Feb 2022 22:16:13 -0600

I believe the draft is sufficiently baked for the WG to build on and take
it forward. I support WG adoption.

Regards,
-Pavan (as a co-author).

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 22 Feb 2022 01:36:50 -0500

I have reviewed the draft  and have provided feedback to the authors to
help improve the draft in previous revisions and do support WG adoption.

Kind Regards

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 22 Feb 2022 08:02:58 +0000

Hi all

I support the adoption of the draft (as co-author)

Best regards

Luis

-----Mensaje original-----
De: Teas <[email-masked]> En nombre de Lou Berger
Enviado el: viernes, 18 de febrero de 2022 14:28
Para: TEAS WG <[email-masked]>
CC: TEAS WG Chairs <[email-masked]>; [email-masked]
Asunto: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Hello,

Thank you,
Lou (as Co-chair)

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: <[email-masked]>
Date: Tue, 22 Feb 2022 08:40:28 +0000

Hi all, 

I highly appreciate the effort made by various author groups to edit this document. Please find below some comments, fwiw:  

(1) I reviewed a previous version of the draft (https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-bestbar-teas-ns-packet-05-rev%20Med.pdf). I know that Tarek (many thanks) released an updated version after that review, but when checking the diff 05-08, I still have many of these concerns with the latest version. 

(2) I have a mixed feeling when reading this document. I like the architectural parallel with 2475, but I'm less comfortable with many of the individual solutions cited in the draft. Separating the overall architecture discussion vs. solution-specific details would be my favorite approach. However, this would conflict with the scope set for the draft: 

   "The focus of this document is on the
   mechanisms required at the device level to address the requirements
   of network slicing in packet networks."

This is even worse as the document says:  

   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. 

which seems to mandate that ** every ** router in the network should be slice-aware, which is not required IMO.

Also, the parallel of an NRP vs. per-domain behavior (PDB) is worth to be mentioned.

(3) I would like if the document can be more explicit in answering questions such as: "Can we realize a slice without having to define a new data plane extension?". The answer is definitely "Yes". See for example the work documented at: https://datatracker.ietf.org/doc/html/draft-barguil-teas-network-slices-instantation-02 

(4) I don't think the document should be published in the Standards Track, but Informational. 

(5) I suggest to update the title form "Realizing Network Slices in IP/MPLS Networks" to "An Approach for Realizing Network Slices in IP/MPLS Networks"

(6) The document states that it " provides a path control technology ... agnostic solution .", while it includes many solution-specific details and even normative references pointing to some "path control" mechanisms. 

(7) It is not clear to me what was the rationale for keeping some individual I-Ds as normative, while accepting to move some others to be informative. 

(8) The document reasons about aggregating "slices" while I think the intent is "slice services". If the slices are aggregated themselves, then a state is needed to be maintained in the network about these individual slices (at least at boundary nodes to glue an individual slice and its parent aggregate). If services are aggregated, then the optimization at the boundary devices is made possible. The "aggregation" information will need to be maintained in controllers. 

(9) The definition section includes some architectural assumptions, e.g., 

      the mapping of one or more IETF network slices to a
      Slice-Flow Aggregate is maintained by the IETF Network Slice
      Controller.

This may also be maintained by an ingress node (as per (8)). 

(10) Many parts of the document can just apply to individual slices, not only aggregates. It would be helpful to call this out as appropriate. 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Teas <[email-masked]> De la part de Lou Berger
> Envoyé : vendredi 18 février 2022 14:28
> À : TEAS WG <[email-masked]>
> Cc : TEAS WG Chairs <[email-masked]>; draft-bestbar-teas-ns-
> [email-masked]
> Objet : [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
> 
> Hello,
> 

_________________________________________________________________________________________________________________________

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: "Rokui, Reza" <[email-masked]>
Date: Tue, 22 Feb 2022 14:25:25 +0000

I support this (as co-author).

Reza

From: Colby Barth <[email-masked]>
Date: Monday, February 21, 2022 at 7:12 AM
To: Lou Berger <[email-masked]>, TEAS WG <[email-masked]>, TEAS WG Chairs <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [**EXTERNAL**] Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
I support WG adoption (as a contributor).

—Colby

On Feb 18, 2022, at 8:28 AM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

This email begins a 2-week adoption poll for:
https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!OSsGDw!e-REq9t2-6cnzf1KHVDO3OaI17ScxusadK4lK8Sjn6eSqMZE8Q4WzkOmyi5k$>

Please note that IPR has been disclosed on this document:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-ns-packet [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-ns-packet__;!!OSsGDw!e-REq9t2-6cnzf1KHVDO3OaI17ScxusadK4lK8Sjn6eSqMZE8Q4WztVSlTQg$>

Thank you,
Lou (as Co-chair)

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!OSsGDw!e-REq9t2-6cnzf1KHVDO3OaI17ScxusadK4lK8Sjn6eSqMZE8Q4Wzmkuhqrm$>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Feb 2022 11:27:53 -0500

With regard to what routers need to be aware of what, I read the wording 
you quote slightly and importantly differently.

As I understand it, that wording means that any rotuer that is providing 
different treatment to a slice flow aggregate (e.g. giving it different 
queueing or other resources) has to be aware of the slice aggregate it 
is treating and how to recognize which packets fall into that slice 
aggregate.

I believe that is the meaning of the words.  And it seems almost 
tautological.  (But still useful to say.)

Yours,
Joel

---

From: Tarek Saad <[email-masked]>
Date: Tue, 22 Feb 2022 21:17:07 +0000

Thanks Med as usual for your feedback and comments. See inline for responses.

From: Teas <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Tuesday, February 22, 2022 at 3:40 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 all,

[TS]: We have made a conscious attempt to maintain the architectural parallel with 2475 (glad you like it). This is meant to be a solution document -- the intent with the narrative is to highlight the architectural parallel and then discuss the solution-specific details.

which seems to mandate that ** every ** router in the network should be slice-aware, which is not required IMO.
[TS]: No, it’s definitely not the intent. What’s stated is any router that needs enforce a specific SFA forwarding treatment is required to associate the packets to a SFA. Routers that don’t need to enforce SFA forwarding treatment are not required to do so. We'll try to rephrase this as Joel put in his response.

[TS]: Indeed. The document describes a ‘control plane only’ slicing mode<https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-08#section-4.2> for network resources. In that case, the network resources are managed in the control plane without additional dataplane requirements.

[TS]: We believe it should be standards track. There are a set of new constructs and behaviors that are introduced in the document.

[TS]: the document is not prescriptive on the technology of choice to establish the transport paths. However, the concepts proposed, are applicable independent of choice of technology.

[TS]: it helps if you can provide a specific example.

[TS]: ack, we propose to update the above as follows:

NEW:
      the mapping of one or more IETF network slices to a
      Slice-Flow Aggregate is maintained by the IETF Network Slice
      Controller. The boundary nodes MAY also maintain a mapping
      of specific IETF network slice service(s) to a SFA.

[TS]: indeed. The document does not preclude this option. We can add a statement to make it explicit too.

Regards,
Tarek (for the co-authors)

Thank you.

Cheers,
Med

---

From: Raveendra Torvi <[email-masked]>
Date: Tue, 22 Feb 2022 21:31:19 +0000

I support WG adoption.
Ravi

> On Feb 18, 2022, at 5:28 AM, Lou Berger <[email-masked]> wrote:
> 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!XOrVThIR9geV4G-vIBca4kYsJ7t9nbINg6ehcE-2v82nfYF8KkCcG8wPDa3mLvU$
> 
> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!XOrVThIR9geV4G-vIBca4kYsJ7t9nbINg6ehcE-2v82nfYF8KkCcG8wPV4HwUTY$
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!XOrVThIR9geV4G-vIBca4kYsJ7t9nbINg6ehcE-2v82nfYF8KkCcG8wPvyeSvqQ$

---

From: <[email-masked]>
Date: Wed, 23 Feb 2022 06:39:47 +0000

Hi Joel, 

I fully agree that if the text said "A router that is providing different treatment to a slice flow aggregate ...." that would be tautological and I would be less concerned with it.

What I was concerned with is to require more service context that isn't required for normal operation of a data plane solution. Think about a domain in which slice aggregates are bound to diffserv PDBs. Routers do not need to be aware that a PHB is for a specific service (slice service, in this case); they will just apply the corresponding treatment to the traffic as appropriate. 

Thanks. 

Cheers,
Med

> De : Teas <[email-masked]> De la part de Joel M. Halpern
> Envoyé : mardi 22 février 2022 17:28
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; TEAS WG
> <[email-masked]>
> Objet : Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08 -
> aggregate awareness
> 
> > I highly appreciate the effort made by various author groups to edit
> this document. Please find below some comments, fwiw:
> >
> > (1) I reviewed a previous version of the draft
> (https://raw.githubusercontent.com/boucadair/IETF-Drafts-
> Reviews/master/draft-bestbar-teas-ns-packet-05-rev%20Med.pdf). I know
> that Tarek (many thanks) released an updated version after that review,
> but when checking the diff 05-08, I still have many of these concerns
> with the latest version.
> >
> > (2) I have a mixed feeling when reading this document. I like the
> architectural parallel with 2475, but I'm less comfortable with many of
> the individual solutions cited in the draft. Separating the overall
> architecture discussion vs. solution-specific details would be my
> favorite approach. However, this would conflict with the scope set for
> the draft:
> >
> > which seems to mandate that ** every ** router in the network should
> be slice-aware, which is not required IMO.
> >
> > (3) I would like if the document can be more explicit in answering
> > questions such as: "Can we realize a slice without having to define a
> > new data plane extension?". The answer is definitely "Yes". See for
> > example the work documented at:
> > https://datatracker.ietf.org/doc/html/draft-barguil-teas-network-slice
> > s-instantation-02
> >
> > (5) I suggest to update the title form "Realizing Network Slices in
> IP/MPLS Networks" to "An Approach for Realizing Network Slices in
> IP/MPLS Networks"
> >
> > (6) The document states that it " provides a path control technology
> ... agnostic solution .", while it includes many solution-specific
> details and even normative references pointing to some "path control"
> mechanisms.
> >
> > (7) It is not clear to me what was the rationale for keeping some
> individual I-Ds as normative, while accepting to move some others to be
> informative.
> >
> > (8) The document reasons about aggregating "slices" while I think the
> intent is "slice services". If the slices are aggregated themselves,
> then a state is needed to be maintained in the network about these
> individual slices (at least at boundary nodes to glue an individual
> slice and its parent aggregate). If services are aggregated, then the
> optimization at the boundary devices is made possible. The "aggregation"
> information will need to be maintained in controllers.
> >
> > (10) Many parts of the document can just apply to individual slices,
> not only aggregates. It would be helpful to call this out as
> appropriate.
> >
> > Thank you.
> >
> > Cheers,
> > Med
> >
> >> De : Teas <[email-masked]> De la part de Lou Berger Envoyé :
> >> vendredi 18 février 2022 14:28 À : TEAS WG <[email-masked]> Cc : TEAS
> >> WG Chairs <[email-masked]>; draft-bestbar-teas-ns-
> >> [email-masked] Objet : [Teas] WG adoption poll:
> >> draft-bestbar-teas-ns-packet-08
> >>
> >> Hello,
> >>
> >> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestba
> >> r-
> >> 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)
> >>

---

From: <[email-masked]>
Date: Wed, 23 Feb 2022 09:48:07 +0000

Hi Tarek,

Please see inline.

Cheers,
Med

De : Teas <[email-masked]> De la part de Tarek Saad
Envoyé : mardi 22 février 2022 22:17
À : BOUCADAIR Mohamed INNOV/NET <[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

From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 22, 2022 at 3:40 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 all,

[Med] The individual solutions that are cited in the draft are ** examples ** to achieve specific features (e.g. global identification). Other solutions (including future ones) may be proposed to provide similar features. If we want the architecture to survive to individual solutions, an arch-oriented document has more merit. Also, as there are already 5 IPR disclosures and it is not clear if they apply to the generic architecture or to the specific solutions I-Ds cited in the draft, I do see a value in "offloading" specific solution details to these solution documents rather than having redundant discussion also included in this arch document.

which seems to mandate that ** every ** router in the network should be slice-aware, which is not required IMO.
[TS]: No, it's definitely not the intent.
[Med] Great. I hope this will be clarified in the text.

What's stated is any router that needs enforce a specific SFA forwarding treatment is required to associate the packets to a SFA. Routers that don't need to enforce SFA forwarding treatment are not required to do so. We'll try to rephrase this as Joel put in his response.

(3) I would like if the document can be more explicit in answering questions such as: "Can we realize a slice without having to define a new data plane extension?". The answer is definitely "Yes". See for example the work documented at: https://datatracker.ietf.org/doc/html/draft-barguil-teas-network-slices-instantation-02
[TS]: Indeed. The document describes a 'control plane only' slicing mode<https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-08#section-4.2> for network resources. In that case, the network resources are managed in the control plane without additional dataplane requirements.

[TS]: We believe it should be standards track. There are a set of new constructs and behaviors that are introduced in the document.
[Med] Given the parallel with 2475 (which is informational) and that this is *an* approach among others to realize slices, I maintain the comment.

[TS]: the document is not prescriptive on the technology of choice to establish the transport paths. However, the concepts proposed, are applicable independent of choice of technology.
[Med] Glad to hear that. Having some text that echoes this reply would be great. Thanks.

[Med] Sure. I'm referring to these three I-Ds.

    [I-D.bestbar-teas-yang-slice-policy]
              Saad, T., Beeram, V. P., Wen, B., Ceccarelli, D., Peng,
              S., Chen, R., Contreras, L. M., and X. Liu, "YANG Data
              Model for Slice Policy", Work in Progress, Internet-Draft,
              draft-bestbar-teas-yang-slice-policy-02, 25 October 2021,
              <https://www.ietf.org/archive/id/draft-bestbar-teas-yang-
              slice-policy-02.txt>.

   [I-D.ietf-lsr-flex-algo]
              Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
              A. Gulko, "IGP Flexible Algorithm", Work in Progress,
              Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October
              2021, <https://www.ietf.org/archive/id/draft-ietf-lsr-
              flex-algo-18.txt>.

   [I-D.kompella-mpls-mspl4fa]

Also, the language is not consistent for all cited solution drafts, e.g.,

      An NRP Policy MAY include a Global Identifier FAS (GIS) field as

      defined in [I-D.kompella-mpls-mspl4fa]

vs.

      [I-D.decraene-mpls-slid-encoded-entropy-label-id] also proposes to

      repurpose the ELI/EL [RFC6790] to carry the Slice Identifier in

      order to minimize the size of the MPLS stack and ease incremental

      deployment.

I would remove the normative language for the text pointing to mspl4fa.

[Med] I hope the point is will be addressed.

NEW:

Regards,

Thank you.

Cheers,
Med

> De : Teas <[email-masked]<mailto:[email-masked]>> De la part de Lou Berger
> À : TEAS WG <[email-masked]<mailto:[email-masked]>>
> Cc : TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>; draft-bestbar-teas-ns-
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Tarek Saad <[email-masked]>
Date: Wed, 23 Feb 2022 19:25:14 +0000

Hi Med,

See below for follow-up responses.

>> [Med] The individual solutions that are cited in the draft are ** examples ** to achieve specific features (e.g. global identification). Other solutions (including future ones) may be proposed to provide similar features. If we want the architecture to survive to individual solutions, an arch-oriented document has more merit. Also, as there are already 5 IPR disclosures and it is not clear if they apply to the generic architecture or to the specific solutions I-Ds cited in the draft, I do see a value in “offloading” specific solution details to these solution documents rather than having redundant discussion also included in this arch document.
[TS]: yes, the intention is to discuss the protocol and/or dataplane extensions related to the solution in separate documents (potentially driven at the respective WGs). We can make sure any such details are not discussed in this document. At this time, the document only provides references to the related work driven outside its scope.

>> [Med] Sure. I’m referring to these three I-Ds.

   [I-D.ietf-lsr-flex-algo]

[TS] : we acknowledge the inconsistency here. We will move these references to informative in the next revision.

vs.

      deployment.

I would remove the normative language for the text pointing to mspl4fa.
[TS]: OK, will make sure the language is consistent for the cited drafts.

Regards,
Tarek

From: [email-masked] <[email-masked]>
Date: Wednesday, February 23, 2022 at 4:48 AM
To: Tarek Saad <[email-masked]>, 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 Tarek,

Please see inline.

Cheers,
Med

[Med] The individual solutions that are cited in the draft are ** examples ** to achieve specific features (e.g. global identification). Other solutions (including future ones) may be proposed to provide similar features. If we want the architecture to survive to individual solutions, an arch-oriented document has more merit. Also, as there are already 5 IPR disclosures and it is not clear if they apply to the generic architecture or to the specific solutions I-Ds cited in the draft, I do see a value in “offloading” specific solution details to these solution documents rather than having redundant discussion also included in this arch document.

which seems to mandate that ** every ** router in the network should be slice-aware, which is not required IMO.
[TS]: No, it’s definitely not the intent.
[Med] Great. I hope this will be clarified in the text.

What’s stated is any router that needs enforce a specific SFA forwarding treatment is required to associate the packets to a SFA. Routers that don’t need to enforce SFA forwarding treatment are not required to do so. We'll try to rephrase this as Joel put in his response.

[Med] Sure. I’m referring to these three I-Ds.

   [I-D.ietf-lsr-flex-algo]

vs.

      deployment.

NEW:

Regards,

Thank you.

Cheers,
Med

Thank you.

---

From: <[email-masked]>
Date: Thu, 24 Feb 2022 07:12:25 +0000

Hi Tarek,

Thank you for the follow-up.

I think that we converge on the intended scope. I hope to see a revised version with a clear separation between the generic architecture with less details about specific solutions/extensions + balanced treatment of the various options to achieve aggregation.

Cheers,
Med

Envoyé : mercredi 23 février 2022 20:25

Hi Med,

   [I-D.ietf-lsr-flex-algo]

vs.

      deployment.

Regards,
Tarek

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 23, 2022 at 4:48 AM
To: 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]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Hi Tarek,

Please see inline.

Cheers,
Med

De : Teas <[email-masked]<mailto:[email-masked]>> De la part de Tarek Saad
Envoyé : mardi 22 février 2022 22:17
À : BOUCADAIR Mohamed INNOV/NET <[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

   [I-D.ietf-lsr-flex-algo]

vs.

      deployment.

NEW:

Regards,

Thank you.

Cheers,
Med

Thank you.

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Thu, 24 Feb 2022 09:04:21 +0000

Hi Authors,

I'd just like to clarify.
Comparing Fig. 5 in draft-ietf-teas-ietf-network-slices-05 with Fig. 1 in this draft, I understand that this draft also describes one of solutions realizing Network Resource Partition(NRP).
If my understanding is correct, NRP-ID is essentially same as FASL and "Slice Aggregate ID" described at Fig.5 in draft-bestbar-lsr-slice-aware-te-00.
From an operational perspective, it's burden to manage many slice related components and the mappings of these components, e.g. connectivity matrix <-> IETF network slice <-> Slice-flow Aggregate <-> FAS <-> NRP.
Do authors have any thought to at least unify these identifiers in a series of bestbar drafts. Or, is there any reason not able to unify these?

Thanks,
Kenichi
-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Lou Berger
Sent: Friday, February 18, 2022 10:28 PM
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,

Thank you,
Lou (as Co-chair)

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 24 Feb 2022 09:03:34 -0600

Kenichi, Hi!

Thanks for the review! This draft discusses the use of Network Resource
Partition (NRP) to support a Slice-Flow Aggregate. The NRP identifier is
unique within an NRP domain and is meant for use in the control/management
plane to identify the resources associated with the NRP (this should be the
identifier used in any relevant control-plane protocol extensions).

The NRP-ID is not the same as Flow-Aggregate Selector (FAS). The FAS is
quite simply the marking in the data plane packet that identifies a
Slice-Flow Aggregate. The same Slice-Flow Aggregate may be identified by
multiple Flow-Aggregate Selectors (see the example in Section 5.1.1 where a
range of VPN service labels – each acting as a FAS – select the same
Slice-Flow Aggregate). The solution architecture leaves room for an
implementation to overload the NRP-ID and use it as a FAS – but that is
strictly an implementation choice.

And yes, we do expect all other related work to eventually align and adhere
to what is specified in this document.

Regards,

-Pavan (as co-author)

On Thu, Feb 24, 2022 at 3:14 AM Ogaki, Kenichi <[email-masked]> wrote:

> Comparing Fig. 5 in draft-ietf-teas-ietf-network-slices-05 with Fig. 1 in
> this draft, I understand that this draft also describes one of solutions
> realizing Network Resource Partition(NRP).
> If my understanding is correct, NRP-ID is essentially same as FASL and
> "Slice Aggregate ID" described at Fig.5 in
> draft-bestbar-lsr-slice-aware-te-00.
> From an operational perspective, it's burden to manage many slice related
> components and the mappings of these components, e.g. connectivity matrix
> <-> IETF network slice <-> Slice-flow Aggregate <-> FAS <-> NRP.
> Do authors have any thought to at least unify these identifiers in a
> series of bestbar drafts. Or, is there any reason not able to unify these?
>
> Thanks,
> Kenichi

---

From: Huzhibo <[email-masked]>
Date: Sat, 26 Feb 2022 01:02:27 +0000

Hi:

I would appreciate it if the authors can clarify the following questions:

1.   Essentially the identifier in data packet is used to identify the NRP which the packet is mapped to, and the set of resource for processing and forwarding the packet. Calling it a flow aggregate selector would confuse the boundary between service flows and the underlay network construct (which is called NRP). In my understanding, the network devices only maintain the NRP specific resource states, they (except the ingress nodes) do not need to know whether and how service flows are mapped to the NRP.

2.   I’m a little confused about the case which multiple VPN labels are used to identify a Slice Flow Aggregate. The VPN service label are usually called service label, it is not clear how a service label can be used to identify a flow aggregate. And since this data plane ID need to be processed by intermediate nodes, can the VPN labels be parsed and processed by the intermediate nodes? BTW, the text in section 5.1.1 describes several options of encapsulating the identifier in MPLS packet header, which does not belong to a TEAS document, better to move them to an MPLS draft.

Thanks

Zhibo
From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, February 24, 2022 11:04 PM
To: Ogaki, Kenichi <[email-masked]>
Cc: Lou Berger <[email-masked]>; TEAS WG Chairs <[email-masked]>; [email-masked]; TEAS WG <[email-masked]>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08

Kenichi, Hi!

Thanks for the review! This draft discusses the use of Network Resource Partition (NRP) to support a Slice-Flow Aggregate. The NRP identifier is unique within an NRP domain and is meant for use in the control/management plane to identify the resources associated with the NRP (this should be the identifier used in any relevant control-plane protocol extensions).

The NRP-ID is not the same as Flow-Aggregate Selector (FAS). The FAS is quite simply the marking in the data plane packet that identifies a Slice-Flow Aggregate. The same Slice-Flow Aggregate may be identified by multiple Flow-Aggregate Selectors (see the example in Section 5.1.1 where a range of VPN service labels – each acting as a FAS – select the same Slice-Flow Aggregate). The solution architecture leaves room for an implementation to overload the NRP-ID and use it as a FAS – but that is strictly an implementation choice.

And yes, we do expect all other related work to eventually align and adhere to what is specified in this document.

Regards,
-Pavan (as co-author)

On Thu, Feb 24, 2022 at 3:14 AM Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Authors,

Thanks,
Kenichi
-----Original Message-----
From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Lou Berger
Sent: Friday, February 18, 2022 10:28 PM
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,

Thank you,
Lou (as Co-chair)

---

From: Xufeng Liu <[email-masked]>
Date: Sat, 26 Feb 2022 13:47:31 -0500

Support.
Thanks,
- Xufeng

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

---

From: Tarek Saad <[email-masked]>
Date: Mon, 28 Feb 2022 04:38:18 +0000

Hi Zhibo,

See inline.

From: Teas <[email-masked]> on behalf of Huzhibo <huzhibo=[email-masked]>
Date: Friday, February 25, 2022 at 8:03 PM
To: Vishnu Pavan Beeram <[email-masked]>, Ogaki, Kenichi <[email-masked]>
Cc: Lou Berger <[email-masked]>, 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:

1.   Essentially the identifier in data packet is used to identify the NRP which the packet is mapped to, and the set of resource for processing and forwarding the packet. Calling it a flow aggregate selector would confuse the boundary between service flows and the underlay network construct (which is called NRP). In my understanding, the network devices only maintain the NRP specific resource states, they (except the ingress nodes) do not need to know whether and how service flows are mapped to the NRP.
[TS]: service flows (from IETF network slices) are aggregated into Slice Flow-Aggregate (SFA) so they are given similar treatment in the network. The flow aggregate traffic carries a Flow-Aggregate Selector (FAS) to allow nodes to distinguish packets belonging to the SFA. The SFA traffic is placed on paths established over the network resources defined by the NRP.

[TS]: the document describes that a FAS can take several forms and depending on the specifc dataplane (e.g., MPLS, IPv6, etc.). The use of the service labels was an example for illustration only. The document already references MPLS documents (e.g., I-D.kompella-mpls-mspl4fa and I-D.decraene-mpls-slid-encoded-entropy-label-id) where proposals allow carrying the FAS in the MPLS label stack.

Regards,
Tarek (for co-authors)

Thanks

Zhibo

Kenichi, Hi!

Regards,
-Pavan (as co-author)

Thanks,
Kenichi
-----Original Message-----
From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Lou Berger
Sent: Friday, February 18, 2022 10:28 PM
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,

Thank you,
Lou (as Co-chair)

---

From: Loa Andersson <[email-masked]>
Date: Mon, 28 Feb 2022 12:53:15 +0800

Tarek,

Inline please.

On 2022-02-28 12:38, Tarek Saad wrote:
> Hi Zhibo,
> 
> See inline.
> 
> *From: *Teas <[email-masked]> on behalf of Huzhibo 
> <huzhibo=[email-masked]>
> *Date: *Friday, February 25, 2022 at 8:03 PM
> *To: *Vishnu Pavan Beeram <[email-masked]>, Ogaki, Kenichi 
> <[email-masked]>
> *Cc: *Lou Berger <[email-masked]>, 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:
> 
> 1.   Essentially the identifier in data packet is used to identify the 
> NRP which the packet is mapped to, and the set of resource for 
> processing and forwarding the packet. Calling it a flow aggregate 
> selector would confuse the boundary between service flows and the 
> underlay network construct (which is called NRP). In my understanding, 
> the network devices only maintain the NRP specific resource states, they 
> (except the ingress nodes) do not need to know whether and how service 
> flows are mapped to the NRP.
> 
> [TS]: service flows (from IETF network slices) are aggregated into Slice 
> Flow-Aggregate (SFA) so they are given similar treatment in the network. 
> The flow aggregate traffic carries a Flow-Aggregate Selector (FAS) to 
> allow nodes to distinguish packets belonging to the SFA. The SFA traffic 
> is placed on paths established over the network resources defined by the 
> NRP.

Are you saying that SFA's have the same FEC? If so are we inventing the 
wheel again?

/Loa
> 
> 2.   I’m a little confused about the case which multiple VPN labels are 
> used to identify a Slice Flow Aggregate. The VPN service label are 
> usually called service label, it is not clear how a service label can be 
> used to identify a flow aggregate. And since this data plane ID need to 
> be processed by intermediate nodes, can the VPN labels be parsed and 
> processed by the intermediate nodes? BTW, the text in section 5.1.1 
> describes several options of encapsulating the identifier in MPLS packet 
> header, which does not belong to a TEAS document, better to move them to 
> an MPLS draft.
> 
> [TS]: the document describes that a FAS can take several forms and 
> depending on the specifc dataplane (e.g., MPLS, IPv6, etc.). The use of 
> the service labels was an example for illustration only. The document 
> already references MPLS documents (e.g., I-D.kompella-mpls-mspl4fa and 
> I-D.decraene-mpls-slid-encoded-entropy-label-id) where proposals allow 
> carrying the FAS in the MPLS label stack.
> 
> Regards,
> 
> Tarek (for co-authors)
> 
> Thanks
> 
> Zhibo
> 
> *From:*Teas [mailto:[email-masked]] *On Behalf Of *Vishnu Pavan 
> Beeram
> *Sent:* Thursday, February 24, 2022 11:04 PM
> *To:* Ogaki, Kenichi <[email-masked]>
> *Cc:* Lou Berger <[email-masked]>; TEAS WG Chairs 
> <[email-masked]>; [email-masked]; TEAS WG 
> <[email-masked]>
> *Subject:* Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
> 
> Kenichi, Hi!
> 
> unique within an NRP domain and is meant for use in the 
> control/management plane to identify the resources associated with the 
> NRP (this should be the identifier used in any relevant control-plane 
> protocol extensions).
> 
> multiple Flow-Aggregate Selectors (see the example in Section 5.1.1 
> where a range of VPN service labels – each acting as a FAS – select the 
> same Slice-Flow Aggregate). The solution architecture leaves room for an 
> And yes, we do expect all other related work to eventually align and 
> adhere to what is specified in this document.
> 
> Regards,
> 
> -Pavan (as co-author)
> 
>     Comparing Fig. 5 in draft-ietf-teas-ietf-network-slices-05 with Fig.
>     1 in this draft, I understand that this draft also describes one of
>     solutions realizing Network Resource Partition(NRP).
>     If my understanding is correct, NRP-ID is essentially same as FASL
>     and "Slice Aggregate ID" described at Fig.5 in
>     From: Teas <[email-masked] <mailto:[email-masked]>> On
>     Behalf Of Lou Berger
>     To: TEAS WG <[email-masked] <mailto:[email-masked]>>
>     Cc: TEAS WG Chairs <[email-masked]
>     <mailto:[email-masked]>>;
>     [email-masked]
>     <mailto:[email-masked]>
>     <https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/>
> 
>     <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas-ns-packet>
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
> 
> 

-- 
Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 28 Feb 2022 13:11:26 -0000

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

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.

---

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

---

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!

---

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

---

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?

---

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.
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?
I feel there is also something missing in defining which slices can
be grouped into aggregates.

---

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

---

Why does this document feel the need to redefine the Network Resource
Partition?

---

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.

---

      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.

---

What are "NRP Policy selection criteria"?

---

What's an "NRP domain"?

---

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

--

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

---

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

---

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

---

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.

---

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?

---

Reading 3.7, and to be clear, you don't intend your mechanism to be
available for CE-terminated slice services?

---

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.

---

3.8 seems to have forgotten about the NRP.

---

4.1 has another paragraph describing DiffServ. Very interesting, but not
relevant to this document.

---

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.

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

---

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?

---

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

---

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?

---

4.1

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

You have already said this.

---

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?

2. I feel fairly sure that this paragraph is intended to carry some 
   useful meaning, but it eludes me.

---

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.

---

4.2

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

What is a slice 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?

---

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.

---

5.1.1

Why "Global Identifier FAS (GIS)"?

---

5.1.1

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

---

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

---

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.

---

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.

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.

---

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.

---

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.

---

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.

---

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.

--

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.

---

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.

---

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.

---

5.2.2

   and MAY be able to

That's a lower case "may"

---

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

---

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.

---

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.

---

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?

---

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?

---

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

---

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.

---

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.

---

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?

---

10.

Interesting that you thank one of the authors for reviewing the
document :-)

---

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.

---

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

---

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

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

Hello,

Please note that IPR has been disclosed on this document:
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)

---

From: Tarek Saad <[email-masked]>
Date: Mon, 28 Feb 2022 14:49:18 +0000

From: Loa Andersson <[email-masked]>
Date: Sunday, February 27, 2022 at 11:53 PM
To: Tarek Saad <[email-masked]>, Huzhibo <huzhibo=[email-masked]>, Vishnu Pavan Beeram <[email-masked]>, Ogaki, Kenichi <[email-masked]>
Cc: Lou Berger <[email-masked]>, 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
Tarek,

Inline please.

[TS]: No. It is possible traffic from multiple SFAs can be forwarded over the same LSP. The presence of the FAS in packet will determine the specific forwarding treatment that would be imposed on packets belonging to the respective SFA.

Regards,
Tarek

/Loa