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

[Joel Halpern Direct <[e-mail]>]

That works for me.
Thanks Med.
Joel

On 3/4/2021 6:05 AM, [e-mail] 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:[e-mail]]
>> Envoyé : jeudi 4 mars 2021 01:42
>> À : Shunsuke Homma <[e-mail]>; BOUCADAIR Mohamed TGI/OLN
>> <[e-mail]>
>> Cc : [e-mail]
>> 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 <[e-mail]
>>> <mailto:[e-mail]>>:
>>>
>>>      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:[e-mail]
>>>      <mailto:[e-mail]>] *De la part de* Adrian Farrel
>>>      *Envoyé :* jeudi 25 février 2021 11:52
>>>      *À :* 'Young Lee' <[e-mail]
>>>      <mailto:[e-mail]>>; 'Luis M. Contreras'
>>>      <[e-mail] <mailto:[e-mail]>>
>>>      *Cc :* 'Joel M. Halpern' <[e-mail]
>>>      <mailto:[e-mail]>>; [e-mail]
>> <mailto:[e-mail]>;
>>>      'Eric Gray' <[e-mail] <mailto:[e-mail]>>;
>> 'John
>>>      E Drake' <jdrake=[e-mail]
>>>      <mailto:[e-mail]>>; 'Rokui, Reza (Nokia -
>>>      CA/Ottawa)' <[e-mail]
>> <mailto:[e-mail]>>;
>>>      BOUCADAIR Mohamed TGI/OLN <[e-mail]
>>>      <mailto:[e-mail]>>
>>>      *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
>>>      [e-mail] <mailto:[e-mail]>
>>>      https://www.ietf.org/mailman/listinfo/teas
>>>      <https://www.ietf.org/mailman/listinfo/teas>
>>>
>>>
>>> _______________________________________________
>>> Teas mailing list
>>> [e-mail]
>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>