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

[Greg Mirsky <[e-mail]>]

Hi John,
thank you and Eric for putting this part in a great concise way. It is now
much simpler and simple, in my opinion, is always the better way.
Yes, I support the proposed update to this WG document.

Regards,
Greg

On Tue, Feb 23, 2021 at 6:52 AM John E Drake <jdrake=
[e-mail]> wrote:

> 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 <[e-mail]> On Behalf Of
> > [e-mail]
> > Sent: Tuesday, February 16, 2021 11:59 AM
> > To: Joel M. Halpern <[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]
> >
> >
> > 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:[e-mail]] Envoyé : mardi 16
> > > février 2021 17:44 À : BOUCADAIR Mohamed TGI/OLN
> > > <[e-mail]>; [e-mail] 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, [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.
> > > >
> >
> > _________________________________________________________________
> > ________________________________________________________
> >
> > 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!TrdpM67-tg4psF0dnG7jBV9LisKHxO_oCNxmQXrJhY-
> > B6MFchY8gBvvb8CNl408$
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>