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

[Tarek Saad <[e-mail]>]

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

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


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.
[TS]: OK, will make sure the language is consistent for the cited drafts.

Regards,
Tarek

From: [e-mail] <[e-mail]>
Date: Wednesday, February 23, 2022 at 4:48 AM
To: Tarek Saad <[e-mail]>, Lou Berger <[e-mail]>, TEAS WG <[e-mail]>
Cc: TEAS WG Chairs <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Hi Tarek,

Please see inline.

Cheers,
Med

De : Teas <[e-mail]> De la part de Tarek Saad
Envoyé : mardi 22 février 2022 22:17
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; Lou Berger <[e-mail]>; TEAS WG <[e-mail]>
Cc : TEAS WG Chairs <[e-mail]>; [e-mail]
Objet : 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 <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 22, 2022 at 3:40 AM
To: Lou Berger <[e-mail]<mailto:[e-mail]>>, TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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.

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

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

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.
[Med] Given the parallel with 2475 (which is informational) and that this is *an* approach among others to realize slices, I maintain the comment.


(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.
[Med] Glad to hear that. Having some text that echoes this reply would be great. Thanks.

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

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

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


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

(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 <[e-mail]<mailto:[e-mail]>> De la part de Lou Berger
> Envoyé : vendredi 18 février 2022 14:28
> À : TEAS WG <[e-mail]<mailto:[e-mail]>>
> Cc : TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>; draft-bestbar-teas-ns-
> [e-mail]<mailto:[e-mail]>
> 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
> [e-mail]<mailto:[e-mail]>
> 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.