Subject: [Teas] Disposition of draft-ietf-teas-ietf-network-slice-definition-00

From: John E Drake <[email-masked]>
Date: Wed, 31 Mar 2021 15:44:09 +0000

Hi,

Eric and I have been asked by the teas working group chairs to merge the subject draft into the framework
draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-framework-00.  Our proposal is detailed below.

Definition of IETF Network Slices
            draft-ietf-teas-ietf-network-slice-definition-01

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2

*****JD  The content of the two introductions will be merged

   2.  Terms and Abbreviations . . . . . . . . . . . . . . . . . . .   3

*****JD  This will be a new section 2 in the Framework draft.    The current
section 2 of the Framework draft will be split between the new section 2 and possibly sections 3 and 4.

   3.  Definition and Scope of IETF Network Slice  . . . . . . . . .   4

*****JD  This section will be moved to the new section 2.
 
   4.  IETF Network Slice System Characteristics . . . . . . . . . .   4

*****JD  This section will be moved to the new section 2

     4.1.  Objectives for IETF Network Slices  . . . . . . . . . . .   5

*****JD  This section will be split  between the new section 2 and  possibly sections 3 and 4.

       4.1.1.  Service Level Objectives  . . . . . . . . . . . . . .   5
       4.1.2.  Minimal Set of SLOs . . . . . . . . . . . . . . . . .   5
       4.1.3.  Other Objectives  . . . . . . . . . . . . . . . . . .   7

*****JD  These sections will be moved to the new section 2.

     4.2.  IETF Network Slice Endpoints  . . . . . . . . . . . . . .   7

*****JD  This section will be moved to the new section 2 and will be updated to use the terminology agreed upon on the mailing list.  A reference to RFC 4364's section 9 "Carriers' Carriers" (https://datatracker.ietf.org/doc/html/rfc4364#section-9)
will be added.  We will also note that the 'CE', 'attachment circuit', and 'PE' can all be virtualized.

       4.2.1.  IETF Network Slice Connectivity Types . . . . . . . .   9

*****JD  This section will be moved to the new section 2.

     4.3.  IETF Network Slice Composition  . . . . . . . . . . . . .   9

*****JD  This section will be moved to the new section 2.  Note that the non-definitional material in *all* of the preceding sections will be split between sections 3 and 4.  Section
4 will become a generalized 'Applicability' section .

   5.  IETF Network Slice Structure  . . . . . . . . . . . . . . . .  10

*****JD  This section will be split  between the new section 2 and  possibly sections 3 and 4.

   6.  IETF Network Slice Stakeholders . . . . . . . . . . . . . . .  11

*****JD  This section will be moved to section 4.

   7.  IETF Network Slice Controller Interfaces  . . . . . . . . . .  12

*****JD  This is covered in section 3.3.

   8.  Realizing IETF Network Slice  . . . . . . . . . . . . . . . .  12

*****JD  This is covered in section 3.5.

   9.  Isolation in IETF Network Slices  . . . . . . . . . . . . . .  13
     9.1.  Isolation as a Service Requirement  . . . . . . . . . . .  13
     9.2.  Isolation in IETF Network Slice Realization . . . . . . .  13

*****JD  These sections will be moved to the new section 2.  They assume a definition of the term 'isolation' which has never been explicitly rendered, so we will propose a definition to the mailing list.

   10. Security Considerations . . . . . . . . . . . . . . . . . . .  14

*****JD  Relevant material will be moved to section 5.2.  We will propose what we consider to be relevant and irrelevant material to the mailing list. 

   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14

*****JD  The Framework draft already has this section.

   12. Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . .  15

*****JD  This section will be moved to section 6.

   13. Informative References  . . . . . . . . . . . . . . . . . . .  15

*****JD  This section will be moved to section 7.

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

*****JD  This will need to be sorted out with the authors and contributors to the Framework draft.

*****JD  For reference, below is the current table of contents for the Framework draft:

