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

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

Hi Eric,

My proposal is to add some text to section 3.2 expressing connectivity intents.

After the third paragraph:
   Consumers normally have limited (or no) visibility into the provider
   network's actual topology and resource availability information.
New text：
Likewise, the transport network may have only limited or no topology information about interconnection of consumer slices.
Therefore, the interconnection needs to be determined by the higher layer system, or is obtained in some preconfigured manner.

My considerations are as follows:
In the example slice service, the gNodeB and UPF use specific addresses to communicate with the transport layer.
1. These  addresses are not allocated by the transport network.
2. If gNodeB or UPF are directly connected with transport network, link addresses may not be used  for communication, though could be learned through standard protocols such as ARP or LLDP.
3. If not directly connected, either via other network nodes or tunnels, still cannot be obtained before the slice service is created.

Thanks,
Bo

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

Bo,

              I have been struggling for some time to understand the point you are making here.

              When we talk about gNB or UPF in the context of a Transport Slice service, the actual RAN and Core node functions are not particularly relevant (i.e. – what they are is not important to the Transport Network).  These are merely names that are mapped in some way to addressable network entities through some form of address lookup or configuration.

              Depending on the technology associated not only with the address of these entities but all lower layer technologies used in connecting to these addressable entities, it is often the case that the transport network endpoints are able to determine not only the connectivity, but the performance of the connection to that addressable entity.

              Usually, when talking about an access link, we are not just talking about the glass, or the copper, connecting the two endpoints of the link; we are also taking about the technology specific components at each endpoint needed to complete the link (e.g. – the Ethernet ports or IP interfaces associated with an Ethernet or IP end-station).

              Every addressable entity (e.g. – Ethernet or IP) is in part an endpoint for the technology used in addressing them.  This applies to a gNB (or – more precisely – to the CU part of a gNB) or UPF as it does to anything else.

              All of which is way too much information to be discussed in this framework document.

              In any case, it is certainly not our intention to restrict applicability of the framework any more than we have to.

              Can you be specific about exactly what text – either already included, or proposed in this discussion – that seems to be problematic?

--
Eric

From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Wubo (lana)
Sent: Thursday, February 27, 2020 3: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]>>; 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

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