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

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 <teas-bounces@ietf.org> De la part de Lou Berger
> Envoyé : vendredi 18 février 2022 14:28
> À : TEAS WG <teas@ietf.org>
> Cc : TEAS WG Chairs <teas-chairs@ietf.org>; draft-bestbar-teas-ns-
> packet@ietf.org
> Objet : [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
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas

_________________________________________________________________________________________________________________________

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.