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

[Shunsuke Homma <[e-mail]>]

Hi Reza,

Thank you for your reply.
My concern was that the texts seem too detailed compared with explanations
of  other entities such as TSC. (e.g., Regarding TSC, definition draft
describes overview and the details are explained in framework draft.)

Also, I think it is a special point of transport slice that SFs excluding
forwarding functions would be endpoints, and it should be emphasized.


While, I agree that this clarification will be helpful, and I'm OK with the
new text if there are no objections from other NS-DT members.


BTW, I have one more comment on  your proposed definition. I understood
that  TSE and TSRE indicate the same one, i.e., TSE is endpoint from
customer/orchestrator view point, and TSRE is one from TNC perspective. Is
it correct? If so, I'm not sure if we should define "TSRE" as  a new term.
I assume that, in realization of transport slice, a TSE would be mapped to
an existing identifier (e.g., router-id) and the related parameters by a
TSC. For example, can the paragraph about TSRE be replaced to the following
text?


"A TSE is mapped to a technology-specific node-id and its configuration
parameters during the  realization of transport slice. A non-exhaustive
list of  node type which would be TSE are routers, switches ..."


Best regards,

Shunsuke




2020年6月18日(木) 0:33 Shunsuke Homma <[e-mail]>om>:

> 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]
> >:
>
>> 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.
>>
>>
>>
>>
>>
>