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

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 16 Jun 2020 13:51:01 +0000

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.

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 16 Jun 2020 18:08:14 +0000

All,

Cheers,

Reza

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 17 Jun 2020 09:27:19 +0000

Hi Reza,
Some comments on line and suggested rewording

Thanks
Sergio

From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Tuesday, June 16, 2020 8:08 PM
To: [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

All,

Cheers,

Reza

SB> I would say “provided” : the customer should know what is the logical identifier from which want to start/terminate his TS right?

   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.
SB> I clearly see the similarity with AP, but I would delete the relation with LTP since LTP is not a “logical” identifier, is a real termination point of a TE link terminating on a specific node. LTP is mapped to a local or remote link identifier (see RFC 3630). In the VN YANG model, an LTP is the VN-AP related termination point on the TE node . So it is clearly distinguished by AP and specific VN-AP.
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 a logical identifier shared between customer and provider to identify an access 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.

---

From: Shunsuke Homma <[email-masked]>
Date: Thu, 18 Jun 2020 00:33:46 +0900

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) <[email-masked]>:

>    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 logical identifier and requested by the customer of
> transport slice during the creation of the transport slice
>
>    - 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
>
>
>
>    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.
>
>
>
>
>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 17 Jun 2020 16:47:00 +0000

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 <[email-masked]>
Date: Wednesday, June 17, 2020 at 11:33 AM
To: Reza Rokui <[email-masked]>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>, Jeff Tantsura <[email-masked]>, "[email-masked]" <[email-masked]>, Kiran Makhijani <[email-masked]>, Kiran Makhijani <[email-masked]>, "Luis M. Contreras" <[email-masked]>, Shunsuke Homma <[email-masked]>, Dhruv Dhody <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>>:
All,

Cheers,

Reza

---

From: Eric Gray <[email-masked]>
Date: Wed, 17 Jun 2020 20:40:07 +0000

Hey, Reza.

A few, mostly minor, points:

The first sentence may have things reversed slightly.

Current wording: 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.

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

Between connections and SLOs, the connections is the part that cannot be an empty set.

The second sentence is worded awkwardly.  The phrase “logical identifier to identify“ is a little circular (actually, the entire sentence is circular, since “transport slice endpoints” is semantically the same as “[endpoints] of a transport slice” – hence the sentence is tautological, but probably that is okay).

Also, “forwarding” presumably happens within the slice, as well as at the end points.  What makes the endpoints different, is that – if there is any format, or encapsulation, adaptation required for packets being forwarded across a transport slice – this will be done at the transport slice endpoints.

Suggested re-wording:    The transport slice endpoints are the logical entities identified as the head-end, and tail-end, points of a transport slice that perform any required conversion, or adaptation, and forwarding of the user traffic. The characteristics of the transport slice endpoints (TSE) are:

With the bullets:

  *   1st bullet – “They are conceptual points …”, or “Each is a conceptual point …” (number agreement).
  *   2nd bullet – “They are associated with a logical identifier requested …” (existing wording is awkward, as well as grammatically incorrect).  Note – I believe this is what the authors intend, but it is not terribly clear in this wording how these “logical identifiers” are known in common between the requester and responder (which must be the case).  Perhaps an example should be provided?
Alternatively “They are logically identified in a request … .”
  *   3rd bullet – I cannot make this one out; why “exactly one?” Is it “application, device, or network function (ADN)” or “application, device, and network function (ADN)” and – if the latter – I would have to disagree as exactly how a transport slice is used by a requester should be entirely up to them (and both application and network function tend to negate this).
  *   4th bullet – similar issue as with 3rd bullet; i.e. – the relationship between TSE and ADN (if ADN means “application, device and network function” – then the relationship could be M:N).  Note that – in all of the last three bullets – it is not at all clear what is meant by “host,” “hosted” or “hosted by” (my impression is that what is meant is the protocol stack presented by the TSE, but – if this is the intention, there are role reversals in the wording of at least one of the bullets).
  *   5th bullet – multiple issues –

.             If the meaning of ADN is as speculated above, “hosted” should probably be “hosting.” In any case, this reverses the sense of the hosting relationship described in the 3rd and 4th bullets.

.             A better wording for the start of the second sentence in this bullet is “A non-exhaustive list of other data includes IP address (v4 or v6), …”

.             “TSE unique identifier“ might benefit from an example – i.e. – “TSE unique identifier (e.g. – logical interface identifier).”

.             I am fairly certain that we would be better off omitting “connectivity type (i.e. P2P, P2MP, MP2MP) etc.)” as this could be considered part of “TDB to add more” and it is not clear what value this adds (i.e. – it would be optional at best).

