Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Adrian Farrel <adrian@olddog.co.uk> Fri, 12 February 2021 16:41 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A951F3A179B for <teas@ietfa.amsl.com>; Fri, 12 Feb 2021 08:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.915
X-Spam-Level:
X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFse0Ae3AiyD for <teas@ietfa.amsl.com>; Fri, 12 Feb 2021 08:41:13 -0800 (PST)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40423A17C3 for <teas@ietf.org>; Fri, 12 Feb 2021 08:41:12 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11CGf97X017095; Fri, 12 Feb 2021 16:41:09 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1771E22044; Fri, 12 Feb 2021 16:41:09 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 09E472203D; Fri, 12 Feb 2021 16:41:09 +0000 (GMT)
Received: from LAPTOPK7AS653V (80.98.162.213.dyn.plus.net [213.162.98.80] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11CGf7UU030608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Feb 2021 16:41:07 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Rokui, Reza (Nokia - CA/Ottawa)'" <reza.rokui@nokia.com>, "'Joel M. Halpern'" <jmh@joelhalpern.com>, teas@ietf.org
References: <cc3949a4-1e60-7f77-45bd-2470be67d9d5@joelhalpern.com> <022001d6fc0e$4facba70$ef062f50$@olddog.co.uk> <86EF8667-4A3F-463A-BA3E-FE74F4875772@nokia.com> <MN2PR05MB6623EAA3DD2499C095311CDFC78D9@MN2PR05MB6623.namprd05.prod.outlook.com> <61180F49-A511-458A-B6AA-96E4C3BBA0A1@nokia.com> <56d8b5c3-5a94-ec85-2950-cadb18676ebd@joelhalpern.com> <83CF461D-A00B-45B0-BC90-6059ECDA9F95@nokia.com> <64a28682-022b-9ac1-2bfb-ebe2f1b26b5e@joelhalpern.com> <3F1804FC-E9EB-41AE-A0F6-EABA1010D7D6@nokia.com>
In-Reply-To: <3F1804FC-E9EB-41AE-A0F6-EABA1010D7D6@nokia.com>
Date: Fri, 12 Feb 2021 16:41:07 -0000
Organization: Old Dog Consulting
Message-ID: <01dc01d7015d$dd362b20$97a28160$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DD_01D7015D.DD3BF780"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKkHwJGzCaQ8Mp5a65/8LWCXraT6QLFWHyxAdK8muoBsrxyxQHoETF5AOTibnkBbYsG8AJOVWNSAnXmajKoQDC3IA==
Content-Language: en-gb
X-Originating-IP: 213.162.98.80
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25942.003
X-TM-AS-Result: No--16.456-10.0-31-10
X-imss-scan-details: No--16.456-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003
X-TMASE-Result: 10--16.456200-10.000000
X-TMASE-MatchedRID: jFqw+1pFnMyyoI+bK8UPQnFPUrVDm6jtGiE93W9CeWt8KRVo74NYIftN 2vjEPERNNaz/hY5bNelwSiDz1DbrnQ3jQA8ofx8MyZHnIMmQ+DgCn5QffvZFlTL/GHoao0dVirf anHZQTbRcRj8sdBngDhcm78cMK0l4wLWaq3OxDLa+DDmHh7vcV8wx7VbZgGmKmXw0RNbqkoIZUp FH6ZsWps49GLHhjMVECcIDBxehhYlDjiIoGQCCmCL/q8mnAJ3EZbvACQZDzTA/gf7afIrQU3N++ aG9CMzdnDKMeR5Nr5XfLyauAXNBAjzA9jekmUldvOAv94sAIMSsU/iX0A2wj6jnoSAHtf3ih8nP E4nVSc2T/piDceLhFvbVlMoE1BA7YwXAgt8PtiC8coKUcaOOvU8S+VNhFmpbX0sJLL5zrJo0MiC z9+S5yJBrt9IGzSxPHN5ba+wqtcmGgcmmxgQLUjXKFtsDtZ7Thomn0bwgVmnkMnUVL5d0E853E2 8akFGC/u1g+FwWSBzi2B7tf0tJEFyYk/c1MboP5v/KP8n9hBwOZNXmvnJaepb9wfEWdZoYCieTl R6U1poJB6JRmN1Hf4+nXBMEOCVgW/OF0jTZNZj6zT5BlgBw34eete0CDyUjJs1nmlVDLIgoIg+p 60zBNe8wp+H295OsfE/01lJTG7enFUuF0i5WJTXgRPG8ApuyKVrLOZD1BXTe6dEbvIyrxcflRu5 1nE3BRlTqvz28JtPMlqxNROWVU+Qu+8z9/q/l4M3l0EeXvQ15j2Sw+Nvsa3T8R5573v0zXa2+zE 1cP+Wbf1ZRqAuFVESSrCrFY/PoIPhlHYLxzHueAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLa2L4yU S6C5aHuc3xfo6LGrSFs54Y4wbX+efAnnZBiL6SszSEYZXnDIg2pniG1+uh5pH6AQqkq7RyR5PWv gSL5Q34MX2xTKdJ+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/C-6qyRUjrlEcldB1GTy8Ycn1DDk>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2021 16:41:18 -0000

Pardon the ASCII art, but I just wanted to quickly illustrate that this is not a new debate by a very long way. As Joel says, some technologies are simply not allowed to be injected into the provider network: MPLS is a good example. In this case either:

- the access connection uses a payload technology such as Ethernet so that the CE-CE connection is an emulated service

- the CE is a provider controlled node that is actually part of the provider network

 

Where the access network is a RAN, it seems unlikely that the PE will have radio capabilities. So the CE must convert to a signal type the provider network can process.

 

Now the (possibly) interesting case is where the provider network is IP. In this case the CE could send an IP packet to the PE (provided address spaces are resolved).

 

Now, when we look at the figures, the debate about where the edge of the slice is located should drop out relatively easily. Just ask: what network resources can be shared, are under provider control, and can be sliced?

 

I think that, further, if we consider a slice to be a network that looks and feels to the customer like it might be a provider network, then this also helps identify the edge.

 

However, *if* we consider the network slice to be a service (which I accept many don't want to do) the question about at what point the service is provided might be more entertaining. It was while considering this that I found Figure 2 of RFC 3985 useful.

 

_________________________     _____________________

(                         )   (                 

(           -----------   )   (   -----------   Provider

( Access   | Customer  |__)___(__| Provider  |  Network

( Network  | Edge Node |  )   (  | Edge Node |  Slice

(           -----------   )   (   -----------

(_________________________)   (______________________

 

 

 

________________   ________________________________

(                ) (                            

(           -----------           -----------   Provider

( Access   | Customer  |_________| Provider  |  Network

( Network  | Edge Node |         | Edge Node |  Slice

(           -----------           -----------

(________________) (_________________________________

 

 

Adrian

 

From: Teas <teas-bounces@ietf.org> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: 12 February 2021 14:52
To: Joel M. Halpern <jmh@joelhalpern.com>; teas@ietf.org
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

 

Joel,

 

Please see section 4.3.2.1. Layer 3 and Layer 2 Encapsulations where the sentence start with If the AN or CN could support MPLS,….

It shows that the traffic from AN or CN (i.e. RAN or Core Network) might be MPLS.

 

Reza

 

 

On 2021-02-12, 9:43 AM, "Joel M. Halpern" <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> > wrote:

 

    Reza, I looked at that paper.  I do not see anything in there that 

    addresses the inconsistency I am calling out below.

 

    Yours,

    Joel

 

    On 2/12/2021 9:09 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:

    > Joel,

    > 

    > There are some discussions on this topic for 5G for example. See the 

    > following draft:

    > 

    >   * draft-geng-teas-network-slice-mapping-02

    > 

    > Reza

    > 

    > On 2021-02-10, 12:41 PM, "Joel Halpern Direct" 

    > <jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern.com> > wrote:

    > 

    >      In every case I know of (which is I grant not every case) the non-IP

    > 

    >      packet is still a packet.  It is generally delivered to the service

    > 

    >      provider as an Ethernet packet (since that is the only other kind of

    > 

    >      packet we actually deal with.)

    > 

    >      I do not know of any operator who trusts his customer to put an MPLS

    > 

    >      label on a packet which the operator will use for switching.  (The

    > 

    >      closest I know of is when the operator actually controls the CPE.  

    > Which

    > 

    >      is clearly not what you are describing.)

    > 

    >      If you have another use case in mind, it would be very helpful if you

    > 

    >      would explain it in more detail.

    > 

    >      Yours,

    > 

    >      Joel

    > 

    >      On 2/10/2021 11:42 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:

    > 

    >      > See inline please.

    > 

    >      >

    > 

    >      > Cheers,

    > 

    >      >

    > 

    >      > Reza

    > 

    >      >

    > 

    >      > *From: *John E Drake <jdrake@juniper.net <mailto:jdrake@juniper.net> >

    > 

    >      > *Date: *Wednesday, February 10, 2021 at 11:21 AM

    > 

    >      > *To: *Reza Rokui <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >, "adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> "

    > 

    >      > <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> >, "'Joel M. Halpern'" <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> >,

    > 

    >      > "teas@ietf.org <mailto:teas@ietf.org> " <teas@ietf.org <mailto:teas@ietf.org> >

    > 

    >      > *Subject: *RE: [Teas] network Slice Endpoint in

    > 

    >      > draft-ietf-teas-ietf-network-slice-definition-00

    > 

    >      >

    > 

    >      > Hi,

    > 

    >      >

    > 

    >      > Comment inline

    > 

    >      >

    > 

    >      > Yours Irrespectively,

    > 

    >      >

    > 

    >      > John

    > 

    >      >

    > 

    >      > Juniper Business Use Only

    > 

    >      >

    > 

    >      > *From:* Teas <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org> > *On Behalf Of * Rokui, Reza 

    > (Nokia

    > 

    >      > - CA/Ottawa)

    > 

    >      > *Sent:* Wednesday, February 10, 2021 7:39 AM

    > 

    >      > *To:* adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; 'Joel M. Halpern' <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> >;

    > 

    >      > teas@ietf.org <mailto:teas@ietf.org> 

    > 

    >      > *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com <mailto:reza.rokui@nokia.com> >

    > 

    >      > *Subject:* Re: [Teas] network Slice Endpoint in

    > 

    >      > draft-ietf-teas-ietf-network-slice-definition-00

    > 

    >      >

    > 

    >      > *[External Email. Be cautious of content]*

    > 

    >      >

    > 

    >      > Joel and Adrian,

    > 

    >      >

    > 

    >      > Agreed that there shall be clarity about the endpoints.

    > 

    >      >

    > 

    >      >                  >>>>>> There are traffic endpoints (the sender and

    > 

    >      > receiver of packets), and there are endpoints of the service (the

    > 

    >      > ingress and egress to the slice).

    > 

    >      >

    > 

    >      > This is correct Adrian.

    > 

    >      >

    > 

    >      > An “IETF network slice” is between two or more endpoints as 

    > outlined in

    > 

    >      > the draft.

    > 

    >      >

    > 

    >      > In summary, the  IETF network slice is defined  between various

    > 

    >      > device/applications/network functions on multiple “IETF network 

    > slice

    > 

    >      > endpoints”.  These are traffic endpoints of the IETF network 

    > slice. We

    > 

    >      > refer to them in the draft as “NSE” (IETF Network Slice Endpoints).

    > 

    >      >

    > 

    >      > In addition , as Adrian mentioned there are endpoints to the 

    > realization

    > 

    >      > of the transport slice (i.e. various services/tunnels/paths). I am

    > 

    >      > suggesting to use term “NSI” (IETF Network Slice Ingress).  Please

    > 

    >      > provide your suggestions for NSI if you have any other suggestions.

    > 

    >      >

    > 

    >      >                  >>>> For example, if the service is being

    > 

    >      >

    > 

    >      >      delivered with MPLS, the Network Slice Endpoint likely 

    > cannot put the

    > 

    >      >

    > 

    >      >      labels on the packet for the MPLS, as it is outside of the IETF

    > 

    >      > network

    > 

    >      >

    > 

    >      >      Slice.  So we will need yet another layer of classification, 

    > and yet

    > 

    >      >

    > 

    >      >      more interworking.

    > 

    >      >

    > 

    >      > This is not correct.  Whatever technology is used to realize the 

    > IETF

    > 

    >      > network slice must be supported by endpoints. If MPLS is 

    > technology of

    > 

    >      > choice, the endpoint must support it in its data-path (and might 

    > also

    > 

    >      > support it in its control-plane).

    > 

    >      >

    > 

    >      > *//*

    > 

    >      >

    > 

    >      > */[JD]  This is incorrect.   E.g., in IETF VPNs, the traffic from 

    > the CE

    > 

    >      > to the PE is *not* MPLS encapsulated.  It is the PE that does the

    > 

    >      > encapsulation./*

    > 

    >      >

    > 

    >      > [Reza] Disagree. There are use-cases where the traffic to transport

    > 

    >      > network is not IP and is Labeled-packets.

    > 

    >      >

    > 

    >      > Cheers,

    > 

    >      >

    > 

    >      > Reza

    > 

    >      >

    > 

    >      >      ------------------Original Message-----------------------

    > 

    >      >

    > 

    >      > On 2021-02-05, 5:29 PM, "Teas on behalf of Adrian Farrel"

    > 

    >      > <teas-bounces@ietf.org on behalf of adrian@olddog.co.uk

    > 

    >      > 

    > <mailto:teas-bounces@ietf.org%20on%20behalf%20of%20adrian@olddog.co.uk>>

    > 

    >      > wrote:

    > 

    >      >

    > 

    >      >      Ah, the old "endpoint" discussion.

    > 

    >      >

    > 

    >      >      Yes, Joel is right, we need to disambiguate endpoints from 

    > endpoints.

    > 

    >      >

    > 

    >      >      There are traffic endpoints (the sender and receiver of 

    > packets),

    > 

    >      > and there

    > 

    >      >

    > 

    >      >      are endpoints of the service (the ingress and egress to the 

    > slice).

    > 

    >      >

    > 

    >      >      There is probably a risk that we get sucked in to the wider 5G

    > 

    >      > picture, but

    > 

    >      >

    > 

    >      >      we need to focus (as Joel says) on the IETF network slice.

    > 

    >      >

    > 

    >      >      I suggest "source/destination" and "IETF network slice 

    > ingress/egress".

    > 

    >      >

    > 

    >      >      And we can avoid discussion of the wider 5G context, as noted

    > 

    >      > elsewhere in

    > 

    >      >

    > 

    >      >      the draft, by diverting that material into a dedicated document.

    > 

    >      >

    > 

    >      >      Cheers,

    > 

    >      >

    > 

    >      >      Adrian

    > 

    >      >

    > 

    >      >      -----Original Message-----

    > 

    >      >

    > 

    >      >      From: Teas <teas-bounces@ietf.org 

    > <mailto:teas-bounces@ietf.org>>

    > 

    >      > On Behalf Of Joel M. Halpern

    > 

    >      >

    > 

    >      >      Sent: 05 February 2021 17:04

    > 

    >      >

    > 

    >      >      To: teas@ietf.org <mailto:teas@ietf.org>  <mailto:teas@ietf.org>

    > 

    >      >

    > 

    >      >      Subject: [Teas] network Slice Endpoint in

    > 

    >      >

    > 

    >      >      draft-ietf-teas-ietf-network-slice-definition-00

    > 

    >      >

    > 

    >      >      Rereading this draft, I realized that I am either confused by or

    > 

    >      >

    > 

    >      >      disagree with the description of the "Network Slice Endpoint"

    > 

    >      > contianed

    > 

    >      >

    > 

    >      >      there.

    > 

    >      >

    > 

    >      >      The endpoint that I think matters is the place where the 

    > IETF Network

    > 

    >      >

    > 

    >      >      Slice Controller starts controlling the QoS and traffic 

    > delivery.  The

    > 

    >      >

    > 

    >      >      Controller doesn't care about the identity of the device 

    > outside of

    > 

    >      > that.

    > 

    >      >

    > 

    >      >      Figure 1 in section 4.2 seems to define that endpoint as the 

    > network

    > 

    >      >

    > 

    >      >      slice realiation endpoint, and describes the network slice 

    > endpoint as

    > 

    >      >

    > 

    >      >      the thing outside the IetF network slice.  This seems

    > 

    >      > counter-productive

    > 

    >      >

    > 

    >      >      to me.  It complicates teh relationship between the endpoitn 

    > and the

    > 

    >      >

    > 

    >      >      service being abstracted.  For example, if the service is beign

    > 

    >      >

    > 

    >      >      delivered with MPLS, the Network Slice Endpoint likely can 

    > not put the

    > 

    >      >

    > 

    >      >      labels on the packet for the MPLS, as it is outside of the IETF

    > 

    >      > network

    > 

    >      >

    > 

    >      >      Slice.  So we will need yet another layer of classification, 

    > and yet

    > 

    >      >

    > 

    >      >      more interworking.

    > 

    >      >

    > 

    >      >      Further, someone has to get the queueing right for traffic 

    > coming

    > 

    >      > out of

    > 

    >      >

    > 

    >      >      the Network Slice Endpoint.  But it is not part of the IETF 

    > Network

    > 

    >      >

    > 

    >      >      Slice, so we don't have any way to get it right.

    > 

    >      >

    > 

    >      >      If we define the edge of the space we care about co-incident 

    > with the

    > 

    >      >

    > 

    >      >      edge of the space we influence, things get a lot cleaner.

    > 

    >      >

    > 

    >      >      Yours,

    > 

    >      >

    > 

    >      >      Joel

    > 

    >      >

    > 

    >      >      _______________________________________________

    > 

    >      >

    > 

    >      >      Teas mailing list

    > 

    >      >

    > 

    >      > Teas@ietf.org <mailto:Teas@ietf.org>  <mailto:Teas@ietf.org>

    > 

    >      >

    > 

    >      > https://www.ietf.org/mailman/listinfo/teas

    > 

    >      > <https://www.ietf.org/mailman/listinfo/teas>

    > 

    >      >

    > 

    >      >      _______________________________________________

    > 

    >      >

    > 

    >      >      Teas mailing list

    > 

    >      >

    > 

    >      > Teas@ietf.org <mailto:Teas@ietf.org>  <mailto:Teas@ietf.org>

    > 

    >      >

    > 

    >      > https://www.ietf.org/mailman/listinfo/teas

    > 

    >      > <https://www.ietf.org/mailman/listinfo/teas>

    > 

    >      >

    > 

    >      >

    > 

    >      > _______________________________________________

    > 

    >      > Teas mailing list

    > 

    >      > Teas@ietf.org <mailto:Teas@ietf.org> 

    > 

    >      > https://www.ietf.org/mailman/listinfo/teas

    > 

    >      >

    > 

    > 

    > _______________________________________________

    > Teas mailing list

    > Teas@ietf.org <mailto:Teas@ietf.org> 

    > https://www.ietf.org/mailman/listinfo/teas

    >