Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

[Eric Gray <[e-mail]>]

Jie,

              I was the one who made the comment, mostly trying to “channel” John Drake.

              Reza responded (vaguely, I have to admit, but accurately) that this is part of what the authors were trying to do with the references to LTP and (in particular) AP (from RFC 8453).

              I re-reading the RFC (which is the ACTN Framework), it includes figures that help to explain this (Figures 12 and 13) – representing customer and operator views of an access service.

              I believe that further explanation is required, but I am not sure that the definitions draft is the place to do that.

--
Eric

From: Teas-ns-dt <[e-mail]> On Behalf Of Dongjie (Jimmy)
Sent: Thursday, June 18, 2020 5:04 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>om>; Shunsuke Homma <[e-mail]>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>om>; Dhruv Dhody <[e-mail]>om>; Luis M. Contreras <[e-mail]>om>; Kiran Makhijani <[e-mail]>om>; Kiran Makhijani <[e-mail]>om>; Jeff Tantsura <[e-mail]>om>; [e-mail]; Shunsuke Homma <[e-mail]>
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi Reza,

Thanks for your proposed text for transport slice endpoints.

From the text I can see the transport endpoint is represented as a logical identifier on the border of the transport slice, while in bullet “They are associated with (hosted by) exactly one application, device, network function (ADN)”, its relationship with application, device, network function is still not quite clear to me. I remember that during last conference call it was suggested some explanation of analogy of endpoints in terms of PE and CE concepts would be helpful. Will you consider that suggestion and provide some text accordingly? Thanks.

Best regards,
Jie

From: Teas-ns-dt [mailto:[e-mail]] On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Thursday, June 18, 2020 12:47 AM
To: Shunsuke Homma <[e-mail]<mailto:[e-mail]>>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[e-mail]<mailto:[e-mail]>>; Dhruv Dhody <[e-mail]<mailto:[e-mail]>>; Luis M. Contreras <[e-mail]<mailto:[e-mail]>>; Kiran Makhijani <[e-mail]<mailto:[e-mail]>>; Kiran Makhijani <[e-mail]<mailto:[e-mail]>>; Jeff Tantsura <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Shunsuke Homma <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi Shunsuke,

I believe the original text was not clear enough and as a result, a few people asked about characteristics of transport slice endpoints.
So, I think it is better  to keep this new version and revise it as needed. Please forward your suggestions.

Cheers,
Reza


From: Shunsuke Homma <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, June 17, 2020 at 11:33 AM
To: Reza Rokui <[e-mail]<mailto:[e-mail]>>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[e-mail]<mailto:[e-mail]>>, Jeff Tantsura <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Kiran Makhijani <[e-mail]<mailto:[e-mail]>>, Kiran Makhijani <[e-mail]<mailto:[e-mail]>>, "Luis M. Contreras" <[e-mail]<mailto:[e-mail]>>, Shunsuke Homma <[e-mail]<mailto:[e-mail]>>, Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi Reza,

This clarification will be very important, but the texts seem too technical and specific  as for definition draft.

In my memory, the original texts provided a classification of transport type endpoints and others (i.e., types of TSRE) for SFC scenarios realized by SFs and transport slices. Transport slices will be realized by several traffic forwarding technologies. Transport type endpoints, such as router and switch, will naturally support forwarding technologies. On the other hand, some service type endpoints won't have the functionalities, and this implies that transport slice framework may require SFs to terminate transport slices with some means. I think this is one of fundamental requirements and should be described in the definition draft.

Therefore, how about returning the section to original text and bringing your text into the framework document?

Best regards,

Shunsuke

2020年6月16日(火) 22:51 Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>:
All,

Following is the modified version of the transport slice endpoint section. Please provide your comments.

Cheers,

Reza


4.2.  Transport slice endpoints

   As discussed in section 3, the transport slice consists of a set of connections between multiple endpoints with a specified connectivity type and one or more SLOs associated with it.

   The transport slice endpoints are the logical identifier to identify the head-end and tail-end points of a transport slice and to perform the forwarding of the user traffic. The characteristics of the transport slice endpoints (TSE) are:

   - They are conceptual point of connection of a network function, device or application to the transport slice.
   - They are logical identifier and requested by the customer of transport slice during the creation of the transport slice
   - They are associated with (hosted by) exactly one application, device, network function (ADN)
   - The cardinality between a TSE and ADN is many:1, i.e. a single device or application can host multiple transport slice endpoints
   -  A TSE is identified by its hosted ADN (its IP address, name , ID etc), TSE unique identifier, TSE unique name and other data. Non-exhaustive list of other data is IP address v4 and v6, VLAN, port, connectivity type (i.e. P2P, P2MP, MP2MP) etc.). TDB to add more

   Note that the concept of the transport slice endpoint is similar to the Link Termination Point (LTP) defined in [draft-ietf-teas-yang-te-topo-18] and access points (AP) defined in [RFC8453] with an important difference. The main difference between them is that both LTP and AP are associated to traffic engineering (TE) whereas TSE is not. In other words. the AP (See section 2.1 RFC8453) is a common identifier for the TE link and LTP is a conceptual point of connection of a TE node to one of the TE links, terminated by the TE node (see section 3.5 draft-ietf-teas-yang-te-topo-18) whereas TSE is a logical head-end and tail-end of the transports slice connections. The TE characteristic of the network might be taken into consideration during the realization of a transport slice.

   There is another type of the endpoints called "Transport Slice Realization endpoints (TSRE)". These endpoints are allocated  and assigned by the network controller during the realization of a transport slice and are technology-specific, i.e. they depends on the network technology which is used during the transport slice realization. They are identified by a hosted node and some associated data. A non-exhaustive list of devices containing TSRE are routers, switches, firewalls, WAN, application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header enrichment functions, and TCP optimizers

4.2.1.  Connectivity patterns within Transport Slice

   The transport slices are a set of connections among the set of  endpoints.  These connections can be point to point (P2P), point to
   multipoint (P2MP), multi-point to point (MP2P), or multi-point to  multi-point (MP2MP) based on the connectivity type requested by the customer.