Next paragraph – multiple issues:

  *   1st sentence in the paragraph: “the concept” seems to introduce a disconnect, since we follow this paragraph with another paragraph that seems to be introducing a different conceptual model.  Perhaps it should be “this concept” (referring to the description of a TSE in the previous
  *   The draft referred to for “Link Termination Point” is seriously out of date (instead of draft-ietf-teas-yang-te-topo-18 - it is currently draft-ietf-teas-yang-te-topo-22 – xml2rfc should have fixed that).
  *   The statement (2nd sentence) – The main difference between them is that both LTP and AP are associated to traffic engineering (TE) whereas TSE is not – is (I believe) misleading; it is quite likely that a packet switching transport slice implementation will use Traffic Engineering to create tunnels with tunnel ingress and egress internally terminated at a transport slice endpoint.  I strongly suspect that – for some implementations – a transport slice endpoint may be exactly the same as an LTP or AP.  I suggest replacing the above text with something along the lines of “While the transport slice concept includes potential realizations not based on traffic engineering,  for some subset of transport slice realizations, a TSE may be an LTP or AP.”
  *   With this change, the next sentence should start with “An AP …” instead of “In other words. The AP …“
  *   The same sentence would then end with “… transport slice connections, which may or may not include one or more TE links” instead of “… transports slice connections.“

Next Paragraph:

  *   The last sentence (“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”) talks about a list of “devices” while many/most of the list members are not devices.  It is non-trivial to come up with a different word for the thing where a TSRE resides – especially while trying to avoid a circular definition.  Maybe “virtual device or function?”

The rest of the proposal is okay.

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Tuesday, June 16, 2020 9:51 AM
To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Shunsuke Homma <[email-masked]>; Jeff Tantsura <[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Luis M. Contreras <[email-masked]>; Shunsuke Homma <[email-masked]>; Dhruv Dhody <[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

All,

Cheers,

Reza

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

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 17 Jun 2020 14:13:07 -0700

Hi Eric,

Thanks for your comments and please see in-line

Cheers,
Jeff
On Jun 17, 2020, 1:40 PM -0700, Eric Gray <[email-masked]>, wrote:
> [jeff] agreed
> [jeff] I’d avoid “logical”
>
> With the bullets:
>
> • 1st bullet – “They are conceptual points …”, or “Each is a conceptual point …” (number agreement).
> • 2nd bullet – “They are associated with a logical identifier requested …” (existing wording is awkward, as well as grammatically incorrect).  Note – I believe this is what the authors intend, but it is not terribly clear in this wording how these “logical identifiers” are known in common between the requester and responder (which must be the case).  Perhaps an example should be provided?
> • 3rd bullet – I cannot make this one out; why “exactly one?” Is it “application, device, or network function (ADN)” or “application, device, and network function (ADN)” and – if the latter – I would have to disagree as exactly how a transport slice is used by a requester should be entirely up to them (and both application and network function tend to negate this).
> • 4th bullet – similar issue as with 3rd bullet; i.e. – the relationship between TSE and ADN (if ADN means “application, device and network function” – then the relationship could be M:N).  Note that – in all of the last three bullets – it is not at all clear what is meant by “host,” “hosted” or “hosted by” (my impression is that what is meant is the protocol stack presented by the TSE, but – if this is the intention, there are role reversals in the wording of at least one of the bullets).
> • 5th bullet – multiple issues –
>
> [jeff] agreed
> [jeff] disagree, this is an enumeration of connectivity types that are exposed to the consumer and are available to be requested , I’d remove “etc”, there's nothing to add
> • 1st sentence in the paragraph: “the concept” seems to introduce a disconnect, since we follow this paragraph with another paragraph that seems to be introducing a different conceptual model.  Perhaps it should be “this concept” (referring to the description of a TSE in the previous
> • The draft referred to for “Link Termination Point” is seriously out of date (instead of draft-ietf-teas-yang-te-topo-18 - it is currently draft-ietf-teas-yang-te-topo-22 – xml2rfc should have fixed that).
> • The statement (2nd sentence) – The main difference between them is that both LTP and AP are associated to traffic engineering (TE) whereas TSE is not – is (I believe) misleading; it is quite likely that a packet switching transport slice implementation will use Traffic Engineering to create tunnels with tunnel ingress and egress internally terminated at a transport slice endpoint.  I strongly suspect that – for some implementations – a transport slice endpoint may be exactly the same as an LTP or AP.  I suggest replacing the above text with something along the lines of “While the transport slice concept includes potential realizations not based on traffic engineering,  for some subset of transport slice realizations, a TSE may be an LTP or AP.”
> • With this change, the next sentence should start with “An AP …” instead of “In other words. The AP …“
> • The same sentence would then end with “… transport slice connections, which may or may not include one or more TE links” instead of “… transports slice connections.“
>
> [jeff] agreed
> Next Paragraph:
>
> • The last sentence (“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”) talks about a list of “devices” while many/most of the list members are not devices.  It is non-trivial to come up with a different word for the thing where a TSRE resides – especially while trying to avoid a circular definition.  Maybe “virtual device or function?”
>
> [jeff] function sounds as a good choice (covers both virtual and physical)
>

---

From: Shunsuke Homma <[email-masked]>
Date: Thu, 18 Jun 2020 23:25:41 +0900

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 <[email-masked]>:

> Hi Reza,
>
> This clarification will be very important, but the texts seem too
> technical and specific  as for definition draft.
>
> 2020年6月16日(火) 22:51 Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]
> >:
>
>> All,
>>
>>
>>
>>    - They are conceptual point of connection of a network function,
>> device or application to the transport slice.
>>
>>    - The cardinality between a TSE and ADN is many:1, i.e. a single
>> device or application can host multiple transport slice endpoints
>>
>>    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.
>>
>>
>>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 18 Jun 2020 09:03:30 +0000

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

Hi Shunsuke,

Cheers,
Reza

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

Hi Reza,

Best regards,

Shunsuke

Cheers,

Reza

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 18 Jun 2020 20:17:56 +0000

Hey Eric and Jeff,

See inline for my comments.
I have incorporated the changes and also modified the text. This is the second version of the text.

Reza

---------------------------------- 2nd version of the Endpoint Text -------------------------------------------------------
4.2.  Transport slice endpoints

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

The transport slice endpoints are the logical entities identified as the head-end and tail-end points of a transport slice that perform any required conversion, or adaptation, and forwarding of the user traffic. The characteristics of the transport slice endpoints (TSE) are:

   - They are conceptual points of connection of a network function, device or application to the transport slice.
   - They are logically identified in a request by the customer of transport slice during the creation of the transport slice
   - They are associated with one application, device and/or network function (ADN). A non-exhaustive list of ADN nodes are 5G RAN nodes, 5G Core nodes, routers, switches, firewalls, WAN, application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header enrichment functions, and TCP optimizers.
   - A TSE is identified by its ADN (its IP address, name , ID etc), TSE unique identifier (e.g. logical interface identifier), TSE unique name and other data. A non-exhaustive list of other data includes IP address (v4 or v6), VLAN, port, connectivity type P2P, P2MP, MP2MP). TDB to add more

Note that this concept is similar to the Link Termination Point (LTP) defined in [draft-ietf-teas-yang-te-topo-22] 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. 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 node and some associated data. A non-exhaustive list of nodes containing TSRE are routers, switches, PON nodes, Wireless nodes and Optical devices.

Note that there will be a mapping between TSE and TSRE on Transport Slice Controller (TSC). When TSC receives a request from its NBI to create a transport slice between multiple TSEs, it will then find the appropriate TSREs and send the request from its SBI to realize the transport slice. The detail of this mapping should be address in Transport slice framework document.

Figure-X shows an example of a transport slice and its realization between multiple TSEs and TSREs.

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )
   ----------  TSRE1  --------                  -------- TRSE2     ---------
   |      o |--------o|  A   |                  |  B   |o----------| o     |
   |    TSE1|         --------                  --------           | TSE2  |
   ----------            (                         )               ---------
                          (                       )
                           (--------------------)

           <--------------------------------------------------------->
                Transport slice between TSE1 and TSE2 with SLO1

                      <================================>
                         Transport slice realization
                           between TSRE1 and TRSE2

Figure X: A transport slice and its realization between multiple TSEs and TSREs
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.

From: Jeff Tantsura <[email-masked]>
Date: Wednesday, June 17, 2020 at 5:13 PM
To: Reza Rokui <[email-masked]>, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>, Shunsuke Homma <[email-masked]>, Kiran Makhijani <[email-masked]>, Kiran Makhijani <[email-masked]>, "Luis M. Contreras" <[email-masked]>, Shunsuke Homma <[email-masked]>, Dhruv Dhody <[email-masked]>, Eric Gray <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi Eric,

Cheers,
Jeff

Hey, Reza.

[Reza] Agreed

[Reza] Agreed

With the bullets:

[Reza] used the former

[Reza] Agreed

[Reza] the latter one.

  *   4th bullet – similar issue as with 3rd bullet; i.e. – the relationship between TSE and ADN (if ADN means “application, device and network function” – then the relationship could be M:N).  Note that – in all of the last three bullets – it is not at all clear what is meant by “host,” “hosted” or “hosted by” (my impression is that what is meant is the protocol stack presented by the TSE, but – if this is the intention, there are role reversals in the wording of at least one of the bullets).
[Reza] Removed all instances of hosted, hosting

[jeff] agreed
[Reza] Agreed

.             I am fairly certain that we would be better off omitting “connectivity type (i.e. P2P, P2MP, MP2MP) etc.)” as this could be considered part of “TDB to add more” and it is not clear what value this adds (i.e. – it would be optional at best).
[jeff] disagree, this is an enumeration of connectivity types that are exposed to the consumer and are available to be requested , I’d remove “etc”, there's nothing to add
[Reza] Agreed with Jeff. I kept them.

  *   1st sentence in the paragraph: “the concept” seems to introduce a disconnect, since we follow this paragraph with another paragraph that seems to be introducing a different conceptual model.  Perhaps it should be “this concept” (referring to the description of a TSE in the previous
  *   The draft referred to for “Link Termination Point” is seriously out of date (instead of draft-ietf-teas-yang-te-topo-18 - it is currently draft-ietf-teas-yang-te-topo-22 – xml2rfc should have fixed that).
  *   The statement (2nd sentence) – The main difference between them is that both LTP and AP are associated to traffic engineering (TE) whereas TSE is not – is (I believe) misleading; it is quite likely that a packet switching transport slice implementation will use Traffic Engineering to create tunnels with tunnel ingress and egress internally terminated at a transport slice endpoint.  I strongly suspect that – for some implementations – a transport slice endpoint may be exactly the same as an LTP or AP.  I suggest replacing the above text with something along the lines of “While the transport slice concept includes potential realizations not based on traffic engineering,  for some subset of transport slice realizations, a TSE may be an LTP or AP.”
[Reza] disagree. In this text we are not talking about the transport slice realization where your text is valid. See the 2nd version of the text above.

  *   The last sentence (“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”) talks about a list of “devices” while many/most of the list members are not devices.  It is non-trivial to come up with a different word for the thing where a TSRE resides – especially while trying to avoid a circular definition.  Maybe “virtual device or function?”
[jeff] function sounds as a good choice (covers both virtual and physical)
[Reza] I have changed this section. See the 2nd version of the text above.

--
Eric

All,

Cheers,

Reza

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 18 Jun 2020 20:15:10 +0000

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

Hey, Reza.

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 18 Jun 2020 20:16:55 +0000

Hi Jie,
Please see the second version of the endpoint text posted in another email thread. I clarify it and added a figure as well.

Reza Rokui, Ph.D.
Director, NSP Product Management
Nokia Canada
IP/Optical Network Automation
T:  +1-613-784-1762
M: +1-613-979-6986
600 March Road, Kanata, Ontario, K2K 2E6
[email-masked]<mailto:[email-masked]>

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thursday, June 18, 2020 at 5:03 AM
To: Reza Rokui <[email-masked]>, Shunsuke Homma <[email-masked]>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>, Dhruv Dhody <[email-masked]>, "Luis M. Contreras" <[email-masked]>, Kiran Makhijani <[email-masked]>, Kiran Makhijani <[email-masked]>, Jeff Tantsura <[email-masked]>, "[email-masked]" <[email-masked]>, Shunsuke Homma <[email-masked]>
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi Reza,

Best regards,
Jie

Hi Shunsuke,

Cheers,
Reza

Hi Reza,

Best regards,

Shunsuke

Cheers,

Reza

---

From: Eric Gray <[email-masked]>
Date: Thu, 18 Jun 2020 20:24:56 +0000

Okay.

From: Jeff Tantsura <[email-masked]>
Sent: Wednesday, June 17, 2020 5:13 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Shunsuke Homma <[email-masked]>; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Luis M. Contreras <[email-masked]>; Shunsuke Homma <[email-masked]>; Dhruv Dhody <[email-masked]>; Eric Gray <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"
Importance: High

Hi Eric,

Cheers,
Jeff
On Jun 17, 2020, 1:40 PM -0700, Eric Gray <[email-masked]<mailto:[email-masked]>>, wrote:

Hey, Reza.

With the bullets:

[jeff] agreed

--
Eric

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

All,

Cheers,

Reza

---

From: Eric Gray <[email-masked]>
Date: Thu, 18 Jun 2020 20:34:09 +0000

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

Hi Reza,

Best regards,
Jie

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

Hi Shunsuke,

Cheers,
Reza

Hi Reza,

Best regards,

Shunsuke

Cheers,

Reza

---

From: Kiran Makhijani <[email-masked]>
Date: Thu, 18 Jun 2020 23:02:09 +0000

Hi Reza,
Minor nits. Sorry I am bit late. Up to you if you want to take them, but may simplify further.

  1.  The first para/stmt  “As discussed..” is no of no value, can be removed.
  2.  Second bullet “They are logically identified..” is not needed. It is explicitly said in the definition.
  3.  More serious problem is with the ADNs. I think combination of ADN and TSRE can confuse the reader, better to remove it. Can we not simply say:

A TSE is associated with a device, an application, and/or network function node. A non-exhaustive list of such nodes includes 5G RAN nodes, 5G Core nodes, routers, switches, firewalls, WAN, application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header enrichment functions, and TCP optimizers.

From: Teas-ns-dt <[email-masked]> on behalf of "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thursday, June 18, 2020 at 1:18 PM
To: Jeff Tantsura <[email-masked]>, Eric Gray <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

Hey, Reza.

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: Eric Gray <[email-masked]>
Date: Fri, 19 Jun 2020 14:26:49 +0000

Kiran, and Reza,

              See in-line below…

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of Kiran Makhijani
Sent: Thursday, June 18, 2020 7:02 PM
To: [email-masked]
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi Reza,

Point number 3 might not be viewed as a minor NIT, precisely.  😊

  1.  The first para/stmt  “As discussed..” is no of no value, can be removed.
So, you are suggesting the text should begin with “A Transport Slice consists of …” – correct?  Or are you suggesting the entire statement should be removed?

  1.  Second bullet “They are logically identified..” is not needed. It is explicitly said in the definition.
Here, I do not understand what you are suggesting; are you saying the entire bullet should be removed?

  1.  More serious problem is with the ADNs. I think combination of ADN and TSRE can confuse the reader, better to remove it. Can we not simply say:

A TSE is associated with a device, an application, and/or network function node. A non-exhaustive list of such nodes includes 5G RAN nodes, 5G Core nodes, routers, switches, firewalls, WAN, application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header enrichment functions, and TCP optimizers.
We do not use the acronym “ADN" elsewhere in the draft – at least in the latest text version I see in GitHub.  Also, it is incredibly difficult to sneak this acronym past most spell checkers.  So I think Kiran has a good point – i.e. – why do we introduce the acronym here, and what value does it serve?

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> on behalf of "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 18, 2020 at 1:18 PM
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, Eric Gray <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

From: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 17, 2020 at 5:13 PM
To: Reza Rokui <[email-masked]<mailto:[email-masked]>>, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>, Shunsuke Homma <[email-masked]<mailto:[email-masked]>>, Kiran Makhijani <[email-masked]<mailto:[email-masked]>>, Kiran Makhijani <[email-masked]<mailto:[email-masked]>>, "Luis M. Contreras" <[email-masked]<mailto:[email-masked]>>, Shunsuke Homma <[email-masked]<mailto:[email-masked]>>, Dhruv Dhody <[email-masked]<mailto:[email-masked]>>, Eric Gray <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi Eric,

Cheers,
Jeff

Hey, Reza.

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: Kiran Makhijani <[email-masked]>
Date: Fri, 19 Jun 2020 14:38:22 +0000

Hi Eric,
The answers to both 1 and 2 are yes and yes.

From: Eric Gray <[email-masked]>
Sent: Friday, June 19, 2020 7:27 AM
To: Kiran Makhijani <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Kiran, and Reza,

              See in-line below…

--
Eric

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Kiran Makhijani
Sent: Thursday, June 18, 2020 7:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi Reza,

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

Hey, Reza.

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: Eric Gray <[email-masked]>
Date: Fri, 19 Jun 2020 15:22:19 +0000

Reza,

I believe I have done a reasonably thorough re-review of the modified text.  Hopefully I caught any remaining issues below…

A minor NIT: there is a close paren after “P2P, P2MP, MP2MP” without a matching open paren.  I assume it is meant to be “(P2P, P2MP, MP2MP)”…

Also, while I didn’t explicitly comment on it previously, “TDB” is probably supposed to be “TBD” (4th bullet).

Other issues:
Jeff had suggested avoiding the use of “logical” in the 2nd paragraph (“… transport slice entities are the logical identifiers …”), and it looks like you agreed – yet it is still there.

It does not look as if you addressed my concern about distinguishing LTP/AP from TSE based on Traffic Engineering.  Given that you mention the possibility that TE may be used in the realization of a transport slice, it would be an improvement if you replaced “whereas TSE is not“ with “whereas TSE might not be.”

I read, and understand your point about the “realization” distinction, but I do not see that as being as much of a distinction as your argument implies.  A very similar argument could be made about both LTP and AP – i.e. – exactly how obvious is it that an entity connecting to either would be aware of the supposed TE association?  In my reading, one big difference between the draft that includes LTP and the RFC that includes AP, AND this draft is that the other two documents are all about a specific set of implementations (based on TE) – while this draft is part of an effort to hide the details of the underlying implementation.

So, saying that a TSE is not associated with TE seems to say something about some subset of potential realizations (possibly including LTP or AP) as being disallowed.

Is there – in your opinion – any reason why a TSE could not also be either an LTP or an AP?  And, if that were the case, what is it about being a TSE that would make the association of either with TE go away?

There are also the comments from Kiran and Greg to consider…

From: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Sent: Thursday, June 18, 2020 4:18 PM
To: Jeff Tantsura <[email-masked]>; Eric Gray <[email-masked]>; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"
Importance: High

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

Hey, Reza.

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: Eric Gray <[email-masked]>
Date: Fri, 19 Jun 2020 15:24:40 +0000

Okay, if I understand your response, you are saying that both should be entirely removed (number 1 had two parts, and a response of “yes” might apply to either) – is that correct?

From: Kiran Makhijani <[email-masked]>
Sent: Friday, June 19, 2020 10:38 AM
To: Eric Gray <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"
Importance: High

Hi Eric,

From: Eric Gray <[email-masked]<mailto:[email-masked]>>
Sent: Friday, June 19, 2020 7:27 AM
To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Kiran, and Reza,

              See in-line below…

--
Eric

Hi Reza,

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: Kiran Makhijani <[email-masked]>
Date: Fri, 19 Jun 2020 16:01:01 +0000

Hi Eric,
Ok, to be clear, I’d like the text to read like below.

   - They are conceptual points of connection of a network function, device or application to the transport slice.
   - They are associated with a device, an application, and/or network function node. A non-exhaustive list of such nodes are  routers, switches, firewalls, WAN, 5G RAN nodes, 5G Core nodes, application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header enrichment functions, and TCP optimizers.
   - A TSE is identified by its unique identifier (e.g. logical interface identifier), TSE unique name and other data. A non-exhaustive list of other data includes IP address (v4 or v6), VLAN, port, connectivity type P2P, P2MP, MP2MP).

