Subject: [Teas] I-D Action: draft-ietf-teas-ietf-network-slices-05.txt

From: [email-masked]
Date: Mon, 25 Oct 2021 15:13:08 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF.

        Title           : Framework for IETF Network Slices
        Authors         : Adrian Farrel
                          Eric Gray
                          John Drake
                          Reza Rokui
                          Shunsuke Homma
                          Kiran Makhijani
                          Luis M. Contreras
                          Jeff Tantsura
	Filename        : draft-ietf-teas-ietf-network-slices-05.txt
	Pages           : 40
	Date            : 2021-10-25

Abstract:
   This document describes network slicing in the context of networks
   built from IETF technologies.  It defines the term "IETF Network
   Slice" and establishes the general principles of network slicing in
   the IETF context.

   The document discusses the general framework for requesting and
   operating IETF Network Slices, the characteristics of an IETF Network
   Slice, the necessary system components and interfaces, and how
   abstract requests can be mapped to more specific technologies.  The
   document also discusses related considerations with monitoring and
   security.

   This document also provides definitions of related terms to enable
   consistent usage in other IETF documents that describe or use aspects
   of IETF Network Slices.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-ietf-network-slices-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Thu, 28 Oct 2021 15:09:46 +0000

Hi Adrian, all,

Many thanks for your effort. I really like this revision. I think that the document is almost stable. 

FWIW, here are few points for consideration in the next iteration:
* Relax the language about technology-agnostic and make it clear that this is for what happens between Pes. The AC part is likely to be technology-specific. A Network Slice Service may include technology-specific elements. 
* Align the terminology with RFC 8309.
* We don't need to be exhaustive in Section 6, but I wonder whether we can cite L3NM and L2NM in that section as well. A short sentence would suffice. This would just echo what we do have in the L3NM/L2NM:

==
   The customer may use a variety of means to request a service that may
   trigger the instantiation of an L3NM.  The customer may use the L3SM
   or more abstract models to request a service that relies upon an
   L3VPN service.  For example, ... or an IETF network slice service
   [I-D.ietf-teas-ietf-network-slices].

...

   'parent-service-id':  Refers to an identifier of the parent service
      (e.g, L3SM, IETF network slice, VPN+) that triggered the creation
      of the VPN service.  This identifier is used to easily correlate
      the (network) service as built in the network with a service
      order.  A controller can use that correlation to enrich or
      populate some fields (e.g., description fields) as a function of
      local deployments.
==

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : I-D-Announce <[email-masked]> De la part de internet-
> [email-masked]
> Envoyé : mardi 26 octobre 2021 00:13
> À : [email-masked]
> Cc : [email-masked]
> Objet : I-D Action: draft-ietf-teas-ietf-network-slices-05.txt
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

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: "Adrian Farrel" <[email-masked]>
Date: Fri, 29 Oct 2021 23:28:38 +0100

Thanks Med,

I really appreciate your opinion that this document is converging on
stability. Sometimes it doesn't feel like it from an editor's perspective!

The alignment with 8309, and citing L2/3NM seems a good idea to me.

I think we may need to discuss around the technology-agnostic/specific
question. I can see that if the service includes the AC, then there could be
some technology-specific elements. I should include this in the discussion
at IETF-112 (especially if I remember!)

Adrian 

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of [email-masked]
Sent: 28 October 2021 16:10
To: [email-masked]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-ietf-network-slices-05.txt

Hi Adrian, all,

Many thanks for your effort. I really like this revision. I think that the
document is almost stable. 

FWIW, here are few points for consideration in the next iteration:
* Relax the language about technology-agnostic and make it clear that this
is for what happens between Pes. The AC part is likely to be
technology-specific. A Network Slice Service may include technology-specific
elements. 
* Align the terminology with RFC 8309.
* We don't need to be exhaustive in Section 6, but I wonder whether we can
cite L3NM and L2NM in that section as well. A short sentence would suffice.
This would just echo what we do have in the L3NM/L2NM:

==

...

Thank you. 

Cheers,
Med

> ftp://ftp.ietf.org/internet-drafts/

____________________________________________________________________________
_____________________________________________

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
[email-masked]
https://www.ietf.org/mailman/listinfo/teas