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

["Joel M. Halpern" <[e-mail]>]

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:[e-mail]%20on%20behalf%20of%20jdrake=[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,____
>>     __ __
>>     [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://www.ietf.org/mailman/listinfo/teas
>     <https://www.ietf.org/mailman/listinfo/teas>
> 
> 
> 
> -- 
> ___________________________________________
> Luis M. Contreras
> [e-mail] <mailto:[e-mail]>
> [e-mail] 
> <mailto:[e-mail]>
> Global CTIO unit / Telefonica