From: Eric Gray <[email-masked]>
Sent: Friday, June 19, 2020 8:25 AM
To: Kiran Makhijani <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

From: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>
Sent: Friday, June 19, 2020 10:38 AM
To: Eric Gray <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"
Importance: High

Hi Eric,

Kiran, and Reza,

              See in-line below…

--
Eric

Hi Reza,

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 19 Jun 2020 09:02:44 -0700

Hi Eric,
thank you for your detailed response. I agree with your proposed change.
Also, I've noticed another occurrence of the "head-end/tail-end"
terminology in

... whereas TSE is a logical head-end and tail-end of the transports slice
connections.

I think that this text is being worked on, so I'm not sure what its version
is at the moment. If we agree that the text should avoid using
"head-end/tail-end" terminology, can that part be related by "endpoint"?
Thus that passage will look as

... whereas TSE is a logical endpoint of the transports slice connections.

And I have one more comment regarding the unidirectional service. I think
that there should be some bandwidth available in the direction opposite to
the direction of the requested service (it would be good to give it a
shorter name) to be used by the control and management planes of the TS.

Regards,
Greg

On Fri, Jun 19, 2020 at 7:09 AM Eric Gray <[email-masked]> wrote:

> Greg,
>
>
>
>               To be clear, what you are suggesting is that the phrase
> “identified as the head-end and tail-end points of a transport slice”
> should be omitted.
>
>
>
>               The part of this phrase that says “of a transport slice” is
> somewhat useful, if possibly not actually necessary.  With this alteration,
> the sentence becomes:
>
>
>
>               “The transport slice endpoints are the logical entities of a
> transport slice that perform any required conversion, or adaptation, and
> forwarding of the user traffic.”
>
>
>
>               However, while I recognize the fact that you are not
> actually proposing text (at this point) relative to the questions you have
> about directionality, this is a point that is made in the draft with
> respect to SLOs in section 4.1.
>
>
>
>               In order to avoid using text that may be specific to
> underlying technology and transport slice implementation, “directionality”
> needs to be defined in terms of SLO, rather than connectivity.  That is,
> the reverse direction of a unidirectional service should not allow
> forwarding of any user traffic.
>
>
>
>               And this brings up a point that probably does need to be
> included: in order to describe a service that is actually unidirectional,
> it is necessary to include as part of the service the fact that the SLO in
> the direction opposite to the direction requested for the service has a *maximum
> bandwidth* of zero, in order to support unidirectional services over an
> infrastructure or technology that does not directly support unidirectional
> connectivity.
>
>
>
> --
>
> Eric
>
>
>
>
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Thursday, June 18, 2020 5:50 PM
> *To:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> *Cc:* Jeff Tantsura <[email-masked]>; LUIS MIGUEL CONTRERAS
> MURILLO <[email-masked]>; Shunsuke Homma <
> [email-masked]>; Kiran Makhijani <[email-masked]>; Kiran
> Makhijani <[email-masked]>; Luis M. Contreras <
> [email-masked]>; Shunsuke Homma <[email-masked]>;
> Dhruv Dhody <[email-masked]>; Eric Gray <[email-masked]>;
> [email-masked]
> *Subject:* Re: [Teas-ns-dt] Proposed text for section "Transport Slice
> Endpoint"
>
>
>
> Hi Reza,
>
> thank you for the text. I have a question. The text states:
>
> The transport slice endpoints are the logical entities identified as the
> head-end and tail-end points of a transport slice ...
>
> I think that calling out head-end and tail-end points the definition
> introduces directionality and implies that a transport slice is a
> unidirectional construct. Is that the intention? If a transport slice has
> directionality as one of its characteristics, then how it realizes MP2MP
> service? A set of unidirectional P2MP TSes? If there's no intention to
> differentiate between uni-directional and bidirectional TS, perhaps
> removing mention of the head-end and tail-end (two places in the text) be
> acceptable. For example, the definition might look like:
>
> The transport slice endpoints are the logical entities that perform any
> required conversion, or adaptation, and forwarding of the user traffic.
>
>
>
> Regards,
>
> Greg
>
> On Thu, Jun 18, 2020 at 1:35 PM Rokui, Reza (Nokia - CA/Ottawa) <
> [email-masked]> wrote:
>
> Hey Eric and Jeff,
>
>
>
> *---------------------------------- 2nd version of the Endpoint Text
> -------------------------------------------------------*
>
> As discussed in section 3, the transport slice consists of a set of one or
> more connections between multiple endpoints with a specified connectivity
> type and a set of SLOs associated with it.
>
>
>
> The transport slice endpoints are the logical entities identified as the
> head-end and tail-end points of a transport slice that perform any required
> conversion, or adaptation, and forwarding of the user traffic. The
> characteristics of the transport slice endpoints (TSE) are:
>
>
>
>    - They are conceptual points of connection of a network function,
>    - They are logically identified in a request by the customer of
>    - They are associated with one application, device and/or network
> function (ADN). A non-exhaustive list of ADN nodes are 5G RAN nodes, 5G
> Core nodes, routers, switches, firewalls, WAN, application acceleration,
> Deep Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], NAT64
> [RFC6146], HTTP header enrichment functions, and TCP optimizers.
>
>    - A TSE is identified by its ADN (its IP address, name , ID etc), TSE
> unique identifier (e.g. logical interface identifier), TSE unique name and
> other data. A non-exhaustive list of other data includes IP address (v4 or
> v6), VLAN, port, connectivity type P2P, P2MP, MP2MP). TDB to add more
>
>
>
> Note that this concept is similar to the Link Termination Point (LTP)
> defined in [draft-ietf-teas-yang-te-topo-22] 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. 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
> 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 node
> and some associated data. A non-exhaustive list of nodes containing TSRE
> are routers, switches, PON nodes, Wireless nodes and Optical devices.
>
>
>
> Note that there will be a mapping between TSE and TSRE on Transport Slice
> Controller (TSC). When TSC receives a request from its NBI to create a
> transport slice between multiple TSEs, it will then find the appropriate
> TSREs and send the request from its SBI to realize the transport slice. The
> detail of this mapping should be address in Transport slice framework
> document.
>
>
>
>    ----------            (                         )
> ---------
> *From: *Jeff Tantsura <[email-masked]>
> *Date: *Wednesday, June 17, 2020 at 5:13 PM
> *To: *Reza Rokui <[email-masked]>, LUIS MIGUEL CONTRERAS MURILLO <
> [email-masked]>, Shunsuke Homma <
> [email-masked]>, Kiran Makhijani <[email-masked]>, Kiran
> Makhijani <[email-masked]>, "Luis M. Contreras" <
> [email-masked]>, Shunsuke Homma <[email-masked]>,
> Dhruv Dhody <[email-masked]>, Eric Gray <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: [Teas-ns-dt] Proposed text for section "Transport Slice
> Endpoint"
>
>
>
> Hi Eric,
>
> Current wording: 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.
>
>
>
> Suggested re-wording: As discussed in section 3, the transport slice
> consists of a set of one or more connections between multiple endpoints
> with a specified connectivity type and a set of SLOs associated with it.
>
> [jeff] agreed
>
> [Reza] Agreed
>
>
>
>
>
> The second sentence is worded awkwardly.  The phrase “logical identifier
> to identify“ is a little circular (actually, the entire sentence is
> circular, since “transport slice endpoints” is semantically the same as
> “[endpoints] of a transport slice” – hence the sentence is tautological,
> but probably that is okay).
>
>
>
> Also, “forwarding” presumably happens within the slice, as well as at the
> end points.  What makes the endpoints different, is that – if there is any
> format, or encapsulation, adaptation required for packets being forwarded
> across a transport slice – this will be done at the transport slice
> endpoints.
>
>
>
> Suggested re-wording:    The transport slice endpoints are the logical
> entities identified as the head-end, and tail-end, points of a transport
> slice that perform any required conversion, or adaptation, and forwarding
> of the user traffic. The characteristics of the transport slice endpoints
> (TSE) are:
>
>    - 1st bullet – “They are conceptual point*s …*”, or “Each is a
>    conceptual point …” (number agreement).
>
> [Reza] used the former
>
>    - 2nd bullet – “They are associated with a logical identifier
>    requested …” (existing wording is awkward, as well as grammatically
>    incorrect).  Note – I believe this is what the authors intend, but it is
>    not terribly clear in this wording how these “logical identifiers” are
>    known in common between the requester and responder (which must be the
>    case).  Perhaps an example should be provided?
>    - 3rd bullet – I cannot make this one out; why “exactly one?” Is it “application,
>    device, *or* network function (ADN)” or “application, device, and
>    network function (ADN)” and – if the latter – I would have to disagree
>    as exactly how a transport slice is used by a requester should be entirely
>    up to them (and both application and network function tend to negate this).
>
> [Reza] the latter one.
>
>    - 4th bullet – similar issue as with 3rd bullet; i.e. – the
>    relationship between TSE and ADN (if ADN means “application, device
>    *and* network function” – then the relationship could be M:N).  Note
>    that – in all of the last three bullets – it is not at all clear what is
>    meant by “host,” “hosted” or “hosted by” (my impression is that what is
>    meant is the protocol stack presented by the TSE, but – if this is the
>    intention, there are role reversals in the wording of at least one of the
>    bullets).
>
>    - 5th bullet – multiple issues –
>
> .             If the meaning of ADN is as speculated above, “hosted”
> should probably be “hosting.” In any case, this reverses the sense of the
> hosting relationship described in the 3rd and 4th bullets.
>
> .             A better wording for the start of the second sentence in
> this bullet is “*A* non-exhaustive list of other data *includes* IP
> address (v4 or v6), …”
>
> .             “TSE unique identifier“ might benefit from an example –
> i.e. – “TSE unique identifier (e.g. – logical interface identifier).”
>
> [jeff] agreed
>
> [Reza] Agreed
>
>
>
> .             I am fairly certain that we would be better off omitting “connectivity
> type (i.e. P2P, P2MP, MP2MP) etc.)” as this could be considered part of “TDB
> to add more” and it is not clear what value this adds (i.e. – it would be
> optional at best).
>
> [jeff] disagree, this is an enumeration of connectivity types that are
> exposed to the consumer and are available to be requested , I’d
> remove “etc”, there's nothing to add
>
>    - 1st sentence in the paragraph: “the concept” seems to introduce a
>    disconnect, since we follow this paragraph with another paragraph that
>    seems to be introducing a different conceptual model.  Perhaps it should be
>    “this concept” (referring to the description of a TSE in the previous
>    - The draft referred to for “Link Termination Point” is seriously out
>    of date (instead of draft-ietf-teas-yang-te-topo-18 - it is currently
>    draft-ietf-teas-yang-te-topo-22 – xml2rfc should have fixed that).
>    - The statement (2nd sentence) – The main difference between them is
>    is not – is (I believe) misleading; it is quite likely that a packet
>    switching transport slice implementation will use Traffic Engineering to
>    create tunnels with tunnel ingress and egress internally terminated at a
>    transport slice endpoint.  I strongly suspect that – for some
>    implementations – a transport slice endpoint may be exactly the same as an
>    LTP or AP.  I suggest replacing the above text with something along the
>    lines of “While the transport slice concept includes potential
>    realizations not based on traffic engineering,  for some subset of
>    transport slice realizations, a TSE may be an LTP or AP.”
>
> [Reza] disagree. In this text we are not talking about the transport slice
> realization where your text is valid. See the 2nd version of the text
> above.
>
>    - With this change, the next sentence should start with “An AP …”
>    instead of “In other words. The AP …“
>    - The same sentence would then end with “… transport slice
>    connections, which may or may not include one or more TE links”
>    instead of “… transports slice connections.“
>
> [jeff] agreed
>
> Next Paragraph:
>
>    - The last sentence (“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”)
>    talks about a list of “devices” while many/most of the list members are not
>    devices.  It is non-trivial to come up with a different word for the thing
>    where a TSRE resides – especially while trying to avoid a circular
>    definition.  Maybe “virtual device or function?”
>
> *From:* Teas-ns-dt <[email-masked]> *On Behalf Of* Rokui,
> Reza (Nokia - CA/Ottawa)
> *Sent:* Tuesday, June 16, 2020 9:51 AM
> *To:* LUIS MIGUEL CONTRERAS MURILLO <
> [email-masked]>; Shunsuke Homma <
> [email-masked]>; Jeff Tantsura <[email-masked]>;
> [email-masked]; Kiran Makhijani <[email-masked]>; Kiran
> Makhijani <[email-masked]>; Luis M. Contreras <
> [email-masked]>; Shunsuke Homma <[email-masked]>;
> Dhruv Dhody <[email-masked]>
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> *Subject:* [Teas-ns-dt] Proposed text for section "Transport Slice
> Endpoint"
>
>
>
> All,
>
>
>
> traffic engineering (TE) whereas TSE is not. 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.
>
>
>
> Teas-ns-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>
>

---

From: Eric Gray <[email-masked]>
Date: Fri, 19 Jun 2020 17:25:19 +0000

Greg,

              A couple of things.

              One is regarding use of “logical” – which Jeff has said he would prefer to avoid; right now, there are a number of separate conversations involving related text – so I have no idea where this will end up.

              The other is about directionality and associated SLO parameters.  One thing that has been discussed and is – I confidently believe – allowed for, is asymmetry in SLOs.  So, if a service would like to include a higher bandwidth in one direction and a trickle in the other, that should be allowed.

              But there are also cases where a true unidirectional service is expected.  Control and management for a non-interactive delivery service might be out-of-band, for instance. And – in such cases -  no traffic should be sent in the opposite direction and (if any is sent) it should not be forwarded (somewhat like a “no-reply” E-Mail address).

              The fact that we can imagine services where there is a need for some bandwidth in each direction does not justify mandating this behavior.

--
Eric

From: Greg Mirsky <[email-masked]>
Sent: Friday, June 19, 2020 12:03 PM
To: Eric Gray <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"
Importance: High

Hi Eric,
thank you for your detailed response. I agree with your proposed change. Also, I've noticed another occurrence of the "head-end/tail-end" terminology in
... whereas TSE is a logical head-end and tail-end of the transports slice connections.
I think that this text is being worked on, so I'm not sure what its version is at the moment. If we agree that the text should avoid using "head-end/tail-end" terminology, can that part be related by "endpoint"? Thus that passage will look as
... whereas TSE is a logical endpoint of the transports slice connections.
And I have one more comment regarding the unidirectional service. I think that there should be some bandwidth available in the direction opposite to the direction of the requested service (it would be good to give it a shorter name) to be used by the control and management planes of the TS.

Regards,
Greg

On Fri, Jun 19, 2020 at 7:09 AM Eric Gray <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

              To be clear, what you are suggesting is that the phrase “identified as the head-end and tail-end points of a transport slice” should be omitted.

              The part of this phrase that says “of a transport slice” is somewhat useful, if possibly not actually necessary.  With this alteration, the sentence becomes:

              “The transport slice endpoints are the logical entities of a transport slice that perform any required conversion, or adaptation, and forwarding of the user traffic.”

              However, while I recognize the fact that you are not actually proposing text (at this point) relative to the questions you have about directionality, this is a point that is made in the draft with respect to SLOs in section 4.1.

              In order to avoid using text that may be specific to underlying technology and transport slice implementation, “directionality” needs to be defined in terms of SLO, rather than connectivity.  That is, the reverse direction of a unidirectional service should not allow forwarding of any user traffic.

              And this brings up a point that probably does need to be included: in order to describe a service that is actually unidirectional, it is necessary to include as part of the service the fact that the SLO in the direction opposite to the direction requested for the service has a maximum bandwidth of zero, in order to support unidirectional services over an infrastructure or technology that does not directly support unidirectional connectivity.

--
Eric

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 18, 2020 5:50 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Luis M. Contreras <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>; Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; Eric Gray <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi Reza,
thank you for the text. I have a question. The text states:
The transport slice endpoints are the logical entities identified as the head-end and tail-end points of a transport slice ...
I think that calling out head-end and tail-end points the definition introduces directionality and implies that a transport slice is a unidirectional construct. Is that the intention? If a transport slice has directionality as one of its characteristics, then how it realizes MP2MP service? A set of unidirectional P2MP TSes? If there's no intention to differentiate between uni-directional and bidirectional TS, perhaps removing mention of the head-end and tail-end (two places in the text) be acceptable. For example, the definition might look like:
The transport slice endpoints are the logical entities that perform any required conversion, or adaptation, and forwarding of the user traffic.

Regards,
Greg
On Thu, Jun 18, 2020 at 1:35 PM Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 19 Jun 2020 14:28:26 -0700

I believe direction is a mandatory variable when defining SLI/SLOs, IP networks are traditionally asymmetrical and would usually have different characteristics depending on the direction (try to measure download vs upload on your internet connection)

Cheers,
Jeff
On Jun 19, 2020, 10:25 AM -0700, Eric Gray <eric.gray=[email-masked]>, wrote:
> > quote_type
> > To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> > Cc: Jeff Tantsura <[email-masked]>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Shunsuke Homma <[email-masked]>; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Luis M. Contreras <[email-masked]>; Shunsuke Homma <[email-masked]>; Dhruv Dhody <[email-masked]>; Eric Gray <[email-masked]>; [email-masked]
> > On Thu, Jun 18, 2020 at 1:35 PM Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]> wrote:
> > > quote_type
> > > Hey Eric and Jeff,
> > >
> > > > quote_type

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 18 Jun 2020 14:50:19 -0700

