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

["Luis M. Contreras" <[e-mail]>]

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]>) 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] <[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]>; BOUCADAIR
> Mohamed TGI/OLN <[e-mail]>; Joel M. Halpern <
> [e-mail]>; [e-mail]
> *Cc :* Rokui, Reza (Nokia - CA/Ottawa) <[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]> 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]
> https://www.ietf.org/mailman/listinfo/teas
>


-- 
___________________________________________
Luis M. Contreras
[e-mail]
[e-mail]
Global CTIO unit / Telefonica