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

[Eric Gray <[e-mail]>]

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] ---