Hi Reza,

Regards,
Greg

---

From: Eric Gray <[email-masked]>
Date: Fri, 19 Jun 2020 14:09:51 +0000

Greg,

--
Eric

Hi Reza,

Regards,
Greg

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: John E Drake <[email-masked]>
Date: Fri, 19 Jun 2020 22:42:39 +0000

Hi,

Why would we have SLOs between the nodes in the transport network slice provider's network as opposed to SLOs between the customer's points of attachment to the transport network slice?

Also, the following seems nonsensical to me:  "They are logically identified in a request by the customer of transport slice during the creation of the transport slice."  How would the customer know the identity of the transport network slice provider's nodes to which it is being attached?  These identifiers are internal to the transport network slice provider's network.  In your Figure X, below, where are the customers?

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Thursday, June 18, 2020 4:15 PM
To: Jeff Tantsura <[email-masked]>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Shunsuke Homma <[email-masked]>; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Luis M. Contreras <[email-masked]>; Shunsuke Homma <[email-masked]>; Dhruv Dhody <[email-masked]>; Eric Gray <[email-masked]>; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

[External Email. Be cautious of content]

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

The second sentence is worded awkwardly.  The phrase "logical identifier to identify" is a little circular (actually, the entire sentence is circular, since "transport slice endpoints" is semantically the same as "[endpoints] of a transport slice" - hence the sentence is tautological, but probably that is okay).

Also, "forwarding" presumably happens within the slice, as well as at the end points.  What makes the endpoints different, is that - if there is any format, or encapsulation, adaptation required for packets being forwarded across a transport slice - this will be done at the transport slice endpoints.

Suggested re-wording:    The transport slice endpoints are the logical entities identified as the head-end, and tail-end, points of a transport slice that perform any required conversion, or adaptation, and forwarding of the user traffic. The characteristics of the transport slice endpoints (TSE) are:
[jeff] I'd avoid "logical"
[Reza] Agreed

With the bullets:

  *   1st bullet - "They are conceptual points ...", or "Each is a conceptual point ..." (number agreement).
[Reza] used the former

  *   2nd bullet - "They are associated with a logical identifier requested ..." (existing wording is awkward, as well as grammatically incorrect).  Note - I believe this is what the authors intend, but it is not terribly clear in this wording how these "logical identifiers" are known in common between the requester and responder (which must be the case).  Perhaps an example should be provided?
Alternatively "They are logically identified in a request ... ."
[Reza] Agreed

  *   3rd bullet - I cannot make this one out; why "exactly one?" Is it "application, device, or network function (ADN)" or "application, device, and network function (ADN)" and - if the latter - I would have to disagree as exactly how a transport slice is used by a requester should be entirely up to them (and both application and network function tend to negate this).
