Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

[Gyan Mishra <[e-mail]>]

Hi All

I have been following along on the “isolation” context debate and I agree
with Xuesong and Luis that I think it is important to define the concept of
“isolation” as it pertains to transport slice.

I agree with Adrian’s comment on transport slice and that the concept of
isolation as a service measurable from a customer point of view and what
they have access to as far as diagnostics as well as delivery isolation
which is an operators point of view of the slice and how transport had been
“sliced” so to speak t create physical or logical isolation.  From a
isolation as a service perspective it does not have to be 100% measurable
by the customer as the customer would not have visibility into the provider
network. Does not mean that isolation as a service can not still be
provided by operators at a higher cost to customers.  There maybe a way to
provide some transparency to customers so they can see what they are paying
for.

In basic terms “isolation” I agree is important to be defined as isolation
has many many different meaning and it could mean one thing to an operator
delivering the service and another thing for a customer paying for a higher
tier Enhanced VPN service and so want to understand what they are getting
as far as SLA and how it can be proven and measured from a customer
perspective.

The reason as well why isolation is critical abstraction layer from a TEAS
traffic steering perspective and why it come up is that from a service
delivery perspective you can steer traffic onto a dedicated path that are
not shard resources and maybe can have “degrees of isolation” as well in
terms of marketing a higher tier SLA to provide that degree of path
isolation by limiting the customers that traverse a traffic engineered
path.   Also when you provisioning a higher tier Enhanced VPN and you have
VPN A and VPN B and you provision for path diversity similarly to OTN 100G
P2P wave circuit provisioning process.  Their maybe customer parameters as
far as “isolation” and cost for the tiers of isolation that the operators
wants to sell to customers. So complete path isolation meaning dedicated or
a degree of isolation meaning logical isolation and each tier has a
different price point.

Some of this verbiage is already in the appendix and may just need some
tweaking but I do agree it is an important to keep as part of the
definition.

Kind Regards

Gyan



