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

"Joel M. Halpern" <jmh@joelhalpern.com> Sat, 03 April 2021 21:44 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 5C0FB3A17D8 for <teas@ietfa.amsl.com>; Sat, 3 Apr 2021 14:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, 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 p3dKGEAdh3RV for <teas@ietfa.amsl.com>; Sat, 3 Apr 2021 14:44:21 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 95CC13A17D9 for <teas@ietf.org>; Sat, 3 Apr 2021 14:44:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4FCVn10HRgz6G7fm; Sat, 3 Apr 2021 14:44:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1617486261; bh=r9fOfbqN1zHgLjOY9Ii/2Sxh7glgmIeXGeELwdwYoCQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=TiyqNBOB1QA8VVJA8gejhJ7LuZCyKtN14rZirvNNFRYXTcyZqJ+WbaxtpuxJZD/kU yra2FGvsBfcXr58vM02ktTzDGUPEGEb8bfOfj/ONpry88MBJyil56/6HClY2oRLt4F YixPyepV/F0ZIWh0BnfeM1STdDcqt24ILImb3NRU=
X-Quarantine-ID: <w-WX0iUOnz7e>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4FCVn03VRzz6G7dV; Sat, 3 Apr 2021 14:44:19 -0700 (PDT)
To: John E Drake <jdrake@juniper.net>, "teas@ietf.org" <teas@ietf.org>
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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <47305aef-a5d8-ee5b-1288-10d78cdfb948@joelhalpern.com>
Date: Sat, 3 Apr 2021 17:44:18 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <MN2PR05MB66239ACEF39F04C622ED51E6C7799@MN2PR05MB6623.namprd05.prod.outlook.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/WWnXw-wcIBSNL4kWqMc_8hYRYGg>
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: Sat, 03 Apr 2021 21:44:26 -0000

That seems to capture what we have been dsicussing.
Thank you,
Joel

On 4/3/2021 4:06 PM, John E Drake 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) 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; 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,
>>
>> 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> On Behalf Of
>>> mohamed.boucadair@orange.com
>>> Sent: Tuesday, February 16, 2021 11:59 AM
>>> To: 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
>>>
>>> [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] Envoyé : mardi 16
>>>> février 2021 17:44 À : BOUCADAIR Mohamed TGI/OLN
>>>> <mohamed.boucadair@orange.com>om>; 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 wrote:
>>>>> Re-,
>>>>>
>>>>> Please see inline.
>>>>>
>>>>> Cheers,
>>>>> Med
>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Teas [mailto:teas-bounces@ietf.org] De la part de Joel M.
>>>>>> Halpern
>>>>>> Envoyé : mardi 16 février 2021 17:12 À : 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 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
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
>>> __;!!N
>>> Et6yMaO-gk!TrdpM67-tg4psF0dnG7jBV9LisKHxO_oCNxmQXrJhY-
>>> B6MFchY8gBvvb8CNl408$