Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

["Wubo (lana)" <[e-mail]>]

Hi Eric,

Sorry, it was my mistake to mislead you.  My suggestion is as follows:
1. The TS endpoint needs a clear definition.  It is recommended that this definition is consistent in both framework and definition draft.
2.  During the interaction between the TSC and the High layer system, the two types of identifying the TS endpoint are described.

Thanks,
Bo

发件人: Eric Gray [mailto:[e-mail]]
发送时间: 2020年2月28日 23:43
收件人: Wubo (lana) <[e-mail]>om>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>om>; John E Drake <[e-mail]>et>; Dongjie (Jimmy) <[e-mail]>om>; Jari Arkko <[e-mail]>om>; [e-mail]
主题: RE: Pull-request #8: Reza’s proposed text addition to the controller section

I was not actually aware that Reza was proposing an update to his text, as opposed to a “summary” explanation for what he had earlier proposed.

From: Wubo (lana) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, February 28, 2020 2:40 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>; John E Drake <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Eric Gray <[e-mail]<mailto:[e-mail]>>; Jari Arkko <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section
Importance: High

I agree with Reza's updated text. It is clear to me.  Thanks!

B.R.
Bo
发件人: Rokui, Reza (Nokia - CA/Ottawa) [mailto:[e-mail]]
发送时间: 2020年2月28日 4:57
收件人: Wubo (lana) <[e-mail]<mailto:[e-mail]>>; John E Drake <jdrake=[e-mail]<mailto:jdrake=[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Eric Gray <eric.gray=[e-mail]<mailto:eric.gray=[e-mail]>>; Jari Arkko <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
抄送: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
主题: Re: Pull-request #8: Reza’s proposed text addition to the controller section

Thanks Bo, John, Jimmy and Eric.

The comment given by Bo is the closest one to whatever I’ve intended to include in Framework draft.

In summary:

-          As indicated by Bo, the Endpoints coming to TSC from its NBI, is shown below. Either one is acceptable.


-          Note that in my original example, CE1 is gNB1 and CE2 is UPF1. Also PE1 and PE2 are ER1 and ER2, respectively.


-          Endpoints are NOT the network elements but rather their APs (as defined in RFC 8453)


-          If endpoints are CE1.x  and CE2.z (left picture), when TSC receives the request to create a transport slice between CE1.x and CE2.z, it will find the PE1.w and PE2.y and initiate creation of  L0-L3 services/paths/tunnels between them to realize transport slice. The reason is that neither CE1 nor CE2 supports services/paths/tunnels


-          If endpoints are PE1.w and PE2.y (right picture), when TSC receives the request to create a transport slice between PE1.w and PE2.y, since network elements PE1 and PE2 supports services/tunnels/paths, TSC will initiate creation of  L0-L3 services/paths/tunnels between them to realize transport slice.


-          Again as indicated by Bo, both cases shall be supported by TSC NBI. We should not favor one vs. other one. In other words, Framework draft should mention both as potential supported cases.

[cid:image001.png@01D5EF0B.19C02840]     [cid:image002.png@01D5EF0B.19C02840]



Reza Rokui, Ph.D.
Director, NSP Product Management
Nokia Canada
IP/Optical Network Automation
T:  [phone]
M: [phone]
600 March Road, Kanata, Ontario, K2K 2E6
[e-mail]<mailto:[e-mail]>


From: "Wubo (lana)" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 27, 2020 at 11:53 AM
To: John E Drake <jdrake=[e-mail]<mailto:jdrake=[e-mail]>>, "Dongjie (Jimmy)" <[e-mail]<mailto:[e-mail]>>, Eric Gray <eric.gray=[e-mail]<mailto:eric.gray=[e-mail]>>, Reza Rokui <[e-mail]<mailto:[e-mail]>>, Jari Arkko <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section

Hi John, Eric,

I don't agree regarding the definition of endpoint and the endpoint parameters to be carried to the TSC.

Taken Reza’s example, also referenced by Eric:
                                                  +----+
                      .----.                       +UPF1|
    [gNB1] +----+    (      )---.                 /+--=-+
         \ |    |===========================[ER2]+
          \| ER1|  (      Network       )          +----+
          /|    |===========================[ER3]+-|UPF2|
         / +----+    `----------------'         +  +----+
    [gNB2]                                       \
                                                  \+----+
                                                   +UPF3|
                                                   +----+
    Legends
      === : Tunnels & Services
      ER: Edge Router

1.endpoint definition
The gNB and the UPF are not part of the transport network.
Only the assess links connected to these devices are shared with the transport network.
The RFC8453(ACTN framework) defines the access point to identify the boundary. I think perhaps we can use a similar definition.

Access Point (AP): An AP is a logical identifier shared between the customer and the operator used to identify an access link.
        The AP is used by the customer when requesting a VNS(Virtual Network Service).

2.endpoint parameters definition
I think there are two possible ways to carry different parameters based on the functionality of the higher-level system and TSC.

1). A higher-level system maintains an NNI connection topology of RAN, core, and transport network.
Therefore, after the slice instance is created in the RAN and the core, ‘provider edge (PE)’ device can be found by the higher-level system,
so it will use endpoints to carry PE access information to the TSC to create the transport slice.

2). The transport network maintain the connection topology with the RAN and the core.
 Therefore, the higher-level system will use endpoints parameters associated with CE or wireless devices to the TSC.

I think the framework should not have only one option.

Thanks,
Bo

发件人: Teas-ns-dt [mailto:[e-mail]] 代表 John E Drake
发送时间: 2020年2月27日 3:20
收件人: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Eric Gray <eric.gray=[e-mail]<mailto:eric.gray=[e-mail]>>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>; Jari Arkko <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
主题: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

Hi,

As I indicated in an email yesterday, I agreed with Eric’s point :

In another view (or way of looking at it), the higher-level entity asks the TSC to connect two or more addressable entities providing both connectivity and SLO parameters, where (at least from the perspective of the higher-level entity, the service terminates at each of the addressable entities included in the request to the TSC.  In this view, the links connecting any ER in the transport service  to the specific entities are part of the requested service – hence any edge router involvement is within the service, not a termination point for the service.  Also, in this view, “finding” the appropriate edge router is not any different from finding the path (or route) for the connection.  This applies during creation of, maintenance or and deletion of the Slice – hence this view is actually the simplest one to use in discussion.  Also note that this view may be significantly more correct, in any case where any specific connected entity may be reached via more than one link.

In other words a transport slice endpoint is always a tenant device (or in IETF terminology a ‘customer equipment (CE)’ device) and the services provided to that transport slice endpoint (e.g., VPNs, service chains, or 5G specific functions) are part of the service definition for that transport slice endpoint.  So, the two types of endpoints defined in section 5.2.1 are actually within the transport slice provider’s network and are not visible outside of it, and section 5.2.1 is incorrect as currently written.

These functions may either be located entirely within the ‘provider edge (PE)’ device (IETF terminology) to which a transport slice endpoint is attached or distributed between the PE and other nodes within the tenant slice provider’s network.  (As an aside I don’t think the functionality associated with ‘transport type endpoint’ actually exists because at a very minimum a packet needs to be tagged with the tenant identifier (or in IETF terminology the ‘VPN identifier’.)

To answer Jimmy’s point, below,  we could state that a given tenant has the option of supplementing the services provided by a transport slice with services of its own.  However, the devices providing these supplemental services are attached to a transport slice as transport slice endpoints and that the transport slice provider is completely unaware of them.  In IETF terminology a device providing such services is a ‘Customer-Provider Edge (C-PE)’ device.

Yours Irrespectively,

John



Juniper Business Use Only
From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, February 26, 2020 7:33 AM
To: Eric Gray <eric.gray=[e-mail]<mailto:eric.gray=[e-mail]>>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>; Jari Arkko <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

Agree that some explanation about the terms would be needed.

It seems a little odd that the “transport slice endpoints” refers to the nodes “gNB, UPF…” which are outside the transport domain, while the “service endpoints” are actually the nodes which are the border nodes of the transport network.

Best regards,
Jie

From: Teas-ns-dt [mailto:[e-mail]] On Behalf Of Eric Gray
Sent: Tuesday, February 25, 2020 10:40 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>; Jari Arkko <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

I agree that more explanation is needed somewhere.  For one thing, we need to agree on the definition for “Service Endpoints” (and whether ot not they are – or can be – distinct from slice end points.

I suspect that this needs to be handled in the definitions draft.  See also my detailed comments in separate mail – which address a disconnect in the figure you used in your explanation…

From: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 25, 2020 8:45 AM
To: Jari Arkko <[e-mail]<mailto:[e-mail]>>; Eric Gray <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section
Importance: High

Jari,
My response is inline.

Reza



From: Jari Arkko <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 25, 2020 at 11:20 AM
To: Reza Rokui <[e-mail]<mailto:[e-mail]>>, Eric Gray <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section

FWIW, I’m happy with the conclusions your Reza and Eric drew. But this one requires further thinking:

    * Using the network abstract topology, it provides mechanism to find
      the Service endpoints (these are technology specific).
      (TODO: this seems unclear. What endpoints are these, are why
      are they different from endpoints discussed earlier?)

EG > Obviously.  IMO, the requesting application (higher-level controller, for example) MUST specify the end-points for the transport service, at least using some abstraction (e.g. – name), and the precise technology of the connecting interface.  This is fairly obvious as the request is based on some knowledge about what is connecting to the Transport Slice at each end that the TSC controller cannot know a priori.  Since this information MUST be in the “API” request, there should be nothing for the TSC to “discover.”

Rewording:

  *   Provides requested services and endpoint connectivity.

[Reza] Modified rewording:

  *   Using the abstract topology of the interconnected networks and provided transport slice endpoints , it will find the Service endpoints.

Explanation:
The concept is shown in our  original Definition draft which later has been removed due to number of pages of the draft to be included in framework draft (or other drafts).
This picture is for 5G use-case but demonstrates the idea.
In summary, the transport slice request is between “transport slice endpoints” gNB1, gNB2, UPF1, UPF2 and UPF3 where the realization of this transport slice is between “service endpoints” ER1, ER2 and ER3.
So, it is clear that the “transport slice endpoints” are different from  “service endpoints”.

Jari: I think this is still confusing, at least to me. From what I can understand there needs to be two things:


  *   At the NBI, the requester needs to tell the controller what endpoints it wants the transport slice to be connecting. This I think we already say. So, for instance, I want this virtual ethernet in this computer connected with a transport slice Slice1 at 10 gbit/s with another virtual ethernet in that other computer.
  *   The controller needs to maintain an internal mapping of how a given slice is realized, so that, for instance, Slice1 in the first computer corresponds to VLAN 123 on physical interface ethx on that computer, switch configuration for VLAN 123, and again VLAN 123 and physical interface ethy on the second computer.

But I’m confused whether your text above talks about the first or the second bullet. In fact it seems to talk about some other function, where the controller somehow analyses abstract topologies to find some endpoints… why? Sorry, maybe not enough caffeinated drinks this morning but I don’t understand ☹

Maybe this would work better:

The controller maintains the connections of the transport slice to the endpoints specified by the consumer. In addition, it will keep track of how communication from those endpoints is mapped to specific underlying components of the realization of the transport slice (such as VPN tunnel endpoints or MPLS labels).

[Reza] It is mainly option 2 above. I am fine with your text Jari but it definitely needs more explanations somewhere either in this draft or other drafts. This is basically related to Section-6 of the original Definition draft which was removed. At that time we wanted to include them in Framework draft.

Jari