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

[John E Drake <[e-mail]>]

Hi,

Please see:  https://tools.ietf.org/html/rfc4364#section-9

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Teas <[e-mail]> On Behalf Of Joel M. Halpern
> Sent: Tuesday, February 23, 2021 9:10 PM
> To: Luis M. Contreras <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-
> definition-00
> 
> [External Email. Be cautious of content]
> 
> 
> We can (easily, and consistently with other IETF use of the term) allow for a PE
> that connects to either a CE or to another operators PE.  The point is that the PE
> are the first / last device in the relevant domain that the provider controls to
> provide the service (in this case, the IETF Network Slice).
> By assumption in the current definitions and Framework drafts, the consumer is
> a distinct domain.  There also can be, as you say, neighbor separate domains.
> 
> Yours,
> Joel
> 
> On 2/23/2021 5:45 PM, Luis M. Contreras wrote:
> > Hi all,
> >
> > Regarding the CE / PE discussion, I have doubts if this would apply to
> > scenarios where we could have stitching of IETF Network Slices or in
> > scenarios where an IETF Network Slice of technology X is supported on
> > IETF Network Slice of technology Y. While end-point can work in all
> > the cases, I think that CE / PE don't become naturally applicable in all cases.
> >
> > Respect to the discussion on IETF Network Slice Service, I think it is
> > redundant since we are talking of consumer/customer and provider in
> > the context of IETF Network Slice, so being "Service" redundant there.
> > Probably adds more confusion than clarification.
> >
> > Best regards
> >
> > Luis
> >
> >
> > El mar, 23 feb 2021 a las 20:20, Eric Gray (<[e-mail]
> > <mailto:[e-mail]>>) escribió:
> >
> >     Reza,
> >
> >     Please see /*in-line responses*/ below…
> >
> >     Note: I am trying not to repeat responses already made.  If I
> >     respond to ay point with a similar response to ay already given, I
> >     apologize in advance...
> >
> >     —
> >     Eric
> >
> >>     — [SNIP] ---
> >>     __ __
> >>     *De :*Teas [mailto:[e-mail]
> >>     <mailto:[e-mail]>]*De la part de*Rokui, Reza (Nokia -
> >>     CA/Ottawa)
> >>     *Envoyé :*mardi 23 février 2021 17:53
> >>     *À :*John E Drake <jdrake=[e-mail]
> >>     <mailto:jdrake=[e-mail]>>; BOUCADAIR Mohamed
> >>     TGI/OLN <[e-mail]
> >>     <mailto:[e-mail]>>; Joel M. Halpern
> >>     <[e-mail] <mailto:[e-mail]>>;[e-mail]
> >>     <mailto:[e-mail]>
> >>     *Cc :*Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]
> >>     <mailto:[e-mail]>>
> >>     *Objet :*Re: [Teas] network Slice Endpoint in
> >>     draft-ietf-teas-ietf-network-slice-definition-00____
> >>     __ __
> >>     All,____
> >>     __ __
> >>     In summary I am in agreement for some parts.____
> >>     Please see a few comments inline.____
> >>     __ __
> >>     Reza____
> >>     __ __
> >>     __ __
> >>     __ __
> >>     __ __
> >>     On 2021-02-23, 9:52 AM, "Teas on behalf of John E Drake"
> >>     <[e-mail] on behalf of
> >>     jdrake=[e-mail]
> >>     <mailto:teas-
> [e-mail]%20on%20behalf%20of%20jdrake=[e-mail].
> org>>
> >>     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,____
> >>     __ __
> >>     [Reza] The IETF network slice endpoints (NSE) can  be mapped to
> >>     some virtual or physical interfaces on CE or PE depends on the
> >>     use-case. But the  “IETF network slice endpoints” are not CE or PE
> >>     nodes themselves.
> >
> >     */CE and PE components are as capable of being virtual as any
> >     component currently included in the /**/draft - hence it might be a
> >     littler bit disingenuous to assume that the end points described in
> >     //the////draft////cannot// be part of a CER or PE, because these are
> >     //“//nodes//”// (implying physical devices)./*
> >     */
> >     /*
> >     */If we are defining ed points specifically to
> >     //justify////using////new// terminology, perhaps we could stop
> >     //doing// that? /*
> >
> >>     ____
> >>     We have added more explanation
> >>     to_draft-wd-teas-ietf-network-slice-nbi-yang-02_figure 4 and 5.
> >>     This is the summary.
> >
> >     */It is awkward to have a terminology section, or a definition
> >     /**/draft, that refers to a modeling draft for explanation of the
> >     terms being defined./*
> >
> >>     ____
> >>     __ __
> >>     “IETF network slice endpoints (NSE)” are logical entities which
> >>     can be mapped to interfaces on CE or PE nodes depends on use-case.
> >>     The following pictures show two use-cases where in one NSE are
> >>     mapped to interface on PE nodes and in other one NSE are mapped to
> >>     interface on CE nodes.____
> >>     __ __
> >>     NSE1                                     NSE2____
> >>            (With PE1 parameters)                       (with PE2
> >>     parameters)____
> >>                    o<--------- IETF Network Slice 1 ------->o____
> >>                    +     |                            |     +____
> >>                    +     |<----------- S1 ----------->|     +____
> >>                    +     |                            |     +____
> >>                    +     |    |<------ T1 ------>|    |     +____
> >>                      +   v    v                  v    v   +____
> >>                        + +----+                  +----+ +____
> >>         +-----+    |     | PE1|==================| PE2|
> >>     +-----+____
> >>         |     |----------X    |                  |    |     |    |
> >>     |____
> >>         |     |    |     |    |                  |    X----------|
> >>     |____
> >>         |     |----------X    |                  |    |     |    |
> >>     |____
> >>         +-----+    |     |    |==================|    |     |
> >>     +-----+____
> >>                    AC    +----+                  +----+     AC____
> >>         Customer         Provider                Provider
> >>     Customer____
> >>         Edge 1           Edge 1                  Edge 2           Edge
> >>     2____
> >>     __ __
> >>     __ __
> >>     __ __
> >>     NSE3                                     NSE4____
> >>            (With CE1 parameters)                       (with CE2
> >>     parameters)____
> >>                    o<--------- IETF Network Slice 2 ------->o____
> >>                    +     |                            |     +____
> >>                    +     |<----------- S2 ----------->|     +____
> >>                    +     |                            |     +____
> >>                  +       |    |<------ T2 ------>|    |      +____
> >>                +         v    v                  v    v        +____
> >>              +     AC    +----+                  +----+          +____
> >>         +-----+    |     | PE1|==================| PE2|
> >>     +-----+____
> >>         |     |----------X    |                  |    |     |    |
> >>     |____
> >>         |     |    |     |    |                  |    X----------|
> >>     |____
> >>         |     |----------X    |                  |    |     |    |
> >>     |____
> >>         +-----+    |     |    |==================|    |     |
> >>     +-----+____
> >>                    AC    +----+                  +----+     AC____
> >>         Customer         Provider                Provider
> >>     Customer____
> >>         Edge 1           Edge 1                  Edge 2           Edge
> >>     2____
> >>     __ __
> >>     __ __
> >>       Legend:____
> >>            O: Representation of the IETF network slice endpoints (NSE)____
> >>            +: Mapping of NES to PE or CE nodes on IETF network____
> >>            X: Physical interfaces used for realization of IETF network
> >>     slice____
> >>            S1: L0/L1/L2/L3 services used for realization of IETF
> >>     network slice____
> >>            T1: Tunnels used for realization of IETF network slice____
> >>     __ __
> >>     __ __
> >>     and that we  replace the current figure in Endpoint section with
> >>     several figures, which show connectivity constructs and which are
> >>     consistent with these RFCs. ____
> >>     [Reza] It is fine. Please suggest a figure and it can be included
> >>     in draft____
> >>     __ __
> >>     We would also like to replace 'consumer' with 'customer',____
> >>     [Reza] Fine____
> >>     __ __
> >>     add 'attachment circuit', and add a new term, viz, 'IETF Network
> >>     Slice Service',____
> >>     [Reza] Why new term? This is what it is called “IETF Network Slice”.
> >
> >     */This is not so much a new term as a clarification for the
> >     phrase “IETF Network Slice” when applied to a “service interface./**/”/*
> >     */
> >     /*
> >     */In order to describe a interface generic enough to be applied in
> >     any technology /**/agnostic fashion, we should be defining a
> >     //“//service//”// interface (as is //obvious// from the choice to
> >     describe this in //“//service//”// terms - i.e. - //“service// level
> >     objectives//”//)./*
> >     */
> >     /*
> >     */If we use the phrase //“//IETF Network Slice Service,//”// it is
> >     clearer that we are referring to a
> >     //“//service-based//”// abstraction of any underlying //“//IETF
> >     Network Slice."/*
> >
> >>     ____
> >>     __ __
> >>     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.____
> >>     [Reza] which part of draft are you referring?
> >
> >     */I had not thought this to be too subtle to be grasped by any
> >     observer that has been following the discussion on end point
> >     /**/definitions./*
> >     */
> >     /*
> >     */The primary discussion in the draft is in section 4.2 (/_IETF
> >     Network Slice Endpoints_/). /*
> >     */
> >     /*
> >     */However, the term //“//endpoint//”// appears //quite// often and
> >     is entirely unclear that there is more than one type of endpoint in
> >     almost all cases.  Hence, because we have defined these in a new
> >     way, it is as if we need to refer (at least) to section 4.2 each and
> >     every time we use the term - and clarify which type of endpoint we
> >     are actually using in each case./*
> >     */
> >     /*
> >     */If we were clear that we are referring to //“//IETF Network Slice
> >     Service//”// endpoints, there is a more common term we could use to
> >     describe the relationship between the endpoints and
> >     //the////network// components where they may occur.  A set of terms
> >     that are not only commonly used, but well understood in the
> > industry./*
> >
> >>     ____
> >>     __ __
> >>         Yours Irrespectively,____
> >>     __ __
> >>         Eric and John____
> >>     __ __
> >>     __ — [SNIP] ---__
> >     _______________________________________________
> >     Teas mailing list
> >     [e-mail] <mailto:[e-mail]>
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-
> gk!R0K1vBmEljR9njyi3BUwu2StTK2Kat8VOEVpNlQLTzJAaCM94ikd0TiX5GG5nho$
> >
> > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tea
> > s__;!!NEt6yMaO-
> gk!R0K1vBmEljR9njyi3BUwu2StTK2Kat8VOEVpNlQLTzJAaCM94ikd
> > 0TiX5GG5nho$ >
> >
> >
> >
> > --
> > ___________________________________________
> > Luis M. Contreras
> > [e-mail] <mailto:[e-mail]>
> > [e-mail]
> > <mailto:[e-mail]>
> > Global CTIO unit / Telefonica
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-
> gk!R0K1vBmEljR9njyi3BUwu2StTK2Kat8VOEVpNlQLTzJAaCM94ikd0TiX5GG5nho$