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

Tarek Saad <tsaad@juniper.net> Sun, 04 April 2021 20:10 UTC

Return-Path: <tsaad@juniper.net>
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 ED13B3A1881 for <teas@ietfa.amsl.com>; Sun, 4 Apr 2021 13:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=EzrMR8UD; dkim=pass (1024-bit key) header.d=juniper.net header.b=H3QBopO5
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 dWEjh5ccYA6M for <teas@ietfa.amsl.com>; Sun, 4 Apr 2021 13:10:27 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 B1DBA3A187F for <teas@ietf.org>; Sun, 4 Apr 2021 13:10:27 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 134K5H53002247; Sun, 4 Apr 2021 13:10:26 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=zhmAqTo3OY8S1Jq/U55KvAbiKjzqUwguKw42KD9YjOA=; b=EzrMR8UDgJrGqW8MS53jvDe94zyHDPeyzePZaOEZRy/hFjiBc4M6+g36SQCQ3XpK23fH 8Gvan/fq4Lgh/q49BlT0F2M8sAA86IeNrsfB35TSHpf0+lgyxZH22trV6BHLAjqJFSUY c/pFUeX/ZqRrVrrarFQ37YAnfHqIYJJbXCVFEBTV9bf8ulBTcw+pdlxDhEL9FsPPxo+L aWhWt59E4o0rRvhuha+GV608mUIaDfjBcQtd8xf5vFztqEIeSgEkt4NOOoRx/w+nq7BH ZeurWMk951hmYzUZzIj7TE2YzFYzOhC81gdHpuZEUpqWObjQxXI2Ho4buEi0YyGNPy4Y nQ==
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2102.outbound.protection.outlook.com [104.47.70.102]) by mx0a-00273201.pphosted.com with ESMTP id 37q3bh0srf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 04 Apr 2021 13:10:25 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ESChDkhHBLXoEWHCnbkI7DuGE8DrpuE3DBtGRsQxkwc+O0Ti0NRhcqoaxA6OZoR+WM2RQs9fOg5pUdUPOhmyItrdn+32Q0irEscxOI0taDDDOKXsUjcSAsv3b1wVFJ4iHQebNnJ7cWsnFeQ6oglBNLfDPaUJz+g/QHLbw1q2zv1WaKbxN//HLoSmFYSsAOwRSlUPWO1tzMzuo9whm9jLiOHNvmQRUjlq+Sa9C0IOuYQBJTbrYZf3eyE9xxVEkpiBsCsY1Da6VDdzsqaWkcyV9nh3JccZlN8mSii15qNq8XErHx3pflppi3I7GUovX1FCXDiyLkCO6GCT6bmNduOQDw==
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=zhmAqTo3OY8S1Jq/U55KvAbiKjzqUwguKw42KD9YjOA=; b=kCASrnVdltiidgBNFIS7Mr0BN/tqU0WFai6XrC4f8eONKdej3PGUj1yRF8MjaaOdCmpNfBHlrx/tTRg5alH2z3w36ipjkoYq300u5t227EhjDqJOMdpve2tUS80JFVUiJBED6Cvx41SP4IAkwXTn4Jy/5VVErx1Zx5EfOjtON/gnthPJiE0STGdLS4nMeou4x8G2eH/M0PKcdSOtxPguy6DdWlCml0GQcGE5/u9X7bm2ocBEhQCArmhUZ9uPbpF5yJMPeCzzP7Hzcw75o2SmTwHnjkDrW7o+x1/cgje6/bJkwi77hwDeSWaV8eRgAkipb5HkpEq4LOf0Fe0oci5iCA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zhmAqTo3OY8S1Jq/U55KvAbiKjzqUwguKw42KD9YjOA=; b=H3QBopO5MqODl4JhAZ29C9iqgV4WjDQk6hA1/2qprQn6IsIOxLOf4E0w8moQ8AVe5GE593Sd//go6ql7DJQQsaEo7LV2WyzIha6gJT+HFqTqB8ZNmHxagZwEiepmfjQ7NvmSLzvTwsrb/OEEfJP//z3Pk+61Gs3IzdvQrD6Nl+k=
Received: from BYAPR05MB4136.namprd05.prod.outlook.com (2603:10b6:a02:85::18) by SJ0PR05MB7311.namprd05.prod.outlook.com (2603:10b6:a03:278::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.8; Sun, 4 Apr 2021 20:10:21 +0000
Received: from BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::a5df:f171:3457:b8bc]) by BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::a5df:f171:3457:b8bc%3]) with mapi id 15.20.3999.032; Sun, 4 Apr 2021 20:10:20 +0000
From: Tarek Saad <tsaad@juniper.net>
To: John E Drake <jdrake@juniper.net>, Greg Mirsky <gregimirsky@gmail.com>
CC: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "teas@ietf.org" <teas@ietf.org>, Kireeti Kompella <kireeti@juniper.net>, Manish Gupta <manishgupta@juniper.net>
Thread-Topic: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
Thread-Index: AQHXKOWmxd7kCs7jj0GxNvnoXjc2GKqjrIkAgADaC4CAAAGkgA==
Date: Sun, 4 Apr 2021 20:10:20 +0000
Message-ID: <E21522AC-F8C0-4960-8843-19CA652AFE14@juniper.net>
References: <cc3949a4-1e60-7f77-45bd-2470be67d9d5@joelhalpern.com> <28233_1613491513_602BED39_28233_126_1_787AE7BB302AE849A7480A190F8B9330315CF830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1bf03e82-3734-885a-7047-cacf5c63d9cc@joelhalpern.com> <8211_1613493543_602BF527_8211_334_1_787AE7BB302AE849A7480A190F8B9330315CF95E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <cde51de3-4533-9acd-a654-59a1dc9f195b@joelhalpern.com> <11878_1613494720_602BF9C0_11878_194_1_787AE7BB302AE849A7480A190F8B9330315CF9FC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <MN2PR05MB6623B0D3F5EEECFB3CE3FA8BC7809@MN2PR05MB6623.namprd05.prod.outlook.com> <MN2PR05MB66239ACEF39F04C622ED51E6C7799@MN2PR05MB6623.namprd05.prod.outlook.com> <218C08BA-342C-4FDF-A0E9-E91D53485BFD@juniper.net> <CA+RyBmWnsehgfib5kKpc2e8HEZVFfX1wXGwfneY4VxAM6Yg5Dw@mail.gmail.com> <MN2PR05MB662317E81DF2C5D85F5601C4C7789@MN2PR05MB6623.namprd05.prod.outlook.com>
In-Reply-To: <MN2PR05MB662317E81DF2C5D85F5601C4C7789@MN2PR05MB6623.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-04-04T16:04:24Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=35478e6e-a80d-4e03-a06c-7a1a13216cbc; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
user-agent: Microsoft-MacOutlook/16.47.21031401
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [2607:fea8:e31f:e400:8054:b64f:8582:2f88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 189e78bf-a47d-4001-a217-08d8f7a5ac66
x-ms-traffictypediagnostic: SJ0PR05MB7311:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <SJ0PR05MB7311949E89FCDDCFAFA39812B7789@SJ0PR05MB7311.namprd05.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: QwxPfRIFkGyldnolQgHHEPmoYgbTudU2xzbHbCcvlQJNfDshfRqMokb1BH5hNtC5kWh8wQHYSOmiSQBIO1J/+4WPjPc0VWJ/eLtW/jMxAoAdlAgq548Tolsug3mfgb0l5EHTWX/gS8zZqB2VM4lak0iwXRevMjRwsHnvLFvkUFcyba6l8IEzpvWEHU8+ZcVQ2aEV0KAxSzPDzskx4Jl8v6iENgK452VwDgx6kAVeHt8JS4fpjhmmGR1jI5tW2D9nrQZwP77x4jdkt+Dfvtn1wKUzHPgkiz6THTn88IWlqmJdGvZbTVTBIqYwZWa2vvhXusqZtN0bayff9rP/eov0E/aKTxFIEtoDB1iMkaxDU59zsKYo1yqjs/Oatczi4uSps5PZ70rEwpjR1sirwFiYC3b6pxMWuKqdRZVj0HpPqUC6T6retk6+om18GYDaPGMhNjG7zW//0f+9XRJJQLMtZS9ueQ9x2bme5AXWbMM4OA97zjlzUjMg1zJ3U05UmkkL9MnLhvfiR9vyYPGdJzCxK0yhWE/6ERkhnyAl2AHqMUFpVe2rSv9XAKSQkIVUjTXyp+jChDogBnXOA/eWsdFE1i2VQ7L+nV3RZCHmNa0nQvZQjlKwq63c4jSSygGVJLOLj9YrwynwQyLumupKr0JSJ+QKq7ZWTXAS7I5p7d1JDFQeURwnHGq2BYFUdZsHHyheW97oIEjywa9W7uc56BvDpSdjonizBgWRuTLHdoJ5pRUkkF6vRw5Ks76DDjUMG71mKeTpIDgHuYPYqw1DRBnYiQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR05MB4136.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(396003)(346002)(136003)(366004)(54906003)(107886003)(110136005)(33656002)(2616005)(8676002)(66574015)(966005)(6512007)(53546011)(6506007)(36756003)(4326008)(478600001)(6486002)(30864003)(71200400001)(316002)(83380400001)(2906002)(5660300002)(76116006)(8936002)(66446008)(64756008)(66476007)(66556008)(86362001)(166002)(66946007)(186003)(38100700001)(45980500001)(579004)(559001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?V0FDM2FKUzJGWGlNMEdLUCtZWGl2elRwbk14Q00rZVJwZ0hRWEUwUHNKSUFU?= =?utf-8?B?cE1NTXdYTDVBdVlUYUZDWitGYUpoTEU0MWo0NmlMZmN0cUcwNUFRYUR6Q0J6?= =?utf-8?B?eEl3bEthbldBR2xZODVKRThlZDJRWGMyTkJSMGVzWjkxYmZ0L3V0K3VUcmxF?= =?utf-8?B?aXBJUGFTRndvMzdhRnVXNHpsWFNaeHNOU0tyeU41Rnd4ZDdnKzNGZHhuSzlM?= =?utf-8?B?MmxCdkR2YTA0ZVFPdTg4WDc2OUd3SGlkUzgyTnJiL3NGbk5FOVNHMjlkS1pF?= =?utf-8?B?YXR5TmVJUE5aTFFxSWlGMzZuQWRXbDFEa0wyNGJLODNITnBZVTFwVXdQWXNm?= =?utf-8?B?akt0TlNMQTBBWmEzckNGOHhFNTBXZ0djVVlDSHUrSnQzSmprZW5aTzRYcjR0?= =?utf-8?B?bVNPOHk5cm42NlJUOC84NjJ0L1Zpd3FhQ2lLKzgxa3E0UFU1TFF2YXhQVFIy?= =?utf-8?B?eWcvS1g0MlU3T3lmRXZFUXF0ckVJWUtxWmN6YlRENUVzQTlYRUk1Ny9LbWFS?= =?utf-8?B?aHFPeVNLSnVhNFMwQnc3aTBFUHFsbFNhSkVHL0MvT3ZIK3MzYTFYdVJ0SkFz?= =?utf-8?B?TUxSK2dNS0VMOGNtUHhmT3NOYkdsak8wS1dWWUhMbDhFVkRpM3ZyZGNuaERw?= =?utf-8?B?enl0blgwSWR5bDJTNXBZNzJ6Ri80OE5oZXplNjB1dHgycC9DcGJabTVDZTAy?= =?utf-8?B?K2dkUWdxNzRzWWlTaE5QWWRFZXBRQTNNV1loMXlnaHp4OFFyWDF6cnliQ2Js?= =?utf-8?B?emhIZ0pBc1JHMlJCbE9tQ3pzbXRzNnNaZ1d5M0NjOHlJVy9Oak4wZWR2N1Zh?= =?utf-8?B?WmpsOHAvOE5OQy9GMXNPRDhiT09ybUpWbjlPWk1vYTloeERoMjZTTVpCMFlU?= =?utf-8?B?VVpOVlBveEhDOUYwY0hIMjZleWxJSi9jN1EvMFFWNkx6dU1raHhjVE5yRjQ3?= =?utf-8?B?c3hYL0E0aVdHNjFPUWhpS09KYzk4cTgzdHJNemNhU1lSMEhEYUsyNWN5czh0?= =?utf-8?B?WlE3SER2Y2tuNnpRaGk2NGZFeTlSaXI2Qm0yT0dicTRpWnhyTkZDeVU5c2F5?= =?utf-8?B?Y3ZGSEszMTVEa3lXMXRhRTF0bG1BVHl4M2xnWVM5b1JXVDhsYzJ1RDNOQ0l2?= =?utf-8?B?UmRRRENwcUE0aHIwQW90aG8zWjBHQWUzbjBvVzg1U0c4dittaUtiajBpcTBp?= =?utf-8?B?WDQ4M1VnZ1UzZWdSUVkwVnBJRGlaclFsYVc3cWpqSnZBNkFEVWxMdkQ1Z0R4?= =?utf-8?B?Z2hxRG5KZk5SeGphdkR1a1B3TTZSalB3RGdxUVNNR2lYVFJXRFdhVTV2SHk3?= =?utf-8?B?NE1aS0FOR1pFNnEzcmFxVGFNSU9oSVhYM1NjNW4vanp0eE5RY1ArVzE1MmlT?= =?utf-8?B?QmZzM203bll0QUVUM2hoaEhBbFBKb3ZrTExGZ0QwZmY2UGQ1ZGFCZkQ0L3ZY?= =?utf-8?B?N21zZXBVRWwwTHJDNlJSOENWcGdzM3JXWjc4WFVTd1crb1preFJJalEwZFFJ?= =?utf-8?B?bUFpMXNLbnJBNHEyckUyZVNnREZWRWtBMThORllHQmllWG5WZCtnb2ZwNFlL?= =?utf-8?B?REN5Z1VuNEk1eHFPcUtIdEtYa1ViUWM5NG11R0M4S1lMeFFwMVI3cloyYTRI?= =?utf-8?B?alQvZ0N1YUV4dGtvSi9LemFCR3piRFFzVGwwZk9XVkN0QXAzejUvcVZsb0R5?= =?utf-8?B?R3ZJVUZTck1pRE5TWmNzSy8xUnA0ZmEweDF1UFlLOHB3ZU9ZRHJlTjJ6Y0Jp?= =?utf-8?B?VlpZS0xncGRDc2M4M3dNRG9WT1dDbU95TTZxTmhkYXNkWmR4QXA5UXNBUW9p?= =?utf-8?B?K1BFTXRBZ1hrSUJQT0hwd0p2NFlmZkhnakEwYjNXcmFyUVJoQnV1SDZMMXht?= =?utf-8?B?cHhFUjVJU2VFL083bmdwYmhTVGxhWnVQeitTeFRySlF5dkE9PQ==?=
Content-Type: multipart/alternative; boundary="_000_E21522ACF8C04960884319CA652AFE14junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR05MB4136.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 189e78bf-a47d-4001-a217-08d8f7a5ac66
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2021 20:10:20.5098 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tpnTJXa7HW1tJFzUv/dGk7MB7WKpuBTMvukQr7yog4SZUY7XqF4lRDokguLr2AgQH6yHmh+ym5F47wgGovUBKw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR05MB7311
X-Proofpoint-ORIG-GUID: 95HRnQbBBHyxcW9uJpvFiQDs8ryixUhh
X-Proofpoint-GUID: 95HRnQbBBHyxcW9uJpvFiQDs8ryixUhh
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-04-04_08:2021-04-01, 2021-04-04 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 priorityscore=1501 mlxlogscore=999 suspectscore=0 phishscore=0 adultscore=0 mlxscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104030000 definitions=main-2104040139
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Wsrfs0lsR5Ed6yY-IYSMVweNvfk>
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: Sun, 04 Apr 2021 20:10:33 -0000

Yes, this is my point. Using the two basic constructs (below), one can realize the more complex connectivity types.

  *   P2P unidirectional
  *   P2MP unidirectional
Also, I am in favor of renaming the above to:

  *   Connection
  *   Connection group (to distinguish it from P2MP multicast)

Regards,
Tarek

On 4/4/21, 12:04 PM, "John E Drake" <jdrake@juniper.net<mailto:jdrake@juniper.net>> wrote:


Greg,

“For a P2P bidirectional connectivity matrix, there are two sending CEs, there are two SLOs, and each may be different”

 Yours Irrespectively,
John



Juniper Business Use Only
From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Saturday, April 3, 2021 11:04 PM
To: Tarek Saad <tsaad@juniper.net>
Cc: John E Drake <jdrake@juniper.net>et>; mohamed.boucadair@orange.com; Joel M. Halpern <jmh@joelhalpern.com>om>; teas@ietf.org; Kireeti Kompella <kireeti@juniper.net>et>; Manish Gupta <manishgupta@juniper.net>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

[External Email. Be cautious of content]

Hi Tarek,
thank you for bringing up these questions. I've been thinking, playing in my mind with the SLO in a network slice.
I agree that the SLO is for an ordered pair of CEs, and thus it is unidirectional regardless of the connection matrix. But I think that there might be a use case for a bidirectional P2P connection, especially if [A, B] and [B, A] SLOs are identical. Also, a bidirectional P2P connection might be a useful construct when directions are sharing each other fate under the protection switchover scenario.

What are your thoughts?

Regards,
Greg

On Sat, Apr 3, 2021 at 7:31 PM Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:

John/all,



I can glean the following from this definition. Let me know if misinterpreted.



1) A connection supporting a network slice is unidirectional. A corollary is: SLO(s) are unidirectional too.

