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

[Greg Mirsky <[e-mail]>]

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) <
[e-mail]> wrote:

> 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 <[e-mail]>
> *Date: *Wednesday, June 17, 2020 at 5:13 PM
> *To: *Reza Rokui <[e-mail]>om>, LUIS MIGUEL CONTRERAS MURILLO <
> [e-mail]>gt;, Shunsuke Homma <
> [e-mail]>gt;, Kiran Makhijani <[e-mail]>om>, Kiran
> Makhijani <[e-mail]>om>, "Luis M. Contreras" <
> [e-mail]>gt;, Shunsuke Homma <[e-mail]>jp>,
> Dhruv Dhody <[e-mail]>om>, Eric Gray <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *RE: [Teas-ns-dt] Proposed text for section "Transport Slice
> Endpoint"
>
>
>
> Hi Eric,
>
> Thanks for your comments and please see in-line
>
>
>
> Cheers,
>
> Jeff
>
> On Jun 17, 2020, 1:40 PM -0700, Eric Gray <[e-mail]>om>, wrote:
>
> 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.
>
> [jeff] agreed
>
> [Reza] Agreed
>
>
>
>
>
> 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:
>
> [jeff] I’d avoid “logical”
>
> [Reza] Agreed
>
>
>
>
>
> With the bullets:
>
>    - 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?
>    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.
>
>
>
> The rest of the proposal is okay.
>
>
>
> --
>
> Eric
>
>
>
> *From:* Teas-ns-dt <[e-mail]> *On Behalf Of* Rokui,
> Reza (Nokia - CA/Ottawa)
> *Sent:* Tuesday, June 16, 2020 9:51 AM
> *To:* LUIS MIGUEL CONTRERAS MURILLO <
> [e-mail]>gt;; Shunsuke Homma <
> [e-mail]>gt;; Jeff Tantsura <[e-mail]>om>;
> [e-mail]; Kiran Makhijani <[e-mail]>om>; Kiran
> Makhijani <[e-mail]>om>; Luis M. Contreras <
> [e-mail]>gt;; Shunsuke Homma <[e-mail]>jp>;
> Dhruv Dhody <[e-mail]>
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
> *Subject:* [Teas-ns-dt] Proposed text for section "Transport Slice
> Endpoint"
>
>
>
> 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. 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.
>
>
>
>
>
> --
> Teas-ns-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>