Re: [Teas] New Slicing revision: I-D Action: draft-ietf-teas-ietf-network-slices-01.txt

[Uma Chunduri <[e-mail]>]

Hi Adrian,

First, many thx for your thoughtful and detailed response. See my quick
comments below ..

Cheers!
--
Uma C.

On Wed, Apr 21, 2021 at 10:09 AM Adrian Farrel <[e-mail]> wrote:

> Hi Uma,
>
>
>
> Thanks for looking at the text.
>
>
>
> > 1. Section 1
> >
> > "This document also provides a framework for discussing IETF Network
> >   Slices.  This framework is intended as a structure for discussing
> >   interfaces and technologies.  It is not intended to specify a new set
> >   of concrete interfaces or technologies. "
>
> >
>
> >   Thanks for defining the scope of the framework document.
>
>
>
> First, this is not my text. This is text taken form one of the
> contributing documents.
>

[Uma]: Ack and appreciate your time, and efforts for making this better.

>
>
> > But there is a lot of  work to be done (IMO)  to realize what's been put
>
> > in this document and it's good to call out that aspect too.
> >   For example as specified in Sec 4.1.1.1 "such as guaranteed
> >   minimum bandwidth, guaranteed maximum latency, maximum permissible
> >   delay variation, maximum permissible packet loss rate" -
> >   we simply can't do these in the shared underlays today or can we?
>
> The question of how to realise network slices, in particular how to use
> existing IETF technologies to meet the SLOs described in this document, is
> important. But it is a big topic with many possible technical answers. In
> my opinion, that issue should be addressed in (probably several) other
> documents depending on the underlying technology, it’s inherent
> capabilities, and the extensions that need to be developed. For some
> underlying technologies this may be handled by an “applicability statement”
> (for example, in the case of the applicability of ACTN when the underlay
> network is TE-capable) or
>

[Uma]: Agree and the 'or' above should have been 'and'

> by protocol extension documents (as suggested by a number drafts – VPN+
> and bestbar).
>

[Uma]: Agree. While this is not the thread to comment technically on VPN+
or bestbar, I am afraid these two may not be encompassing solutions (these
two *may be* necessary or *may be* important protocol extensions) to
address everything laid out in this doc. If that spirit is reflected that
would be great.

>
>
> But this is just my opinion. If there is consensus that this document
> should contain a detailed explanation of how to match the objectives of
> network slicing with the underlay technologies, then we should address that.
>
>
> > 2. Section 1
> >
> >   The above is reinforced with the last paragraph. How do we define the
> "beginning" ?
> >   Slices topic has been discussed in the design team for almost 1.5
> years and in the IETF for 3+ years.
> >   So I am not sure, this can be defined and it is helpful.
>
> I agree that that paragraph is not terribly helpful. That said, this is
> text that the design team produced!
>
>
>
> I would propose
>
> OLD
>
>    Note that it is conceivable that extensions to these IETF
>
>    technologies are needed in order to fully support all the ideas that
>
>    can be implemented with slices, but at least in the beginning there
>
>    is no plan for the creation of new protocols or interfaces.
>
> NEW
>
>    Note that it is conceivable that extensions to these IETF
>
>    technologies are needed in order to fully support all the ideas that
>
>    can be implemented with slices.  Evaluation of existing technologies,
>
>    proposed extensions to existing protocols and interfaces, or the
>
>    creation of new protocols or interfaces is outside the scope of this
>
>    document.
>
> END
>
>
>
[Uma]: Thx


> >   Section 1.1:
> > "This document specifies a framework for the use of existing
> >   technologies as components to provide an IETF Network Slice service,
> >   and might also discuss (or reference) modified and potential new
> >   technologies, as they develop (such as candidate technologies
> >   described in section 5 of [I-D.ietf-teas-enhanced-vpn])."
> >
> >   Can we reconcile the above with Section 1 statements?
>
> Yes, we should. Probably…
>
>
>
> NEW
>
>    This document specifies definitions and a framework for the
>   provision of an IETF Network Slice service.  Section 5.5 briefly
>
>    indicates some candidate technologies for realizing IETF
>
>    Network Slices.
>
> END
>
>
>
> Note: My proposal for merging section 5.5 and section 6 (per the thread
> with Daniele) will follow shortly.
>
>
>
[Uma]: Ack.

> > 3.  Section 1
>
> >
> >  [I-D.ietf-teas-enhanced-vpn] has been referred throughout the document
>  (in sec 1, 3, 5, 5.5, 5.5.1), maybe
> >  this is because of yet to be streamlined text from both documents. It
> appears this is a mandatory for IETF network slicing
>
> That is exactly the reason. The text is simply merged with some basic
> edits.
>
> I believe that (per the note above, and the thread with Daniele) this can
> be streamlined to show that VPN+ is one way to deliver IETF Network Slices
> in a specific environment.
>
[Uma]: Sure.

> >   But can this document discuss what ought to be done if there is no
> VPN/enhanced VPN?
> >
> > *I would note - there are early slicing deployments (in LTE networks)
> either with existing VPN
> >   technologies or *no* VPN technology to realize the slicing (I was
> involved in such deployments).
> >   Please don't misunderstand statement as against
> >   to enhancedVPN (which nicely documents how better underlay
> technologies can be effectively used with VPNs).
>
> I believe you might find it valuable to write up a draft describing your
> deployments.
>
[Uma]: I made this comment after a long discussion privately with one of
the folks who is deploying the solutions. If he is willing, I shall put
together a document. Again, this would be one scenario for IETF network
slicing in the 5G deployments (in some segments of the network). Some
aspects are covered in
https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility

