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

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

Thanks Med and Joel for the answers.

Noting what you said, and assuming that we are covering not only IP/MPLS
technologies, probably we need to associate the same idea of CE and PE to
technologies where those roles are not commonly associated, such as OTN,
DWDM or wireless / microwave, since all of them can be potential targets of
the IETF Network Slicing realization. Then, if we follow this same
rationale and finally the WG decides to go in this direction, I guess we
need to span the CE and PE conception also to those, maybe explaining this
in the definitions draft. Am I right?

Med, when I was referring to IETF Network Slice of technology X or Y I was
thinking on the realization. So my point here is that in case you have an
IETF Network Slice let's say realized as IP/MPLS, and another one let's say
realized on OTN or DWDM, where the IP/MPLS slice is supported by the
OTN/DWDM slice, can we consider that the CE is IP/MPLS and the PE is
OTN/DWDM? It sounds strange to me.

Best regards

Luis


El mié, 24 feb 2021 a las 7:16, <[e-mail]> escribió:

> 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]>)
> 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]
> <[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]
> https://www.ietf.org/mailman/listinfo/teas
>
>
>
>
> --
>
> ___________________________________________
>
> Luis M. Contreras
>
> [e-mail]
>
> [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.
>
>

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