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

Adrian Farrel <adrian@olddog.co.uk> Wed, 10 February 2021 17:29 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 D3BF63A106D; Wed, 10 Feb 2021 09:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 2PPpUfHIF9su; Wed, 10 Feb 2021 09:29:27 -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 92C883A1066; Wed, 10 Feb 2021 09:29:25 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11AHTNcC005061; Wed, 10 Feb 2021 17:29:23 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6E1BF2204A; Wed, 10 Feb 2021 17:29:23 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 5859C2204E; Wed, 10 Feb 2021 17:29:23 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.112.213.140]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 11AHTMg0028880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Feb 2021 17:29:22 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'John E Drake'" <jdrake=40juniper.net@dmarc.ietf.org>, "'Rokui, Reza \(Nokia - CA/Ottawa\)'" <reza.rokui@nokia.com>, "'Joel M. Halpern'" <jmh@joelhalpern.com>
Cc: <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>
In-Reply-To: <MN2PR05MB6623EAA3DD2499C095311CDFC78D9@MN2PR05MB6623.namprd05.prod.outlook.com>
Date: Wed, 10 Feb 2021 17:29:21 -0000
Organization: Old Dog Consulting
Message-ID: <048e01d6ffd2$450970f0$cf1c52d0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_048F_01D6FFD2.450BBAE0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKkHwJGzCaQ8Mp5a65/8LWCXraT6QLFWHyxAdK8muoBsrxyxaiFDZDQ
Content-Language: en-gb
X-Originating-IP: 87.112.213.140
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--19.386-10.0-31-10
X-imss-scan-details: No--19.386-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003
X-TMASE-Result: 10--19.385900-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFqyoI+bK8UPQnFPUrVDm6jtYM9s6twyNwk7sEw6V/IotGcf sFD2kA8IvK4UqXG+u6TneA4MikqUyak6nmK7TvDCEclbAMYYY6xa9oWcYwi86iuGKh4AkqKVyKM XhR45RlOtfxiXzL+HkZ+Jh3xpp8Vmv4K1ropPyL3JkecgyZD4OLgZIOJjEsJdD+XGOhgZ/4cqhf HQ+5BrT3P+9mhbDjvtgSrseSRoVo96jB+z5vh/7dMrcx6d6fiW9dvYnOTLyCKZvRtF5rjVr1zqJ KZva025JjHPzO9FVvLiSteJN66HrVvzhdI02TWY/NOUkr6ADzf4uJ1REX4MHbYekL3kH7KjveYm FYIsxlcDz7w2/Q/VreWhxKYPrS+4dm10NLkSjkGKYdYQLbymTfsJB65N+sbMr3DiW2de5g9OSQV LhkECnDYKx5SxZ3YGvbpXoI5m83heUmqJNf32QqNT4eJsLoMr3vjS0O+N37X8kFwgcyoo4fdj6o /+Xn0ToNj8W+M7L55wsNvdLvOhPfJpYN2UUHMHWTGejGdB9VLHfH5echwIxH6hVrHbLLE3WyRxg P0YDauaaBYwlL5lPidYqQJcNp3goRhq4uL6L1iRS9zmYCUyQaVOmPK+OiPn9eHbbeDQLPa4k1qR tytLgRRp6WYTXdz5XSj4oZ3/fRU9AOF20d7i32wwF0xqB3EIlsVu5QodRJhYbPLopoBzQhCnYZE mcg0NnDKMeR5Nr5VaNLZwpkKt4qDnkXE/iJaxtKV49RpAH3tlnkeRE0Y2A9fVxEPp7g/kWaKHLy GMBsIg+k3nPoRSHrMxMjgM+PsneODBMji6el+eAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyKvd+Ts+ zmxbFKMqIeOstiflxhPCV6M7c1n7i+l0hm3N5ddD4UFJmHph1OU51jo9NWz4wJFa+R+5nu5DA1C ZQYA7tVjJgibnMrsaSaM59QyOdIuFxqO/nqCPZXMTWXMzEt+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/TZDKLptFTkc6ZBH4x0ZhOrWhfEE>
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: Wed, 10 Feb 2021 17:29:30 -0000

Hi all, 

 

In case this discussion is getting heated, can I observe that I find Figure 2 of RFC 3985 hugely useful in this context. Yes, it is only referring to a P2P service and not an MP2MP service, but the same concepts apply and it is likely that all our figures will only show P2P anyway.

 

You might note that that figure does not use the term “end point” and does this without any loss of meaning. However, whether the terms CE and PE will be applicable for us (probably they are) is up for debate.

 

You might also note that the rest of 3985 *does* use the term “endpoint” but it does so only to refer to “tunnel endpoints”.

 

Let’s step even further back from this.

Is a network slice “connectivity” or does is it a network service?

Connections, tunnels, links all have end points.

Services have “service delivery points” and “access points”.

Or is a slice a type of network (virtual or logical or sliced)?

Networks have “edges” and “access points”.

 

Adrian

 

From: Teas <teas-bounces@ietf.org> On Behalf Of John E Drake
Sent: 10 February 2021 16:21
To: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>om>; adrian@olddog.co.uk; 'Joel M. Halpern' <jmh@joelhalpern.com>om>; 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.

 

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> 

    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> 

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

 

    _______________________________________________

    Teas mailing list

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

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