2) From a sending CE, there are only 2 types of connectivity matrices:

·         P2P unidirectional

·         P2MP unidirectional

Using the above type of matrices on a sending CE, one can realize any of network slice connectivity type required – e.g., quoting your example, a MP2P can be realized by (N – 1) P2P unidirectional connectivity matrices on the sending CEs.



3) The SLOs are per matrix type – either P2P or P2MP. Is the definition anywhere precluding having multiple connectivity types of matrices from a sending CE for the same network slice?(e.g. a mix of (n x P2P) and m x P2MP connectivity matrices on the same sending CE for the same network slice)?



Regards,

Tarek



On 4/3/21, 4:06 PM, "Teas on behalf of John E Drake" <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org> on behalf of jdrake=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:



    Hi,



    As a follow-up to the email, below, that Eric and I sent in late February, here is our proposed definition of an IETF Network Slice Service:





    IETF Network Slice Service - A service provider instantiates a service for a customer which is specified in terms of a set of the customer's endpoints (CEs), a set of connectivity matrices (MP2MP, P2MP, MP2P, and P2P) between subsets of these CEs and an SLO for each CE sending to each connectivity matrix.  I.e.,

in a given IETF network slice service there may be multiple connectivity matrices of the same or different type, each connectivity matrix may be between a different subset of CEs, and for a given connectivity matrix each sending CE has its own SLO and each SLO may be different.  It is also the case that a given sending CE may have a different SLO for each connectivity matrix to which it is sending.  Note that a given sending CEs's SLO for a given connectivity matrix applies between it and each of the receiving CEs for that connectivity matrix.



    This results in the following connectivity matrices:



             For a MP2MP connectivity matrix with N CEs, each of the N sending CEs has its own SLO and each may be different



             For a P2MP connectivity matrix, there is only one sending CE and there is only one SLO



             For a MP2P connectivity matrix with N CEs, each of the N - 1 sending CEs has its own SLO and each may be different



             For a P2P unidirectional connectivity matrix, there is only one sending CE and there is only one SLO



                  For a P2P bidirectional connectivity matrix, there are two sending CEs, there are two SLOs, and each may be different



    If an IETF network slice service customer wants to have hub and spoke connectivity between N CEs in order to control how traffic is distributed between its CEs, it requests a set of N - 1 P2P unidirectional connectivity matrices, each between a sending CE spoke and the hub CE, and a P2MP connectivity matrix between the sending CE hub and the spoke CEs.



    It should be noted that per [RFC4364} section 9 (https://datatracker.ietf.org/doc/html/rfc4364#section-9<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4364*section-9__;Iw!!NEt6yMaO-gk!Re9TWXBB48lKs2jUNTw2_iNuEZL2_61UYeKvK_n59MV7lfMPJ91pTywhv9jHWzc$>) an IETF network slice service customer may actually be its own IETF network slice service provider in the same or different provider network.



    For a given IETF network slice service, the IETF network slice customer and the IETF network slice provider agree, on a per-CE basis which end of the attachment circuit provides the service demarcation point.  This determines whether the attachment circuit is included in any SLOs for the subject CE.



    Yours Irrespectively,



    John





    Juniper Business Use Only



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

    > From: John E Drake

    > Sent: Tuesday, February 23, 2021 9:53 AM

    > To: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; Joel M. Halpern

    > <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>; teas@ietf.org<mailto:teas@ietf.org>

    > Subject: RE: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-

    > definition-00

    >

    > Hi,

    >

    > Eric and I have reviewed the Definitions draft, the email thread with the subject

    > line: Network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00,

    > and the RFCs referenced in emails on that thread - 3985, 4110, 4026, 4664, and

    > 8309, and we would like to propose that in the Definitions draft we replace

    > 'network slice endpoint' with 'CE' and 'network slice realization endpoint' with

    > 'PE', that we reference  RFCs  3985, 4110, 4026, 4664, and 8309, and that we

    > replace the current figure in Endpoint section with several figures, which show

    > connectivity constructs and which are consistent with these RFCs.  We would

    > also like to replace 'consumer' with 'customer', add 'attachment circuit', and add

    > a new term, viz, 'IETF Network Slice Service', whose definition is a set of CEs, a

    > set of connectivity constructs (MP2MP, P2MP, P2P, etc.) between subsets of

    > these CEs and an SLO for each CE sending to each connectivity construct.

    >

    > As an aside, the Endpoint section of the Definitions draft uses the bulk of its

    > prose enumerating what its endpoints are not.  Per Yakov, since there are a

    > potentially infinite number of things which its endpoints are not, this is futile and

    > we would like to remove that prose.

    >

    > Yours Irrespectively,

    >

    > Eric and John

    >

    >

    > Juniper Business Use Only

    >

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

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

    > > mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>

    > > Sent: Tuesday, February 16, 2021 11:59 AM

    > > To: Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>; teas@ietf.org<mailto:teas@ietf.org>

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

    > > draft-ietf-teas-ietf-network-slice-

    > > definition-00

    > >

    > > [External Email. Be cautious of content]

    > >

    > >

    > > Re-,

    > >

    > > Indeed. That's need to be fixed.

    > >

    > > As we are on the terminology, I do also suggest that the draft is

    > > updated to adhere to RFC8309. Given the recursiveness discussed in the

    > > draft, having geo- coordinates interfaces is also confusing. Inspiring

    > > from RFC8309 would make more sense.

    > >

    > > Cheers,

    > > Med

    > >

    > > > -----Message d'origine-----

    > > > De : Joel M. Halpern [mailto:jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>] Envoyé : mardi 16

    > > > février 2021 17:44 À : BOUCADAIR Mohamed TGI/OLN

    > > > <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>; teas@ietf.org<mailto:teas@ietf.org> Objet : Re: [Teas]

    > > > network Slice Endpoint in draft-ietf-teas-ietf-

    > > > network-slice-definition-00

    > > >

    > > > I would be happy to use CE and PE.  I would also be happy to use

    > > > completely different words.  The current diagram and terminology

    > > > makes this very confusing, and leads to problems.

    > > >

    > > > Yours,

    > > > Joel

    > > >

    > > > On 2/16/2021 11:39 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:

    > > > > Re-,

    > > > >

    > > > > Please see inline.

    > > > >

    > > > > Cheers,

    > > > > Med

    > > > >

    > > > >> -----Message d'origine-----

    > > > >> De : Teas [mailto:teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>] De la part de Joel M.

    > > > >> Halpern

    > > > >> Envoyé : mardi 16 février 2021 17:12 À : teas@ietf.org<mailto:teas@ietf.org> Objet : Re:

    > > > >> [Teas] network Slice Endpoint in draft-ietf-teas-ietf-

    > > > >> network-slice-definition-00

    > > > >>

    > > > >> The document is not about the request from the external customer

    > > > (the

    > > > >> request for the end-to-end network slice). It is about the

    > > > >> request from other orchestration systems to the IETF Network

    > > > >> Slice

    > > > management

    > > > >> systems.

    > > > >

    > > > > [Med] ... which is still behaving as the customer role.

    > > > >

    > > > >   Yes, those systems need to know where they intent to

    > > > >> utilize the IETF network slice.  But the IETF network slice does

    > > > not

    > > > >> need to know about that.

    > > > >

    > > > > [Med] This is what I fail to see. The orchestrator has an internal

    > > > vision that is not available to the entity asking for a slice. These

    > > > nodes are not even known to the "other orchestration systems" when

    > > > asking for a slice.

    > > > >

    > > > >>

    > > > >> In particular, when we get to talking about configuring the IETF

    > > > >> Network Slice properties, the edge (ingress) that the IETF

    > > > >> Network Slice controller controls (and corresponding egress) is

    > > > >> what needs

    > > > to

    > > > >> be provisioned.

    > > > >

    > > > > [Med] Agree, but that is a distinct phase.

    > > > >

    > > > > BTW, ingress/egress are as a function of the traffic direction. A

    > > > node (PE) may behave as both ingress and egress for the same slice.

    > > > >

    > > > >> It is possible that on the egress side there needs to be

    > > > information

    > > > >> about how to deliver the traffic externally.

    > > > >

    > > > > [Med] Agree. That node does not need to be visible (known in

    > > > advance) to the entity that will consume the corresponding slice.

    > > > >

    > > > >    But that would not be

    > > > >> in terms of end-points since from the perspective of the IETF

    > > > Network

    > > > >> Slice, on the egress that is not an endpoint of anything.

    > > > >

    > > > > [Med] I agree that "endpoint" is confusing. "Customer Node/Edge"

    > > > > vs

    > > > "Provider Edge" are my favorite here.

    > > > >

    > > > >>

    > > > >> Yours,

    > > > >> Joel

    > > > >>

    > > > >> On 2/16/2021 11:05 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:

    > > > >>> Hi Joel,

    > > > >>>

    > > > >>> I disagree with this note. I do think that both flavors of

    > > > >> "endpoint" should be included in the draft.

    > > > >>>

    > > > >>> >From the customer standpoint, a slice request cannot be

    > > > >> characterized by elements not visible to the customer. The scope

    > > > of a

    > > > >> requested slice can only be characterized between nodes that are

    > > > >> known to the requestor. This is usually called, CE.

    > > > >>>

    > > > >>> The mapping between a CE and a network device (typically, a PE)

    > > > is

    > > > >> a process that is internal to the slice provider.

    > > > >>>

    > > > >>> The CE-PE link cannot be systematically excluded as some

    > > > >>> specific

    > > > >> behaviors may need to be enforced in the CE-PE link. Think about

    > > > >> a slice that is implemented by means of a PE-based VPN and which

    > > > >> requires some specific routing + QoS policies at the CE-PE link.

    > > > >>>

    > > > >>> Cheers,

    > > > >>> Med

    > > > >

    > > > >

    > > > >

    > > >

    > >

    > _________________________________________________________________

    > > ____

    > > > _

    > > > > ___________________________________________________

    > > > >

    > > > > Ce message et ses pieces jointes peuvent contenir des informations

    > > > > confidentielles ou privilegiees et ne doivent donc pas etre

    > > > diffuses,

    > > > > exploites ou copies sans autorisation. Si vous avez recu ce

    > > > > message par erreur, veuillez le signaler a l'expediteur et le

    > > > > detruire

   > > > ainsi que les pieces jointes. Les messages electroniques etant

    > > > susceptibles d'alteration, Orange decline toute responsabilite si ce

    > > > message a ete altere, deforme ou falsifie. Merci.

    > > > >

    > > > > This message and its attachments may contain confidential or

    > > > > privileged information that may be protected by law; they should

    > > > not be distributed, used or copied without authorisation.

    > > > > If you have received this email in error, please notify the sender

    > > > and delete this message and its attachments.

    > > > > As emails may be altered, Orange is not liable for messages that

    > > > have been modified, changed or falsified.

    > > > > Thank you.

    > > > >

    > >

    > >

    > _________________________________________________________________

    > > ________________________________________________________

    > >

    > > Ce message et ses pieces jointes peuvent contenir des informations

    > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,

    > > exploites ou copies sans autorisation. Si vous avez recu ce message

    > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi

    > > que les pieces jointes. Les messages electroniques etant susceptibles

    > > d'alteration, Orange decline toute responsabilite si ce message a ete altere,

    > deforme ou falsifie. Merci.

    > >

    > > This message and its attachments may contain confidential or

    > > privileged information that may be protected by law; they should not

    > > be distributed, used or copied without authorisation.

    > > If you have received this email in error, please notify the sender and

    > > delete this message and its attachments.

    > > As emails may be altered, Orange is not liable for messages that have

    > > been modified, changed or falsified.

    > > Thank you.

    > >

    > > _______________________________________________

    > > Teas mailing list

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

    > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas>

    > > __;!!N

    > > Et6yMaO-gk!TrdpM67-tg4psF0dnG7jBV9LisKHxO_oCNxmQXrJhY-

    > > B6MFchY8gBvvb8CNl408$

    _______________________________________________

    Teas mailing list

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

    https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Re9TWXBB48lKs2jUNTw2_iNuEZL2_61UYeKvK_n59MV7lfMPJ91pTywhOXK0tfI$>


Juniper Business Use Only
_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Re9TWXBB48lKs2jUNTw2_iNuEZL2_61UYeKvK_n59MV7lfMPJ91pTywhOXK0tfI$>