On Thu, Aug 27, 2020 at 6:43 AM LUIS MIGUEL CONTRERAS MURILLO <
[e-mail]> wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi all,
>
>
>
>
>
> I agree with Xuesong in the fact that we cannot leave the idea of
> isolation open to interpretation. This is precisely the reason why we need
> to have a definition
>
> on it in the context of transport slicing.
>
>
>
>
>
> Best regards
>
>
>
>
>
> Luis
>
>
>
>
>
>
>
>
>
> *De:* Teas <[e-mail]>
>
> *En nombre de *Gengxuesong (Geng Xuesong)
>
>
> *Enviado el:* jueves, 27 de agosto de 2020 4:28
>
>
> *Para:* Daniele Ceccarelli <[e-mail]>; Dongjie
> (Jimmy) <[e-mail]>; Jeff Tantsura <[e-mail]>;
> TEAS WG <[e-mail]>; Jari Arkko <[e-mail]>
>
>
> *CC:* Vishnu Pavan Beeram <[e-mail]>
>
>
> *Asunto:* Re: [Teas] WG adoption -
> draft-nsdt-teas-transport-slice-definition - Appendix
>
>
>
>
>
>
>
>
>
> Hi Daniele
>
>
>
>
>
> You have pointed out some technique that may not be necessarily under the
> concept of isolation.
>
> The first one disjointness is used mostly for protection and the second
> one is a dedicated physical link/network for some service. Isolation, in my
> understanding, describes the requirement that the traffic of service won’t
> interfere with each other when they
>
> are transmitted together. These two cases may not be included.
>
>
> And, most importantly, these possible different understanding of this
> concept makes it more
>
> necessary to be clearly defined in the document.
>
>
>
>
>
> Xuesong
>
>
>
>
>
>
>
>
>
> *From:* Daniele Ceccarelli [mailto:[e-mail]
> <[e-mail]>]
>
>
>
>
> *Sent:* Wednesday, August 26, 2020 9:34 PM
>
>
> *To:* Dongjie (Jimmy) <[e-mail]>; Gengxuesong (Geng Xuesong) <
> [e-mail]>; Jeff Tantsura <[e-mail]>;
>
> TEAS WG <[e-mail]>; Jari Arkko <[e-mail]>
>
>
> *Cc:* Vishnu Pavan Beeram <[e-mail]>
>
>
> *Subject:* RE: [Teas] WG adoption -
> draft-nsdt-teas-transport-slice-definition - Appendix
>
>
>
>
>
>
>
>
>
> Hi,
>
>
>
>
>
> I see different interpretations of isolation and they make me think we
> don’t need it, let me try to explain why.
>
>
>
>
>
>
>
>
>    1. In some cases I see as requirement the fact that a given traffic
>    must not share a path with another type of traffic, or a port, or a
>    link…that’s
>
>    what we commonly call “disjointness”, right? We’ve been speaking about
>    SRLG disjointness for decades.
>    2. In some other cases the requirement is not to have any type of
>    interference from any type of traffic in the network…that’s a leased line,
>    or a dedicated network…we
>
>    can’t really speak about network slice there.
>
>
>
>
>
>
> If I got the requirements right, I believe we already have all the cases
> covered.
>
>
> Am I missing any other requirement?
>
>
>
>
>
> BR
>
>
> Daniele
>
>
>
>
>
>
>
>
>
> *From:* Teas <[e-mail]>
>
> *On Behalf Of *Dongjie (Jimmy)
>
>
> *Sent:* den 26 augusti 2020 14:56
>
>
> *To:* Gengxuesong (Geng Xuesong) <[e-mail]>; Jeff Tantsura <
> [e-mail]>; TEAS WG <[e-mail]>; Jari
>
> Arkko <[e-mail]>
>
>
> *Cc:* Vishnu Pavan Beeram <[e-mail]>
>
>
> *Subject:* Re: [Teas] WG adoption -
> draft-nsdt-teas-transport-slice-definition - Appendix
>
>
>
>
>
>
>
>
>
> I also agree with the proposal of the chairs, and think it is important to
> have input from the WG about these terms.
>
>
>
>
>
>
> For isolation, there was some discussion in design team about classifying
> the isolation requirement into different dimensions in the
>
> context of IETF, such as: traffic separation, interference avoidance,
> failure protection, etc., then each can be mapped to corresponding
> mechanisms defined and developed in IETF.
>
>
>
>
>
>
> Perhaps we could follow this way to clarify the meaning of isolation from
> a transport slice point of view, and may find suitable terms
>
> to refer to some specific isolation requirement.
>
>
>
>
>
> Best regards,
>
>
> Jie
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Gengxuesong (Geng Xuesong)
>
>
>
>
> *Sent:* Wednesday, August 26, 2020 10:40 AM
>
>
> *To:* Jeff Tantsura <[e-mail]>; TEAS WG <[e-mail]>;
> Jari Arkko <[e-mail]>
>
>
> *Cc:* Vishnu Pavan Beeram <[e-mail]>
>
>
> *Subject:* RE: [Teas] WG adoption -
> draft-nsdt-teas-transport-slice-definition - Appendix
>
>
>
>
>
>
>
>
>
> +1
>
>
> And one more supplementary comment about “Isolation is not a directly
> measurable SLO”. Maybe
>
> here is some fog about what is measurable. Isolation could not described
> by number/value. But it doesn’t mean that it is an abstract concept that
> could not be defined precisely. People are asking whether TE link is
> isolated or not. It could be clarified by
>
> some deep analysis, good discussions and clear text. There is no
> conclusion yet just because we don’t even allow it to be existing in an WG
> document. And I don’t think the definition of other SDOs really matter.
> Because isolation in mobile network is different
>
> from isolation in IETF. If there is requirement in IETF, define it in
> IETF.. We can’t say we could not get to somewhere because there is no
> path.. Build the path by ourselves.
>
>
>
>
>
>
> Xuesong
>
>
>
>
>
>
>
>
>
> *From:* Teas [mailto:[e-mail] <[e-mail]>]
>
> *On Behalf Of *Jeff Tantsura
>
>
> *Sent:* Wednesday, August 26, 2020 6:32 AM
>
>
> *To:* TEAS WG <[e-mail]>; Jari Arkko <jari.arkko@piuha....net
> <[e-mail]>>
>
>
> *Cc:* Vishnu Pavan Beeram <[e-mail]>
>
>
> *Subject:* Re: [Teas] WG adoption -
> draft-nsdt-teas-transport-slice-definition - Appendix
>
>
>
>
>
>
>
>
>
>
>
>
>
> I find Pavan and Lou proposal reasonable and a good/working way forward.
>
>
> While isolation is not a directly measurable SLO, it is often a legally
> binding requirement wrt service provided, could be expressed as a physical
> SRLG or disjointness.
>
>
> It is also a viable constrain to be used in  a path computation logic.
>
>
> There are connectivity RFIs that explciteily require full physical
> separation/isolation - finance for security reasons,  DCI for resiliency,
> etc.
>
>
>
>
>
> We could pretend it doesn’t exist (which is the complete removal) or find
> an appropriate and acceptable to the WG description as the document
> evolves.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Cheers,
>
>
>
>
> Jeff
>
>
>
>
>
>
>
>
>
>
> On Aug 25, 2020, 12:59 PM -0700, Jari Arkko <[e-mail]>, wrote:
>
>
>
>
> High-level bit: I would like to see the document adopted. With changes if
> needed. Let the WG decide. Design teams are there just for preparing
> proposals. Authority to do stuff is entirely in the
>
> WG now.
>
>
>
>
>
> When it comes to the isolation topic, however, FWIW, I wanted to provide
> both a context from design team discussions and my personal perspective on
> this.
>
>
>
>
>
> Design team discussions:
>
>
>
>
>
> We’ve had variants of this discussion on almost all of the calls we’ve
> had for the last year. One one side there was our shared observation that
> industry uses the term isolation, and (perhaps less widely shared
>
> conclusion) that it is important to be able to relate to this. On the
> other side, there was our shared agreement that what matters from a
> requirement perspective is the bandwidth and other requirements, and that
> there are several techniques that can provide
>
> the desired characteristic of not having your neighbour affect the
> bandwidth the service provider has agreed to give you.
>
>
>
>
>
> The text that we had was in an appendix precisely because we felt that the
> top-level SLOs should be the requirement and are sufficient by themselves.
> The appendix only attempts to say that
>
> “there’s multiple ways to achieve this, and by the way, this term in the
> industry relates to our work in this indirect way”....
>
>
>
>
>
> I can appreciate that we may have failed in the task of writing that.
> Delete and move on, no biggie :-)
>
>
>
>
>
> Personal perspective:
>
>
>
>
>
> My impression of customer requirements and how they get represented
> matches with what Joel has been saying in this thread.
>
>
>
>
>
> I’m fine removing the appendix.
>
>
>
>
>
> If I had my way, I would write the document based entirely on the primary
> characteristics
>
> — such as that we promise you n GB/s. Then I would write a footnote or
> appendix somewhere that explains that this notion isolation has also been
> discussed elsewhere, and that it can be represented using the primary
> characteristics,
>
> and hence need not be discussed further in this document. One could
> perhaps also point out that there are multiple ways to implement the
> primary characteristics promises, so that those promises can be kept
> despite what’s happening
>
> with your neighbour’s traffic. And leave it at that. But I understand
> from this thread that people are reluctant to do that, and may even be
> reluctant to write anything about isolation. I’m fine with that,
>
> too.
>
>
>
>
>
> Jari
>
>
>
>
>
> _______________________________________________
>
>
> Teas mailing list
>
>
> [e-mail]
>
>
> https://www.ietf.org/mailman/listinfo/teas
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------
>
>
>
>
>
> 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
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Teas mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/teas
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD