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

Joel Halpern Direct <jmh.direct@joelhalpern.com> Thu, 04 March 2021 13:02 UTC

Return-Path: <jmh.direct@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 E7C9F3A1AAF for <teas@ietfa.amsl.com>; Thu, 4 Mar 2021 05:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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_DNSWL_BLOCKED=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 sYbg9xto89TZ for <teas@ietfa.amsl.com>; Thu, 4 Mar 2021 05:02:37 -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 E29CF3A1AA7 for <teas@ietf.org>; Thu, 4 Mar 2021 05:02:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Drrcs448Lz1pHch; Thu, 4 Mar 2021 05:02:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1614862957; bh=loQeoqqu9eEm2I+54lahTFYVPO6NZ+5ggIIamEuSBK8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=a+a4ZIwlBKrCTg0Mu51o+VXhKlFb2Kx6zSsIiE8brLAd1mOfFrZjclx+ukXDQXZ7F R3s3oc5D6qVHEsAb5qpzcddq/zawPQlQG3Q3OE+q1lmxc/dj8fRMwAKl3uFyhRBzYp Z8uUfyKjHb2jbIS1ssEePvttFYK7bNu6K4LOEhfU=
X-Quarantine-ID: <1JaZ-QLBFA86>
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 4Drrcs07Hyz1nv8q; Thu, 4 Mar 2021 05:02:36 -0800 (PST)
To: mohamed.boucadair@orange.com
Cc: "teas@ietf.org" <teas@ietf.org>
References: <5411_1614779813_603F95A5_5411_22_6_787AE7BB302AE849A7480A190F8B9330315E7FA9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAGU6MPfSDGGx3aRO6Vi1vFpS2k9yOM3ACsUb=jVPQB6-aehWgA@mail.gmail.com> <c2811489-0b88-ad7a-4374-555e2ef3032c@joelhalpern.com> <5592_1614855931_6040BEFB_5592_11_14_787AE7BB302AE849A7480A190F8B9330315F56BF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Message-ID: <af87c5e0-7766-24f0-70b0-8c517a77d7e2@joelhalpern.com>
Date: Thu, 4 Mar 2021 08:02:36 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <5592_1614855931_6040BEFB_5592_11_14_787AE7BB302AE849A7480A190F8B9330315F56BF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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/hAxvWJFdI9xBVZbKGmLzLLsucHs>
Subject: Re: [Teas] CE-based Network Slice RE: 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: Thu, 04 Mar 2021 13:02:40 -0000

That works for me.
Thanks Med.
Joel

On 3/4/2021 6:05 AM, mohamed.boucadair@orange.com wrote:
> Re-,
> 
> I think here where we need to invoke the new term proposed by John/Eric: IETF Network Slice Service.
> 
> The IETF Network Slice Service is always between CEs.
> 
> Other than the managed CE case, the scope of the IETF Network Slice is what Joel said with an emphasis on the adequate configuration of the access circuit.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> Envoyé : jeudi 4 mars 2021 01:42
>> À : Shunsuke Homma <s.homma0718@gmail.com>om>; BOUCADAIR Mohamed TGI/OLN
>> <mohamed.boucadair@orange.com>
>> Cc : teas@ietf.org
>> Objet : Re: [Teas] CE-based Network Slice RE: network Slice Endpoint
>> in draft-ietf-teas-ietf-network-slice-definition-00
>>
>> I can't speak for Med, but in my opinion, the right scope for the
>> IETF Network Slice is PE to PE.  Information about the access circuit
>> will need to be provided, but it is not, as I understand it,under the
>> control of the IETF Network Slice Controller.
>>
>> Yours,
>> Joel
>>
>> On 3/3/2021 7:25 PM, Shunsuke Homma wrote:
>>> Hi Med,
>>>
>>> I think it's an important discussion. I'd like to clarify the range
>>> which should be managed as an IETF network slice. In my
>> understanding,
>>> CE will be a slice consumer's end-host or an endpoint of an
>> opposite
>>> network slice, and it will be generally out of control of IETF
>> network
>>> slice. As you described, there may be cases where CE makes marking
>> on
>>> traffic and PE allocate it to appropriate slice based on the mark,
>> but
>>> I think the arrangement between CE and PE will be done by
>>> controller/orchestrator higher than IETF Network Slice Controller.
>> In
>>> other words, a necessary policy is set to PE from higher
>>> controller/orchestrator, and IETF network slice can work
>> independently
>>> of whether the CE is slice-aware or not.
>>>
>>> So my question is which is appropriate as the range of IETF network
>> slice.
>>>
>>> 1. it is always between CE and CE,
>>> 2. it is always between PE and PE,
>>> 3. it is basically from PE to PE, and sometimes between CE and CE
>>> (e.g., in case that CE is slice-aware,)
>>>
>>> # From a network operator or slice provider aspect, I'd like to
>> know
>>> whether SLA/SLO between CE and PE must  be assured.
>>>
>>> Regards,
>>>
>>> Shunsuke
>>>
>>> 2021年3月3日(水) 22:57 <mohamed.boucadair@orange.com
>>> <mailto:mohamed.boucadair@orange.com>>:
>>>
>>>      Re-,____
>>>
>>>      __ __
>>>
>>>      Thanks Adrian for raising this point.____
>>>
>>>      __ __
>>>
>>>      My take is that we can’t discard it by design. Take the example
>> of
>>>      stitched slices where packets are marked by the CE + that
>> marking is
>>>      trusted by the PE to graft them to the appropriate network
>> slice.
>>>      Likewise, a hierarchical design where an aggregate slice trusts
>> the
>>>      marking of the upper slice to identify how to map between the
>>>      levels. Such trust may be justified under specific deployment
>>>      contexts. ____
>>>
>>>      __ __
>>>
>>>      Cheers,____
>>>
>>>      Med____
>>>
>>>      __ __
>>>
>>>      *De :* Teas [mailto:teas-bounces@ietf.org
>>>      <mailto:teas-bounces@ietf.org>] *De la part de* Adrian Farrel
>>>      *Envoyé :* jeudi 25 février 2021 11:52
>>>      *À :* 'Young Lee' <younglee.tx@gmail.com
>>>      <mailto:younglee.tx@gmail.com>>; 'Luis M. Contreras'
>>>      <contreras.ietf@gmail.com <mailto:contreras.ietf@gmail.com>>
>>>      *Cc :* 'Joel M. Halpern' <jmh@joelhalpern.com
>>>      <mailto:jmh@joelhalpern.com>>; teas@ietf.org
>> <mailto:teas@ietf.org>;
>>>      'Eric Gray' <ewgray2k@gmail.com <mailto:ewgray2k@gmail.com>>;
>> 'John
>>>      E Drake' <jdrake=40juniper.net@dmarc.ietf.org
>>>      <mailto:40juniper.net@dmarc.ietf.org>>; 'Rokui, Reza (Nokia -
>>>      CA/Ottawa)' <reza.rokui@nokia.com
>> <mailto:reza.rokui@nokia.com>>;
>>>      BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com
>>>      <mailto:mohamed.boucadair@orange.com>>
>>>      *Objet :* Re: [Teas] network Slice Endpoint in
>>>      draft-ietf-teas-ietf-network-slice-definition-00____
>>>
>>>      __ __
>>>
>>>      __ __
>>>
>>>      [...] ____
>>>
>>>      ...but we have to ask ourselves carefully whether we **really**
>> want
>>>      the CE-based approach in our network slicing:____
>>>
>>>      __-__What are the considerations for how much knowledge of the
>>>      underlay network has to be shared to the CE?____
>>>
>>>      __-__What are the considerations for how an underlay
>> distinguishes
>>>      CE-originated slicing traffic?____
>>>
>>>      These are pretty much the same questions that CE-based VPNs
>> have to
>>>      answer. Of course, the concept of a “provider-managed CE”
>> muddies
>>>      these waters somewhat.____
>>>
>>>      __ __
>>>
>>>      Conversely, the port-based PE-based VPN has none of these
>> problems,
>>>      but does have to agree on the “Access Connection” encoding, and
>> that
>>>      is either payload-sensitive (like in PWE3) or technology-aware
>> (like
>>>      in L3VPN).____
>>>
>>>      __ __
>>>
>>>      [...] ____
>>>
>>>      __ __
>>>
>>>
>>>
>> _____________________________________________________________________
>> _
>>> ___________________________________________________
>>>
>>>      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://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
>>>
> 
> _________________________________________________________________________________________________________________________
> 
> 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://www.ietf.org/mailman/listinfo/teas
>