Re: [Teas-ns-dt] definitions section 4 improvement discussion

Luis,

I removed multiple copies of the inappropriate "Notice" included in your earlier E-Mail, below.

We had multiple discussions about the fact that we should not say anything about what goes on inside (or under) a Transport Slice Controller, or through the transport slice controller.

If you think back, you should recall that we are only modeling anything beneath the TSC NBI logically and we are not asserting that any of the logical constructs associated with this logical model can be presumed to exist.

For specific examples, there may be no TSC SBI and there may be no actual network controller.

>From our perspective, it is useful to think of the TSC as a black box, controlled via the NBI, and having physical connectivity to service users only as will have been determined in deployment.

Consequently, we cannot (and should not try to) "focus" on "programmable constructs" or "concentrate" on "programmable capabilities."

That will be the task of a TSC implementation.  We are not defining TSC implementation, at this time (or quite possibly ever).

If you want to create a TSC implementation, here is not the place to do so.

This  is, in my opinion, exactly what folks are missing here: i.e. - since we are trying to define how we can instruct a TSC to provide a service, with no more information about how the TSC is allowed to do that than that minimum unavoidable information, then we cannot describe requested services in terms that cannot be seen directly by the user.

The minute we start to talk about what a TSC must do in order to meet a set of service criteria we might expect assuming some specific way of providing the service requested - without spelling those service criteria (parameters or objectives) out explicitly - we are talking about "how the TSC provides" the service, rather than "what the service is."

So if a customer wants the equivalent of a TDM service, with a bandwidth X - for example, they need to translate this into a list of objectives that they would expect from such a TDM service (e.g. =latency, delay variation, etc.).

Once a customer actually goes through this process, they may (and likely will) realize that there are some characteristics of a TDM service that they may not need for their particular application - at least not to the extent that an actual TDM service could be able to provide it.

If that is the case, then they may either skip those objectives, or accept a lower level of assurance (in either case, capitalizing on an opportunity to reduce service costs).

Even if they decide that they need all of the expected characteristics of a corresponding TDM transport slice service, they can request such a service (in packetized form) from a TSC and the TSC can them implement the requested transport slice service in any way that is determined to be best by underlay capabilities and provider policies, that is otherwise completely independent of the fact that the transport slice service will look like a (packetized) TDM service.

This allows for efficiencies and cost savings to the transport slice service provider - especially if the transport slice service provider is also providing other services, with different objectives and expectations.

And it makes the process of trying to define an abstract interface between the transport slice user and the transport slice provider a good deal simpler.

So, win-win.

What I am afraid of is that some customers are reluctant to actually work out exactly what they really need and this is the underlying argument for why they want the TSC NBI to "accept" isolation as an objective, and perform the necessary translation for them.

But it must be abundantly clear by now that - if the customer doesn't tell us exactly what they mean by isolation - then any translation we define will likely fail to match their (undefined) expectations.

And this is largely a "customer-management" issue - hence something that does not belong in the scope of our work here.

--

Eric

-----Original Message-----
From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Tuesday, May 5, 2020 5:08 AM
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>om>; Kiran Makhijani <kiranm@futurewei.com>om>; teas-ns-dt@ietf.org
Subject: Re: [Teas-ns-dt] definitions section 4 improvement discussion

Hi Joel,

Some comments to your points:

<jmh>

I had assumed that things with high reliability needs would specify that they need 99.99% (or 5-9s, or even 6-9s) for the relevant SLO parameters.  And pay the price the operator needs to get to have that be offerable.  I would not expect the customer to express this kind of high reliability requirement as an isolation requirement, as isolation does not actually equate to reliability.  (I can have an isolated fiber.  If it is cut, I am out of luck.  And I got no benefit from having the isolated fiber.) </jmh>

Isolation implies dedication of a number of resources. With those dedicated resources two situations could happen: (1) everything works fine, so no impacts on SLOs; (2) something works wrong, thus the operator can allocate different but equivalent resources in such a way that SLOs are not impacted.

This works for sure at certain levels. If we are talking of dedicated infrastructure (as in your example of the fiber) this could not be possible. However there are connectivity constructs that make it possible (the referred lambda, for instance, which could be provided through a different path).

I would say that the explicit implication of isolation is dedication of resources, while the implicit one is some service guarantees (apart from others such as maybe security, predictability, robustness, etc).

<jmh>

At the same time, if we really wanted to get into isolation, we would have to get into the difference among dedicate conduit, dedicate fiber,

dedicate lambda, dedicate time slice, ...).   None of those are degrees.

  They are different ways of delivering a service.  With different effects.  Note that this is quite separate from a requirement that two different access points from a customer must have no failure point in common.  That is a complex thing to express in an SLO, and hard to

monitor.   But it is Very different from what has been described as

isolation.

