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

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

From: Teas <teas-bounces@ietf.org> on behalf of mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
Date: Tuesday, February 22, 2022 at 3:40 AM
To: Lou Berger <lberger@labn.net>, TEAS WG <teas@ietf.org>
Cc: TEAS WG Chairs <teas-chairs@ietf.org>, draft-bestbar-teas-ns-packet@ietf.org <draft-bestbar-teas-ns-packet@ietf.org>
Subject: 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas