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

[[e-mail]]

Hi Luis,

Actually, this is all about recursion, service decomposition and manipulating customer/provider ROLES. In all cases, there are reference points delimiting the scope of the slice from both the customer view (we call them, customer edges) and provider view (provider edges).

Nothing prevents that at the realization stage, two PEs can’t be connected. I’m thinking about the example where inter-AS VPN can be used to implement an IETF network slice.

BTW, can you please clarify what do you mean by a “IETF Network Slice of technology X or Y” as slice is technology-agnostic? Thank you.

Cheers,
Med

De : Luis M. Contreras [mailto:[e-mail]]
Envoyé : mardi 23 février 2021 23:46
À : Eric Gray <[e-mail]>
Cc : BOUCADAIR Mohamed TGI/OLN <[e-mail]>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>; John E Drake <jdrake=[e-mail]>; [e-mail]; Joel M. Halpern <[e-mail]>
Objet : Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

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


--
___________________________________________
Luis M. Contreras
[e-mail]<mailto:[e-mail]>
[e-mail]<mailto:[e-mail]>
Global CTIO unit / Telefonica

_________________________________________________________________________________________________________________________

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.