</jmh>

What we could expect from a transport slice controller (TSC) is to work on programmable assets (via network controllers probably). Then I guess the focus should be on the programmable constructs providing isolation, not in the physical infrastructure which will not be addressable by the TSC. So I would concentrate on programmable capabilities, leaving the rest apart.

Maybe, as discussed, isolation cannot be expressed through a SLO, but it will be an attribute or characteristic of the service.

Regarding the description in the draft, yes, should be changed to avoid confusion.

<jmh>

The biggest risk is that if we geet too specific about how these things will be measured, we can end up with volumes of text.  I agree with the description Luis used.  But if we start trying to define (as contracts have to) the exact start and end of measurement intervals, the exact clock skew allowed by the measurement tools, and the exact technique to be used to measure these things, we will create a never-ending nightmare for ourselves.

</jmh>

Probably it would be enough referring that some time window could be considered, describing in rough way, not exact details. Or just referring some of the existing RFCs dealing with the topic as examples/references for defining SLOs.

Thanks

Best regards

Luis

-----Mensaje original-----

De: Joel Halpern Direct <jmh.direct@joelhalpern.com<mailto:jmh.direct@joelhalpern.com>> Enviado el: lunes, 4 de mayo de 2020 22:06

Para: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica..com<mailto:luismiguel.contrerasmurillo@telefonica..com>>; Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>

Asunto: Re: definitions section 4 improvement discussion

Trimmed to one part I want to comment on.  Reply bracketted by <jmh></jmh> for quoting clarity.

Yours,

Joel

On 5/4/2020 3:56 PM, LUIS MIGUEL CONTRERAS MURILLO wrote:

> Hi Kiran,

>

> Some comments from my side in-line (adding also Joel who is not in the

> TEAS NS DT list - I think- but was part of the discussion today)

>

> Best regards

>

> Luis

>

> *De:*Teas-ns-dt <teas-ns-dt-bounces@ietf.org<mailto:teas-ns-dt-bounces@ietf.org>> *En nombre de *Kiran

> Makhijani *Enviado el:* lunes, 4 de mayo de 2020 18:07

> *Para:* teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>

> *Asunto:* [Teas-ns-dt] definitions section 4 improvement discussion

....

>  2. Dealing with failures:

>

> I am little worried about how we are mixing up the avoidable,

> recoverable and non-recoverable failures. I did not agree that

> fan-failure faults are same as congestion. In case of congestion - it

> must be avoided by minimizing or penalizing other less-critical

> traffic - because a transport slice asked for this. In case of

> recoverable HA or failover should kick in. finally non-recoverable are

> multiple faults:- both active and failover links saw problems and it

> is impossible to send any traffic. In transport slices, we can specify

> enough to prevent avoidable and recoverable failures. For example,

> consider a critical-service transport slice and what must be done to

> provide disruption free and always-on, and reliable service?

>

> */[Luis>>] I also see them as different kind of events. In order to

> deal with infrastructure failures, operators typically design the

> network architecture to avoid the kind of problems as the example of

> the fan failure. IN case of happening something like that (which

> implies that the node goes down), an alternative path in the network

> will take care of the traffic, avoiding impact on customers. Networks

> can be designed to deal with single or multiple failures. More

> protection more cost./*

>

> */However a network design like before could have events of congestion

> (flash crowd events, exceptional situations -e.g. COVID-19-, failures

> in parts of the network, etc). In this situations isolation,

> understood as the way of dedicating resources to customers, could

> guarantee that the resources allocated to a given customer are

> respected and not used for others. Examples of situations like thos

> could be the same lambda example as before, some calendar slots in

> FlexEthernet, some queues allocated for a specific customer (at least in ingress), etc.

> Statistical multiplexing mechanisms cannot guarantee that, is clear,

> bit there are other mechanisms as the ones mentioned before, which are

> also part of the overall transport network./*

>

> */This does not mean that the cost of such dedication of resources

> will be equivalent to non-dedicated resources, for sure not. But there

> could be situation where such kind of guarantees are needed: emergency

> services, banks, stock markets, etc. Such kind of specialized services

> will be the ones demanding such kind of special solutions with the

> expectation of being more economic than building and running their own

> network (as happened in the computing world by the way)./*

>

> */So maybe this will not be the common norm, but there are a number of

> use cases that will have such needs, and because of that we need to

> define a solution being comprehensive, not partial./*

I had assumed that things with high reliability needs would specify that they need 99.99% (or 5-9s, or even 6-9s) for the relevant SLO parameters.  And pay the price the operator needs to get to have that be offerable.  I would not expect the customer to express this kind of high reliability requirement as an isolation requirement, as isolation does not actually equate to reliability.  (I can have an isolated fiber.  If it is cut, I am out of luck.  And I got no benefit from having the isolated fiber.)