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

[tom petch <[e-mail]>]

From: Teas <[e-mail]> on behalf of John E Drake <jdrake=[e-mail]>
Sent: 16 February 2021 19:11

CE, PE, and attachment circuit are all pretty standard IETF terms.

<tp>
Indeed, the RFC Editor offers a choice of
- Customer Edge (CE)  or
- Control Element (CE)  or
- Congestion Experienced (CE)

Tom Petch

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Teas <[e-mail]> On Behalf Of Joel M. Halpern
> Sent: Tuesday, February 16, 2021 11:44 AM
> To: [e-mail]; [e-mail]
> Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-
> definition-00
>
> [External Email. Be cautious of content]
>
>
> 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, [e-mail] wrote:
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Teas [mailto:[e-mail]] De la part de Joel M.
> >> Halpern
> >> Envoyé : mardi 16 février 2021 17:12
> >> À : [e-mail]
> >> 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, [e-mail] 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.
> >
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!WwkejosBVkuIchCGJXaCm1T8VfR8wz-qtyI0_9r0T-
> BO1LShePwDGA6L6j-HWgk$
_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas