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

[Young Lee <[e-mail]>]

Sorry. I meant DC networks that host "core network functions".

2021년 2월 24일 (수) 오후 7:22, Young Lee <[e-mail]>님이 작성:

> Hi,
>
> This is an interesting discussion. I am now in the mobile side and
> reconginize that there are a number of scenarios that may need transport
> network slices (which is now called IETF network slices). For instance,
> possibly slices may be needed in the fronthaul, midhaul and backhaul as
> well as within DC networks that host the functions. Other than backhaul
> networks, the terms CE and PE may not be adequate because for the
> aforementioned transport networks except the backhaul, CE and PE
> terminology would not easily apply. For each of the aforementioned
> transport subnetworks, I think using slice endpoints makes more sense.
>
> In other words, I agree with Luis on this point.
>
> My two cents,
> Young
>
>
> 2021년 2월 24일 (수) 오후 7: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
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>