>
> It may be, however, that you misunderstand the VPN+ work.
>
[Uma]: No question about that but I assure there are more folks and I am
really thankful for your response below.


> We saw a similar mismatch of language while doing the L3SM work. A “VPN”
> is often considered in terms of the protocols and tools necessary to
> operate a network in order to achieve a particular type of service. For
> example, we talk about BGP/MPLS VPNs. This is natural as we are engineers
> many of whom spend a lot of time working with protocols or deploying
> devices. But there is also a meaning of “VPN” which may be paraphrased as a
> “VPN service.” That is the consumer’s view of the VPN. When looked at in
> this way, the enhanced VPN of draft-ietf-teas-enhanced-vpn is not
> dissimilar to an IETF Network Slice.
>
[Uma]: Excellent summary. But, it's important to separate underlay
capabilities and how those can be used with all sorts of VPNs.

> > 4. Section 1
> >   "The common or base network that
> >   is used to provide the VPNs is often referred to as an underlay
> >   network,.."
> >
> >   Common network doesn't provide VPNs but rather allows multiple VPNs to
> share the network.
> >   s/provide/serve
>
> I don’t understand the distinction you are trying to make.
> I suppose that other available words are “enable,” “support,” “build,” and
> “deliver”.
> Does any of these work for you?
>
[Uma]: Maybe I will pick "support" (other terms you listed are fine too).
See below.

>
>
> "a VPN may in turn serve as an underlay network
> >   for IETF Network Slices"
> >
> >   I am missing something here on how? Also this contradicts the earlier
> statement.
> >  Can you elaborate more here?
>
> Networks can be stacked, right? An overlay network may be treated as a
> fully-fledged network (such is virtualization) and so be an underlay for
> the provision of another service.
> Maybe this should say…
>
> OLD
>    As an example technology, a VPN may in turn serve as an underlay
>    network for IETF Network Slices.
> NEW
>   An overlay network may, in turn, serve as an underlay network to
>    support another overlay network.
> END
>
[Uma]: Much better. I guess, there is this notion of IETF slicing from the
consumer point of view represented in this document (aka consumer gets a
VPN with a logical part of the underlay) and hence it seems this document
is centered around (on this aspect) providing "that" VPN service with
underlay. Now, I seem to realize why it was heavily focused on VPN+. Some
of my comments are mostly from technology agnostic underlay perspective to
build the core slicing requirements.

> > 4. Section 4.2
> >
> >    It's good to cover the link between the NSE and the IETF network
> node, which is part of the network topology.
> >    This is generally needed in E2E scenarios and there is a lot of work
> done here in different WGs for many years.
>
> Good comment, but are you proposing anything in particular?
>
[Uma]: No, not really. This link is not part of the topology (PE-PE) is a
general case.  I am just saying this is an important piece for E2E slicing
solution else this would be the bottleneck for SLO fulfillment.

>
> Thanks,
> Adrian
>
>
>
> On Fri, Apr 16, 2021 at 3:39 AM Adrian Farrel <[e-mail]> wrote:
>
> Hi,
>
> In this revision, I have tidied the text. That involved:
> - Fixing inconsistent editorial standards between the source documents
> - Some more minor editorials
> - Moving a couple of sections around
> - Collapsing a little duplication arising from pulling text from two places
> - Removing cross-references between the source documents
> - Removing the tagging of the source material
>
> In doing so, there were two small paragraphs that didn't seem to belong.
> These can be seen in the Appendix.
>
> ACTION: All: Please shout if you believe this text should not be deleted.
>
> While this document is now in a condition that can be reviewed and
> commented
> on, I propose to make some suggestions to reduce and consolidate the text.
> I
> will bring these to the list as separate threads (some have already been
> seen on the list, but we should make the proposed changes clear). They will
> cover:
>
> - Discussion of realisation.
>   This should be a discussion of architectural realisation, not of
> underlying technologies.
>   Currently we have:
>    - a large section on ACTN
>    - a couple of references to VPN+
>    - no mention of the architecture underlying
> draft-bestbar-teas-yang-slice-policy
>   I already suggested (on list) a way to reduce the ACTN text, but it has
> since been
>   proposed to me that all discussion of realisation of the architecture can
> be best
>   achieved with brief paragraphs and references. I will propose text.
>
> - Isolation and "unmeasurable SLOs"
>   This has long been a contentious topic. I think we had reached a bit of a
> compromise
>   in the definitions draft, but doing the merge has caused me to re-read it
> and I am
>   uneasy. I will be making a text suggestion to clarify the purpose and
> meaning of the
>   section on isolation, and that will depend on us also clarifying the
> description of
>   "directly measurable SLOs" and "indirectly measurable SLOs.
>
> - Revisiting the definition of a network slice
>   This is obviously pretty core to our work! John Drake previously sent a
> suggestion to
>   the list (2021-04-03). This caused a bit of discussion and raises a
> number
> of points.
>   I plan to try to tease out the various points to see whether we can agree
> them
>   Separately and then come up with new definitions text. This may be a good
> topic
>   For our first telechat on the document.
>
> ACTION: Chairs: Decide what the rules are for having telechat meetings for
> this document.
>
> Thanks,
> Adrian
>
> -----Original Message-----
> From: I-D-Announce <[e-mail]> On Behalf Of
> [e-mail]
> Sent: 16 April 2021 11:19
> To: [e-mail]
> Cc: [e-mail]
> Subject: I-D Action: draft-ietf-teas-ietf-network-slices-01.txt
>
>
> 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-01.txt
>         Pages           : 33
>         Date            : 2021-04-16
>
> 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 are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-teas-ietf-network-slices-01
>
> https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-ietf-network-slices-01
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> 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
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
>