Framework for IETF Network Slices
            draft-ietf-teas-ietf-network-slice-framework-00

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IETF Network Slice Objectives . . . . . . . . . . . . . . . .   4
   3.  Framework . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Management systems or other applications  . . . . . . . .   6
     3.2.  Expressing connectivity intents . . . . . . . . . . . . .   6
     3.3.  IETF Network Slice Controller (NSC) . . . . . . . . . . .   8
       3.3.1.  Northbound Interface (NBI)  . . . . . . . . . . . . .   9
     3.4.  Mapping . . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.5.  Underlying technology . . . . . . . . . . . . . . . . . .   9
   4.  Applicability of ACTN to IETF Network Slices  . . . . . . . .  10
   5.  Considerations  . . . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Monitoring  . . . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Security Considerations . . . . . . . . . . . . . . . . .  13
     5.3.  Privacy Considerations  . . . . . . . . . . . . . . . . .  13
     5.4.  IANA Considerations . . . . . . . . . . . . . . . . . . .  13
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

Yours Irrespectively,

John

Juniper Business Use Only

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 31 Mar 2021 19:03:00 +0000

Hi John, all,

Thanks for raising this.

I have however some concerns from technical and formal points of view.

Regarding the technical -- We (as a group) have been discussing extensively the definitions draft along one year or more, now reaching a stable document, yet with few points to solve. But we can consider it as mature. This is not the case for the framework draft, that has not received the attention that it deserves yet because the efforts were concentrated on the definitions one. Recently, during adoption, a number of comments were raised, and some other are expected to come once the group starts discussing it in deep. So, in summary, framework draft requires yet a number of iterations of work and discussion.
Thus combining definitions and framework at this stage seems not to be the best, since stable parts of the document (the ones from definitions) could become re-opened because of the overall discussion of the combined document. This is not desirable and can slow down the progress of the slicing topics. Then I think it is reasonable to not combine yet the documents, until a more profound pass is given to the framework document, including the resolution of the comments received during adoption. Once the framework document could be stable, then could be reasonable to consider combining both, in my view.
Also it could be necessary to identify the actual incremental/delta technical content of framework w.r.t. definitions to focus on that specific parts, which is an exercise not yet done (I wonder if it should be the definitions draft the one taken parts of current framework document and not the other way around).

Regarding the formal -- The way in which you propose the combination looks more like an "integration" of definitions in framework rather than a "merge". I would expect first a common joint work on approaching the best way of merging, not a unidirectional interaction. Also a balanced participation of the both editorial teams in the discussion/proposition to the group, especially because of the lot of work put in definitions until now and the amount of material found in definitions.

(Note aside - It was not clear to me if the design team was yet active, the charter was not completed I guess, but now I assume the DT will not be longer active, is this right?).

Best regards

Luis

-----Mensaje original-----
De: Teas <[email-masked]> En nombre de John E Drake
Enviado el: miércoles, 31 de marzo de 2021 17:44
Para: [email-masked]
Asunto: [Teas] Disposition of draft-ietf-teas-ietf-network-slice-definition-00

Hi,

Table of Contents

Table of Contents

Yours Irrespectively,

John

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

________________________________

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 privileged and confidential 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: Greg Mirsky <[email-masked]>
Date: Wed, 31 Mar 2021 12:53:20 -0700

Hi John, Eric, et al.,
I appreciate the proposal and believe that it correctly reflects the
discussion of the draft-ietf-teas-network-slice-definition we had within
the DT and as the WG. In fact, I support the proposed updates of the
content of the draft-ietf-teas-network-slice-definition while maintaining
it as a separate document. In my opinion, either way, works.

Regards,
Greg

On Wed, Mar 31, 2021 at 8:44 AM John E Drake <jdrake=
[email-masked]> wrote:

> draft:
> https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-framework-00.
> Our proposal is detailed below.
>
>
> *****JD  This section will be moved to the new section 2 and will be
> updated to use the terminology agreed upon on the mailing list.  A
> reference to RFC 4364's section 9 "Carriers' Carriers" (
> https://datatracker.ietf.org/doc/html/rfc4364#section-9)
> *****JD  This section will be moved to the new section 2.  Note that the
> non-definitional material in *all* of the preceding sections will be split
> between sections 3 and 4.  Section
> *****JD  These sections will be moved to the new section 2.  They assume a
> definition of the term 'isolation' which has never been explicitly
> rendered, so we will propose a definition to the mailing list.
>
> *****JD  Relevant material will be moved to section 5.2.  We will propose
> what we consider to be relevant and irrelevant material to the mailing
> list.
>