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

From: Kiran Makhijani <[email-masked]>
Date: Mon, 4 May 2020 16:07:19 +0000

Hello,
Thanks for converging on improvement on most of the text. A little more discussion is necessary:

  1.  Can an SLO confidence be 100%?

I was bit confused with this discussion. Most comments were that there is no such thing as 100% confidence but I am not convinced. Is it possible to specify a slice by saying SLO1: guarantees of resource such as bandwidth (Say X mbps) with 100% confidence and SLO2: availability 99.999%? - I hope the answer is Yes. Right?

Another context for 100% confidence context is (Luis also raised this) when NF or SF resources are asked for, they should be seen as virtual but allocated (100%) resource with the guarantee of compute or memory requirements - i.e. without having to contend with another traffic. (confidence sounds bit odd here, but that's what we are using to replace resolution or isolation).

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

  1.  Monitoring in the context of measurable SLOs:

Jie raised an interesting comment on directly measurable attributes. Many SLOs will require different means of monitoring.  We have not discussed this as a characteristic of a transport slice. Should customer specify any monitoring as part of the transport slice? Perhaps not, but then there is a mention of "monitoring thresholds" in framework document in 3.3. We should have corresponding text in the definition.

Regards
Kiran

---

From: Eric Gray <[email-masked]>
Date: Mon, 4 May 2020 19:55:36 +0000

Kiran,

#1

              There are some possible SLO parameters that are effectively 100%.

              One that comes up is the requirement not to allow traffic from one VPN (being used as a "transport slice") to "leak" to another VPN.

              This can happen, of course, but only as a result of a misconfiguration error, or equipment failure.  Not much of anything can prevent these from happening (there are cases where this can be demonstrated to occur with TDM, for example, if a misconfiguration occurs at an Add-Drop Multiplexer.

              These risks can be (and usually are) mitigated by (for example) service activation testing, OAM, etc.

              It can be argued that any SLO parameter can be said to be 100%, if any departure from this would result in an immediate termination of the service.  This is essentially the case with your 1st example under #1.

              The issue that comes up in that is whether a failure to meet the SLO can be immediately detected by a service (which might - for instance - require that there is at least one OAM PDU for every service PDU).  This seems like a lot of overhead, at least to anyone not familiar with the payload envelope format used in TDM.

              As you can imagine, meeting these criteria could make the service very costly.

              But, the definition draft does not need to delve into this at that level of detail.  It should be sufficient to say that a specific parameter may have a "confidence level" in a range of from a minimum (10% was suggested, but it could be any arbitrary value less than 100%) and a maximum (possibly as high as 100%, depending on the parameter).

              To keep things simple at this point, we should allow that the range includes 100%, even when that is not achievable.

              As I mentioned (during today's meeting), there are a lot of possible failures that the customer would not be able to distinguish from congestion (such as weather in microwave, over heating in equipment, etc.) so a guarantee that a customer will never see behavior that looks as if it is caused by congestion effects from other traffic is not guaranteed to be determinable.

#2

              Once again, we're conflating "what" a customer asks for with "how" the provider  will meet the request.  A customer will not ask that the provider "poisons" other traffic in order to meet their committed objectives for that customer; what they will ask for is some level of assurance that their (presumed higher priority) traffic is not perceptibly impacted by other (presumed lower priority) traffic.

              Your assertion that "it must be avoided by ..." is clearly a "how" statement - hence out of scope (even as an example/assumption).  This is a good example of why it is that customers do not get to define what priority the customer's traffic gets in the provider's network.

#3

              The input that a customer (or subscriber) has in requesting monitoring of a service may indeed ask for notification when the service is nearing a threshold value that might impact the service.  How the provider does the monitoring to support this notification is not up to the customer - as long as the customer receives the notification.  Once again, this falls into the "how to do it" realm, rather than in the "what it is that the customer actually needs" realm.

              Also, we are not saying (in the framework draft) that the thresholds that may be established are tripped as a result of direct monitoring of each service.  The TSC has the responsibility to do this and may actually do it in any number of ways - depending on (for instance) the details of the underlay deployment.

              I do find that - while the framework draft explicitly states that the details of the NBI (of which monitoring is one example) are not in scope  - you seem to be arguing that these same details may be in scope for the definitions draft.

              I strongly suspect that we could make a statement in the definitions draft along the lines of "monitoring transport slice performance against some subset of specific SLO might be necessary, depending on a customer having the ability to ask for this via the NBI and the provider being able to provide it."

              The thing that may need to be re-emphasized in this context is that a transport slice service provider (via a TSC) may not be able to provide some services that a customer may request.  In an environment where the transport network and the customer network are both in the same administrative domain, there is always the option for the "provider" to expand the infrastructure to meet increasing "customer" demand.  In the real world, this doesn't happen in real-time.

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of Kiran Makhijani
Sent: Monday, May 4, 2020 12:07 PM
To: [email-masked]
Subject: [Teas-ns-dt] definitions section 4 improvement discussion

Hello,

Regards
Kiran

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 4 May 2020 19:56:31 +0000

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 <[email-masked]> En nombre de Kiran Makhijani
Enviado el: lunes, 4 de mayo de 2020 18:07
Para: [email-masked]
Asunto: [Teas-ns-dt] definitions section 4 improvement discussion

Hello,

[Luis>>] At least for the contracts I know (mostly related to interconnection matters) there is no absolute 100% of guarantee for SLOs. Each SLO committed is stated in according to its nature; two examples:

.- latency - usually (in the context of interconnection) an average value is committed for reaching destinations in different geographical areas.

.- packet loss - usually a max value is committed.

Those values are committed to not being exceeded X% of some period of time (e.g. days in a month, minutes a day, etc). So absolute 100% cannot be guaranteed because there are circumstances which are not controllable at all.

[Luis>>] My comment above is about performance. Here I was trying to introduce the analogy with what happens in the compute multi-tenancy approach. A customer can simply (1) request for resources or (2) can even ask for a dedicated host with a number of resources, where the customer actually doesn't care if it is hostA or hostE. Here, the analogy I see, according to what we discussed today, is a customer asking (1) some resources (e.g. 10 G bandwidth) or (2) some dedicated transport capabilities with a number of resources (e.g., a 10 G lambda). The important thing is that the customer doesn't care which specific lambda is, is up to the provider to allocate lambda1 or lambda8, as long as it is dedicated for the customer.

Both cases, (1) and (2) can be satisfied from the operator side simply allocating a dedicated lambda. But the operator has additional flexibility in case (1) since if no explicit dedication is requested, the customer request can be groomed with other signals from other customers (for sure guaranteeing the committed SLO of 10 G).

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

[Luis>>] In the examples I have mentioned in the point number 1, apart from defining the SLO and the threshold, also the way of measuring it and the time window are specified. So, I think we can go in that direction and I think there are a number of RFCs we could leverage on in this respect.

Regards
Kiran

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 4 May 2020 16:06:25 -0400

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 <[email-masked]> *En nombre de *Kiran Makhijani
> *Enviado el:* lunes, 4 de mayo de 2020 18:07
> *Para:* [email-masked]
> *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.)

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.

> 
>  3. Monitoring in the context of measurable SLOs:
> 
> Jie raised an interesting comment on directly measurable attributes. 
> Many SLOs will require different means of monitoring.  We have not 
> discussed this as a characteristic of a transport slice. Should customer 
> specify any monitoring as part of the transport slice? Perhaps not, but 
> then there is a mention of “monitoring thresholds” in framework document 
> in 3.3. We should have corresponding text in the definition.
> 
> */[Luis>>] In the examples I have mentioned in the point number 1, apart 
> from defining the SLO and the threshold, also the way of measuring it 
> and the time window are specified. So, I think we can go in that 
> direction and I think there are a number of RFCs we could leverage on in 
> this respect./*

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.

> 
> Regards
> 
> Kiran
> 
> 
> ------------------------------------------------------------------------
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, 
> puede contener información privilegiada o confidencial y es para uso 
> exclusivo de la persona o entidad de destino. Si no es usted. el 
> destinatario indicado, queda notificado de que la lectura, utilización, 
> divulgación y/o copia sin autorización puede estar prohibida en virtud 
> de la legislación vigente. Si ha recibido este mensaje por error, le 
> rogamos que nos lo comunique inmediatamente por esta misma vía y proceda 
> a su destrucción.
> 
> The information contained in this transmission is privileged and 
> confidential information intended only for the use of the individual or 
> entity named above. If the reader of this message is not the intended 
> recipient, you are hereby notified that any dissemination, distribution 
> or copying of this communication is strictly prohibited. If you have 
> received this transmission in error, do not read it. Please immediately 
> reply to the sender that you have received this communication in error 
> and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
> destinatário, pode conter informação privilegiada ou confidencial e é 
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa 
> senhoria o destinatário indicado, fica notificado de que a leitura, 
> utilização, divulgação e/ou cópia sem autorização pode estar proibida em 
> virtude da legislação vigente. Se recebeu esta mensagem por erro, 
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
> proceda a sua destruição

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 5 May 2020 09:07:57 +0000

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 <[email-masked]>
Enviado el: lunes, 4 de mayo de 2020 22:06
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Kiran Makhijani <[email-masked]>; [email-masked]
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:
> TEAS NS DT list - I think- but was part of the discussion today)
>
> Best regards
>
> Luis
>
> *De:*Teas-ns-dt <[email-masked]> *En nombre de *Kiran
> Makhijani *Enviado el:* lunes, 4 de mayo de 2020 18:07
...
> 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./*
>
> (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

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

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.

> discussed this as a characteristic of a transport slice. Should
> customer specify any monitoring as part of the transport slice?
> Perhaps not, but then there is a mention of "monitoring thresholds" in
> framework document in 3.3. We should have corresponding text in the definition.
>
> */[Luis>>] In the examples I have mentioned in the point number 1,
> apart from defining the SLO and the threshold, also the way of
> measuring it and the time window are specified. So, I think we can go
> in that direction and I think there are a number of RFCs we could
> leverage on in this respect./*

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.

> Este mensaje y sus adjuntos se dirigen exclusivamente a su
> destinatario, puede contener información privilegiada o confidencial y
> es para uso exclusivo de la persona o entidad de destino. Si no es
> usted. el destinatario indicado, queda notificado de que la lectura,
> utilización, divulgación y/o copia sin autorización puede estar
> prohibida en virtud de la legislación vigente. Si ha recibido este
> mensaje por error, le rogamos que nos lo comunique inmediatamente por
> esta misma vía y proceda a su destrucción.
>
> confidential information intended only for the use of the individual
> or entity named above. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited.
> If you have received this transmission in error, do not read it.
> Please immediately reply to the sender that you have received this
> communication in error and then delete it.
>
> utilização, divulgação e/ou cópia sem autorização pode estar proibida
> em virtude da legislação vigente. Se recebeu esta mensagem por erro,

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Eric Gray <[email-masked]>
Date: Tue, 5 May 2020 18:55:14 +0000

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 <[email-masked]> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Tuesday, May 5, 2020 5:08 AM
To: Joel Halpern Direct <[email-masked]>; Kiran Makhijani <[email-masked]>; [email-masked]
Subject: Re: [Teas-ns-dt] definitions section 4 improvement discussion

Hi Joel,

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

<jmh>

isolation.

</jmh>

<jmh>

</jmh>

Thanks

Best regards

Luis

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

De: Joel Halpern Direct <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Yours,

Joel

> *De:*Teas-ns-dt <[email-masked]<mailto:[email-masked]>> *En nombre de *Kiran

> *Para:* [email-masked]<mailto:[email-masked]>

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

....

isolation.

> ----------------------------------------------------------------------

--- [SNIP] ---

--- [SNIP] ---

--

Teas-ns-dt mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: "Luis M. Contreras" <[email-masked]>
Date: Tue, 5 May 2020 23:19:07 +0200

Hi Eric,

thanks for removing the Notice, included by default on my emails (internal
policies), I will use my gmail address to avoid that. Apologies.

I think I'm not so far from your view, except in some specific points. I
quote here some parts of your email, apologies in advance if I cut too many
words altering the real message

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

I think we can assume programmable solutions since we are dealing with a
controller. If programmable is not the proper word (*) , maybe we can say
controllable nodes/equipment via a centralized element, such in the case of
ACTN (RFC8453) or ABNO (RFC7491).
(*) I'm not native English speaker so probably I cannot express precisely
the concept, but I hope it can be properly understood.

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

Without entering on technology options/details I only foresee two ways of
ensuring a behavior like a TDM service for the customer requesting it when
mixed in the same network with other non-TDM like service requests:
(1) overprovisioning the network in such a way that the TDM-like customers
do not experience any issue because a permanent excess and availability of
resources (bandwidth, queues, express links for reducing latency, etc)
(2) reservation of resources being dedicated only for those TDM-like
customers, coexisting gracefully with the other kind of customers not
needing the TDM-like behavior.
I think option (2) is the best option.

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

Even in the case of requesting isolation, the customer will be required
always to express her/his needs (or SLOs). Isolation is an additional
atribute. In other words, requesting isolation withour detailing SLOs such
as throughput, latency, etc is nor practical

Best regards

Luis

El mar., 5 may. 2020 a las 20:55, Eric Gray (<eric.gray=
[email-masked]>) escribió:

> 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.
>
>
>
> 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).
>
>
>
> 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
>
>
>
> To: Joel Halpern Direct <[email-masked]>; Kiran Makhijani <
> [email-masked]>; [email-masked]
> 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,
>
> 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.
>
> 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
>
>
>
> De: Joel Halpern Direct <[email-masked]
> <[email-masked]>> Enviado el: lunes, 4 de mayo de 2020 22:06
>
> Para: LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmurillo@telefonica..com>; Kiran Makhijani <
> kiranm@futurewei..com <[email-masked]>>; [email-masked]
>
> 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.)
>
>
>
> 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,
>
> 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.
>
>
>
> >
>
> > Regards
>
> >
>
> > Kiran
>
> >
>
> >
>
> [email-masked]
> [email-masked]

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 5 May 2020 17:42:59 -0400

Luis, if I am reading your note properly, you refer to a customer asking 
for a TDM behavior.

As far as I know, we are talking about a packet service.
Also presumably, what the custoemr actually wants can be described in 
terms of the SLO parameters we typically use (loss, delay, delay 
variation, bandwidth).
If so, it is actually better for the customer and the providing operator 
if the request is made in terms of those parameters, rather than an 
under-specified term like TDM packet service.

Then the operator is free to use any technique under the cover to meet 
the requirement.  What combination of dedicated resources, 
under-utilization of shared resources, prioritization, and other 
techniques, are used by the operator is up to him.  As long as the SLOs 
are met.

Yours,
Joel

On 5/5/2020 5:19 PM, Luis M. Contreras wrote:
> Hi Eric,
> 
> thanks for removing the Notice, included by default on my emails 
> (internal policies), I will use my gmail address to avoid that. Apologies.
> 
> quote here some parts of your email, apologies in advance if I cut too 
> many words altering the real message
> 
>  >> we cannot (and should not try to) "focus" on "programmable 
> controller. If programmable is not the proper word (*) , maybe we can 
> say controllable nodes/equipment via a centralized element, such in the 
> case of ACTN (RFC8453) or ABNO (RFC7491).
> (*) I'm not native English speaker so probably I cannot express 
> precisely the concept, but I hope it can be properly understood.
> 
>  >> TSC can them implement the requested transport slice service in any 
> way that is determined to be best by underlay capabilities and provider 
> Without entering on technology options/details I only foresee two ways 
> of ensuring a behavior like a TDM service for the customer requesting it 
> when mixed in the same network with other non-TDM like service requests:
> (1) overprovisioning the network in such a way that the TDM-like 
> customers do not experience any issue because a permanent excess and 
> availability of resources (bandwidth, queues, express links for reducing 
> latency, etc)
>  >> 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
> 
> atribute. In other words, requesting isolation withour detailing SLOs 
> such as throughput, latency, etc is nor practical
> 
> Best regards
> 
> Luis
> 
> 
> El mar., 5 may. 2020 a las 20:55, Eric Gray 
> (<eric.gray=[email-masked] 
> <mailto:[email-masked]>>) escribió:
> 
>     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.____
> 
>     __ __
> 
>     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____
> 
>     __ __
> 
>     From: Teas-ns-dt <[email-masked]
>     <mailto:[email-masked]>> On Behalf Of LUIS MIGUEL
>     CONTRERAS MURILLO
>     To: Joel Halpern Direct <[email-masked]
>     <mailto:[email-masked]>>; Kiran Makhijani
>     <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>
>     __ __
>     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>____
> 
>     __ __
> 
>     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.____
> 
>     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>____
> 
>     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-----____
> 
>     <mailto:[email-masked]>> 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:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>____
> 
>     Asunto: Re: definitions section 4 improvement discussion____
> 
>     __ __
> 
>     <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 <[email-masked]
>     <mailto:[email-masked]>> *En nombre de *Kiran ____
> 
>      > Makhijani *Enviado el:* lunes, 4 de mayo de 2020 18:07____
> 
>      > *Para:* [email-masked] <mailto:[email-masked]>____
> 
>      > *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 ____
> 
>     ____
>      > 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, ____
> 
>     ____
>      > 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.)____
> 
>     __ __
> 
>     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.____
> 
>     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.____
> 
>     __ __
> 
>      >__ __
> 
>      >  3. Monitoring in the context of measurable SLOs:____
> 
>      >__ __
> 
>      > Jie raised an interesting comment on directly measurable
>     attributes.____
> 
>      > Many SLOs will require different means of monitoring.  We have
>     not ____
> 
>      > discussed this as a characteristic of a transport slice. Should ____
> 
>      > customer specify any monitoring as part of the transport slice?____
> 
>      > Perhaps not, but then there is a mention of "monitoring
>     thresholds" in ____
> 
>      > framework document in 3.3. We should have corresponding text in
>     the definition.____
> 
>      >__ __
> 
>      > */[Luis>>] In the examples I have mentioned in the point number
>     1, ____
> 
>      > apart from defining the SLO and the threshold, also the way of ____
> 
>      > measuring it and the time window are specified. So, I think we
>     can go ____
> 
>     ____
>      > leverage on in this respect./*____
> 
>     __ __
> 
>     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.____
> 
>     __ __
> 
>      >__ __
> 
>      > Regards____
> 
>      >__ __
> 
>      > Kiran____
> 
>      >__ __
> 
>      >__ __
> 
>      >
>     ----------------------------------------------------------------------____
> 
>     __ __
> 
>     --- [SNIP] ---____
> 
>     __ __
> 
>     ____________________________________
> 
>     __ __
> 
>     --- [SNIP] ---____
> 
>     __ __
> 
>     --____
> 
>     Teas-ns-dt mailing list____
> 
>     [email-masked] <mailto:[email-masked]>____
> 
>     https://www.ietf.org/mailman/listinfo/teas-ns-dt____
> 
>     -- 
>     Teas-ns-dt mailing list
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 6 May 2020 13:33:06 +0200

Hi Joel,

yes, the customer is required to always express the service in terms of SLO
parameters as you point out, with or without the extra request of being
provided using resources in an isolated / dedicated / reserved manner.

SLOs should be always there.

Best regards

Luis

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 7 May 2020 15:32:51 +0000

Hi Luis and Joel,

I also agree that in addition to using parameters such as packet loss, bandwidth, latency, delay variation to describe the service requirement, for some services there is also requirement to have dedicated network resources allocated, so as to avoid or reduce unpredicted interference from other services or customers in the network. This can be seen as a generic requirement, and is not bound to any specific implementation.

Note that we may claim that the requirement of particular bandwidth, latency, delay variation can be met in a statistic multiplexing network with no resource reservation, while actually they are met at average over a relatively long time scale. This may not be good enough for services which were carried using a dedicated network (no interference from other customers) and plan to migrate to shared infrastructure, or which require those typical parameters be met at a shorter time scale.

Best regards,
Jie

From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of Luis M. Contreras
Sent: Wednesday, May 6, 2020 7:33 PM
To: Joel M. Halpern <[email-masked]>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Kiran Makhijani <[email-masked]>; Eric Gray <eric.gray=[email-masked]>; [email-masked]
Subject: Re: [Teas-ns-dt] definitions section 4 improvement discussion

Hi Joel,

yes, the customer is required to always express the service in terms of SLO parameters as you point out, with or without the extra request of being provided using resources in an isolated / dedicated / reserved manner.

Best regards

Luis

El mar., 5 may. 2020 a las 23:43, Joel M. Halpern (<[email-masked]<mailto:[email-masked]>>) escribió:
Luis, if I am reading your note properly, you refer to a customer asking
for a TDM behavior.

Yours,
Joel

On 5/5/2020 5:19 PM, Luis M. Contreras wrote:
> (<eric.gray=[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>>) escribió:
>
>     Luis,____
>
>     __ __
>
>     From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> On Behalf Of LUIS MIGUEL
>     CONTRERAS MURILLO
>     To: Joel Halpern Direct <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:jmh.direct@joelhalpern..com>>>; Kiran Makhijani
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     De: Joel Halpern Direct <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> Enviado el: lunes, 4 de mayo
>     de 2020 22:06____
>
<mailto:luismiguel.contrerasmurillo@telefonica..com%0b>>     <mailto:luismiguel.contrerasmurillo@telefonica..<mailto:luismiguel.contrerasmurillo@telefonica.>.com>>; Kiran
>     Makhijani <kiranm@futurewei..com <mailto:[email-masked]<mailto:[email-masked]>>>;
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>____
>
>      > *De:*Teas-ns-dt <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> *En nombre de *Kiran ____
>
>      > *Para:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>____
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>____
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>

--
___________________________________________
Luis M. Contreras
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
Global CTIO unit / Telefonica

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 May 2020 11:41:23 -0400

If an operator needs to dedicate resources in order to meet the customer 
requirements, that is fine.
But the customer requirement is not for dedicated resources.  It is for 
observable behaviors.
When the customer asks for dedicated resoruces, it is necessary to ask 
"and what behavior do you want".  Specifying "dedicated" across the NBI 
or as part of the slice definition is, as far as I can tell, 
counter-productive and mis-leading.

Yours,
Joel

On 5/7/2020 11:32 AM, Dongjie (Jimmy) wrote:
> Hi Luis and Joel,
> 
> I also agree that in addition to using parameters such as packet loss, 
> bandwidth, latency, delay variation to describe the service requirement, 
> for some services there is also requirement to have dedicated network 
> resources allocated, so as to avoid or reduce unpredicted interference 
> from other services or customers in the network. This can be seen as a 
> generic requirement, and is not bound to any specific implementation.
> 
> Note that we may claim that the requirement of particular bandwidth, 
> latency, delay variation can be met in a statistic multiplexing network 
> with no resource reservation, while actually they are met at average 
> over a relatively long time scale. This may not be good enough for 
> services which were carried using a dedicated network (no interference 
> from other customers) and plan to migrate to shared infrastructure, or 
> which require those typical parameters be met at a shorter time scale.
> 
> Best regards,
> 
> Jie
> 
> *From:*Teas-ns-dt [mailto:[email-masked]] *On Behalf Of 
> *Luis M. Contreras
> *Sent:* Wednesday, May 6, 2020 7:33 PM
> *To:* Joel M. Halpern <[email-masked]>
> *Cc:* LUIS MIGUEL CONTRERAS MURILLO 
> <[email-masked]>; Kiran Makhijani 
> <[email-masked]>; Eric Gray 
> <eric.gray=[email-masked]>; [email-masked]
> *Subject:* Re: [Teas-ns-dt] definitions section 4 improvement discussion
> 
> Hi Joel,
> 
> yes, the customer is required to always express the service in terms of 
> SLO parameters as you point out, with or without the extra request of 
> being provided using resources in an isolated / dedicated / reserved manner.
> 
>     >  >> we cannot (and should not try to) "focus" on "programmable 
>     >  >> TSC can them implement the requested transport slice service in any 
>     >  >> that some customers are reluctant to actually work out exactly what 
>     > (<eric.gray=[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked]
>     <mailto:[email-masked]>>>) escribió:
>     > 
>     >     Luis,____
>     > 
>     >     __ __
>     > 
>     >     From: Teas-ns-dt <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>>
>     On Behalf Of LUIS MIGUEL
>     >     CONTRERAS MURILLO
>     >     To: Joel Halpern Direct <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:jmh.direct@joelhalpern..com>>>;
>     Kiran Makhijani
>     >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>;
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     De: Joel Halpern Direct <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>>
>     Enviado el: lunes, 4 de mayo
>     >     de 2020 22:06____
>     > 
>     <mailto:luismiguel.contrerasmurillo@telefonica..com%0b>>   
>       <mailto:luismiguel.contrerasmurillo@telefonica..
>     <mailto:luismiguel.contrerasmurillo@telefonica.>.com>>; Kiran
>     >     Makhijani <kiranm@futurewei..com <mailto:[email-masked] <mailto:[email-masked]>>>;
>     <mailto:[email-masked] <mailto:[email-masked]>>____
>     > 
>     >      > 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 <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>>
>     *En nombre de *Kiran ____
>     > 
>     >      > Makhijani *Enviado el:* lunes, 4 de mayo de 2020 18:07____
>     > 
>     >      > *Para:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>____
>     > 
>     >      > *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
>     >      > 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./*____
>     > 
>     >     __ __
>     > 
>     >      >__ __
>     >      >  3. Monitoring in the context of measurable SLOs:____
>     > 
>     >      >__ __
>     > 
>     >      > Jie raised an interesting comment on directly measurable
>     >     attributes.____
>     > 
>     >      > Many SLOs will require different means of monitoring.  We have
>     >     not ____
>     > 
>     >      > discussed this as a characteristic of a transport slice. Should ____
>     > 
>     >      > customer specify any monitoring as part of the transport slice?____
>     > 
>     >      > Perhaps not, but then there is a mention of "monitoring
>     >     thresholds" in ____
>     > 
>     >      > framework document in 3.3. We should have corresponding text in
>     >     the definition.____
>     > 
>     >      >__ __
>     > 
>     >      > */[Luis>>] In the examples I have mentioned in the point number
>     >     1, ____
>     > 
>     >      > apart from defining the SLO and the threshold, also the way of ____
>     > 
>     >      > measuring it and the time window are specified. So, I think we
>     >     can go ____
>     > 
>     >      > in that direction and I think there are a number of RFCs we could
>     >     ____
>     > 
>     >      > leverage on in this respect./*____
>     > 
>     >     __ __
>     > 
>     >      >__ __
>     >      > Regards____
>     >      >__ __
>     >      > Kiran____
>     >      >__ __
>     >      >__ __
>     >      >
>     <mailto:[email-masked] <mailto:[email-masked]>>____
>     > 
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     > <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Eric Gray <[email-masked]>
Date: Mon, 11 May 2020 17:35:51 +0000

Jie,

              I am not sure it is the least bit accurate to characterize your response starting with the words “I also agree …” – because your response is actually far from agreement with the seemingly converging discussion to which you are responding.

              As has been repeatedly stated, whether or not the service uses “dedicated” resources is not a measurable characteristic of a service.

              For example, in many locations (in many entire regions of the world), there are no (verifiable) instances in which even TDM services are not actually carried over a statistically multiplexed packet network, using circuit emulation.  For the capacity required (to support those legacy TDM services that cannot be moved to some form of statistically multiplexed, packet-based, “transport” directly) – typically relatively low-speed – the fact that service is carried using statistically multiplexed packets is not detectable by the customer.

              In much of North America, for example, a very common use case for this is where some relatively rare outlying installations of plain old telephone services (POTS) require low-speed circuit emulation to carry the telephone service to/from the nearest packet-based termination point simply because of very old deployments of antiquated telephone equipment that would otherwise require replacement.

              Many (if not most) service providers faced with these ancient deployments have offered huge incentives to those subscribers to move to a more modern service subscription – for example, by offering deep discounts on all-in-one digital services (including Telephone, Internet and Television).  This helps those providers to reduce their service costs by eliminating CAPEX and OPEX costs associated with having to maintain and support outdated service equipment in parallel with their primary networking infrastructure.

              Where higher-speed service are required, and a customer has a preference for TDM-like behavior, it may be possible to offer them TDM services with the requested capacity directly.  Otherwise, potential subscribers will need to accept what is available (or bear the costs associated with redeploying of TDM services on their own – assuming the service provider has to do this redeployment, has the capability to do so in a reasonable time frame, and is willing – none of which is by any means guaranteed).

              Explaining the realistic choices available to a customer is strictly a customer-management issue – and therefore clearly not a standards objective.

              When you refer to other services – based on some “generic requirement […] not bound to any specific implementation” – as a generic requirement, you also have to include the specific service characteristics that can be observed by a subscriber, along with any time scale that they are willing to pay for.  At the same time, a service provider needs to evaluate the risks that apply to them of any possibility of not being able to provide that service – over the requested time scale(s) – in determining what to charge the subscriber.

              Your second paragraph raises the issue of “resource reservation” as if this were the same as dedication of specific network resources.  It is quite possible to allocate specific network resources (e.g. – capacity, priority, etc.) to a service provided by a network – without dedicating specific components (software or hardware) to make this happen.  This is a deployment and network engineering issue, not a technology or component implementation issue.

              As pointed out above, even if one deploys a solution that relies on an underlying TDM infrastructure, there is (in many cases) no wat to guarantee those TDM service are not themselves provided (at least in part) over a packet-switched network.

              Where TDM services are provided by circuit emulation, the “TDM link (circuit emulation)” is effectively a “virtual dedicated resource.”  That is a concept that may be at the root of the issue in this discussion, because it is incredibly difficult to distinguish – for a subscriber perspective – a “virtual dedicated resource” from a “resource allocation” in the services that can be offered in either case.

              The fact that “circuit emulation” may be undetectably in use, in many existing network services, serves as both a proof of concept that one can achieve the required service characteristics using existing networks, as well as a proof that even reliance on TDM services does not completely eliminate the possibility that these same services may be impacted (given, typically at a very low level) by resource contention as a result of shared resources.

              What is a major sticking point in this is that it is not seen as a common case that subscribers are so intent on having dedicated network resources (as opposed to allocated network resources) that they are willing to bear the entire cost for doing so on their own.

              For the most part, subscribers are looking to do pretty much the exact opposite – i.e. – they want to lower their costs by having acceptable services that rely on shared resources, using already deployed infrastructure.  Standards – including the current network slicing standardization efforts (of which our transport slicing efforts are a part) – are moving in the direction of making this sharing easier.

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of Dongjie (Jimmy)
Sent: Thursday, May 7, 2020 11:33 AM
To: Luis M. Contreras <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Kiran Makhijani <[email-masked]>; Eric Gray <eric.gray=[email-masked]>; [email-masked]
Subject: Re: [Teas-ns-dt] definitions section 4 improvement discussion

Hi Luis and Joel,

Best regards,
Jie

From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of Luis M. Contreras
Sent: Wednesday, May 6, 2020 7:33 PM
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] definitions section 4 improvement discussion

Hi Joel,

Best regards

Luis

Yours,
Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 14 May 2020 15:00:52 +0000

Hi Eric,

Please see some replies inline with [Jie]:

From: Eric Gray [mailto:[email-masked]]
Sent: Tuesday, May 12, 2020 1:36 AM
To: Dongjie (Jimmy) <[email-masked]>; Luis M. Contreras <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Kiran Makhijani <[email-masked]>; Eric Gray <eric.gray=[email-masked]>; [email-masked]
Subject: RE: [Teas-ns-dt] definitions section 4 improvement discussion

Jie,

[Jie] I was agreeing with Luis’s statement “the customer is required to always express the service in terms of SLO parameters as you point out, with or without the extra request of being provided using resources in an isolated / dedicated / reserved manner.” In short, the customer’s requirement can be expressed using the traditional bandwidth, delay, loss, etc., and may also include additional requirement to have some form of dedicated or reserved resources.

[Jie] This was discussed on the previous conference call, are all the SLO parameters directly measurable? Some examples: availability, diversity.

[Jie] Thanks for providing these examples. Migrating existing services from dedicated networks onto a shared network infrastructure is a valid case, and it aligns what network slicing aims to provide. It is a good thing to us that some traditional TDM based services can be easily migrated to packet based networks (i.e. via pseudowires), while it does not preclude the existence of services which do have strict requirement on guaranteed SLAs and will give us some more challenges.

[Jie] As mentioned in previous conference call, temporary SLA degradation may be neglectable to some customers, while may be equivalent to service interruption for some others. Maybe the first step is to see whether we have agreement on such difference, then we could figure out how to characterize it.

[Jie] In recent TEAS virtual meeting, the definition of “TE” was discussed, and resource reservation is listed as one component of “TE” technology.

[Jie] If we only look at the services we already provided in the past, I’m afraid we may miss some new requirement and reach some relatively conservative conclusions. While 3GPP (and other organizations) are looking at the potential new services and business models.

Best regards,
Jie

--
Eric

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Dongjie (Jimmy)
Sent: Thursday, May 7, 2020 11:33 AM
To: Luis M. Contreras <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] definitions section 4 improvement discussion

Hi Luis and Joel,

Best regards,
Jie

Hi Joel,

Best regards

Luis

Yours,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 19 May 2020 12:19:17 -0700

Hi Jie,
I would note that different calculatable performance metrics differently
reflect the presence of extreme measurement results. For example, a single
high value will have a larger impact on the mean than on the median. AFAIK,
for that reason providing percentile (95, 99, and 99.9) values might be
informative, operationally useful, and less dependent on the measurement
time period.

Regards,
Greg

On Thu, May 7, 2020 at 8:33 AM Dongjie (Jimmy) <[email-masked]> wrote:

> resources allocated, so as to avoid or reduce unpredicted interference from
> other services or customers in the network. This can be seen as a generic
> requirement, and is not bound to any specific implementation.
>
>
>
> with no resource reservation, while actually they are met at average over a
> relatively long time scale. This may not be good enough for services which
> were carried using a dedicated network (no interference from other
> customers) and plan to migrate to shared infrastructure, or which require
> those typical parameters be met at a shorter time scale.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Teas-ns-dt [mailto:[email-masked]] *On Behalf Of *Luis
> M. Contreras
> *Cc:* LUIS MIGUEL CONTRERAS MURILLO <
> [email-masked]>; Kiran Makhijani <
> [email-masked]>; Eric Gray <eric.gray=[email-masked]>;
> [email-masked]
> SLO parameters as you point out, with or without the extra request of being
> >     <mailto:[email-masked] <jmh.direct@joelhalpern..com>>>;
> Kiran Makhijani
> <luismiguel.contrerasmurillo@telefonica..com%0b>>     <mailto:
> luismiguel.contrerasmurillo@telefonica..
> <luismiguel.contrerasmurillo@telefonica.>.com>>; Kiran