[Reza] the latter one.

  *   4th bullet - similar issue as with 3rd bullet; i.e. - the relationship between TSE and ADN (if ADN means "application, device and network function" - then the relationship could be M:N).  Note that - in all of the last three bullets - it is not at all clear what is meant by "host," "hosted" or "hosted by" (my impression is that what is meant is the protocol stack presented by the TSE, but - if this is the intention, there are role reversals in the wording of at least one of the bullets).
[Reza] Removed all instances of hosted, hosting

  *   5th bullet - multiple issues -

.             If the meaning of ADN is as speculated above, "hosted" should probably be "hosting." In any case, this reverses the sense of the hosting relationship described in the 3rd and 4th bullets.

.             A better wording for the start of the second sentence in this bullet is "A non-exhaustive list of other data includes IP address (v4 or v6), ..."

.             "TSE unique identifier" might benefit from an example - i.e. - "TSE unique identifier (e.g. - logical interface identifier)."

[jeff] agreed
[Reza] Agreed

.             I am fairly certain that we would be better off omitting "connectivity type (i.e. P2P, P2MP, MP2MP) etc.)" as this could be considered part of "TDB to add more" and it is not clear what value this adds (i.e. - it would be optional at best).
[jeff] disagree, this is an enumeration of connectivity types that are exposed to the consumer and are available to be requested , I'd remove "etc", there's nothing to add
[Reza] Agreed with Jeff. I kept them.

Next paragraph - multiple issues:

  *   1st sentence in the paragraph: "the concept" seems to introduce a disconnect, since we follow this paragraph with another paragraph that seems to be introducing a different conceptual model.  Perhaps it should be "this concept" (referring to the description of a TSE in the previous
  *   The draft referred to for "Link Termination Point" is seriously out of date (instead of draft-ietf-teas-yang-te-topo-18 - it is currently draft-ietf-teas-yang-te-topo-22 - xml2rfc should have fixed that).
  *   The statement (2nd sentence) - The main difference between them is that both LTP and AP are associated to traffic engineering (TE) whereas TSE is not - is (I believe) misleading; it is quite likely that a packet switching transport slice implementation will use Traffic Engineering to create tunnels with tunnel ingress and egress internally terminated at a transport slice endpoint.  I strongly suspect that - for some implementations - a transport slice endpoint may be exactly the same as an LTP or AP.  I suggest replacing the above text with something along the lines of "While the transport slice concept includes potential realizations not based on traffic engineering,  for some subset of transport slice realizations, a TSE may be an LTP or AP."
[Reza] disagree. In this text we are not talking about the transport slice realization where your text is valid. See the 2nd version of the text above.

  *   With this change, the next sentence should start with "An AP ..." instead of "In other words. The AP ..."
  *   The same sentence would then end with "... transport slice connections, which may or may not include one or more TE links" instead of "... transports slice connections."
[jeff] agreed
Next Paragraph:

  *   The last sentence ("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") talks about a list of "devices" while many/most of the list members are not devices.  It is non-trivial to come up with a different word for the thing where a TSRE resides - especially while trying to avoid a circular definition.  Maybe "virtual device or function?"
[jeff] function sounds as a good choice (covers both virtual and physical)
[Reza] I have changed this section. See the 2nd version of the text above.

--
Eric

All,

Cheers,

Reza

---

From: John E Drake <[email-masked]>
Date: Fri, 19 Jun 2020 22:45:24 +0000

Jeff,

I completely agree, but that is not what the text says:  "The transport slice endpoints are the logical entities identified as the head-end and tail-end points of a transport slice that perform any required conversion, or adaptation, and forwarding of the user traffic.".

Yours Irrespectively,

John

Juniper Business Use Only
From: Jeff Tantsura <[email-masked]>
Sent: Friday, June 19, 2020 6:29 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Shunsuke Homma <[email-masked]>; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Luis M. Contreras <[email-masked]>; Shunsuke Homma <[email-masked]>; Dhruv Dhody <[email-masked]>; Eric Gray <[email-masked]>; [email-masked]; John E Drake <[email-masked]>
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

John ,

SLO defines a metric/boundaries of a service as perceived by the consumer(end-user) at the endpoint(s) where the  end user connected to the service (slice).

Cheers,
Jeff
On Jun 19, 2020, 3:21 PM -0700, John E Drake <[email-masked]<mailto:[email-masked]>>, wrote:
Hi,

Why would we have SLOs between the nodes that are providing the transport network slice to its customers, as opposed to SLOs between the customer's points of attachment to the transport network slice?

Yours Irrespectively,

John

To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Luis M. Contreras <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>; Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; Eric Gray <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 19 Jun 2020 15:56:56 -0700

John,

So the measurements are performed between the slice' end-points (head and tail ends). Where do you see inconstancy?

Cheers,
Jeff
On Jun 19, 2020, 3:45 PM -0700, John E Drake <[email-masked]>, wrote:
> Jeff,
>
> I completely agree, but that is not what the text says:  “The transport slice endpoints are the logical entities identified as the head-end and tail-end points of a transport slice that perform any required conversion, or adaptation, and forwarding of the user traffic.”.
>
> Yours Irrespectively,
>
> John
>
>
> On Jun 19, 2020, 3:21 PM -0700, John E Drake <[email-masked]>, wrote:
> > quote_type
> > Hi,
> >
> > Why would we have SLOs between the nodes that are providing the transport network slice to its customers, as opposed to SLOs between the customer’s points of attachment to the transport network slice?
> >
> > Yours Irrespectively,
> >
> > John
> >
> >

---

From: John E Drake <[email-masked]>
Date: Fri, 19 Jun 2020 23:26:34 +0000

Jeff,

The point is that the transport network slice provider's network is *completely opaque* to the transport network slice user.  The latter has a set of endpoints which they want to have connected using a variety of dataplane constructs (MP2MP, P2MP, MP2P, P2P bi-directional, and P2P uni-directional) each with a specific SLO.  Any discussion of how the network slice provider's network is constructed or how it operates is completely irrelevant.

To answer your specific question, the SLOs are between the transport network slice user's points of attachment to the transport network slice for each specified dataplane construct, so the SLOs should be between the customer's points of attachment and not between the transport network slice provider's nodes that are supporting those points of attachment.

Yours Irrespectively,

John

Juniper Business Use Only
From: Jeff Tantsura <[email-masked]>
Sent: Friday, June 19, 2020 6:57 PM
To: [email-masked]; John E Drake <[email-masked]>
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

John,

Cheers,
Jeff
On Jun 19, 2020, 3:45 PM -0700, John E Drake <[email-masked]<mailto:[email-masked]>>, wrote:
Jeff,

Yours Irrespectively,

John

To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Luis M. Contreras <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>; Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; Eric Gray <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; John E Drake <[email-masked]<mailto:[email-masked]>>

John ,

Cheers,
Jeff

Yours Irrespectively,

John

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 19 Jun 2020 17:00:11 -0700

Hi John,
I agree with your view on which element is an SLO measurement point:

To answer your specific question, the SLOs are between the transport
network slice user’s points of attachment to the transport network slice
for each specified dataplane construct, so the SLOs should be between the
customer’s points of attachment and not between the transport network slice
provider’s nodes that are supporting those points of attachment.

On the other hand, who's performing the SLO monitoring? I think that there
could be several scenarios. If the provider of the TNS manages CEs, then
SLO can be monitored between CEs. But, I think, there could be scenarios
when the provider doesn't have control over CEs. How to monitor SLO in that
scenario? Could the customer and the provider agree that in that scenario
SLO is monitored between CEs?

Regards,
Greg

On Fri, Jun 19, 2020 at 4:26 PM John E Drake <jdrake=
[email-masked]> wrote:

> Jeff,
>
>
>
> The point is that the transport network slice provider’s network is **completely
> opaque** to the transport network slice user.  The latter has a set of
> endpoints which they want to have connected using a variety of dataplane
> constructs (MP2MP, P2MP, MP2P, P2P bi-directional, and P2P uni-directional)
> each with a specific SLO.  Any discussion of how the network slice
> provider’s network is constructed or how it operates is completely
> irrelevant.
>
>
>
> To answer your specific question, the SLOs are between the transport
> network slice user’s points of attachment to the transport network slice
> for each specified dataplane construct, so the SLOs should be between the
> customer’s points of attachment and not between the transport network slice
> provider’s nodes that are supporting those points of attachment.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *From:* Jeff Tantsura <[email-masked]>
> *Sent:* Friday, June 19, 2020 6:57 PM
> *To:* [email-masked]; John E Drake <[email-masked]>
> *Subject:* RE: [Teas-ns-dt] Proposed text for section "Transport Slice
> Endpoint"
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> John,
>
> So the measurements are performed between the slice' end-points (head and
> tail ends). Where do you see inconstancy?
>
>
>
> Cheers,
>
> Jeff
>
> I completely agree, but that is not what the text says:  “The transport
> slice endpoints are the logical entities identified as the head-end and
> tail-end points of a transport slice that perform any required conversion,
> or adaptation, and forwarding of the user traffic.”.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *From:* Jeff Tantsura <[email-masked]>
> *Sent:* Friday, June 19, 2020 6:29 PM
> *To:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; LUIS MIGUEL
> CONTRERAS MURILLO <[email-masked]>; Shunsuke
> Homma <[email-masked]>; Kiran Makhijani <[email-masked]>;
> Kiran Makhijani <[email-masked] <kiranmak@gmail..com>>; Luis M.
> Contreras <[email-masked]>; Shunsuke Homma <
> [email-masked]>; Dhruv Dhody <[email-masked]>; Eric
> Gray <[email-masked]>; [email-masked]; John E Drake <
> [email-masked]>
> *Subject:* RE: [Teas-ns-dt] Proposed text for section "Transport Slice
> Endpoint"
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> John ,
>
> SLO defines a metric/boundaries of a service as perceived by the
> consumer(end-user) at the endpoint(s) where the  end user connected to the
> service (slice).
>
>
>
> Cheers,
>
> Jeff
>
> Why would we have SLOs between the nodes that are providing the transport
> network slice to its customers, as opposed to SLOs between the customer’s
> points of attachment to the transport network slice?
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *Sent:* Thursday, June 18, 2020 4:15 PM
> *To:* Jeff Tantsura <[email-masked]>; LUIS MIGUEL CONTRERAS
> *[External Email. Be cautious of content]*
>
>
>
> Hey Eric and Jeff,
>
>
>
> conversion, or adaptation, and forwarding of the user traffic.. The
> *From:* Jeff Tantsura <[email-masked]>
> *Date:* Wednesday, June 17, 2020 at 5:13 PM
> *To:* Reza Rokui <[email-masked]>, LUIS MIGUEL CONTRERAS MURILLO <
> *Cc:* "[email-masked]" <[email-masked]>
> *Subject:* RE: [Teas-ns-dt] Proposed text for section "Transport Slice
> Endpoint"
>
>
>
> Hi Eric,
>
>    up to them (and both application and network function tend to negate this)..
>
> [Reza] the latter one.
>
> should probably be “hosting..” In any case, this reverses the sense of the
> [email-masked] <contreras.ietf@gmail..com>>; Shunsuke Homma <
> [email-masked]>; Dhruv Dhody <[email-masked]>

