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

"Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com> Fri, 12 February 2021 16:26 UTC

Return-Path: <reza.rokui@nokia.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 C49BB3A1787 for <teas@ietfa.amsl.com>; Fri, 12 Feb 2021 08:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.151
X-Spam-Level:
X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=nokia.onmicrosoft.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 SUoCCtSJsZuI for <teas@ietfa.amsl.com>; Fri, 12 Feb 2021 08:26:25 -0800 (PST)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2102.outbound.protection.outlook.com [40.107.237.102]) (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 88F363A1784 for <teas@ietf.org>; Fri, 12 Feb 2021 08:26:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jGULo+vbPDVS9YoUoGM859Pw8Xryx/xn3Ys4K0QsdwKNRRPOv9YaPiMHoETGTZnNCjWRRl+8KxfxTldWrXonw5JSyYqPRzYT13F3OQ3O/8Dkgi/I8dx9ypYRhmY2WlzWts/csFhTtZl8aa3C2ocRXDD51mke3sl+eODoqh+0kcLhQaLXvkCeGESak9fXVgsrGeEbSXvz9kSHpzCiqCGgocnGrwbkj6NJX+T5Smw6tXF99EGF93vg4wOKaEx+wiNPkMyB1AfdRPUxIQP5ZFWSnJBnrmd5XAzC9pZF7JjoHI4bcwyEZEf9X2YDO7rnjOeWoZU8bPy3GMRBKOP658NoWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y6+thhQvVeidjMIl5oKfj9ur3borjCjQDqzM1I2+ZaA=; b=VpSgosEQ/gsrK6z3TLwNn6AYSlx4pKE8kjiolY3N7Hyh+pava+c+SMpJtqTAEGg/Hn/VtShaUfPjikXF9LQOAhj5xTW1ksip6gsAF2Hr8Vny6clokoMKG5MgcJiSmqTWq0ft1RY0fNA59zjTsK8T4vJKGfBELPFIH0Gf2j3PVScucvg/4DMO/XBTRE/ZraWpPma8MJhdKOwKraU30BFZ0HsSfg3lStBL1b3Vky2oAo8FhqH31tGfubg9xNFPuONwUgVbpqUkKpFDdUUPZ2BRTcBbF6Ey3QWWcnaCqLuK+3AnKTEPA4/+V64BFGuGgesryJMoKu8VnAgoKFLGMh7i1w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y6+thhQvVeidjMIl5oKfj9ur3borjCjQDqzM1I2+ZaA=; b=O+udt8VAuhWsWh46EN8dJwJjQGh4/C47aTUIgunmRRE8xLOJuPfIc09gOY/uMZvICHZyTEir4z7g3F3X2wTXmK9jEO/lWjE5iVuV+tGvUg2V4M+g74fZSCzO4a2hMdLJTDaknSP84xScXA4Hf/msINXmAPtxxHGZh1cEzQJ8w/c=
Received: from BN6PR08MB2707.namprd08.prod.outlook.com (2603:10b6:404:c0::10) by BN7PR08MB3985.namprd08.prod.outlook.com (2603:10b6:406:8b::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.29; Fri, 12 Feb 2021 16:26:18 +0000
Received: from BN6PR08MB2707.namprd08.prod.outlook.com ([fe80::bcda:a2e1:1f5d:b93f]) by BN6PR08MB2707.namprd08.prod.outlook.com ([fe80::bcda:a2e1:1f5d:b93f%3]) with mapi id 15.20.3846.034; Fri, 12 Feb 2021 16:26:18 +0000
From: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
Thread-Index: AQHXAVvKshwTBfHFM0iRh1odiRKjNg==
Date: Fri, 12 Feb 2021 16:26:17 +0000
Message-ID: <9D5BF106-2D0F-48CF-B9CA-6686CD3686D3@nokia.com>
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> <98d704ba-916e-3d42-5795-30b22d3e3bb5@joelhalpern.com>
In-Reply-To: <98d704ba-916e-3d42-5795-30b22d3e3bb5@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.45.21011103
authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [24.246.4.36]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 5b1a00b8-b9d5-455d-5115-08d8cf72ed06
x-ms-traffictypediagnostic: BN7PR08MB3985:
x-microsoft-antispam-prvs: <BN7PR08MB39850F913A11D3C78AF04F789F8B9@BN7PR08MB3985.namprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0G5lUJWoaMskEXhzrazx2IjfqcJeUNsa60ybjulaqBShtu2W6XoG6vP++Qfc7Km1N957e15zOpUCZFutIYBAmGH0FqEmCyjcErWRsWm2FcqAQA+lKmW1FuKlvZn4KXOy6n/PL4nNLb3zWnTagCNh2LK0UpWrJ2Geplu/a4EHBq5qMA5pUlI/mnAzzjnuZvXAmxsvB/MIp3waWS9I1hjwhjP8C3UVQsEpaditxodrmQ4kSOSuXKCARr6bcrsFQHCjhdRDhWeaiRIawdSuJsHMnnES6Vit4hO2CdpCQJCq968MaMGaiKsOHCA12T+6x5HEyEHgbMI4sREJOR/PoXYjCK3cq2SHNPWmweAYjBrvVddKN9BoK2uW6wF1UO5MM4reOXS34hAZNdSlR57dd30TCVMMWvblciGizi0pZgMuWlB571X6qtokRXTKzGcwJlOzKj8jiHE6tS9YMhC0kD4WjN4rQ2IDkc2eSo0g2xO3W4tw9t8QDsf0e8Ry0VPDrPrWl8Ocr9j67IJs44NYTajyRhdn4X2q/ToHSUVg5P7cDXyRVGt7bIUg411YnTSCYCwI+wA/KDWR2E0r/kPSd0BuhkmWN8nP02Ha7NEc52nbgqDkhztQrOVPfyveQU/OXUJOv/sREXsvqSLc3x0cb5DcRw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR08MB2707.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(39860400002)(136003)(396003)(366004)(2616005)(26005)(8676002)(478600001)(83380400001)(86362001)(53546011)(966005)(33656002)(6506007)(316002)(64756008)(66476007)(91956017)(76116006)(66556008)(186003)(8936002)(71200400001)(36756003)(66446008)(66946007)(30864003)(6512007)(110136005)(5660300002)(6486002)(2906002)(45980500001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?VG1tSEFjdlEzTzA2aG04eXgya0FIYTI0eEpmLzhwa3BLR2x6VlBXek16MWRD?= =?utf-8?B?VkhDRmFKcTNlL2MrNWpzcnN5VDhsaDZnU2FpNlJsZ3RkL0llSE96WEhoMkc1?= =?utf-8?B?L2FSU3ZoTUFIY2VkYVhMcjdjR3NNcTBVejJzU3U5ZHVCTVIvQjVKbXJ1ODcv?= =?utf-8?B?cmE2cXFJb3hBbHN0WTg1SVpxczlnbnZkV2RZRUFJdFhNcjRRcFJCc1Z2ckg3?= =?utf-8?B?OUFGOWhtSUY5aWE2SDlsdStYZkhoeWE5YzFHL1d1aS9VbW9NYno2YzRTWk8x?= =?utf-8?B?cEs3TzByN3hnZHBkeUMvWkw5V3N4RUpta2pXT3hEQVBNeGE3SHV2NTNhZmNu?= =?utf-8?B?V0lvRHg2ckxQblBielNqNzhBOGJ5bFZtVnBRdmw5UlVVSldlM00rVmhwaXV0?= =?utf-8?B?R094V2g5eWg1K3ArRDUyMm93eXVpMDhxOVFNR1dwWUMwMm9QWlN0TjFZWnBC?= =?utf-8?B?UVVvR3BRYWhPNFlrTk1HQ0hlTXlVcytKQ2VKYXc3VGFTdWJjOU82cmh5TndP?= =?utf-8?B?UDRiSHB6SUJ1YmdLaTN6ZGI0U0J6U1hBd2NvdDNTVzJBZzI1R1ZZOTUrcHBi?= =?utf-8?B?Mlp4UmZKdWlRVlNOUVg5bHE3aHFQU3FaOTdvUGUzenltT0NpRHRWZ0svOW9W?= =?utf-8?B?b3lNY0hISzdxam54Z01vakNWdFVWOVVhV292cWhWUEtjN1pkUGNMME5HK2tq?= =?utf-8?B?WkxKVzJVTDNkRWxaT3UrZ2hmN1VmYTRmM1BFVi80aFJwMllIYk9nRWRuOGxF?= =?utf-8?B?bzQrOUNWY0VyVW8xQ2VVeVAvM2FNNUpJK2ZQR3phUmhGdVBCczJDN0ltalA4?= =?utf-8?B?WGlwWGkvb21NQ1JNNU9TM3N5RHF1d1VDdGM5UUZiQ1VUbk1WOTl3RjBBdmZi?= =?utf-8?B?WW9Ua2FsMFZHeFJOYmE3cEdIUnU5ZHMyQTRLVnZrTk12aVUxN3Y3ZDVxdjVR?= =?utf-8?B?RkFRRmtKQXJybk40Y0FkbkRYMmp3ZWozVXJ4MVVNMzdUZzNwZUdjUGZ0RUhB?= =?utf-8?B?cTNkd1I5ay9QSEJwQ0RTNHQzTUk1UkRyNVBQNElWZUVYZ2NlUDdFSWdpMmwr?= =?utf-8?B?TDdCQmdDVC81dkJwclhVdVdwUU85VUQwQW9aeElJZE9TaWg2aVNiTit2Z0w3?= =?utf-8?B?eGp2Mkw0QlpwVnJQTFBQY3VlTkZZOG8zUG4wajBzWUE0ZDJmMnA4dkNHUzIw?= =?utf-8?B?NGYxQmVVWmJhVjVTWWhPd3paaUl4VGxBZE53NURaSUVubS9ZLzkrYWY5U2NC?= =?utf-8?B?TFRqR1lEUHc2bUx1ajN0MHBQN09wUHAxUHp4eVU5dHliUVYzTnRoejVGQkpC?= =?utf-8?B?RytiOGJNN2R3aW4yeDJTT2NpRVpEUlFQL0I2NjhCVStMSDh0M012UXVhR3B1?= =?utf-8?B?cFJPWFRyWlVocEN4Z2k4U0pOVHZtQ09kT1IvQkE3SWZ3RWt1NytMbEVsMGFy?= =?utf-8?B?UkxKbWVwNlFTekVKM1lrNG5mTk83eGl1dU5YV1VOTGs3cTFYdEpoQ0xvU005?= =?utf-8?B?ejdESXFtRFhpN2liSnFFK2tzTkhQRmhOcHluSWhkNjM1NWl6UXQvQjVQeURh?= =?utf-8?B?MWlYYnlyZ2dZd0R0VHNQd0dwc2NxVnhMN3hNK0ZJRmc5a0Ruc0dlVUNxRWxU?= =?utf-8?B?ZzB2b1prbmdjdWhDelNIakxUUnZmc1NIRDFxMm8rQXQwaHQzTDVkK0g3eEZU?= =?utf-8?B?VzRPbmVvQ3lDMm1CTS8rcEdZZHM0S1hUL0M5b3R1QTM4c3RVcTNCWUg5dTJm?= =?utf-8?Q?+U/HVFlCD2s4gtWTKgVjyx0qG0zo4BFFXFmAkvO?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <EF9C4E449B0654479DCE055B31909901@namprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN6PR08MB2707.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b1a00b8-b9d5-455d-5115-08d8cf72ed06
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2021 16:26:18.1351 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Amb8SImH1bcLlYghBwsEz/IsO98dKzhM5o2Y2kySCgfSN/lvajOw2YA23GpTrpksu4476lI3CHNHfLruUS2LNA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR08MB3985
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/-DTtrWuZ1YGqwKi7dd9tYqOoMTM>
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:26:28 -0000

	>>> as an indicator of the service to be provided, that is fine.
This is my understanding as well. The mpls label is used for separation of e2e network slides which means separation of L0/L2/L2/L3 services during the realization.

Reza
 

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

    Yes, it shows that the authors thinks the AN / CN could send MPLS.
    If that label is consumed by the operational edge (ingress) as an 
    indicator of the service to be provided, that is fine.  But that is not 
    what drew.  I know of no operator that will allow an MPLS label from a 
    customer to be passed into and used by the internals of their network.

    Yours,
    Joel

    On 2/12/2021 9:51 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
    > Joel,
    > 
    > Please see section 4_.3.2.1. Layer 3 and Layer 2 Encapsulations wh_ere 
    > 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> 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> 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
    > 
    >      >
    >