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

[Jeff Tantsura <[e-mail]>]

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 <[e-mail]>et>, wrote:
> 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 <[e-mail]> wrote:
> >
> > [External Email. Be cautious of content]
> >
> > Hi John,
> > I agree with your view on which element is an SLO measurement point:
> > > quote_type
> > > 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=[e-mail]> 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
> > > >
> > > >
> > > > Juniper Business Use Only
> > > > From: Jeff Tantsura <[e-mail]>
> > > > Sent: Friday, June 19, 2020 6:57 PM
> > > > To: [e-mail]; John E Drake <[e-mail]>
> > > > 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
> > > > On Jun 19, 2020, 3:45 PM -0700, John E Drake <[e-mail]>et>, 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
> > > > >
> > > > >
> > > > > Juniper Business Use Only
> > > > > From: Jeff Tantsura <[e-mail]>
> > > > > Sent: Friday, June 19, 2020 6:29 PM
> > > > > To: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>om>; LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>om>; Shunsuke Homma <[e-mail]>om>; Kiran Makhijani <[e-mail]>om>; Kiran Makhijani <kiranmak@gmail..com>; Luis M. Contreras <[e-mail]>om>; Shunsuke Homma <[e-mail]>jp>; Dhruv Dhody <[e-mail]>om>; Eric Gray <[e-mail]>om>; [e-mail]; John E Drake <[e-mail]>
> > > > > 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
> > > > > On Jun 19, 2020, 3:21 PM -0700, John E Drake <[e-mail]>et>, 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
> > > > > >
> > > > > >
> > > > > > Juniper Business Use Only
> > > > > > From: Teas-ns-dt <[e-mail]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
> > > > > > Sent: Thursday, June 18, 2020 4:15 PM
> > > > > > To: Jeff Tantsura <[e-mail]>om>; LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>om>; Shunsuke Homma <[e-mail]>om>; Kiran Makhijani <[e-mail]>om>; Kiran Makhijani <[e-mail]>om>; Luis M. Contreras <[e-mail]>om>; Shunsuke Homma <[e-mail]>jp>; Dhruv Dhody <[e-mail]>om>; Eric Gray <[e-mail]>om>; [e-mail]
> > > > > > Cc: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
> > > > > > Subject: Re: [Teas-ns-dt] Proposed text for section "Transport Slice Endpoint"
> > > > > >
> > > > > > [External Email. Be cautious of content]
> > > > > >
> > > > > > 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]>om>, Shunsuke Homma <s.homma0718@gmail..com>, Kiran Makhijani <[e-mail]>om>, Kiran Makhijani <[e-mail]>om>, "Luis M.. Contreras" <[e-mail]>om>, 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 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.
> > > > > > >
> > > > > > > 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]>om>; Shunsuke Homma <[e-mail]>om>; Jeff Tantsura <[e-mail]>om>; [e-mail]; Kiran Makhijani <[e-mail]>om>; Kiran Makhijani <[e-mail]>om>; Luis M. Contreras <[e-mail]>om>; 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