---

From: John E Drake <[email-masked]>
Date: Sat, 20 Jun 2020 00:14:21 +0000

I would expect the both the transport network slice provider and the transport network slice user would monitor SLOs

Sent from my iPhone

On Jun 19, 2020, at 8:00 PM, Greg Mirsky <[email-masked]> wrote:

Hi John,
I agree with your view on which element is an SLO measurement point:
To answer your specific question, the SLOs are between the transport network slice user’s points of attachment to the transport network slice for each specified dataplane construct, so the SLOs should be between the customer’s points of attachment and not between the transport network slice provider’s nodes that are supporting those points of attachment.
On the other hand, who's performing the SLO monitoring? I think that there could be several scenarios. If the provider of the TNS manages CEs, then SLO can be monitored between CEs. But, I think, there could be scenarios when the provider doesn't have control over CEs. How to monitor SLO in that scenario? Could the customer and the provider agree that in that scenario SLO is monitored between CEs?

Regards,
Greg

On Fri, Jun 19, 2020 at 4:26 PM John E Drake <jdrake=[email-masked]<mailto:[email-masked]>> wrote:
Jeff,

The point is that the transport network slice provider’s network is *completely opaque* to the transport network slice user.  The latter has a set of endpoints which they want to have connected using a variety of dataplane constructs (MP2MP, P2MP, MP2P, P2P bi-directional, and P2P uni-directional) each with a specific SLO.  Any discussion of how the network slice provider’s network is constructed or how it operates is completely irrelevant.

To answer your specific question, the SLOs are between the transport network slice user’s points of attachment to the transport network slice for each specified dataplane construct, so the SLOs should be between the customer’s points of attachment and not between the transport network slice provider’s nodes that are supporting those points of attachment.

Yours Irrespectively,

John

To: [email-masked]<mailto:[email-masked]>; John E Drake <[email-masked]<mailto:[email-masked]>>

John,

Cheers,
Jeff

Yours Irrespectively,

John

To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:luismiguel.contrerasmurillo@telefonica..com>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <kiranmak@gmail..com<mailto:kiranmak@gmail..com>>; Luis M. Contreras <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>; Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; Eric Gray <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; John E Drake <[email-masked]<mailto:[email-masked]>>

John ,

Cheers,
Jeff

Yours Irrespectively,

John

Hey Eric and Jeff,

Reza

The transport slice endpoints are the logical entities identified as the head-end and tail-end points of a transport slice that perform any required conversion, or adaptation, and forwarding of the user traffic... The characteristics of the transport slice endpoints (TSE) are:

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

To: Reza Rokui <[email-masked]<mailto:[email-masked]>>, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>, Shunsuke Homma <s.homma0718@gmail..com<mailto:[email-masked]>>, Kiran Makhijani <[email-masked]<mailto:[email-masked]>>, Kiran Makhijani <[email-masked]<mailto:[email-masked]>>, "Luis M.. Contreras" <[email-masked]<mailto:[email-masked]>>, Shunsuke Homma <[email-masked]<mailto:[email-masked]>>, Dhruv Dhody <[email-masked]<mailto:[email-masked]>>, Eric Gray <[email-masked]<mailto:[email-masked]>>

Hi Eric,

Cheers,
Jeff

With the bullets:

  *   3rd bullet – I cannot make this one out; why “exactly one?” Is it “application, device, or network function (ADN)” or “application, device, and network function (ADN)” and – if the latter – I would have to disagree as exactly how a transport slice is used by a requester should be entirely up to them (and both application and network function tend to negate this)...
[Reza] the latter one.

.             If the meaning of ADN is as speculated above, “hosted” should probably be “hosting..” In any case, this reverses the sense of the hosting relationship described in the 3rd and 4th bullets.

.             “TSE unique identifier“ might benefit from an example – i..e. – “TSE unique identifier (e.g. – logical interface identifier).”

[jeff] agreed
[Reza] Agreed

.             I am fairly certain that we would be better off omitting “connectivity type (i.e.. P2P, P2MP, MP2MP) etc.)” as this could be considered part of “TDB to add more” and it is not clear what value this adds (i.e. – it would be optional at best).
[jeff] disagree, this is an enumeration of connectivity types that are exposed to the consumer and are available to be requested , I’d remove “etc”, there's nothing to add
[Reza] Agreed with Jeff. I kept them.

--
Eric

To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Luis M. Contreras <[email-masked]<mailto:contreras.ietf@gmail..com>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>; Dhruv Dhody <[email-masked]<mailto:[email-masked]>>

All,

Cheers,

Reza

