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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 12 February 2021 14:43 UTC

Return-Path: <jmh@joelhalpern.com>
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 5C4083A16FB for <teas@ietfa.amsl.com>; Fri, 12 Feb 2021 06:43:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 ZjHL8tbVPogo for <teas@ietfa.amsl.com>; Fri, 12 Feb 2021 06:43:51 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 E99973A16FA for <teas@ietf.org>; Fri, 12 Feb 2021 06:43:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Dcbpv62Syz1pH4Q; Fri, 12 Feb 2021 06:43:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1613141031; bh=shACCcYL2ilB7gKu2yFf8lw4aQJeO1YD3/ymTUOj2WI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=WyH2NZmv8s+HtGCY2/S65LGp848y15zyU6pYYt0Alsc7NEJKCnnRgd7cvdNjpkYlR l1lEh3ynvBKCOwicxXfcOsy5OKrcl5K8Fa0ASW49Tse4dYFFVdaio9B1R9mo4HsrcH +EvVFg8xsAFA6jKhSZKr4aaxrxziGD0DQOMWMNyM=
X-Quarantine-ID: <tAfOoRaHnipI>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4Dcbpv1XRGz1nsT9; Fri, 12 Feb 2021 06:43:51 -0800 (PST)
To: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, "teas@ietf.org" <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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <64a28682-022b-9ac1-2bfb-ebe2f1b26b5e@joelhalpern.com>
Date: Fri, 12 Feb 2021 09:43:50 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <83CF461D-A00B-45B0-BC90-6059ECDA9F95@nokia.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/UB5f-I-ddMauoIePtqNg8RomMO4>
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 14:43:56 -0000

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> 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>
> 
>      > *Date: *Wednesday, February 10, 2021 at 11:21 AM
> 
>      > *To: *Reza Rokui <reza.rokui@nokia.com>om>, "adrian@olddog.co.uk"
> 
>      > <adrian@olddog.co.uk>uk>, "'Joel M. Halpern'" <jmh@joelhalpern.com>om>,
> 
>      > "teas@ietf.org" <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> *On Behalf Of * Rokui, Reza 
> (Nokia
> 
>      > - CA/Ottawa)
> 
>      > *Sent:* Wednesday, February 10, 2021 7:39 AM
> 
>      > *To:* adrian@olddog.co.uk; 'Joel M. Halpern' <jmh@joelhalpern.com>om>;
> 
>      > teas@ietf.org
> 
>      > *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <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>
> 
>      >
> 
>      >      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
> 
>      > <https://www.ietf.org/mailman/listinfo/teas>
> 
>      >
> 
>      >      _______________________________________________
> 
>      >
> 
>      >      Teas mailing list
> 
>      >
> 
>      > 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
> 
>      > https://www.ietf.org/mailman/listinfo/teas
> 
>      >
> 
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>