--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas-ns-dt__;!!NEt6yMaO-gk!Wxs8Q4xllJMNcGBf9tFLqJ24aS8LucJUxwuLFdpaFmOaGLP2hdbMRme5rqbqYG0$>

---

From: John E Drake <[email-masked]>
Date: Fri, 19 Jun 2020 22:20:48 +0000

Hi,

Yours Irrespectively,

John

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 19 Jun 2020 15:29:22 -0700

John ,

Cheers,
Jeff

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 20 Jun 2020 13:38:12 -0700

John,

Fully agree with you, the distrust goes deep.
An SLA between provider and user defines a set of SLOs and conditions wrt their representation.
It is the job of the provider to demonstrate that SLOs are within their boundaries, as agreed within SLA.
It is up to the user to either blindly trust those (happens often in managed services) or validate and compare to the data provided by the provider. Discrepancy could be used as base of dispute as to whether SLA terms have been met.

Greg/Bo
Following the PE-CE model - the only difference here, is that if CE is managed by the provider - the boundary is at CE, if it is managed by the user - at PE. Note that “last-mile” PE-CE link is often provided by a 3rd party, and as such depends on the previously mentioned set of boundaries. In case of provider managed service, it is responsibility of the provider (and would be a part of end2end service), while if iy is responsibility of the user to get connectivity the provider’ PE, and dealing with the 3rd party providing this connectivity.

Cheers,
Jeff
On Jun 19, 2020, 5:14 PM -0700, John E Drake <[email-masked]>, wrote:
> > > On Fri, Jun 19, 2020 at 4:26 PM John E Drake <jdrake=[email-masked]> wrote:
> > > > Jeff,
> > > >
> > > > > To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Shunsuke Homma <[email-masked]>; Kiran Makhijani <[email-masked]>; Kiran Makhijani <kiranmak@gmail..com>; Luis M. Contreras <[email-masked]>; Shunsuke Homma <[email-masked]>; Dhruv Dhody <[email-masked]>; Eric Gray <[email-masked]>; [email-masked]; John E Drake <[email-masked]>
> > > > > > To: Reza Rokui <[email-masked]>, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>, Shunsuke Homma <s.homma0718@gmail..com>, Kiran Makhijani <[email-masked]>, Kiran Makhijani <[email-masked]>, "Luis M.. Contreras" <[email-masked]>, Shunsuke Homma <[email-masked]>, Dhruv Dhody <[email-masked]>, Eric Gray <[email-masked]>
> > > > > > > • 3rd bullet – I cannot make this one out; why “exactly one?” Is it “application, device, or network function (ADN)” or “application, device, and network function (ADN)” and – if the latter – I would have to disagree as exactly how a transport slice is used by a requester should be entirely up to them (and both application and network function tend to negate this)...
> > > > > > >
> > > > > > > [Reza] the latter one.
> > > > > > >

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Sun, 21 Jun 2020 03:24:52 +0000

Hi Sergio,

Sorry, I missed your email. See  my responses inline.

Reza

From: Sergio Belotti <[email-masked]>
Date: Wednesday, June 17, 2020 at 5:27 AM
To: Reza Rokui <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Sergio Belotti <[email-masked]>
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi Reza,

Thanks
Sergio

All,

Cheers,

Reza

   - 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
SB> I would say “provided” : the customer should know what is the logical identifier from which want to start/terminate his TS right?
[Reza] Agreed. Will be included.

   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.
SB> I clearly see the similarity with AP, but I would delete the relation with LTP since LTP is not a “logical” identifier, is a real termination point of a TE link terminating on a specific node. LTP is mapped to a local or remote link identifier (see RFC 3630). In the VN YANG model, an LTP is the VN-AP related termination point on the TE node . So it is clearly distinguished by AP and specific VN-AP.
[Reza] You are right about LTP. But, the text for transport slice endpoints is not saying whether AP or LTP is logical or physical. The main point of my text is that Transport Slice Endpoints are different.

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 22 Jun 2020 16:38:59 +0000

Hi Greg,

See inline

Reza

From: Greg Mirsky <[email-masked]>
Date: Thursday, June 18, 2020 at 5:50 PM
To: Reza Rokui <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>, Shunsuke Homma <[email-masked]>, Kiran Makhijani <[email-masked]>, Kiran Makhijani <[email-masked]>, "Luis M. Contreras" <[email-masked]>, Shunsuke Homma <[email-masked]>, Dhruv Dhody <[email-masked]>, Eric Gray <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi Reza,
thank you for the text. I have a question. The text states:
The transport slice endpoints are the logical entities identified as the head-end and tail-end points of a transport slice ...
I think that calling out head-end and tail-end points the definition introduces directionality and implies that a transport slice is a unidirectional construct. Is that the intention? If a transport slice has directionality as one of its characteristics, then how it realizes MP2MP service? A set of unidirectional P2MP TSes? If there's no intention to differentiate between uni-directional and bidirectional TS, perhaps removing mention of the head-end and tail-end (two places in the text) be acceptable.
[Reza] It was not the intention. Your point is valid

For example, the definition might look like:
The transport slice endpoints are the logical entities that perform any required conversion, or adaptation, and forwarding of the user traffic.
[Reza] I used your text

Regards,
Greg

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 22 Jun 2020 16:42:05 +0000

Hi Kiaran,
See inline.

Reza

From: Teas-ns-dt <[email-masked]> on behalf of Kiran Makhijani <[email-masked]>
Date: Thursday, June 18, 2020 at 7:02 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi Reza,

[Reza] Agreed.

  1.  Second bullet “They are logically identified..” is not needed. It is explicitly said in the definition.
[Reza] It is reworded in 2nd version.

[Reza] It is reworded in 2nd version.

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

Hey, Reza.

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 22 Jun 2020 17:04:50 +0000

Eric,
See inline.

Reza

From: Eric Gray <[email-masked]>
Date: Friday, June 19, 2020 at 11:22 AM
To: Reza Rokui <[email-masked]>, Jeff Tantsura <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Reza,

[Reza] Corrected

 [Reza] Corrected

Other issues:
Jeff had suggested avoiding the use of “logical” in the 2nd paragraph (“… transport slice entities are the logical identifiers …”), and it looks like you agreed – yet it is still there.
[Reza] I prefer to keep logical or replace it with some other term. Any suggestion?

I read, and understand your point about the “realization” distinction, but I do not see that as being as much of a distinction as your argument implies.  A very similar argument could be made about both LTP and AP – i.e. – exactly how obvious is it that an entity connecting to either would be aware of the supposed TE association?  In my reading, one big difference between the draft that includes LTP and the RFC that includes AP, AND this draft is that the other two documents are all about a specific set of implementations (based on TE) – while this draft is part of an effort to hide the details of the underlying implementation.
 [Reza] Reworded. See new text.

So, saying that a TSE is not associated with TE seems to say something about some subset of potential realizations (possibly including LTP or AP) as being disallowed.
  [Reza] Reworded. See new text.

Is there – in your opinion – any reason why a TSE could not also be either an LTP or an AP?  And, if that were the case, what is it about being a TSE that would make the association of either with TE go away?
  [Reza] TSE can be those but with different object model. For this reason, I do not want to say that TSE is LTP or AP because later the expectation it that their object model are the same.

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

Hey, Reza.

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 22 Jun 2020 17:15:21 +0000

Kiran,
All your changes are included with a small change. I also added “associated node” to last bullet. See new text.

Reza

Date: Friday, June 19, 2020 at 12:01 PM

Hi Eric,

Hi Eric,

Kiran, and Reza,

              See in-line below…

--
Eric

Hi Reza,

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 22 Jun 2020 17:19:48 +0000

John,
  >>>> Why would we have SLOs between the nodes that are providing the transport network slice to its customers, as opposed to SLOs between the customer’s points of attachment to the transport networ…

Based on transport slice definition, the Transport slice SLO is between Transport slice endpoints .

Cheers,

Reza

Reza Rokui, Ph.D.

From: John E Drake <[email-masked]>
Date: Friday, June 19, 2020 at 6:20 PM
To: Reza Rokui <[email-masked]>, Jeff Tantsura <[email-masked]>, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>, Shunsuke Homma <[email-masked]>, Kiran Makhijani <[email-masked]>, Kiran Makhijani <[email-masked]>, "Luis M. Contreras" <[email-masked]>, Shunsuke Homma <[email-masked]>, Dhruv Dhody <[email-masked]>, Eric Gray <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"

Hi,

Yours Irrespectively,

John

Hey Eric and Jeff,

Reza

                           (--------------------)
                          (  Transport Network   )
      ADN1               (                        )

Hi Eric,

Cheers,
Jeff

With the bullets:

[jeff] agreed
[Reza] Agreed

--
Eric

All,

Cheers,

Reza