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

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 19 Aug 2020 10:50:13 -0500

All,

This is start of a *three* week poll on making
draft-nsdt-teas-transport-slice-definition-03 a TEAS working group document.
Please send email to the list indicating "yes/support" or "no/do not
support". If indicating no, please state your reservations with the
document. If yes, please also feel free to provide comments you'd
like to see addressed once the document is a WG document.

The poll ends September 9th (extra week to account for vacation season).

Thanks,
Pavan and Lou

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 19 Aug 2020 12:04:20 -0400

Without repairs to the issues I have raised on the email list, I do not 
think this document should be adopted as a WG document.
We are close, but not quite there.

Yours,
Joel

On 8/19/2020 11:50 AM, Vishnu Pavan Beeram wrote:
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Kiran Makhijani <[email-masked]>
Date: Thu, 20 Aug 2020 18:54:41 +0000

Hi Joel,
After having replied to your comments, we have not heard further if they were convincing.
Please let us know. 
Thanks
Kiran

> -----Original Message-----
> From: Teas <[email-masked]> On Behalf Of Joel M. Halpern
> Sent: Wednesday, August 19, 2020 9:04 AM
> To: Vishnu Pavan Beeram <[email-masked]>; TEAS WG
> <[email-masked]>
> Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition
> 
> Without repairs to the issues I have raised on the email list, I do not think this
> document should be adopted as a WG document.
> > document. If yes, please also feel free to provide comments you'd like
> > to see addressed once the document is a WG document.
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40f
> utur
> >
> ewei.com%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b240189
> c753a1d
> >
> 5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2FGSlz2Q4%2B
> RAlZTXBv5
> > XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=0
> >
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fu
> turewei.com%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b2401
> 89c753a1d5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2FG
> Slz2Q4%2BRAlZTXBv5XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=0

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 20 Aug 2020 16:19:28 -0400

No, your replies did not in any way address my concerns.

I would suggest removing the references to TSRE and more importantly 
removing appendix A.1, or at least the last part of the appendix.

Yours,
Joel

---

From: Kiran Makhijani <[email-masked]>
Date: Thu, 20 Aug 2020 21:20:18 +0000

Hi Joel, 
I am ok to remove some part from Appendix only if it is included in the framework first.

But for the TSRE, I have proposed clearer and shorter text that they are not visible to the consumer of a transport slices. One of the purpose of definitions document is 'define' common terminology in the scope of transport slices, and all we are saying is that when realizing a transport slice, things TSEs will map to are called TSREs. 
I am not able to see the drawback of saying so.

Thanks
Kiran

> From: Joel Halpern Direct <[email-masked]>
> Sent: Thursday, August 20, 2020 1:19 PM
> To: Kiran Makhijani <[email-masked]>; Vishnu Pavan Beeram
> <[email-masked]>; TEAS WG <[email-masked]>
> >> Subject: Re: [Teas] WG adoption -
> >> draft-nsdt-teas-transport-slice-definition
> >>
> >> Without repairs to the issues I have raised on the email list, I do
> >> not think this document should be adopted as a WG document.
> ewei.com%7C7bb861e35ac84653b62208d8454659ac%7C0fee8ff2a3b240189
> c753a1d
> >
> 5591fedc%7C1%7C1%7C637335515772670726&amp;sdata=MZQKraVa8fj3BL
> sLRq9T9a
> > Ypp3C%2Bu1w9c7DgIVE6kE0%3D&amp;reserved=0
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 20 Aug 2020 19:00:10 -0400

Since I do not think that the material in the appendix is useful, I for 
one will not push for adding it to the Framework.  You are welcome to 
dabate adding it to the framework with the rest of the WG.  But it does 
not belong in the definitions draft.

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 20 Aug 2020 19:02:01 -0400

The rule of thumb for a standard is not to specify things you do not 
need, as what you actually need will likely turn out to be different, if 
you need it at all.

As such, I do not see any jsutification for including TSRE in this draft.

Having said that, this is not a hill I will die on.  If the WG chairs 
decide it is useful and belongs then fine, so be it.

Yours,
Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 21 Aug 2020 03:17:20 +0000

Hi Joel, 

In the design team there were several rounds of discussion about the content in the appendix and where it should be placed. The current text in the appendix reflects the consensus of the design team, although some minor edits were not included yet. 

As for whether some of the text in appendix will be moved to the framework document, currently the design team has no specific opinion about this, and feedbacks from WG are appreciated. While as Kiran mentioned, description and discussion about isolation is needed in the NS-DT documents.

Best regards,
Jie

> From: Teas [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Friday, August 21, 2020 7:00 AM
> Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition -
> Appendix
> 
> Since I do not think that the material in the appendix is useful, I for one will not
> push for adding it to the Framework.  You are welcome to dabate adding it to
> the framework with the rest of the WG.  But it does not belong in the
> definitions draft.
> 
> Yours,
> Joel
> 
> > But for the TSRE, I have proposed clearer and shorter text that they are not
> visible to the consumer of a transport slices. One of the purpose of definitions
> document is 'define' common terminology in the scope of transport slices, and
> all we are saying is that when realizing a transport slice, things TSEs will map to
> are called TSREs.
> >>> After having replied to your comments, we have not heard further if
> >>> they
> >> were convincing.
> >>> Please let us know.
> >>> Thanks
> >>> Kiran
> >>>
> >>>>> Please send email to the list indicating "yes/support" or "no/do
> >>>>> not support". If indicating no, please state your reservations
> >>>>> with the document. If yes, please also feel free to provide
> >>>>> comments you'd like to see addressed once the document is a WG
> document.
> >>>>>

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 20 Aug 2020 23:28:07 -0400

The consensus of the design team is relevant as a recommendation to the 
WG, but otherwise is not relevant for whether the WG should agree.  In 
terms of WG adoption, the design team draft has the same status as any 
other individual draft. The WG comes to its conclusion.

There is no obligation for the WG to retain the text from the appendix 
anywhere.  In particular, the WG is under no obligation to retain the 
last paragraph of teh appendix anywhere.

I have not seen any good argument for retaining the text.  It does not 
seem to add to or even fit with the purpose of the definitions draft. 
If anything, it is confusing at it seems to say "this is not a parameter 
/ this is a parameter"

Yours,
Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 21 Aug 2020 08:25:56 +0000

Hi Joel, 

Thanks for your clarification about the procedure. 

What I meant is to provide some background about the design team's discussion, which may help the WG to review and give comments on this draft. Of course the decision will be made by the WG. 

One of the reasons of keeping the isolation discussion in this draft is that isolation has been considered as one of the characteristics of network slicing in most of the related standards and publications, and it would be incomplete if the definition draft does not touch this. And in IETF history isolation has been considered as one requirement of VPNs, the discussion is necessary for explaining the relationship and difference between network slice and VPNs. Also note that in the last paragraph of the appendix, it tries to separate the requirements on isolation from several possible realization mechanism, which makes this description reasonably generic. 

Best regards,
Jie

> From: Joel Halpern Direct [mailto:[email-masked]]
> Sent: Friday, August 21, 2020 11:28 AM
> To: Dongjie (Jimmy) <[email-masked]>; Kiran Makhijani
> <[email-masked]>; Vishnu Pavan Beeram
> anywhere.  In particular, the WG is under no obligation to retain the last
> paragraph of teh appendix anywhere.
> 
> I have not seen any good argument for retaining the text.  It does not seem
> to add to or even fit with the purpose of the definitions draft.
> If anything, it is confusing at it seems to say "this is not a parameter / this is
> a parameter"
> 
> Yours,
> Joel
> 
> > In the design team there were several rounds of discussion about the
> content in the appendix and where it should be placed. The current text in
> the appendix reflects the consensus of the design team, although some
> minor edits were not included yet.
> >
> > As for whether some of the text in appendix will be moved to the
> framework document, currently the design team has no specific opinion
> about this, and feedbacks from WG are appreciated. While as Kiran
> mentioned, description and discussion about isolation is needed in the NS-DT
> documents.
> >
> > Best regards,
> > Jie
> >
> >> draft-nsdt-teas-transport-slice-definition - Appendix
> >>
> >> Since I do not think that the material in the appendix is useful, I
> >> for one will not push for adding it to the Framework.  You are
> >> welcome to dabate adding it to the framework with the rest of the WG.
> >> But it does not belong in the definitions draft.
> >>
> >> Yours,
> >> Joel
> >>
> >>> I am ok to remove some part from Appendix only if it is included in
> >>> the
> >> framework first.
> >>>
> >> visible to the consumer of a transport slices. One of the purpose of
> >> definitions document is 'define' common terminology in the scope of
> >> transport slices, and all we are saying is that when realizing a
> >> transport slice, things TSEs will map to are called TSREs.
> >>>> I would suggest removing the references to TSRE and more
> >>>> importantly removing appendix A.1, or at least the last part of the
> appendix.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>>> After having replied to your comments, we have not heard further
> >>>>> if they
> >>>> were convincing.
> >>>>> Please let us know.
> >>>>> Thanks
> >>>>> Kiran
> >>>>>
> >>>>>> Without repairs to the issues I have raised on the email list, I
> >>>>>> do not think this document should be adopted as a WG document.
> >>>>>>> draft-nsdt-teas-transport-slice-definition-03 a TEAS working
> >>>>>>> group
> >>>>>> document.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w
> >>>>>> .i
> >>>>
> >>

---

From: "Luis M. Contreras" <[email-masked]>
Date: Fri, 21 Aug 2020 10:49:03 +0200

Hi Jie, Joel, all,

Just to share my view. The idea of isolation is intrinsically related to
the notion of slice in the industry, and as such it should be covered in
the definitions draft when referring to transport slices.

The development of what isolation implies, in practical terms, could go to
the framework draft or to any other specific document, and for sure we can
expect references to degrees of isolation achieved in the mapping of
slicing mechanisms to distinct transport technologies through the SBI of
the TSC.

Not covering isolation at all, basically makes the work on transport
slicing incomplete from an operator’s perspective.

In that sense I support keeping the text on isolation (as an annex or in
the main part of the document). For sure the text can be always improved,
but as it is now is a sufficiently generic definition to facilitate the
development of its scope when applied to transport slicing in any other
document.

Best regards,

Luis

El vie., 21 ago. 2020 a las 10:26, Dongjie (Jimmy) (<[email-masked]>)
escribió:

> What I meant is to provide some background about the design team's
> discussion, which may help the WG to review and give comments on this
> draft. Of course the decision will be made by the WG.
>
> One of the reasons of keeping the isolation discussion in this draft is
> that isolation has been considered as one of the characteristics of network
> slicing in most of the related standards and publications, and it would be
> incomplete if the definition draft does not touch this. And in IETF history
> isolation has been considered as one requirement of VPNs, the discussion is
> necessary for explaining the relationship and difference between network
> slice and VPNs. Also note that in the last paragraph of the appendix, it
> tries to separate the requirements on isolation from several possible
> realization mechanism, which makes this description reasonably generic.
>
> Best regards,
> Jie
>
>
> seem
> / this is
> > w.
> > w.

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

---

From: David Sinicrope <[email-masked]>
Date: Fri, 21 Aug 2020 13:10:36 +0000

Jie,
You note “isolation has been considered as one of the characteristics of network slicing in most of the related standards and publications, and it would be incomplete if the definition draft does not touch this. And in IETF history isolation has been considered as one requirement of VPNs, the discussion is necessary for explaining the relationship and difference between network slice and VPNs.”

I’m not sure where this is coming from. Do you have references to support these claims?  I’m specifically referring to the claim that “most” related standards and publications consider isolation as a characteristic.  This has not been my experience at all over the last 3 decades including the history of the IETF.

If anything the history of work on VPNs deals with identification of the traffic associated with the VPN not its isolation. Any treatment or characteristic of that traffic has been a function of QoS.

Isolation, in my experience, has not been part of the discussion or texts until the introduction of network slicing and only introduced by a subset of the community.

I agree the text on isolation is confusing and not needed.  I also ask that it be removed.

Thanks,
Dave

________________________________
From: Teas <[email-masked]> on behalf of Dongjie (Jimmy) <[email-masked]>
Sent: Friday, August 21, 2020 4:26 AM
To: Joel Halpern Direct; Kiran Makhijani; Vishnu Pavan Beeram; TEAS WG
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Hi Joel,

Best regards,
Jie

> https://protect2.fireeye.com/v1/url?k=7d132922-23b3ea8b-7d1369b9-86959e472243-a669baec95ff5981&q=1&e=8a1db88d-cb42-478e-8eb8-da70acca25e3&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww
> w.
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://protect2.fireeye.com/v1/url?k=19c50183-4765c22a-19c54118-86959e472243-be7fb3e456e3f9a6&q=1&e=8a1db88d-cb42-478e-8eb8-da70acca25e3&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww
> w
> >>>>>> .i
> >>>>
> >>
> https://protect2.fireeye.com/v1/url?k=d37b5edd-8ddb9d74-d37b1e46-86959e472243-a54dacfae536c914&q=1&e=8a1db88d-cb42-478e-8eb8-da70acca25e3&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww
> w.
> >>>>>
> >>>>
> >>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 21 Aug 2020 11:42:00 -0400

Luis, I think I disagree with you.
Not of course, about the question of whether operators care about 
isolation properties.
But about whether it belongs in this document.

I am quite sure that when designing services for customers, you and your 
team worry about many forms of isolation.  Many of which do not appear 
in the eventual SLA (even if they do occur in informal discussion).  And 
many of which do not appear as explicit parameters on any of the interfaces.

The authors attempted t provide an observable definition of isolation. 
They were not able to do so.  The text they now have tries to claim 
utility, claims relevance to the customer, but is not acutally usable in 
designing a service.

"Isolation" as a network property probably is actually many different 
properties.  For example, a bandwidth commitment (which we do have in 
the definitions) is a form of isolation.  A delay variation commitment 
is a form of isolation.  But as a term on its own, separate from these 
parameters, "isolation" does not add value to this document.

Also remember that no document we produce will be or can bee complete. 
We produce useful pieces.  You put them together.  As an operator you 
add your many constraints, your customers goals and constraints, and you 
build and deliver service.

Yours,
Joel

On 8/21/2020 4:49 AM, Luis M. Contreras wrote:
> The development of what isolation implies, in practical terms, could go 
> to the framework draft or to any other specific document, and for sure 
> we can expect references to degrees of isolation achieved in the mapping 
> of slicing mechanisms to distinct transport technologies through the SBI 
> of the TSC.
> 
> the main part of the document). For sure the text can be always 
> improved, but as it is now is a sufficiently generic definition to 
> facilitate the development of its scope when applied to transport 
> slicing in any other document.
> 
> Best regards,
> 
> Luis
> 
> 
> El vie., 21 ago. 2020 a las 10:26, Dongjie (Jimmy) (<[email-masked] 
> <mailto:[email-masked]>>) escribió:
> 
>     Hi Joel,
> 
>     discussion, which may help the WG to review and give comments on
>     this draft. Of course the decision will be made by the WG.
> 
>     One of the reasons of keeping the isolation discussion in this draft
>     is that isolation has been considered as one of the characteristics
>     of network slicing in most of the related standards and
>     publications, and it would be incomplete if the definition draft
>     does not touch this. And in IETF history isolation has been
>     considered as one requirement of VPNs, the discussion is necessary
>     for explaining the relationship and difference between network slice
>     and VPNs. Also note that in the last paragraph of the appendix, it
>     tries to separate the requirements on isolation from several
>     possible realization mechanism, which makes this description
>     reasonably generic.
> 
>     Best regards,
>     Jie
> 
> 
>      > From: Joel Halpern Direct [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      > To: Dongjie (Jimmy) <[email-masked]
>     <mailto:[email-masked]>>; Kiran Makhijani
>      > <[email-masked] <mailto:[email-masked]>>; Vishnu
>     Pavan Beeram
>      > <[email-masked] <mailto:[email-masked]>>; TEAS WG
>     <[email-masked] <mailto:[email-masked]>>
>      > >> From: Teas [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Joel M.
>      > >> Halpern
>      > >> To: Kiran Makhijani <[email-masked]
>     <mailto:[email-masked]>>; Vishnu Pavan Beeram
>      > >> <[email-masked] <mailto:[email-masked]>>; TEAS
>     WG <[email-masked] <mailto:[email-masked]>>
>      > >>> But for the TSRE, I have proposed clearer and shorter text
>     that they
>      > >>> are not
>      > >>>> From: Joel Halpern Direct <[email-masked]
>     <mailto:[email-masked]>>
>      > >>>> To: Kiran Makhijani <[email-masked]
>     <mailto:[email-masked]>>; Vishnu Pavan Beeram
>      > >>>> <[email-masked] <mailto:[email-masked]>>; TEAS
>     WG <[email-masked] <mailto:[email-masked]>>
>      > >>>>>> From: Teas <[email-masked]
>     <mailto:[email-masked]>> On Behalf Of Joel M. Halpern
>      > >>>>>> To: Vishnu Pavan Beeram <[email-masked]
>     <mailto:[email-masked]>>; TEAS WG
>      > >>>>>> <[email-masked] <mailto:[email-masked]>>
>      > >>>>>>> The poll ends September 9th (extra week to account for
>     vacation
>      > >> season).
>      > >>>>>>>
>      > >>>>>>> Thanks,
>      > >>>>>>> Pavan and Lou
>      > >>>>>>>
>      > >>>>>>> [email-masked] <mailto:[email-masked]>
>      > >>>>>>>
>      > >>>>>>
>      > >>>>
>      > >>
>      > ietf.org
>     <http://ietf.org>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40
>      > f
>      > >>>>>> utur
>      > >>>>>>>
>      > >>>>>>
>      > >>>>
>      > >>
>      > ewei.com
>     <http://ewei.com>%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b24018
>      > 9
>      > >>>>>> c753a1d
>      > >>>>>>>
>      > >>>>>>
>      > >>>>
>      > >>
>      > >>>>>> [email-masked] <mailto:[email-masked]>
>      > >>>>>>
>      > >>>>
>      > >>
>      > etf.org
>     <http://etf.org>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40f
>      > u
>      > >>>>>>
>      > >>>>
>      > >>
>      > turewei.com
>     <http://turewei.com>%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b24
>      > 01
>      > >>>>>>
>      > >>>>
>      > >>
>      > >>>>> [email-masked] <mailto:[email-masked]>
>      > >>>>>
>      > >>>>
>      > >>
>      > ietf.org
>     <http://ietf.org>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40
>      > f
>      > >>>> utur
>      > >>>>>
>      > >>>>
>      > >>
>      > ewei.com
>     <http://ewei.com>%7C7bb861e35ac84653b62208d8454659ac%7C0fee8ff2a3b24018
>      > 9
>      > >>>> c753a1d
>      > >>>>>
>      > >>>>
>      > >>
>      > >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 21 Aug 2020 15:50:43 +0000

Hi,

(speaking as an individual)

While the document is in it's early stages, I think it is important to sort out this use of the term "isolation". Already by use of the term "transport", the scope of this work may be confused with the traditional definition of a transport network and overlapping with ITU-T SG15's transport technologies. Important is to define "transport" carefully for the IETF context, which I think this document is a good start. Mixing "isolation" with "dedicated resources" is a step back to the traditional definition.

As the authors note, the term "isolation" is used in other SDOs, including 3GPP, but it is used differently. Here's a recent publicly available white paper from ETSI NFV which summarizes the requirements from 3GPP for network slicing:
https://www.etsi.org/deliver/etsi_gr/NFV-EVE/001_099/012/03.01.01_60/gr_NFV-EVE012v030101p.pdf

In this ETSI document, when they discuss isolation properties, physical resources are not mentioned, they discuss performance, resiliency, security, privacy and management. 3GPP recognizes resources may be logical or physical (and either fully or partly), it is not a "requirement". Physical and virtual resources are used with respect to "realize", not define.

I agree with Joel and Dave, I think Appendix A's example saying a customer will request "dedicated resources" and saying the solution of using dedicated resources (vs. VPN)  guarantees the requirements are met, clashes with the rest of the document (section 5.3 and section 6) which carefully defines resources not as defining a slice but for realizing a slice. Maybe the authors intended it to be an example, but it is too confusing in the context of this document to mix the definition of "isolation" with "dedicated resources". While an Appendix, it should not clash with the main document. Best is to remove for now.

Thanks,
Deborah
(individual)

From: Teas <[email-masked]> On Behalf Of David Sinicrope
Sent: Friday, August 21, 2020 9:11 AM
To: Dongjie (Jimmy) <[email-masked]>; Joel Halpern Direct <[email-masked]>; Kiran Makhijani <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Jie,
You note "isolation has been considered as one of the characteristics of network slicing in most of the related standards and publications, and it would be incomplete if the definition draft does not touch this. And in IETF history isolation has been considered as one requirement of VPNs, the discussion is necessary for explaining the relationship and difference between network slice and VPNs."

I'm not sure where this is coming from. Do you have references to support these claims?  I'm specifically referring to the claim that "most" related standards and publications consider isolation as a characteristic.  This has not been my experience at all over the last 3 decades including the history of the IETF.

Thanks,
Dave

From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>

Hi Joel,

Best regards,
Jie

> To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani
> <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram
> <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
> >> To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram
> >> <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
> >>>> From: Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
> >>>> To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram
> >>>> <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
> >>>>>> From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
> >>>>>> To: Vishnu Pavan Beeram <vishnupavan@gmail..com<mailto:vishnupavan@gmail..com>>; TEAS WG
> >>>>>> <[email-masked]<mailto:[email-masked]>>
> >>>>>>> [email-masked]<mailto:[email-masked]>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://protect2.fireeye.com/v1/url?k=7d132922-23b3ea8b-7d1369b9-86959e472243-a669baec95ff5981&q=1&e=8a1db88d-cb42-478e-8eb8-da70acca25e3&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww<https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3D7d132922-2D23b3ea8b-2D7d1369b9-2D86959e472243-2Da669baec95ff5981-26q-3D1-26e-3D8a1db88d-2Dcb42-2D478e-2D8eb8-2Dda70acca25e3-26u-3Dhttps-253A-252F-252Fnam11.safelinks.protection.outlook.com-252F-253Furl-253Dhttps-25253A-25252F-25252Fww&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=bUkqIf98ir2n0fhlYgEu_c2k4w8oW1idwDGwyySsfhA&e=>
> w.
> >>>>>>>
> >>>>>>
> >>>>
> >>
> >>>>>> [email-masked]<mailto:[email-masked]>
> >>>>>>
> >>>>
> >>
> https://protect2.fireeye.com/v1/url?k=19c50183-4765c22a-19c54118-86959e472243-be7fb3e456e3f9a6&q=1&e=8a1db88d-cb42-478e-8eb8-da70acca25e3&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww<https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3D19c50183-2D4765c22a-2D19c54118-2D86959e472243-2Dbe7fb3e456e3f9a6-26q-3D1-26e-3D8a1db88d-2Dcb42-2D478e-2D8eb8-2Dda70acca25e3-26u-3Dhttps-253A-252F-252Fnam11.safelinks.protection.outlook.com-252F-253Furl-253Dhttps-25253A-25252F-25252Fww&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=VhW4TGe4z7ZeD8qijXBRD9ZkiGcGBi0YJ6buh0kXY6A&e=>
> w
> >>>>>> .i
> >>>>
> >>
> >>>>> [email-masked]<mailto:[email-masked]>
> >>>>>
> >>>>
> >>
> https://protect2.fireeye.com/v1/url?k=d37b5edd-8ddb9d74-d37b1e46-86959e472243-a54dacfae536c914&q=1&e=8a1db88d-cb42-478e-8eb8-da70acca25e3&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww<https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3Dd37b5edd-2D8ddb9d74-2Dd37b1e46-2D86959e472243-2Da54dacfae536c914-26q-3D1-26e-3D8a1db88d-2Dcb42-2D478e-2D8eb8-2Dda70acca25e3-26u-3Dhttps-253A-252F-252Fnam11.safelinks.protection.outlook.com-252F-253Furl-253Dhttps-25253A-25252F-25252Fww&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=KontY0Ex6UJRo2EpGG4LrA-TsJBJxvvILb-PVW6PMdI&e=>
> w.
> >>>>>
> >>>>
> >>
> >> [email-masked]<mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/teas<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=OFFFT8ma706KrhOLX304z0qEw74Wg7S_eelu5EONhKs&e=>
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=OFFFT8ma706KrhOLX304z0qEw74Wg7S_eelu5EONhKs&e=>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 21 Aug 2020 08:57:50 -0700

Hi Jie,
I hope you or other proponents of the continued use of isolation metric
help me to understand how it can be measured or calculated. Personally, I
can only compare it to the connectivity verification that, as part of the
Fault Management OAM toolset, allows us to detect the state of
misconnection for the given OAM domain. Do you think that the connectivity
check is related to slice isolation? What else can be used as a metric to
quantify the slice isolation? I am concerned, that if the
document introduces something that is not measurable or calculable, that
something is not really useful and may not be needed at all.

Regards,
Greg

---

From: Kiran Makhijani <[email-masked]>
Date: Fri, 21 Aug 2020 22:52:42 +0000

Hi Joel, 
Looks like your main concern is that text seem to say that isolation is observable.  

That's not the intent. We just wanted to scope 'isolation' with in the context of transport slices not define it. During IETF 107 you gave a feedback that isolation is not directly observable, and we all completely agreed, dropped a lot of text accordingly.

In this text, the important piece is to capture that customer could also be very specific about asking "my traffic should be separated from (or should have no interference with) other traffic". 
This is not covered in the document and without such clarification, we cannot scope NBI properly. I was thinking if we define 'isolation' then that can be a container in NBI. One common use case where customer could ask this is financial institutions or critical infrastructure explicitly asking for a (or a set of) physical ports or links. 

The last para simply says there are 3 related things that customer could explicitly ask for (termed as 'isolation') and when realizing transport slices operators could possibly do so & so to meet those asks.

An alternative to deleting the text maybe  - don’t use term isolation but describe explicit requirement of traffic separation. And maybe clearly say this is not 'directly' observable and will rely on other means of monitoring that are case specific such as mapping physical port counters to service counters etc.

-Kiran

> From: Joel M. Halpern <[email-masked]>
> Sent: Friday, August 21, 2020 8:42 AM
> To: Luis M. Contreras <[email-masked]>; Dongjie (Jimmy)
> <[email-masked]>
> Cc: Kiran Makhijani <[email-masked]>; Vishnu Pavan Beeram
> <[email-masked]>; TEAS WG <[email-masked]>; LUIS MIGUEL
> CONTRERAS MURILLO <[email-masked]>
> Not of course, about the question of whether operators care about isolation
> properties.
> I am quite sure that when designing services for customers, you and your team
> worry about many forms of isolation.  Many of which do not appear in the
> eventual SLA (even if they do occur in informal discussion).  And many of which
> do not appear as explicit parameters on any of the interfaces.
> 
> They were not able to do so.  The text they now have tries to claim utility,
> claims relevance to the customer, but is not actually usable in designing a
> service.
> 
> properties.  For example, a bandwidth commitment (which we do have in the
> definitions) is a form of isolation.  A delay variation commitment is a form of
> isolation.  But as a term on its own, separate from these parameters, "isolation"
> does not add value to this document.
> 
> We produce useful pieces.  You put them together.  As an operator you add
> your many constraints, your customers goals and constraints, and you build and
> deliver service.
> 
> Yours,
> Joel
> 
> > Just to share my view. The idea of isolation is intrinsically related
> > to the notion of slice in the industry, and as such it should be
> > covered in the definitions draft when referring to transport slices.
> >
> > The development of what isolation implies, in practical terms, could
> > go to the framework draft or to any other specific document, and for
> > sure we can expect references to degrees of isolation achieved in the
> > mapping of slicing mechanisms to distinct transport technologies
> > through the SBI of the TSC.
> >
> > In that sense I support keeping the text on isolation (as an annex or
> > in the main part of the document). For sure the text can be always
> >      > paragraph of the appendix anywhere.
> >      >
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.or
> g%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C6e84819cea1748c
> 9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63
> 7336213276038270&amp;sdata=YEYEYBqLKk3v%2BrBZ%2FvEqYRqPq9m1eITo
> eHak5DEVtDQ%3D&amp;reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;da
> ta=02%7C01%7Ckiranm%40
> >      > f
> >      > >>>>>> utur
> >      > >>>>>>>
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      > ewei.com
> >
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.c
> om%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C6e84819cea174
> 8c9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C
> 637336213276038270&amp;sdata=PDkVSDt7Cr1L01rmtnysaKRRafqOmKfrr9sN
> G%2BmbpcA%3D&amp;reserved=0>%7Cf26ab959470747a36b2808d84459a35
> 1%7C0fee8ff2a3b24018
> >      > 9
> >      > >>>>>> c753a1d
> >      > >>>>>>>
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      >
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org
> %2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C6e84819cea1748c
> 9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63
> 7336213276038270&amp;sdata=He3XPdNABefXKOz92Z0QYR2Va2KIe43lclCTD7
> 12p5M%3D&amp;reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;data=02
> %7C01%7Ckiranm%40f
> >      > u
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      > turewei.com
> >
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturew
> ei.com%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C6e84819cea
> 1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0
> %7C637336213276038270&amp;sdata=7PuKdwn1Yyw9PIxiIfj62%2Bya%2FBPG
> fkCKgMnpTNbtAPs%3D&amp;reserved=0>%7Cf26ab959470747a36b2808d844
> 59a351%7C0fee8ff2a3b24
> >      > 01
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      >
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.or
> g%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C6e84819cea1748c
> 9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63
> 7336213276038270&amp;sdata=YEYEYBqLKk3v%2BrBZ%2FvEqYRqPq9m1eITo
> eHak5DEVtDQ%3D&amp;reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;da
> ta=02%7C01%7Ckiranm%40
> >      > f
> >      > >>>> utur
> >      > >>>>>
> >      > >>>>
> >      > >>
> >      > ewei.com
> >
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.c
> om%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C6e84819cea174
> 8c9f64308d845e8c14b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C
> 637336213276038270&amp;sdata=PDkVSDt7Cr1L01rmtnysaKRRafqOmKfrr9sN
> G%2BmbpcA%3D&amp;reserved=0>%7C7bb861e35ac84653b62208d8454659a
> c%7C0fee8ff2a3b24018
> >      > 9
> >      > >>>> c753a1d
> >      > >>>>>
> >      > >>>>
> >      > >>
> >      >
> etf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fut
> urewei.com%7C6e84819cea1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c
> 753a1d5591fedc%7C1%7C0%7C637336213276038270&amp;sdata=7y5PXKjGP
> WZBvHzDObgm3N64pexXe8yeS8zH0YpWfNw%3D&amp;reserved=0
> ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fut
> ur
> >
> ewei.com%7C6e84819cea1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c75
> 3a1d
> >
> 5591fedc%7C1%7C0%7C637336213276038270&amp;sdata=7y5PXKjGPWZBvHz
> DObgm3N
> > 64pexXe8yeS8zH0YpWfNw%3D&amp;reserved=0
> >
> >
> >
> > --

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 21 Aug 2020 16:21:14 -0700

Hi Kiran,
I have to admit that I'm confused by the last paragraph in your note.
First, you agree that isolation interpreted is not observable (though I am
not sure what quote marks around directly signify). But then you add "will
rely on other means of monitoring". Isn't any type of monitoring, in fact,
a method of a direct observation?
Also, I sense that one of the motivations behind using the term isolation
is to differentiate between physical and virtual instances that provide a
service, e.g., physical link vs. a link in the overlay network. If that is
the case, perhaps we can avoid the contention around the use of the term
isolation as SLO and instead add a parameter that can have two values,
physical and virtual?

Regards,
Greg

On Fri, Aug 21, 2020 at 3:53 PM Kiran Makhijani <[email-masked]>
wrote:

> That's not the intent. We just wanted to scope 'isolation' with in the
> context of transport slices not define it. During IETF 107 you gave a
> feedback that isolation is not directly observable, and we all completely
> agreed, dropped a lot of text accordingly.
>
> In this text, the important piece is to capture that customer could also
> be very specific about asking "my traffic should be separated from (or
> should have no interference with) other traffic".
> This is not covered in the document and without such clarification, we
> cannot scope NBI properly. I was thinking if we define 'isolation' then
> that can be a container in NBI. One common use case where customer could
> ask this is financial institutions or critical infrastructure explicitly
> asking for a (or a set of) physical ports or links.
>
> The last para simply says there are 3 related things that customer could
> explicitly ask for (termed as 'isolation') and when realizing transport
> slices operators could possibly do so & so to meet those asks.
>
> An alternative to deleting the text maybe  - don’t use term isolation but
> describe explicit requirement of traffic separation. And maybe clearly say
> this is not 'directly' observable and will rely on other means of
> monitoring that are case specific such as mapping physical port counters to
> service counters etc.
>
> -Kiran
>
> isolation
> team
> utility,
> > >      > anywhere.  In particular, the WG is under no obligation to
> retain
> > >     the last
> > >      > >>>> importantly removing appendix A.1, or at least the last
> part
> > >     of the
> > >      > appendix.
> > >      > >>>>
> > >      > >>>> Yours,
> > >      > >>>> Joel
> > >      > >>>>
> > >      > >>>>>>> Please send email to the list indicating "yes/support"
> or
> > >     "no/do
> > >      > >>>>>>> comments you'd like to see addressed once the document
> is
> > >     a WG
> > >      > >> document.
> > >      > >>>>>>>
> > <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.or
> > <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org
> > <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.or

---

From: Kiran Makhijani <[email-masked]>
Date: Sat, 22 Aug 2020 01:28:10 +0000

Please see inline

From: Greg Mirsky <[email-masked]>
Sent: Friday, August 21, 2020 4:21 PM
To: Kiran Makhijani <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; Luis M. Contreras <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Hi Kiran,
I have to admit that I'm confused by the last paragraph in your note.
First, you agree that isolation interpreted is not observable (though I am not sure what quote marks around directly signify). But then you add "will rely on other means of monitoring". Isn't any type of monitoring, in fact, a method of a direct observation?
[KM] It is not direct monitoring, it is an inference from some other piece of information. (I was just thinking out loud, how could you prove it)
Also, I sense that one of the motivations behind using the term isolation is to differentiate between physical and virtual instances that provide a service, e.g., physical link vs. a link in the overlay network. If that is the case, perhaps we can avoid the contention around the use of the term isolation as SLO
[KM] it is not an SLO, it is an additional ask or specification.
and instead add a parameter that can have two values, physical and virtual?
[KM] Yes, it could work but it is too specific to the example, what if there were others. I prefer something along the lines of traffic-separation.

Regards,
Greg

On Fri, Aug 21, 2020 at 3:53 PM Kiran Makhijani <[email-masked]<mailto:[email-masked]>> wrote:
Hi Joel,
Looks like your main concern is that text seem to say that isolation is observable.

-Kiran

> From: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
> To: Luis M. Contreras <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy)
> <[email-masked]<mailto:[email-masked]>>
> Cc: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram
> <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; LUIS MIGUEL
> CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>
> > El vie., 21 ago. 2020 a las 10:26, Dongjie (Jimmy)
> > (<[email-masked]<mailto:[email-masked]>
> > <mailto:[email-masked]<mailto:[email-masked]>>>) escribió:
> >
> >     Hi Joel,
> >
> >      > From: Joel Halpern Direct [mailto:[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>]
> >      > To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>>; Kiran Makhijani
> >      > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Vishnu
> >     Pavan Beeram
> >      > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; TEAS WG
> >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> >      > >> From: Teas [mailto:[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>] On Behalf Of Joel M.
> >      > >> Halpern
> >      > >> To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>>; Vishnu Pavan Beeram
> >      > >> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; TEAS
> >     WG <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> >      > >>>> From: Joel Halpern Direct <[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>>
> >      > >>>> To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>>; Vishnu Pavan Beeram
> >      > >>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
> TEAS
> >     WG <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> >      > >>>>>> From: Teas <[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>> On Behalf Of Joel M. Halpern
> >      > >>>>>> To: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>>; TEAS WG
> >      > >>>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> >      > >>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >      > >>>>>>>
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      >
> >      > ietf.org<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898959798&sdata=i%2FH%2Fm%2FGG4ritzVpp08xIzXIK4YNiMj6Bqinei%2F7mGiI%3D&reserved=0>
> >
> g%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898969798&sdata=0vi%2FPjQDQF784ogZ3pZMeGneN4bceuPPuihcHOoeBTU%3D&reserved=0>%7C6e84819cea1748c
> >      > ewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898969798&sdata=k49Ao2avtmNlZZSLxFrtYPkzSSJ12W6dcAnSZfR6IGA%3D&reserved=0>
> >
> om%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898979787&sdata=OPhISgDytgKqV7i9r2sIcriQd6XIt0eBZYZi7B0HYt4%3D&reserved=0>%7C6e84819cea174
> >      > >>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      >
> >      > etf.org<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898989785&sdata=qk3DEhb0CDuMWuv5Bvby5v8hASoBaedDVA5KWyaVvUU%3D&reserved=0>
> >
> %2F&amp;data=02%7C01%7Ckiranm%40futurewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898989785&sdata=nwlLNsIR4YHNSqH6FkKSmiY9RQr3v4AqNc8oJm2JpaI%3D&reserved=0>%7C6e84819cea1748c
> >      > turewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898999777&sdata=gmGb4yQzcuu%2Ba3gy2Vk7g9ArOPYJEJ2nuEKV0dPV97Q%3D&reserved=0>
> >
> ei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898999777&sdata=NqB51hPKoN7hh7lCvTw4EZ8jc%2Bp86Wz4ydg0uI2K%2BVM%3D&reserved=0>%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899009773&sdata=A6VwFF%2BX9vWDkDbubs6ZwJ5yWecRxCH27Il1chW3fGE%3D&reserved=0>%7C6e84819cea
> >      > >>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >      > >>>>>
> >      > >>>>
> >      > >>
> >      >
> >      > ietf.org<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899009773&sdata=YtwHjHJMdexxmf%2FgOtni7FuMCK%2BoN1tEzO83sKs39vQ%3D&reserved=0>
> >
> g%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899019770&sdata=Ebx7iTH1ZHOZYHLJRPJkiTOq2f101QGxoj7diCDpLy0%3D&reserved=0>%7C6e84819cea1748c
> >      > ewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899029764&sdata=L6TlRSA7R%2FUEhvbO1G7ILnBQrB6v%2BE4HKXwZrep8MnE%3D&reserved=0>
> >
> om%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899029764&sdata=Srzj8P8Wtu%2BjzqWJraL01gfMDOQPos%2F6ld8NWW4xT%2BI%3D&reserved=0>%7C6e84819cea174
> >      > >> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >      > >>
> etf.org<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899039761&sdata=Hj%2B1D5kmLTUoVvYkj1MfuXhJvEP62dzttTslX7mFFdQ%3D&reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fut
> urewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Furewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899039761&sdata=Vmir%2FW4ezf1i5fEseTzWYPycP%2FYBEERhEY031WZLWf8%3D&reserved=0>%7C6e84819cea1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c
> >     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >
> >
> ietf.org<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899049755&sdata=tvLFMHdzMdqH6k9k977HSkSpfcTmCKZoXrdo7cwW9AQ%3D&reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fut
> ur
> >
> ewei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899049755&sdata=ZW9NvXJ6ux5gcNvgjWII%2BQsGaL3YRKS32Q8Bh1uFseg%3D&reserved=0>%7C6e84819cea1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c75
> 3a1d
> >
> > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > [email-masked]<mailto:[email-masked]>
> > <mailto:[email-masked]<mailto:[email-masked]>>
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899059751&sdata=KzFInnEA4Q3bmCD1NXkAX6dCxrzJwT%2BKv1NbOAcYX1o%3D&reserved=0>

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 21 Aug 2020 21:38:19 -0400

I think Kiran that you are missing the point.
What actually matters are the measurables, not the inferences.

Sure, in the sales discussions if a customer asks "will my traffic be 
protected from competing traffic?" the answer will be "Yes, of course." 
When it comes time to write the contract and the SLA, which uses the 
SLOs, the contract terms will say things like
     Traffic X will always have avaiable bandwidth Y.
        [unstated, but assumed is "regardless of competing traffic"]
or
     Traffic Z will be delivered with delay variation less than A.
         [unstated, but assumed is "regardless of competing traffic"]

Isolation is not something special.  And it is not something that can be 
written into a customer agreement as a freestanding term.  Unless it is 
related to a measurable, none of the customer, the operator, or a judge 
trying to enforce the contract will know whether it has been met.

Similarly, what goes over the (northbound) interface this document is 
concerned with has to be measurables.  Otherwise they are not 
deliverable.  (And this applies to any derived southbound as well.)

The text in Appendix A simply sserves to confuse readers as to what we 
are doing.  Please, remove it.

Yours,
Joel

On 8/21/2020 9:28 PM, Kiran Makhijani wrote:
> Please see inline
> 
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Friday, August 21, 2020 4:21 PM
> *To:* Kiran Makhijani <[email-masked]>
> *Cc:* Joel M. Halpern <[email-masked]>; Luis M. Contreras 
> <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; LUIS 
> MIGUEL CONTRERAS MURILLO <[email-masked]>; 
> Vishnu Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>
> *Subject:* Re: [Teas] WG adoption - 
> First, you agree that isolation interpreted is not observable (though I 
> am not sure what quote marks around directly signify). But then you add 
> "will rely on other means of monitoring". Isn't any type of monitoring, 
> in fact, a method of a direct observation?
> 
> */[KM] It is not direct monitoring, it is an inference from some other 
> piece of information. (I was just thinking out loud, how could you prove 
> it)/*
> 
> Also, I sense that one of the motivations behind using the term 
> isolation is to differentiate between physical and virtual instances 
> that provide a service, e.g., physical link vs. a link in the overlay 
> network. If that is the case, perhaps we can avoid the contention around 
> the use of the term isolation as SLO
> 
> */[KM] it is not an SLO, it is an additional ask or specification./*
> 
> */[KM] Yes, it could work but it is too specific to the example, what if 
> there were others. I prefer something along the lines of 
> traffic-separation./*
> 
> Regards,
> 
> Greg
> 
>     That's not the intent. We just wanted to scope 'isolation' with in
>     the context of transport slices not define it. During IETF 107 you
>     gave a feedback that isolation is not directly observable, and we
>     all completely agreed, dropped a lot of text accordingly.
> 
>     In this text, the important piece is to capture that customer could
>     also be very specific about asking "my traffic should be separated
>     from (or should have no interference with) other traffic".
>     This is not covered in the document and without such clarification,
>     we cannot scope NBI properly. I was thinking if we define
>     'isolation' then that can be a container in NBI. One common use case
>     where customer could ask this is financial institutions or critical
>     infrastructure explicitly asking for a (or a set of) physical ports
>     or links.
> 
>     The last para simply says there are 3 related things that customer
>     could explicitly ask for (termed as 'isolation') and when realizing
>     transport slices operators could possibly do so & so to meet those asks.
> 
>     An alternative to deleting the text maybe  - don’t use term
>     isolation but describe explicit requirement of traffic separation.
>     And maybe clearly say this is not 'directly' observable and will
>     rely on other means of monitoring that are case specific such as
>     mapping physical port counters to service counters etc.
> 
>     -Kiran
> 
>      > To: Luis M. Contreras <[email-masked]
>     <mailto:[email-masked]>>; Dongjie (Jimmy)
>      > <[email-masked] <mailto:[email-masked]>>
>      > Cc: Kiran Makhijani <[email-masked]
>     <[email-masked] <mailto:[email-masked]>>; LUIS MIGUEL
>      > CONTRERAS MURILLO <[email-masked]
>     <mailto:[email-masked]>>
>      > > (<[email-masked] <mailto:[email-masked]>
>      > > <mailto:[email-masked] <mailto:[email-masked]>>>)
>     escribió:
>      > >
>      > >     Hi Joel,
>      > >
>      > >      > -----Original Message-----
>      > >      > From: Joel Halpern Direct
>     [mailto:[email-masked] <mailto:[email-masked]>
>      > >      > Sent: Friday, August 21, 2020 11:28 AM
>      > >      > To: Dongjie (Jimmy) <[email-masked]
>     <mailto:[email-masked]>
>      > >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>     Kiran Makhijani
>      > >      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; Vishnu
>      > >     Pavan Beeram
>      > >      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; TEAS WG
>      > >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      > >      > Subject: Re: [Teas] WG adoption -
>      > >     draft-nsdt-teas-transport-slice-definition -
>      > >      > Appendix
>      > >      >
>      > >      > The consensus of the design team is relevant as a
>     recommendation
>      > >     to the
>      > >      > WG, but otherwise is not relevant for whether the WG should
>      > >     agree.  In
>      > >      > terms of WG adoption, the design team draft has the same
>     status
>      > >     as any
>      > >      > other individual draft. The WG comes to its conclusion.
>      > >      >
>      > >      > There is no obligation for the WG to retain the text
>     from the
>      > >     appendix
>      > >      > anywhere.  In particular, the WG is under no obligation
>     to retain
>      > >     the last
>      > >      > paragraph of the appendix anywhere.
>      > >      >
>      > >      > I have not seen any good argument for retaining the
>     text.  It
>      > >     does not seem
>      > >      > to add to or even fit with the purpose of the
>     definitions draft.
>      > >      > If anything, it is confusing at it seems to say "this is
>     not a
>      > >     parameter / this is
>      > >      > a parameter"
>      > >      >
>      > >      > Yours,
>      > >      > Joel
>      > >      >
>      > >      > On 8/20/2020 11:17 PM, Dongjie (Jimmy) wrote:
>      > >      > > Hi Joel,
>      > >      > >
>      > >      > > In the design team there were several rounds of discussion
>      > >     about the
>      > >      > content in the appendix and where it should be placed. The
>      > >     current text in
>      > >      > the appendix reflects the consensus of the design team,
>     although some
>      > >      > minor edits were not included yet.
>      > >      > >
>      > >      > > As for whether some of the text in appendix will be
>     moved to the
>      > >      > framework document, currently the design team has no
>     specific opinion
>      > >      > about this, and feedbacks from WG are appreciated. While
>     as Kiran
>      > >      > mentioned, description and discussion about isolation is
>     needed
>      > >     in the NS-DT
>      > >      > documents.
>      > >      > >
>      > >      > > Best regards,
>      > >      > > Jie
>      > >      > >
>      > >      > >> -----Original Message-----
>      > >      > >> From: Teas [mailto:[email-masked]
>     <mailto:[email-masked]>
>      > >     <mailto:[email-masked]
>     <mailto:[email-masked]>>] On Behalf Of Joel M.
>      > >      > >> Halpern
>      > >      > >> Sent: Friday, August 21, 2020 7:00 AM
>      > >      > >> To: Kiran Makhijani <[email-masked]
>     <mailto:[email-masked]>
>      > >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>; Vishnu Pavan Beeram
>      > >      > >> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; TEAS
>      > >     WG <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      > >      > >> Subject: Re: [Teas] WG adoption -
>      > >      > >> draft-nsdt-teas-transport-slice-definition - Appendix
>      > >      > >>
>      > >      > >> Since I do not think that the material in the appendix is
>      > >     useful, I
>      > >      > >> for one will not push for adding it to the
>     Framework.  You are
>      > >      > >> welcome to dabate adding it to the framework with the
>     rest of
>      > >     the WG.
>      > >      > >> But it does not belong in the definitions draft.
>      > >      > >>
>      > >      > >> Yours,
>      > >      > >> Joel
>      > >      > >>
>      > >      > >> On 8/20/2020 5:20 PM, Kiran Makhijani wrote:
>      > >      > >>> Hi Joel,
>      > >      > >>> I am ok to remove some part from Appendix only if it is
>      > >     included in
>      > >      > >>> the
>      > >      > >> framework first.
>      > >      > >>>
>      > >      > >>> But for the TSRE, I have proposed clearer and
>     shorter text
>      > >     that they
>      > >      > >>> are not
>      > >      > >> visible to the consumer of a transport slices. One of the
>      > >     purpose of
>      > >      > >> definitions document is 'define' common terminology
>     in the
>      > >     scope of
>      > >      > >> transport slices, and all we are saying is that when
>     realizing a
>      > >      > >> transport slice, things TSEs will map to are called
>     TSREs.
>      > >      > >>> I am not able to see the drawback of saying so.
>      > >      > >>>
>      > >      > >>> Thanks
>      > >      > >>> Kiran
>      > >      > >>>
>      > >      > >>>> -----Original Message-----
>      > >      > >>>> From: Joel Halpern Direct
>     <[email-masked] <mailto:[email-masked]>
>      > >      > >>>> Sent: Thursday, August 20, 2020 1:19 PM
>      > >      > >>>> To: Kiran Makhijani <[email-masked]
>     <mailto:[email-masked]>
>      > >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>; Vishnu Pavan Beeram
>      > >      > >>>> <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>;
>      > TEAS
>      > >     WG <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      > >      > >>>> Subject: Re: [Teas] WG adoption -
>      > >      > >>>> draft-nsdt-teas-transport-slice-definition
>      > >      > >>>>
>      > >      > >>>> No, your replies did not in any way address my
>     concerns.
>      > >      > >>>>
>      > >      > >>>> I would suggest removing the references to TSRE and
>     more
>      > >      > >>>> importantly removing appendix A.1, or at least the
>     last part
>      > >     of the
>      > >      > appendix.
>      > >      > >>>>
>      > >      > >>>> Yours,
>      > >      > >>>> Joel
>      > >      > >>>>
>      > >      > >>>> On 8/20/2020 2:54 PM, Kiran Makhijani wrote:
>      > >      > >>>>> Hi Joel,
>      > >      > >>>>> After having replied to your comments, we have not
>     heard
>      > >     further
>      > >      > >>>>> if they
>      > >      > >>>> were convincing.
>      > >      > >>>>> Please let us know.
>      > >      > >>>>> Thanks
>      > >      > >>>>> Kiran
>      > >      > >>>>>
>      > >      > >>>>>> -----Original Message-----
>      > >      > >>>>>> From: Teas <[email-masked]
>     <mailto:[email-masked]>
>      > >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> On Behalf Of Joel M. Halpern
>      > >      > >>>>>> Sent: Wednesday, August 19, 2020 9:04 AM
>      > >      > >>>>>> To: Vishnu Pavan Beeram <[email-masked]
>     <mailto:[email-masked]>
>      > >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>; TEAS WG
>      > >      > >>>>>> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      > >      > >>>>>> Subject: Re: [Teas] WG adoption -
>      > >      > >>>>>> draft-nsdt-teas-transport-slice-definition
>      > >      > >>>>>>
>      > >      > >>>>>> Without repairs to the issues I have raised on
>     the email
>      > >     list, I
>      > >      > >>>>>> do not think this document should be adopted as a WG
>      > document.
>      > >      > >>>>>> We are close, but not quite there.
>      > >      > >>>>>>
>      > >      > >>>>>> Yours,
>      > >      > >>>>>> Joel
>      > >      > >>>>>>
>      > >      > >>>>>> On 8/19/2020 11:50 AM, Vishnu Pavan Beeram wrote:
>      > >      > >>>>>>> All,
>      > >      > >>>>>>>
>      > >      > >>>>>>> This is start of a *three* week poll on making
>      > >      > >>>>>>> draft-nsdt-teas-transport-slice-definition-03 a
>     TEAS working
>      > >      > >>>>>>> group
>      > >      > >>>>>> document.
>      > >      > >>>>>>> Please send email to the list indicating
>     "yes/support" or
>      > >     "no/do
>      > >      > >>>>>>> not support". If indicating no, please state your
>      > >     reservations
>      > >      > >>>>>>> with the document. If yes, please also feel free
>     to provide
>      > >      > >>>>>>> comments you'd like to see addressed once the
>     document is
>      > >     a WG
>      > >      > >> document.
>      > >      > >>>>>>>
>      > >      > >>>>>>> The poll ends September 9th (extra week to
>     account for
>      > >     vacation
>      > >      > >> season).
>      > >      > >>>>>>>
>      > >      > >>>>>>> Thanks,
>      > >      > >>>>>>> Pavan and Lou
>      > >      > >>>>>>>
>      > >      > >>>>>>> _______________________________________________
>      > >      > >>>>>>> Teas mailing list
>      > >      > >>>>>>> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      > >      > >>>>>>>
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > >      > w.
>      > >      > >>>>>>>
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      > ietf.org
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898959798&sdata=i%2FH%2Fm%2FGG4ritzVpp08xIzXIK4YNiMj6Bqinei%2F7mGiI%3D&reserved=0>
>      > >
>      >
>      > g%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898969798&sdata=0vi%2FPjQDQF784ogZ3pZMeGneN4bceuPPuihcHOoeBTU%3D&reserved=0>%7C6e84819cea1748c
>      > >      > f
>      > >      > >>>>>> utur
>      > >      > >>>>>>>
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      > ewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898969798&sdata=k49Ao2avtmNlZZSLxFrtYPkzSSJ12W6dcAnSZfR6IGA%3D&reserved=0>
>      > >
>      >
>      > om%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898979787&sdata=OPhISgDytgKqV7i9r2sIcriQd6XIt0eBZYZi7B0HYt4%3D&reserved=0>%7C6e84819cea174
>      > >      > 9
>      > >      > >>>>>> c753a1d
>      > >      > >>>>>>>
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > 5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2FGSlz2Q4%
>      > >      > 2B
>      > >      > >>>>>> RAlZTXBv5
>      > >      > >>>>>>> XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=0
>      > >      > >>>>>>>
>      > >      > >>>>>>
>      > >      > >>>>>> _______________________________________________
>      > >      > >>>>>> Teas mailing list
>      > >      > >>>>>> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > >      > w
>      > >      > >>>>>> .i
>      > >      > >>>>
>      > >      > >>
>      > >      > etf.org
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898989785&sdata=qk3DEhb0CDuMWuv5Bvby5v8hASoBaedDVA5KWyaVvUU%3D&reserved=0>
>      > >
>      >
>      > %2F&amp;data=02%7C01%7Ckiranm%40futurewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898989785&sdata=nwlLNsIR4YHNSqH6FkKSmiY9RQr3v4AqNc8oJm2JpaI%3D&reserved=0>%7C6e84819cea1748c
>      > >      > u
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      > turewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898999777&sdata=gmGb4yQzcuu%2Ba3gy2Vk7g9ArOPYJEJ2nuEKV0dPV97Q%3D&reserved=0>
>      > >
>      >
>      > ei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898999777&sdata=NqB51hPKoN7hh7lCvTw4EZ8jc%2Bp86Wz4ydg0uI2K%2BVM%3D&reserved=0>%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899009773&sdata=A6VwFF%2BX9vWDkDbubs6ZwJ5yWecRxCH27Il1chW3fGE%3D&reserved=0>%7C6e84819cea
>      > >      > 01
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > 89c753a1d5591fedc%7C1%7C0%7C637334499094612048&amp;sdata=%2F
>      > >      > G
>      > >      > >>>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > Slz2Q4%2BRAlZTXBv5XlCZ9YKaUKQ7C4IUIgdQDVJ%2Bk%3D&amp;reserved=
>      > >      > 0
>      > >      > >>>>>
>      > >      > >>>>> _______________________________________________
>      > >      > >>>>> Teas mailing list
>      > >      > >>>>> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      > >      > >>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > >      > w.
>      > >      > >>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      > ietf.org
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899009773&sdata=YtwHjHJMdexxmf%2FgOtni7FuMCK%2BoN1tEzO83sKs39vQ%3D&reserved=0>
>      > >
>      >
>      > g%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899019770&sdata=Ebx7iTH1ZHOZYHLJRPJkiTOq2f101QGxoj7diCDpLy0%3D&reserved=0>%7C6e84819cea1748c
>      > >      > f
>      > >      > >>>> utur
>      > >      > >>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      > ewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899029764&sdata=L6TlRSA7R%2FUEhvbO1G7ILnBQrB6v%2BE4HKXwZrep8MnE%3D&reserved=0>
>      > >
>      >
>      > om%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899029764&sdata=Srzj8P8Wtu%2BjzqWJraL01gfMDOQPos%2F6ld8NWW4xT%2BI%3D&reserved=0>%7C6e84819cea174
>      > >      > 9
>      > >      > >>>> c753a1d
>      > >      > >>>>>
>      > >      > >>>>
>      > >      > >>
>      > >      >
>      > 5591fedc%7C1%7C1%7C637335515772670726&amp;sdata=MZQKraVa8fj3
>      > >      > BL
>      > >      > >>>> sLRq9T9a
>      > >      > >>>>> Ypp3C%2Bu1w9c7DgIVE6kE0%3D&amp;reserved=0
>      > >      > >>>>>
>      > >      > >>
>      > >      > >> _______________________________________________
>      > >      > >> Teas mailing list
>      > >      > >> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      > >      > >>
>      >
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899039761&sdata=Hj%2B1D5kmLTUoVvYkj1MfuXhJvEP62dzttTslX7mFFdQ%3D&reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fut
>      > urewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Furewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899039761&sdata=Vmir%2FW4ezf1i5fEseTzWYPycP%2FYBEERhEY031WZLWf8%3D&reserved=0>%7C6e84819cea1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c
>      > > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      > >
>      > >
>      >
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899049755&sdata=tvLFMHdzMdqH6k9k977HSkSpfcTmCKZoXrdo7cwW9AQ%3D&reserved=0>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fut
>      > ur
>      > >
>      > ewei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899049755&sdata=ZW9NvXJ6ux5gcNvgjWII%2BQsGaL3YRKS32Q8Bh1uFseg%3D&reserved=0>%7C6e84819cea1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c75
>      > 3a1d
>      > >
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      > > <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899059751&sdata=KzFInnEA4Q3bmCD1NXkAX6dCxrzJwT%2BKv1NbOAcYX1o%3D&reserved=0>
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 21 Aug 2020 18:41:01 -0700

Hi Kiran,
thank you for your response.
If we cannot give a formal definition to the isolation, then I, strongly
believing in Occam razor principle, suggest taking it out until we better
understand what it is.

Regards,
Greg

On Fri, Aug 21, 2020 at 6:28 PM Kiran Makhijani <[email-masked]>
wrote:

> *Cc:* Joel M. Halpern <[email-masked]>; Luis M. Contreras <
> [email-masked]>; Dongjie (Jimmy) <[email-masked]>; LUIS
> *[KM] It is not direct monitoring, it is an inference from some other
> it)*
> isolation as SLO
> *[KM] it is not an SLO, it is an additional ask or specification.*
>
> *[KM] Yes, it could work but it is too specific to the example, what if
> traffic-separation.*
> > > (<[email-masked]
> > >      > 2B
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898999777&sdata=NqB51hPKoN7hh7lCvTw4EZ8jc%2Bp86Wz4ydg0uI2K%2BVM%3D&reserved=0>
> > >      > G
> > >      > 0
> > >      > BL
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899039761&sdata=Hj%2B1D5kmLTUoVvYkj1MfuXhJvEP62dzttTslX7mFFdQ%3D&reserved=0>
> %2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fut
> > urewei.com
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Furewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899039761&sdata=Vmir%2FW4ezf1i5fEseTzWYPycP%2FYBEERhEY031WZLWf8%3D&reserved=0>
> %7C6e84819cea1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899049755&sdata=tvLFMHdzMdqH6k9k977HSkSpfcTmCKZoXrdo7cwW9AQ%3D&reserved=0>
> %2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40fut
> > ur
> > >
> > ewei.com
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899049755&sdata=ZW9NvXJ6ux5gcNvgjWII%2BQsGaL3YRKS32Q8Bh1uFseg%3D&reserved=0>
> %7C6e84819cea1748c9f64308d845e8c14b%7C0fee8ff2a3b240189c75
> > 3a1d
> > >

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 22 Aug 2020 05:05:12 +0000

Hi Deborah,

Thanks a lot for your comment.

As mentioned both in your mail and pervious mails by others and myself, network slicing is coupled with the concept of isolation in 5G related communities, such as 3GPP, GSMA, ETSI, etc. Similar to the term "transport" network, IMO it is also important to define or describe "isolation" for the IETF context, so as to avoid the possible confusion both in and outside IETF.

The text in the appendix is trying to give explanation about the isolation in the context of IETF or "transport" network, and it also tries to separate the requirement from realization. As explained in the text, isolation as a requirement has multi-dimension meanings, it can mean traffic separation or interference avoidance, etc., and each can be realized by some specific technologies, providing dedicated resource is just listed as one approach to realize some dimension of the requirement. The current text may need some improvement to better clarify the requirement and the realization separately, while such confusion just shows the necessity of explaining it further in IETF.

Best regards,
Jie

From: BRUNGARD, DEBORAH A [mailto:[email-masked]]
Sent: Friday, August 21, 2020 11:51 PM
To: David Sinicrope <david.sinicrope=[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Joel Halpern Direct <[email-masked]>; Kiran Makhijani <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>
Subject: RE: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Hi,

Thanks,
Deborah
(individual)

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of David Sinicrope
Sent: Friday, August 21, 2020 9:11 AM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Jie,

Thanks,
Dave

Hi Joel,

Best regards,
Jie

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Sat, 22 Aug 2020 12:03:36 +0000

Hi Jie,
(Individual)

Yes, the term isolation needs careful definition. Here in this definition document, need to be careful in defining vs. realization (solutions). It’s always a difficult trade in any requirements document.

“Dedicated resources” has many interpretations for packet network technologies - especially when realized over a multilayer network. As noted in the ETSI document, virtualization technologies when used for infrastructure, especially 5G, the advantages are being flexible and dynamic. “Dedicated” is not mentioned.

If we were doing a document in SG15, “dedicated” is somewhat clear, though even there it always is entertaining when the question is asked “does it mean the older fixed fiber distribution panel”. But not in this document where we are discussing a virtual network topology (described in the document).

Best is to remove the example  for now - if any example in the appendix, use a VPN and/or TE VNT which are IETF technologies. But as this work is to understand what more is needed for our technologies, it would be confusing without a comprehensive solution explanation.

Thanks, Good weekends,
Deborah
(Individual)

On Aug 22, 2020, at 1:05 AM, Dongjie (Jimmy) <[email-masked]> wrote:

Hi Deborah,

As mentioned both in your mail and pervious mails by others and myself, network slicing is coupled with the concept of isolation in 5G related communities, such as 3GPP, GSMA, ETSI, etc. Similar to the term “transport” network, IMO it is also important to define or describe “isolation” for the IETF context, so as to avoid the possible confusion both in and outside IETF.

The text in the appendix is trying to give explanation about the isolation in the context of IETF or “transport” network, and it also tries to separate the requirement from realization. As explained in the text, isolation as a requirement has multi-dimension meanings, it can mean traffic separation or interference avoidance, etc., and each can be realized by some specific technologies, providing dedicated resource is just listed as one approach to realize some dimension of the requirement. The current text may need some improvement to better clarify the requirement and the realization separately, while such confusion just shows the necessity of explaining it further in IETF.

Best regards,
Jie

Hi,

While the document is in it’s early stages, I think it is important to sort out this use of the term “isolation”. Already by use of the term “transport”, the scope of this work may be confused with the traditional definition of a transport network and overlapping with ITU-T SG15’s transport technologies. Important is to define “transport” carefully for the IETF context, which I think this document is a good start. Mixing “isolation” with “dedicated resources” is a step back to the traditional definition.

As the authors note, the term “isolation” is used in other SDOs, including 3GPP, but it is used differently. Here’s a recent publicly available white paper from ETSI NFV which summarizes the requirements from 3GPP for network slicing:
https://www.etsi.org/deliver/etsi_gr/NFV-EVE/001_099/012/03.01.01_60/gr_NFV-EVE012v030101p.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.etsi.org_deliver_etsi-5Fgr_NFV-2DEVE_001-5F099_012_03.01.01-5F60_gr-5FNFV-2DEVE012v030101p.pdf&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=gqhaYzybXCBPhw5oIBQATHe-nbZzzDh-oXrQZxU_2Gw&s=-IRr0tfeosn2ArvhNrpBKsQyiHvcabz_drsneDIBPUw&e=>

In this ETSI document, when they discuss isolation properties, physical resources are not mentioned, they discuss performance, resiliency, security, privacy and management. 3GPP recognizes resources may be logical or physical (and either fully or partly), it is not a “requirement”. Physical and virtual resources are used with respect to “realize”, not define.

I agree with Joel and Dave, I think Appendix A’s example saying a customer will request “dedicated resources” and saying the solution of using dedicated resources (vs. VPN)  guarantees the requirements are met, clashes with the rest of the document (section 5.3 and section 6) which carefully defines resources not as defining a slice but for realizing a slice. Maybe the authors intended it to be an example, but it is too confusing in the context of this document to mix the definition of “isolation” with “dedicated resources”. While an Appendix, it should not clash with the main document. Best is to remove for now.

Thanks,
Deborah
(individual)

Jie,

Thanks,
Dave

Hi Joel,

Best regards,
Jie

---

From: "Luis M. Contreras" <[email-masked]>
Date: Sat, 22 Aug 2020 20:07:19 +0200

Hi Joel,

please, see my replies in-line.

Best regards

Luis

El vie., 21 ago. 2020 a las 17:42, Joel M. Halpern (<[email-masked]>)
escribió:

> [Luis>>] At first stage, it can be expected some form of isolation
attribute in the slice request at least for 3GPP based services, but this
will be extended to other services in the future. Since all those
communication services are "client" of the transport network, it is
necessary to define isolation in the context of transport slice in order to
provide guidance to operators. Not having it, the consequence is that a
significant gap is created.

> [Luis>>] In my view, expressing isolation intents (whatever the form could
be, which is for further work) precisely provides guidance on the design of
a transport slice. Different degrees of isolation could impose different
constraints on the transport slice. In other words, different customers
requiring a transport slice with similar measurable SLOs (in terms of
throughput, latency, etc) but different isolation needs will be honored
with a distinct transport slice realization, which will take into account
the constraints derived from the specific isolation requirements.

> parameters, "isolation" does not add value to this document.

[Luis>>] I agree on the fact that isolation can be probably realized in
different manners. But isolation can be not only related to performance
issues, but others such as security, service continuity, service
specialization, etc. Whatever reason why the customer could ask for
isolation is him / her decision. Leaving the operator to infer the service
expectations of the customer in terms of isolation is not the way, I think.
Then processing of explicit isolation needs has value for fulfilling
customer's expectations. Otherwise, how can be ensure a given transport
slice request when the customer has some isolation needs?

> [Luis>>] I agree, but incompleteness can happen because two reasons: (1)
we don't anticipate the problem, and because of that, the problem cannot be
tackle, producing and incomplete document; and (2) we don't cover a certain
issue on purpose, even we recognize it is a key (or at least,
controversial) aspect for the problem. We are in the second case now, and I
think, again from the perspective of an operator, we need to cover it. The
development of isolation implications in transport slices is out of the
scope of definitions draft, but isolation, as an important (and specific)
topic of transport slices, should be in definitions draft.

Yours,
> >     <http://ietf.org
> >%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40
> >      > f
> >      > >>>>>> utur
> >      > >>>>>>>
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      > ewei.com
> >     <http://ewei.com
> >%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b24018
> >      > 9
> >      > >>>>>> c753a1d
> >      > >>>>>>>
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >     <http://etf.org
> >%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40f
> >      > u
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >      > turewei.com
> >     <http://turewei.com
> >%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b24
> >      > 01
> >      > >>>>>>
> >      > >>>>
> >      > >>
> >     <http://ietf.org
> >%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40
> >      > f
> >      > >>>> utur
> >      > >>>>>
> >      > >>>>
> >      > >>
> >      > ewei.com
> >     <http://ewei.com
> >%7C7bb861e35ac84653b62208d8454659ac%7C0fee8ff2a3b24018
> >      > 9
> >      > >>>> c753a1d
> >      > >>>>>
> >      > >>>>
> >      > >>

---

From: "Luis M. Contreras" <[email-masked]>
Date: Sat, 22 Aug 2020 20:13:10 +0200

Hi Deborah,

as you comment, there are different views from different SDOs on isolation.
But we lack our own view in IETF. This is precisely the reason why we
should include a preliminary definition on the definitions draft that could
be further elaborated in the framework document or in any other.

For sure, text is (should be) reviewed up to the point of reaching certain
consensus. In fact the current text was hardly debated, amended and
discussed during the design team calls (one per week). Again, probably
requires more views as the ones in this thread. I think this reflects, in
fact, the importance of keeping it in the definition draft.

Best regards

Luis

El vie., 21 ago. 2020 a las 17:52, BRUNGARD, DEBORAH A (<[email-masked]>)
escribió:

> While the document is in it’s early stages, I think it is important to
> sort out this use of the term “isolation”. Already by use of the term
> “transport”, the scope of this work may be confused with the traditional
> definition of a transport network and overlapping with ITU-T SG15’s
> transport technologies. Important is to define “transport” carefully for
> the IETF context, which I think this document is a good start. Mixing
> “isolation” with “dedicated resources” is a step back to the traditional
> definition.
>
>
>
> As the authors note, the term “isolation” is used in other SDOs, including
> 3GPP, but it is used differently. Here’s a recent publicly available white
> paper from ETSI NFV which summarizes the requirements from 3GPP for network
> slicing:
>
>
> In this ETSI document, when they discuss isolation properties, physical
> resources are not mentioned, they discuss performance, resiliency,
> security, privacy and management. 3GPP recognizes resources may be logical
> or physical (and either fully or partly), it is not a “requirement”.
> Physical and virtual resources are used with respect to “realize”, not
> define.
>
>
>
> I agree with Joel and Dave, I think Appendix A’s example saying a customer
> will request “dedicated resources” and saying the solution of using
> dedicated resources (vs. VPN)  guarantees the requirements are met, clashes
> with the rest of the document (section 5.3 and section 6) which carefully
> defines resources not as defining a slice but for realizing a slice. Maybe
> the authors intended it to be an example, but it is too confusing in the
> context of this document to mix the definition of “isolation” with
> “dedicated resources”. While an Appendix, it should not clash with the main
> document. Best is to remove for now.
>
>
>
> Thanks,
>
> Deborah
>
> (individual)
>
>
>
> *From:* Teas <[email-masked]> *On Behalf Of * David Sinicrope
> *Sent:* Friday, August 21, 2020 9:11 AM
> *To:* Dongjie (Jimmy) <[email-masked]>; Joel Halpern Direct <
> [email-masked]>; Kiran Makhijani <[email-masked]>;
> You note “isolation has been considered as one of the characteristics of
> network slicing in *most of the related standards and publications,* and
> it would be incomplete if the definition draft does not touch this. And *in
> IETF history isolation has been considered as one requirement of VPNs,*
> the discussion is necessary for explaining the relationship and difference
> between network slice and VPNs.”
>
>
>
> I’m not sure where this is coming from. Do you have references to support
> these claims?  I’m specifically referring to the claim that “most” related
> standards and publications consider isolation as a characteristic.  This
> has not been my experience at all over the last 3 decades including the
> history of the IETF.
>
>
>
> If anything the history of work on VPNs deals with identification of the
> traffic associated with the VPN not its isolation. Any treatment or
> characteristic of that traffic has been a function of QoS.
>
>
>
> Isolation, in my experience, has not been part of the discussion or texts
> until the introduction of network slicing and only introduced by a subset
> of the community.
>
>
>
> ------------------------------
>
> *From:* Teas <[email-masked]> on behalf of Dongjie (Jimmy) <
> [email-masked]>
> *Sent:* Friday, August 21, 2020 4:26 AM
> *To:* Joel Halpern Direct; Kiran Makhijani; Vishnu Pavan Beeram; TEAS WG
> <[email-masked]>]
> > >> From: Teas [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Joel M.
> > >> Halpern
> > >>>>>> To: Vishnu Pavan Beeram <vishnupavan@gmail..com>; TEAS WG
> > >>>>>> <[email-masked]>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3D7d132922-2D23b3ea8b-2D7d1369b9-2D86959e472243-2Da669baec95ff5981-26q-3D1-26e-3D8a1db88d-2Dcb42-2D478e-2D8eb8-2Dda70acca25e3-26u-3Dhttps-253A-252F-252Fnam11.safelinks.protection.outlook.com-252F-253Furl-253Dhttps-25253A-25252F-25252Fww&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=bUkqIf98ir2n0fhlYgEu_c2k4w8oW1idwDGwyySsfhA&e=>
> > w.
> > >>>>>>>
> > >>>>>>
> > >>>>
> > >>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3D19c50183-2D4765c22a-2D19c54118-2D86959e472243-2Dbe7fb3e456e3f9a6-26q-3D1-26e-3D8a1db88d-2Dcb42-2D478e-2D8eb8-2Dda70acca25e3-26u-3Dhttps-253A-252F-252Fnam11.safelinks.protection.outlook.com-252F-253Furl-253Dhttps-25253A-25252F-25252Fww&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=VhW4TGe4z7ZeD8qijXBRD9ZkiGcGBi0YJ6buh0kXY6A&e=>
> > w
> > >>>>>> .i
> > >>>>
> > >>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3Dd37b5edd-2D8ddb9d74-2Dd37b1e46-2D86959e472243-2Da54dacfae536c914-26q-3D1-26e-3D8a1db88d-2Dcb42-2D478e-2D8eb8-2Dda70acca25e3-26u-3Dhttps-253A-252F-252Fnam11.safelinks.protection.outlook.com-252F-253Furl-253Dhttps-25253A-25252F-25252Fww&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=KontY0Ex6UJRo2EpGG4LrA-TsJBJxvvILb-PVW6PMdI&e=>
> > w.
> > >>>>>
> > >>>>
> > >>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=OFFFT8ma706KrhOLX304z0qEw74Wg7S_eelu5EONhKs&e=>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=OFFFT8ma706KrhOLX304z0qEw74Wg7S_eelu5EONhKs&e=>

---

From: "Luis M. Contreras" <[email-masked]>
Date: Sat, 22 Aug 2020 20:27:45 +0200

Hi Joel,

the NBI, apart from considering measurable parameters, could need to
consider characteristics of the service. For instance, servicing a given
geographical area but avoiding any other for whatever reason (e.g.,
security, content rights, etc).

Isolation is not a directly measurable characteristic (maybe could be using
intrusive mechanisms similar to service activation tests such in ITU-T
Y.1564, thinking loud) but can be observable in case of eventual situations
in the network, I think.

Best regards

Luis

El sáb., 22 ago. 2020 a las 3:38, Joel Halpern Direct (<
[email-masked]>) escribió:

> >      > >      > From: Joel Halpern Direct
> >      > >      > <[email-masked] <mailto:[email-masked]>
> >      > >      > <[email-masked] <mailto:[email-masked]>
> >      > >      > The consensus of the design team is relevant as a
> >     recommendation
> >      > >     to the
> >      > >      > WG, but otherwise is not relevant for whether the WG
> should
> >      > >     agree.  In
> >      > >      > terms of WG adoption, the design team draft has the same
> >     status
> >      > >     as any
> >      > >      > There is no obligation for the WG to retain the text
> >     from the
> >      > >     appendix
> >      > >      > anywhere.  In particular, the WG is under no obligation
> >     to retain
> >      > >     the last
> >      > >      > I have not seen any good argument for retaining the
> >     text.  It
> >      > >     does not seem
> >      > >      > If anything, it is confusing at it seems to say "this is
> >     not a
> >      > >     parameter / this is
> >      > >      > a parameter"
> >      > >      >
> >      > >      > Yours,
> >      > >      > Joel
> >      > >      >
> >      > >      > > In the design team there were several rounds of
> discussion
> >      > >     about the
> >      > >      > content in the appendix and where it should be placed.
> The
> >      > >     current text in
> >      > >      > mentioned, description and discussion about isolation is
> >     needed
> >      > >     in the NS-DT
> >      > >      > documents.
> >      > >      > >
> >      > >      > > Best regards,
> >      > >      > > Jie
> >      > >      > >
> >      > >      > >> <[email-masked] <mailto:[email-masked]>
> >      > >      > >> Since I do not think that the material in the
> appendix is
> >      > >     useful, I
> >      > >      > >> welcome to dabate adding it to the framework with the
> >     rest of
> >      > >     the WG.
> >      > >      > >>> I am ok to remove some part from Appendix only if it
> is
> >      > >     included in
> >      > >      > >>> the
> >      > >      > >> framework first.
> >      > >      > >>>
> >      > >      > >> visible to the consumer of a transport slices. One of
> the
> >      > >     purpose of
> >      > >      > >> definitions document is 'define' common terminology
> >     in the
> >      > >     scope of
> >      > >      > >>>> From: Joel Halpern Direct
> >      > >      > >>>> <[email-masked]
> >      > >      > >>>> importantly removing appendix A.1, or at least the
> >     last part
> >      > >     of the
> >      > >      > appendix.
> >      > >      > >>>>
> >      > >      > >>>> Yours,
> >      > >      > >>>> Joel
> >      > >      > >>>>
> >      > >      > >>>>> After having replied to your comments, we have not
> >     heard
> >      > >     further
> >      > >      > >>>>> if they
> >      > >      > >>>> were convincing.
> >      > >      > >>>>> Please let us know.
> >      > >      > >>>>> Thanks
> >      > >      > >>>>> Kiran
> >      > >      > >>>>>
> >      > >      > >>>>>> <[email-masked] <mailto:[email-masked]>
> >      > >      > >>>>>> Without repairs to the issues I have raised on
> >     the email
> >      > >     list, I
> >      > >      > >>>>>> do not think this document should be adopted as a
> WG
> >      > document.
> >      > >      > >>>>>>> Please send email to the list indicating
> >     "yes/support" or
> >      > >     "no/do
> >      > >      > >>>>>>> comments you'd like to see addressed once the
> >     document is
> >      > >     a WG
> >      > >      > >> document.
> >      > >      > >>>>>>>
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898959798&sdata=i%2FH%2Fm%2FGG4ritzVpp08xIzXIK4YNiMj6Bqinei%2F7mGiI%3D&reserved=0
> >
> >      > >
> >      >
> >     <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898969798&sdata=0vi%2FPjQDQF784ogZ3pZMeGneN4bceuPPuihcHOoeBTU%3D&reserved=0
> >%7C6e84819cea1748c
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898969798&sdata=k49Ao2avtmNlZZSLxFrtYPkzSSJ12W6dcAnSZfR6IGA%3D&reserved=0
> >
> >      > >
> >      >
> >     <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.c
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898979787&sdata=OPhISgDytgKqV7i9r2sIcriQd6XIt0eBZYZi7B0HYt4%3D&reserved=0
> >%7C6e84819cea174
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898989785&sdata=qk3DEhb0CDuMWuv5Bvby5v8hASoBaedDVA5KWyaVvUU%3D&reserved=0
> >
> >      > >
> >      >
> >     <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898989785&sdata=nwlLNsIR4YHNSqH6FkKSmiY9RQr3v4AqNc8oJm2JpaI%3D&reserved=0
> >%7C6e84819cea1748c
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898999777&sdata=gmGb4yQzcuu%2Ba3gy2Vk7g9ArOPYJEJ2nuEKV0dPV97Q%3D&reserved=0
> >
> >      > >
> >      >
> >     <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturew
> >      > ei.com
> >     <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488898999777&sdata=NqB51hPKoN7hh7lCvTw4EZ8jc%2Bp86Wz4ydg0uI2K%2BVM%3D&reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899009773&sdata=A6VwFF%2BX9vWDkDbubs6ZwJ5yWecRxCH27Il1chW3fGE%3D&reserved=0
> >%7C6e84819cea
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899009773&sdata=YtwHjHJMdexxmf%2FgOtni7FuMCK%2BoN1tEzO83sKs39vQ%3D&reserved=0
> >
> >      > >
> >      >
> >     <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899019770&sdata=Ebx7iTH1ZHOZYHLJRPJkiTOq2f101QGxoj7diCDpLy0%3D&reserved=0
> >%7C6e84819cea1748c
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899029764&sdata=L6TlRSA7R%2FUEhvbO1G7ILnBQrB6v%2BE4HKXwZrep8MnE%3D&reserved=0
> >
> >      > >
> >      >
> >     <
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.c
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899029764&sdata=Srzj8P8Wtu%2BjzqWJraL01gfMDOQPos%2F6ld8NWW4xT%2BI%3D&reserved=0
> >%7C6e84819cea174
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899039761&sdata=Hj%2B1D5kmLTUoVvYkj1MfuXhJvEP62dzttTslX7mFFdQ%3D&reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Furewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899039761&sdata=Vmir%2FW4ezf1i5fEseTzWYPycP%2FYBEERhEY031WZLWf8%3D&reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899049755&sdata=tvLFMHdzMdqH6k9k977HSkSpfcTmCKZoXrdo7cwW9AQ%3D&reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewei.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899049755&sdata=ZW9NvXJ6ux5gcNvgjWII%2BQsGaL3YRKS32Q8Bh1uFseg%3D&reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C9f6c466f17774a9ae70e08d84628ee14%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637336488899059751&sdata=KzFInnEA4Q3bmCD1NXkAX6dCxrzJwT%2BKv1NbOAcYX1o%3D&reserved=0
> >
> >
>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Sat, 22 Aug 2020 19:23:28 +0000

Hi Luis,

Not sure if you are saying isolation or the appendix example “dedicated resources” needs to stay in the draft?

It is the appendix which I am saying needs to be removed as the term has no meaning. Can a dedicated resource be a TE link? It has defined properties e.g. bandwidth. It is an IETF term.

Isolation also needs to be better defined so we can understand the term - Can you find a reference - 3GPP? As I noted, ETSI references 3GPP, and dedicated resources is not a property of isolation. Does a TE link provide isolation?

Yes, this is just an adoption call, but if it defines isolation as dedicated resources, this document is more appropriately done in SG15 for a single layer “transport” technology network. We need to sort out definitions/examples appropriate for IETF technologies.

Thanks,
Deborah
(individual)

Sent from my iPhone

On Aug 22, 2020, at 2:13 PM, Luis M. Contreras <[email-masked]> wrote:

Hi Deborah,

as you comment, there are different views from different SDOs on isolation. But we lack our own view in IETF. This is precisely the reason why we should include a preliminary definition on the definitions draft that could be further elaborated in the framework document or in any other.

For sure, text is (should be) reviewed up to the point of reaching certain consensus. In fact the current text was hardly debated, amended and discussed during the design team calls (one per week). Again, probably requires more views as the ones in this thread. I think this reflects, in fact, the importance of keeping it in the definition draft.

Best regards

Luis

El vie., 21 ago. 2020 a las 17:52, BRUNGARD, DEBORAH A (<[email-masked]<mailto:[email-masked]>>) escribió:
Hi,

As the authors note, the term “isolation” is used in other SDOs, including 3GPP, but it is used differently. Here’s a recent publicly available white paper from ETSI NFV which summarizes the requirements from 3GPP for network slicing:
https://www.etsi.org/deliver/etsi_gr/NFV-EVE/001_099/012/03.01.01_60/gr_NFV-EVE012v030101p.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.etsi.org_deliver_etsi-5Fgr_NFV-2DEVE_001-5F099_012_03.01.01-5F60_gr-5FNFV-2DEVE012v030101p.pdf&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=whW6wCobCa_-nytdz17CmIM40MsdkhU4HeVJS4I_bsE&e=>

Thanks,
Deborah
(individual)

Jie,

Thanks,
Dave

Hi Joel,

Best regards,
Jie

> ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__ietf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=_vZwb9xSXx0L6LXfU3SfsyRQZwtLTKNMilXa3FKnxI0&e=>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40
> f
> >>>>>> utur
> >>>>>>>
> >>>>>>
> >>>>
> >>
> ewei.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__ewei.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=N1J-JP8i0vnf9QQkG1THaAUZj8a6qGyoLBC5rz0soh4&e=>%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b24018
> 9
> >>>>>> c753a1d
> >>>>>>>
> >>>>>>
> >>>>
> >>
> etf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__etf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=3zktgPf9FDsA3X9B-avff6-WYBQH1mx7Z-UUkgUayBc&e=>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40f
> u
> >>>>>>
> >>>>
> >>
> turewei.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__turewei.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=reHowyeT_UiuqtGsQwTotMvswWqVsTdUD1WFd1iyKRA&e=>%7Cf26ab959470747a36b2808d84459a351%7C0fee8ff2a3b24
> 01
> >>>>>>
> >>>>
> >>
> ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__ietf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=_vZwb9xSXx0L6LXfU3SfsyRQZwtLTKNMilXa3FKnxI0&e=>%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40
> f
> >>>> utur
> >>>>>
> >>>>
> >>
> ewei.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__ewei.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=N1J-JP8i0vnf9QQkG1THaAUZj8a6qGyoLBC5rz0soh4&e=>%7C7bb861e35ac84653b62208d8454659ac%7C0fee8ff2a3b24018
> 9
> >>>> c753a1d
> >>>>>
> >>>>
> >>
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PIYtUeW125RV0PtLtAB1VkyAsOdbMntl_enBZv4d2qc&s=OFFFT8ma706KrhOLX304z0qEw74Wg7S_eelu5EONhKs&e=>
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=H2IkukcySu5L351hyjuLvFIrQ8xp245DL4MTOrIYm3g&e=>

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 24 Aug 2020 12:45:50 -0500

WG,

Thanks to everyone who weighed in on the discussion on the adoption call so
far.

WRT the appendix and terminology:

Based on this discussion and the focus of this draft, i.e., definition(s),
our recommendations for the authors are as follows:

   - Add placeholders in the main text for definitions from a transport
   network slice point of view:
      - Isolation
      - Network resources (shared vs dedicated)

        (Note: we believe it is important for the WG to get consensus on
these terms, so just placeholders for now.)

   - Remove the Appendix

The text on solution aspects (how the slice is realized) should not be in
this document.

Given that the adoption poll will run till September 9th, we think it would
be helpful to have these changes made ASAP so that  the above changes can
be discussed as part of the  adoption call.

Regards,

-Pavan and Lou

On Sat, Aug 22, 2020 at 2:24 PM BRUNGARD, DEBORAH A <[email-masked]> wrote:

> It is the appendix which I am saying needs to be removed as the term has
> no meaning. Can a dedicated resource be a TE link? It has defined
> properties e.g. bandwidth. It is an IETF term.
>
> Isolation also needs to be better defined so we can understand the term -
> Can you find a reference - 3GPP? As I noted, ETSI references 3GPP, and
> dedicated resources is not a property of isolation. Does a TE link provide
> isolation?
>
> Yes, this is just an adoption call, but if it defines isolation as
> dedicated resources, this document is more appropriately done in SG15 for a
> single layer “transport” technology network. We need to sort out
> definitions/examples appropriate for IETF technologies.
>
> Thanks,
> Deborah
> (individual)
>
> Sent from my iPhone
>
> as you comment, there are different views from different SDOs on
> isolation. But we lack our own view in IETF. This is precisely the reason
> why we should include a preliminary definition on the definitions draft
> that could be further elaborated in the framework document or in any other.
>
>> As the authors note, the term “isolation” is used in other SDOs,
>> including 3GPP, but it is used differently. Here’s a recent publicly
>> available white paper from ETSI NFV which summarizes the requirements from
>> 3GPP for network slicing:
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.etsi.org_deliver_etsi-5Fgr_NFV-2DEVE_001-5F099_012_03.01.01-5F60_gr-5FNFV-2DEVE012v030101p.pdf&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=whW6wCobCa_-nytdz17CmIM40MsdkhU4HeVJS4I_bsE&e=>
>>
>>
>>
>> I agree with Joel and Dave, I think Appendix A’s example saying a
>> customer will request “dedicated resources” and saying the solution of
>> using dedicated resources (vs. VPN)  guarantees the requirements are met,
>> clashes with the rest of the document (section 5.3 and section 6) which
>> carefully defines resources not as defining a slice but for realizing a
>> slice. Maybe the authors intended it to be an example, but it is too
>> confusing in the context of this document to mix the definition of
>> “isolation” with “dedicated resources”. While an Appendix, it should not
>> clash with the main document. Best is to remove for now.
>>
>>
>>
>> Thanks,
>>
>> Deborah
>>
>> (individual)
>>
>>
>>
>> *From:* Teas <[email-masked]> *On Behalf Of *David Sinicrope
>> > >> From: Teas [mailto:[email-masked] <[email-masked]>]
>> On Behalf Of Joel M.
>> > >> Halpern
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__ietf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=_vZwb9xSXx0L6LXfU3SfsyRQZwtLTKNMilXa3FKnxI0&e=>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__ewei.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=N1J-JP8i0vnf9QQkG1THaAUZj8a6qGyoLBC5rz0soh4&e=>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__etf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=3zktgPf9FDsA3X9B-avff6-WYBQH1mx7Z-UUkgUayBc&e=>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__turewei.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=reHowyeT_UiuqtGsQwTotMvswWqVsTdUD1WFd1iyKRA&e=>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__ietf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=_vZwb9xSXx0L6LXfU3SfsyRQZwtLTKNMilXa3FKnxI0&e=>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__ewei.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=N1J-JP8i0vnf9QQkG1THaAUZj8a6qGyoLBC5rz0soh4&e=>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=AwJ8Rnj_oE7hSXkxDfEAJfQZRnzKHK_oWcI00DDK6ig&s=H2IkukcySu5L351hyjuLvFIrQ8xp245DL4MTOrIYm3g&e=>
>>
>
>
> --

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 25 Aug 2020 10:08:08 +0000

Hi WG,

Resource reservation/allocation is very important for SLA guarantee. A service without dedicated resource could be queued up/dropped in the network, even if it uses the highest priority, considering that the network resource couldn’t be unlimited.
So I support to add proper descriptions about resource reservation/allocation in  draft-nsdt-teas-transport-slice-definition.
Also, resource allocation is one of the key technologies in DetNet, which is described in RFC8557(Deterministic Networking Problem Statement) and RFC8655(Deterministic Networking Architecture). Maybe the following text could be considered as reference[*][**].

Best Regards
Xuesong

----
[*] RFC rfc8557 section 2 (https://tools.ietf.org/html/rfc8557)
2<https://tools.ietf.org/html/rfc8557#section-2>.  On Deterministic Networking
…
   Reserving resources before packet transmission is the one fundamental
   shift in the behavior of network applications that is impossible to
   avoid.  In the first place, a network cannot deliver finite latency
   and practically zero packet loss to an arbitrarily high offered load.
   Secondly, achieving practically zero packet loss for unthrottled
   (though bandwidth-limited) flows means that bridges and routers have
   to dedicate buffer resources to specific flows or classes of flows.
   The requirements of each reservation have to be translated into the
   parameters that control each host's, bridge's, and router's queuing,
   shaping, and scheduling functions and delivered to the hosts,
   bridges, and routers.

[**] RFC8655 section 3.2.1 (https://tools.ietf.org/html/rfc8655#section-3.2.1)
3.2.1<https://tools.ietf.org/html/rfc8655#section-3.2.1>.  Resource Allocation
3.2.1.1<https://tools.ietf.org/html/rfc8655#section-3.2.1.1>.  Eliminate Contention Loss
   The primary means by which DetNet achieves its QoS assurances is to
   reduce, or even completely eliminate, packet loss due to output
   packet contention within a DetNet node as a cause of packet loss.
   This can be achieved only by the provision of sufficient buffer
   storage at each node through the network to ensure that no packets
   are dropped due to a lack of buffer storage.  Note that App-flows are
   generally not expected to be responsive to implicit [RFC2914<https://tools.ietf.org/html/rfc2914>] or
   explicit congestion notification [RFC3168<https://tools.ietf.org/html/rfc3168>].

   Ensuring adequate buffering requires, in turn, that the source and
   every DetNet node along the path to the destination (or nearly every
   node; see Section 4.3.3<https://tools.ietf.org/html/rfc8655#section-4.3.3>) be careful to regulate its output to not
   exceed the data rate for any DetNet flow, except for brief periods
   when making up for interfering traffic.  Any packet sent ahead of its
   time potentially adds to the number of buffers required by the next-
   hop DetNet node and may thus exceed the resources allocated for a
   particular DetNet flow.  Furthermore, rate limiting (e.g., using
   traffic policing) and shaping functions (e.g., shaping as defined in
   [RFC2475<https://tools.ietf.org/html/rfc2475>]) at the ingress of the DetNet domain must be applied.  This
   is needed for meeting the requirements of DetNet flows as well as for
   protecting non-DetNet traffic from potentially misbehaving DetNet
   traffic sources.  Note that large buffers have some issues (see,
   e.g., [BUFFERBLOAT<https://tools.ietf.org/html/rfc8655#ref-BUFFERBLOAT>]).

   The low-level mechanisms described in Section 4.5<https://tools.ietf.org/html/rfc8655#section-4.5> provide the
   necessary regulation of transmissions by an end system or DetNet node
   to provide resource allocation.  The allocation of the bandwidth and
   buffers for a DetNet flow requires provisioning.  A DetNet node may
   have other resources requiring allocation and/or scheduling that
   might otherwise be over-subscribed and trigger the rejection of a
   reservation.
3.2.1.2<https://tools.ietf.org/html/rfc8655#section-3.2.1.2>.  Jitter Reduction
   A core objective of DetNet is to enable the convergence of sensitive
   non-IP networks onto a common network infrastructure.  This requires
   the accurate emulation of currently deployed mission-specific
   networks, which, for example, rely on point-to-point analog (e.g.,
   4-20mA modulation) and serial-digital cables (or buses) for highly
   reliable, synchronized, and jitter-free communications.  While the
   latency of analog transmissions is basically the speed of light,
   legacy serial links are usually slow (in the order of Kbps) compared
   to, say, Gigabit Ethernet, and some latency is usually acceptable.
   What is not acceptable is the introduction of excessive jitter, which
   may, for instance, affect the stability of control systems.

   Applications that are designed to operate on serial links usually do
   not provide services to recover the jitter, because jitter simply
   does not exist there.  DetNet flows are generally expected to be
   delivered in order, and the precise time of reception influences the
   processes.  In order to converge such existing applications, there is
   a desire to emulate all properties of the serial cable, such as clock
   transportation, perfect flow isolation, and fixed latency.  While
   minimal jitter (in the form of specifying minimum, as well as
   maximum, end-to-end latency) is supported by DetNet, there are
   practical limitations on packet-based networks in this regard.  In
   general, users are encouraged to use a combination of:

   *  Sub-microsecond time synchronization among all source and
      destination end systems, and

   *  Time-of-execution fields in the application packets.

   Jitter reduction is provided by the mechanisms described in
   Section 4.5<https://tools.ietf.org/html/rfc8655#section-4.5> that also provide resource allocation.

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, August 25, 2020 1:46 AM
To: BRUNGARD, DEBORAH A <[email-masked]>
Cc: Joel Halpern Direct <[email-masked]>; Luis M. Contreras <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Kiran Makhijani <[email-masked]>; David Sinicrope <david.sinicrope=[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

WG,

Thanks to everyone who weighed in on the discussion on the adoption call so far.

Based on this discussion and the focus of this draft, i.e., definition(s),  our recommendations for the authors are as follows:

  *   Add placeholders in the main text for definitions from a transport network slice point of view:

     *   Isolation
     *   Network resources (shared vs dedicated)
        (Note: we believe it is important for the WG to get consensus on these terms, so just placeholders for now.)

  *   Remove the Appendix

The text on solution aspects (how the slice is realized) should not be in this document.

Given that the adoption poll will run till September 9th, we think it would be helpful to have these changes made ASAP so that  the above changes can be discussed as part of the  adoption call.

Regards,
-Pavan and Lou

On Sat, Aug 22, 2020 at 2:24 PM BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>> wrote:
Hi Luis,

Thanks,
Deborah
(individual)
Sent from my iPhone

On Aug 22, 2020, at 2:13 PM, Luis M. Contreras <[email-masked]<mailto:[email-masked]>> wrote:

Hi Deborah,

Best regards

Luis

Thanks,
Deborah
(individual)

Jie,

Thanks,
Dave

Hi Joel,

Best regards,
Jie

---

From: David Sinicrope <[email-masked]>
Date: Tue, 25 Aug 2020 12:30:18 -0400

I agree the current term has no meaning, contradicts the main document concerning the use of dedicated resources and it should be removed from the document.  I’m sure it doesn’t need to be present in the document to continue debate and work on it and in the meantime we might get agreement on the rest of the text.

Dave

> On Aug 22, 2020, at 15:24, BRUNGARD, DEBORAH A <[email-masked]> wrote:
> 
>  Hi Luis,
> 
>>> El vie., 21 ago. 2020 a las 17:52, BRUNGARD, DEBORAH A (<[email-masked]>) escribió:
>>> Hi,
>>> 
>>>  
>>>

---

From: David Sinicrope <[email-masked]>
Date: Tue, 25 Aug 2020 12:34:34 -0400

Just saw Pavan and Lou’s summary and agree with that path forward.
Thanks,
Dave 

> On Aug 25, 2020, at 12:30, David Sinicrope <[email-masked]> wrote:
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 25 Aug 2020 22:59:45 +0300

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

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 25 Aug 2020 15:31:58 -0700

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

---

From: Young Lee <[email-masked]>
Date: Wed, 26 Aug 2020 08:32:45 +0900

+1

If isolation is not the right term in IETF, I'd think a reasonable
compromise is to use terms like 'sharing property' or a similar term. The
extreme case of the attributes under this property disjointness in
port/node/link/path level. This would be equivalent to private dedicated
network level if you will. Other level of sharing can be enumerated
thereof.

Thanks.
Young

2020년 8월 26일 (수) 오전 7:32, Jeff Tantsura <[email-masked]>님이 작성:

> 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.
> 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
> 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”.
>
> My impression of customer requirements and how they get represented
> matches with what Joel has been saying in this thread.
>
> 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
>

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 25 Aug 2020 16:51:29 -0700

+1 (Jeff and Young).

2 quick thoughts:

a) Sometimes (based on the context) it also can be viewed as isolation from
the best-effort/shortest-path traffic path or a TE tunnel specifically
created for that slice (one basic form of isolation in the TE world).
Extreme form of  isolation lends itself to a dedicated network (private 5G)
and that may not be much to do with this document, perhaps.

b) In the below message, though it might be giving an example
    "... desired characteristic of not having your neighbour affect the
bandwidth the service provider has agreed to give you."

   It sounded like what an end user is getting from an SP? If that is the
case the scope is way bigger than PE to PE case (need to read the latest
version to see what's the scope).
   In any case, it's good to clarify the entreprise traffic isolation or
end user. If it is later the implications that need to be dealt with would
be much more here.

And finally isolation in all cases in shared infrastructure could be a myth.

--
Uma C.

On Tue, Aug 25, 2020 at 4:33 PM Young Lee <[email-masked]> wrote:

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

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 26 Aug 2020 02:39:58 +0000

+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:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Wednesday, August 26, 2020 6:32 AM
To: TEAS WG <[email-masked]>; Jari Arkko <[email-masked]>
Cc: Vishnu Pavan Beeram <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

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 <[email-masked]<mailto:[email-masked]>>, wrote:

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

Personal perspective:

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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 26 Aug 2020 12:55:37 +0000

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 <[email-masked]>; TEAS WG <[email-masked]>; Jari Arkko <[email-masked]>
Cc: Vishnu Pavan Beeram <[email-masked]>
Subject: RE: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

+1

Xuesong

From: Teas [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Wednesday, August 26, 2020 6:32 AM
To: TEAS WG <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>
Cc: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Cheers,
Jeff

Design team discussions:

Personal perspective:

Jari

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 26 Aug 2020 13:33:54 +0000

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 <[email-masked]> On Behalf Of Dongjie (Jimmy)
Sent: den 26 augusti 2020 14:56
To: Gengxuesong (Geng Xuesong) <[email-masked]>; Jeff Tantsura <[email-masked]>; TEAS WG <[email-masked]>; Jari Arkko <[email-masked]>
Cc: Vishnu Pavan Beeram <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Best regards,
Jie

To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>

+1

Xuesong

To: TEAS WG <[email-masked]<mailto:[email-masked]>>; Jari Arkko <jari.arkko@piuha..net<mailto:[email-masked]>>

Cheers,
Jeff

Design team discussions:

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

Personal perspective:

Jari

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Thu, 27 Aug 2020 02:28:28 +0000

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:[email-masked]]
Sent: Wednesday, August 26, 2020 9:34 PM
To: Dongjie (Jimmy) <[email-masked]>; Gengxuesong (Geng Xuesong) <[email-masked]>; Jeff Tantsura <[email-masked]>; TEAS WG <[email-masked]>; Jari Arkko <[email-masked]>
Cc: Vishnu Pavan Beeram <[email-masked]>
Subject: RE: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Hi,

BR
Daniele

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Dongjie (Jimmy)
Sent: den 26 augusti 2020 14:56
To: Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>
Cc: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Best regards,
Jie

+1

Xuesong

Cheers,
Jeff

Design team discussions:

Personal perspective:

Jari

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 27 Aug 2020 10:43:06 +0000

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 <[email-masked]> En nombre de Gengxuesong (Geng Xuesong)
Enviado el: jueves, 27 de agosto de 2020 4:28
Para: Daniele Ceccarelli <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Jeff Tantsura <[email-masked]>; TEAS WG <[email-masked]>; Jari Arkko <[email-masked]>
CC: Vishnu Pavan Beeram <[email-masked]>
Asunto: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Hi Daniele

Xuesong

To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>

Hi,

BR
Daniele

Best regards,
Jie

+1

Xuesong

To: TEAS WG <[email-masked]<mailto:[email-masked]>>; Jari Arkko <jari.arkko@piuha...net<mailto:[email-masked]>>

Cheers,
Jeff

Design team discussions:

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

Personal perspective:

Jari

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: <[email-masked]>
Date: Thu, 27 Aug 2020 12:26:54 +0000

Hi all,

I support this effort.

That’s said, I do think the document should leverage existing documents, e.g., use https://tools.ietf.org/html/rfc7297 to define the SLOs:

   3<https://tools.ietf.org/html/rfc7297#section-3>.  Connectivity Provisioning Profile (CPP) . . . . . . . . . . .   9<https://tools.ietf.org/html/rfc7297#page-9>

     3.1<https://tools.ietf.org/html/rfc7297#section-3.1>.  Customer Nodes Map  . . . . . . . . . . . . . . . . . . .   9<https://tools.ietf.org/html/rfc7297#page-9>

     3.2<https://tools.ietf.org/html/rfc7297#section-3.2>.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .  10<https://tools.ietf.org/html/rfc7297#page-10>

     3.3<https://tools.ietf.org/html/rfc7297#section-3.3>.  QoS Guarantees  . . . . . . . . . . . . . . . . . . . . .  11<https://tools.ietf.org/html/rfc7297#page-11>

     3.4<https://tools.ietf.org/html/rfc7297#section-3.4>.  Availability  . . . . . . . . . . . . . . . . . . . . . .  11<https://tools.ietf.org/html/rfc7297#page-11>

     3.5<https://tools.ietf.org/html/rfc7297#section-3.5>.  Capacity  . . . . . . . . . . . . . . . . . . . . . . . .  12<https://tools.ietf.org/html/rfc7297#page-12>

     3.6<https://tools.ietf.org/html/rfc7297#section-3.6>.  Conformance Traffic . . . . . . . . . . . . . . . . . . .  13<https://tools.ietf.org/html/rfc7297#page-13>

     3.7<https://tools.ietf.org/html/rfc7297#section-3.7>.  Overall Traffic Guarantees  . . . . . . . . . . . . . . .  13<https://tools.ietf.org/html/rfc7297#page-13>

     3.8<https://tools.ietf.org/html/rfc7297#section-3.8>.  Traffic Isolation . . . . . . . . . . . . . . . . . . . .  13<https://tools.ietf.org/html/rfc7297#page-13>

     3.9<https://tools.ietf.org/html/rfc7297#section-3.9>.  Flow Identification . . . . . . . . . . . . . . . . . . .  13<https://tools.ietf.org/html/rfc7297#page-13>

     3.10<https://tools.ietf.org/html/rfc7297#section-3.10>. Routing and Forwarding  . . . . . . . . . . . . . . . . .  14<https://tools.ietf.org/html/rfc7297#page-14>

     3.11<https://tools.ietf.org/html/rfc7297#section-3.11>. Activation Means  . . . . . . . . . . . . . . . . . . . .  15<https://tools.ietf.org/html/rfc7297#page-15>

     3.12<https://tools.ietf.org/html/rfc7297#section-3.12>. Invocation Means  . . . . . . . . . . . . . . . . . . . .  15<https://tools.ietf.org/html/rfc7297#page-15>

     3.13<https://tools.ietf.org/html/rfc7297#section-3.13>. Notifications . . . . . . . . . . . . . . . . . . . . . .  16<https://tools.ietf.org/html/rfc7297#page-16>

Cheers,
Med

De : Teas [mailto:[email-masked]] De la part de Vishnu Pavan Beeram
Envoyé : mercredi 19 août 2020 17:50
À : TEAS WG <[email-masked]>
Cc : TEAS WG Chairs <[email-masked]>
Objet : [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

All,

Thanks,
Pavan and Lou

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Aug 2020 11:15:55 -0400

RFC 7297 is an Independent Submission Informational RFC.
Looking at it, building from it, and where agreed copying the text would 
seem sensible.
Referencing it normatively would be a major problem, as it is not an 
IETF consensus document.

Yours,
Joel

On 8/27/2020 8:26 AM, [email-masked] wrote:
> Hi all,
> 
> I support this effort.
> 
> That’s said, I do think the document should leverage existing documents, 
> e.g., use https://tools.ietf.org/html/rfc7297 to define the SLOs:
> 
> 3  <https://tools.ietf.org/html/rfc7297#section-3>.  Connectivity Provisioning Profile (CPP) . . . . . . . . . . . 9  <https://tools.ietf.org/html/rfc7297#page-9>
> 
> 3.1  <https://tools.ietf.org/html/rfc7297#section-3.1>.  Customer Nodes Map  . . . . . . . . . . . . . . . . . . . 9  <https://tools.ietf.org/html/rfc7297#page-9>
> 
> 3.2  <https://tools.ietf.org/html/rfc7297#section-3.2>.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 10  <https://tools.ietf.org/html/rfc7297#page-10>
> 
> 3.3  <https://tools.ietf.org/html/rfc7297#section-3.3>.  QoS Guarantees  . . . . . . . . . . . . . . . . . . . . . 11  <https://tools.ietf.org/html/rfc7297#page-11>
> 
> 3.4  <https://tools.ietf.org/html/rfc7297#section-3.4>.  Availability  . . . . . . . . . . . . . . . . . . . . . . 11  <https://tools.ietf.org/html/rfc7297#page-11>
> 
> 3.5  <https://tools.ietf.org/html/rfc7297#section-3.5>.  Capacity  . . . . . . . . . . . . . . . . . . . . . . . . 12  <https://tools.ietf.org/html/rfc7297#page-12>
> 
> 3.6  <https://tools.ietf.org/html/rfc7297#section-3.6>.  Conformance Traffic . . . . . . . . . . . . . . . . . . . 13  <https://tools.ietf.org/html/rfc7297#page-13>
> 
> 3.7  <https://tools.ietf.org/html/rfc7297#section-3.7>.  Overall Traffic Guarantees  . . . . . . . . . . . . . . . 13  <https://tools.ietf.org/html/rfc7297#page-13>
> 
> 3.8  <https://tools.ietf.org/html/rfc7297#section-3.8>.  Traffic Isolation . . . . . . . . . . . . . . . . . . . . 13  <https://tools.ietf.org/html/rfc7297#page-13>
> 
> 3.9  <https://tools.ietf.org/html/rfc7297#section-3.9>.  Flow Identification . . . . . . . . . . . . . . . . . . . 13  <https://tools.ietf.org/html/rfc7297#page-13>
> 
> 3.10  <https://tools.ietf.org/html/rfc7297#section-3.10>. Routing and Forwarding  . . . . . . . . . . . . . . . . . 14  <https://tools.ietf.org/html/rfc7297#page-14>
> 
> 3.11  <https://tools.ietf.org/html/rfc7297#section-3.11>. Activation Means  . . . . . . . . . . . . . . . . . . . . 15  <https://tools.ietf.org/html/rfc7297#page-15>
> 
> 3.12  <https://tools.ietf.org/html/rfc7297#section-3.12>. Invocation Means  . . . . . . . . . . . . . . . . . . . . 15  <https://tools.ietf.org/html/rfc7297#page-15>
> 
>       3.13  <https://tools.ietf.org/html/rfc7297#section-3.13>. Notifications . . . . . . . . . . . . . . . . . . . . . .16  <https://tools.ietf.org/html/rfc7297#page-16>
> 
> Cheers,
> 
> Med
> 
> *De :*Teas [mailto:[email-masked]] *De la part de* Vishnu Pavan 
> Beeram
> *Envoyé :* mercredi 19 août 2020 17:50
> *À :* TEAS WG <[email-masked]>
> *Cc :* TEAS WG Chairs <[email-masked]>
> *Objet :* [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition
> 
> All,
>

---

From: Eric Gray <[email-masked]>
Date: Thu, 27 Aug 2020 16:20:56 -0400

With the changes suggested by the WG chairs, regarding removal of the appendix and adding placeholder text to the draft, draft-nsdt-teas-transport-slice-definition is even more ready for adoption than it was when presented at IETF 108.

I support the adoption of this draft.

I also realize that there is work cut out for the working group before this draft should be considered finished, and I see a lot of the discussion going on in the adoption thread as being somewhat ahead of its time - because the draft should be adopted as suggested by the WG Chairs - before we delve into the actual content and details.

As a co-editor of the Framework draft, I believe there are some simple ways to polish both drafts further along the lines of suggestions made by many people in this thread - but that is a discussion for after we decide to adopt the drafts.

Some of that discussion has already started - in background mode, as well as in this thread - but much of it should wait until we can make appropriate suggestions to the WG and gain some high degree of consensus on what to actually do.

—
Eric

---

From: <[email-masked]>
Date: Fri, 28 Aug 2020 06:15:07 +0000

Hi Joel, 

> Looking at it, building from it, and where agreed copying the text
> would seem sensible.

Yes, that is what I had in mind.  

Cheers,
Med

> -----Message d'origine-----
> De : Joel M. Halpern [mailto:[email-masked]]
> Envoyé : jeudi 27 août 2020 17:16
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; Vishnu
> Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>
> Objet : Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-
> definition
> 
> Looking at it, building from it, and where agreed copying the text
> would seem sensible.
> > That’s said, I do think the document should leverage existing
> > documents, e.g., use https://tools.ietf.org/html/rfc7297 to define
> the SLOs:
> >
> > 3  <https://tools.ietf.org/html/rfc7297#section-3>.  Connectivity
> > Provisioning Profile (CPP) . . . . . . . . . . . 9
> > <https://tools.ietf.org/html/rfc7297#page-9>
> >
> > 3.1  <https://tools.ietf.org/html/rfc7297#section-3.1>.  Customer
> > Nodes Map  . . . . . . . . . . . . . . . . . . . 9
> > <https://tools.ietf.org/html/rfc7297#page-9>
> >
> > 3.2  <https://tools.ietf.org/html/rfc7297#section-3.2>.  Scope . . .
> .
> > . . . . . . . . . . . . . . . . . . . . . . 10
> > <https://tools.ietf.org/html/rfc7297#page-10>
> >
> > 3.3  <https://tools.ietf.org/html/rfc7297#section-3.3>.  QoS
> > Guarantees  . . . . . . . . . . . . . . . . . . . . . 11
> > <https://tools.ietf.org/html/rfc7297#page-11>
> >
> > 3.4  <https://tools.ietf.org/html/rfc7297#section-
> 3.4>.  Availability
> > . . . . . . . . . . . . . . . . . . . . . . 11
> > <https://tools.ietf.org/html/rfc7297#page-11>
> >
> > 3.5  <https://tools.ietf.org/html/rfc7297#section-3.5>.  Capacity  .
> .
> > . . . . . . . . . . . . . . . . . . . . . . 12
> > <https://tools.ietf.org/html/rfc7297#page-12>
> >
> > 3.6  <https://tools.ietf.org/html/rfc7297#section-3.6>.  Conformance
> > Traffic . . . . . . . . . . . . . . . . . . . 13
> > <https://tools.ietf.org/html/rfc7297#page-13>
> >
> > 3.7  <https://tools.ietf.org/html/rfc7297#section-3.7>.  Overall
> > Traffic Guarantees  . . . . . . . . . . . . . . . 13
> > <https://tools.ietf.org/html/rfc7297#page-13>
> >
> > 3.8  <https://tools.ietf.org/html/rfc7297#section-3.8>.  Traffic
> > Isolation . . . . . . . . . . . . . . . . . . . . 13
> > <https://tools.ietf.org/html/rfc7297#page-13>
> >
> > 3.9  <https://tools.ietf.org/html/rfc7297#section-3.9>.  Flow
> > Identification . . . . . . . . . . . . . . . . . . . 13
> > <https://tools.ietf.org/html/rfc7297#page-13>
> >
> > 3.10  <https://tools.ietf.org/html/rfc7297#section-3.10>. Routing
> and
> > Forwarding  . . . . . . . . . . . . . . . . . 14
> > <https://tools.ietf.org/html/rfc7297#page-14>
> >
> > 3.11  <https://tools.ietf.org/html/rfc7297#section-3.11>. Activation
> > Means  . . . . . . . . . . . . . . . . . . . . 15
> > <https://tools.ietf.org/html/rfc7297#page-15>
> >
> > 3.12  <https://tools.ietf.org/html/rfc7297#section-3.12>. Invocation
> > Means  . . . . . . . . . . . . . . . . . . . . 15
> > <https://tools.ietf.org/html/rfc7297#page-15>
> >
> >       3.13  <https://tools.ietf.org/html/rfc7297#section-3.13>.
> > Notifications . . . . . . . . . . . . . . . . . . . . . .16
> > <https://tools.ietf.org/html/rfc7297#page-16>
> >
> > Cheers,
> >
> > Med
> >
> > Beeram *Envoyé :* mercredi 19 août 2020 17:50 *À :* TEAS WG
> > <[email-masked]> *Cc :* TEAS WG Chairs <[email-masked]>
> *Objet :*
> > [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition
> >
> > All,
> >
> like

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Aug 2020 23:56:41 +0100

Hi all,

I spent a good chunk of time yesterday and today catching up on the threads about this document. I believe there are several important things to say:

1. Many thanks are due to the Design Team which I know has invested a lot of time and thought into working on their small set of documents. Such effort should not go unrecognised.

2. Several comments have referred to the consensus that the Design Team reached on the content of the document. It's good that the DT was able to reach consensus - I haven't gone back to determine whether it was rough and how it was measured, and that doesn't matter if they agree it was reached. However, the consensus, of itself is only informational as we consider the document and doesn't carry weight against arguments put forward in this discussion (especially by people who were not active participants in the DT). Let's hear all voices and opinions and not squash them with the DT's collective view.

3. I am puzzled by the debate about what to do with text that might be removed from this document. We are debating adopting this draft and don't (at this stage) have control over what goes in other DT documents (or any other non-WG document). If the WG decides that text does not belong in this document, then that is all we decided and people are free to place that text elsewhere: in some other non-WG draft if their co-authors agree, or in a new draft of their own. So let's debate what text we want in *this* document on its own merits.

4. The discussion of "isolation" seems to get significantly hung up on the difference between "isolation as part of a service objective" and "isolation as a delivery mechanism". Service objectives are not necessarily directly or easily observable by a client. For example, you might ask your service provider to guarantee that your traffic is not routed via <insert name of country you don't trust>, but when packets are tunnelled and the provider doesn't give you good access to their internal diagnostic traces, it can be less than simple to verify that they are meeting this objective. Thus, absolute requests for isolation are probably meaningless at the service interface and in some network technologies they cannot really be delivered, anyway. What is more important is that we deconstruct "isolation" into the concepts that the client does actually care about: no misdelivery, no observation of traffic by another client, no interference on traffic quality/delivery owing to the activity of other clients. In draft-king-teas-applicability-actn-slicing we tried to tease out these distinctions and believed that the way in which these service features might be delivered are an entirely different matter - if someone wants to write a document called "Delivering Service Isolation Using SRv6" then I think that would be a fine place to discuss such issues.

5. Document review and opinion on adoption. That's next on my list 😊

Best,

Adrian

From: Teas <[email-masked]> On Behalf Of Vishnu Pavan Beeram
Sent: 19 August 2020 16:50
To: TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>
Subject: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

All,

Thanks,
Pavan and Lou

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 29 Aug 2020 16:09:49 -0400

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 <
[email-masked]> 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 <[email-masked]>
>
> *En nombre de *Gengxuesong (Geng Xuesong)
>
>
> *Enviado el:* jueves, 27 de agosto de 2020 4:28
>
>
> *Para:* Daniele Ceccarelli <[email-masked]>; Dongjie
> (Jimmy) <[email-masked]>; Jeff Tantsura <[email-masked]>;
> TEAS WG <[email-masked]>; Jari Arkko <[email-masked]>
>
>
> *CC:* Vishnu Pavan Beeram <[email-masked]>
>
>
> *Asunto:* Re: [Teas] WG adoption -
> 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:[email-masked]
> <[email-masked]>]
>
>
>
>
> *Sent:* Wednesday, August 26, 2020 9:34 PM
>
>
> *To:* Dongjie (Jimmy) <[email-masked]>; Gengxuesong (Geng Xuesong) <
> [email-masked]>; Jeff Tantsura <[email-masked]>;
>
> TEAS WG <[email-masked]>; Jari Arkko <[email-masked]>
>
>
> *Cc:* Vishnu Pavan Beeram <[email-masked]>
>
>
> *Subject:* RE: [Teas] WG adoption -
> 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.
>
>
>
>
>
>
> *From:* Teas <[email-masked]>
>
> *On Behalf Of *Dongjie (Jimmy)
>
>
> *Sent:* den 26 augusti 2020 14:56
>
>
> *To:* Gengxuesong (Geng Xuesong) <[email-masked]>; Jeff Tantsura <
> [email-masked]>; TEAS WG <[email-masked]>; Jari
>
> Arkko <[email-masked]>
>
>
> *Cc:* Vishnu Pavan Beeram <[email-masked]>
>
>
> 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 <[email-masked]>; TEAS WG <[email-masked]>;
> Jari Arkko <[email-masked]>
>
>
> *Cc:* Vishnu Pavan Beeram <[email-masked]>
>
>
> *Subject:* RE: [Teas] WG adoption -
> 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:[email-masked] <[email-masked]>]
>
> *On Behalf Of *Jeff Tantsura
>
>
> *Sent:* Wednesday, August 26, 2020 6:32 AM
>
>
> *To:* TEAS WG <[email-masked]>; Jari Arkko <jari.arkko@piuha....net
> <[email-masked]>>
>
>
> *Cc:* Vishnu Pavan Beeram <[email-masked]>
>
>
> proposals. Authority to do stuff is entirely in the
>
> WG now.
>
>
>
>
>
> 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 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”....
>
>
>
>
>
> 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
>
>
>
>
>
> 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
>
>
>
>
>
>
>
>

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 29 Aug 2020 16:28:36 -0400

Isolation in very basic terms you can think of the two ends of the spectrum
dedicated and shared and then you have all the degrees of isolation to get
to dedicated which would be the highest cost as far as tier of service.

This concept is no different then provisioning optical OTN 100G circuits
with path diversity that when provisioning circuits at Layer 1 you don’t
any DWDM wavelength to traverse a common pop or path.

Kind Regards

Gyan

On Sat, Aug 29, 2020 at 4:09 PM Gyan Mishra <[email-masked]> wrote:

>>    what we commonly call “disjointness”, right? We’ve been speaking
>>    about SRLG disjointness for decades.
>> *To:* Gengxuesong (Geng Xuesong) <[email-masked]>; Jeff Tantsura
>> <[email-masked]>; TEAS WG <[email-masked]>; Jari
>>
>> I also agree with the proposal of the chairs, and think it is important
>> to have input from the WG about these terms.
>>
>>
>>
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> themselves. The appendix only attempts to say that
>>
>> 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
>>

*Gyan Mishra*

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 29 Aug 2020 14:37:37 -0700

Hi Xuesong,
I assume that the term "isolation" is not simply a replacement for
"dedicated" and is intended to apply to cases when transport slices share
underlying infrastructure. If that is the case,  I think there's a sort of
contradiction between statements "isolation is SLO" and "isolation is not
directly measurable [calculable GIM]". I wonder, What is the opposite of
isolation as a TS characteristic? I imagine that one example of that would
be a case when the flow from one slice is using resources from another,
i.e., interference between slices. There is a number of performance metrics
that may indicate the lack of isolation but that, in my view, can be
attributed to under-isolation (for the lack of better term at the moment)
between slices as the result of root cause analysis of increased latency
and/or packet loss. And even if interference from another slice doesn't
result in observable quality degradation, an operator can compare the
offered load from the customer with the available BW. And that information
doesn't have to be measured by the client but reported by the operator in
the agreed intervals and aggregated on an hourly and daily basis.
Certainly, we can have more cases that constitute the un-isolationism of
slices but that, I suspect, still will be observable, measurable,
calculable through other SLOs and only the analysis will point to the
inadequate isolation of resources.
But back to the isolation. I believe that the proposal from WG Chairs is
the best way forward. Let us explore our interpretations of the term and
work on formulating one we can build consensus (rough) around. And if so
happens that there is none, then we all get a better understanding of the
problem and may get it in the new document.

Regards,
Greg

On Tue, Aug 25, 2020 at 7:40 PM Gengxuesong (Geng Xuesong) <
[email-masked]> wrote:

> 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:[email-masked]] *On Behalf Of *Jeff Tantsura
> *To:* TEAS WG <[email-masked]>; Jari Arkko <[email-masked]>
> indirect way”..
> 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

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 29 Aug 2020 18:28:59 -0400

Hi Greg

Sorry to speak out of turn.

I agree with you from my perspective that “isolation” is an abstraction or
dedicated so is not the same and that is why you can have degrees of
isolation between slices and as you mention with the slices stepping on
each other or cross talk as far as resource sharing.

My guess on opposite of isolation from TS perspective is where all VPN
overlay have the same treatment and all the same characteristics as far as
SLO and they all sit on the same set of TSEs.

There maybe some cases where with RSVP TE is used for per VRF TE coloring
or SR based SR-TE per VRF coloring where different VPNs have different set
of TSE paths and may have a degree of isolation based on TSEs set and
sharing of resources.  So both examples from a TS perspective would have
based on TSO metrics have a degree of isolation or segregation of traffic.

Kind Regards

Gyan

On Sat, Aug 29, 2020 at 5:37 PM Greg Mirsky <[email-masked]> wrote:

>> 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:[email-masked]]
>>
>> industry relates to our work in this indirect way”..
>>
>>
>>
>>
>>

*Gyan Mishra*

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Mon, 31 Aug 2020 03:11:35 +0000

Hi Greg,

Thank you for directing the discussion to the technical nature of isolation. Please find comments below:
I assume that the term "isolation" is not simply a replacement for "dedicated" and is intended to apply to cases when transport slices share underlying infrastructure.
I agree about your description of isolation. Although there may be other kinds of understanding which will broaden the scope of this concept. I will leave it to the authors and WG. The discussions below based on the assumption that “isolation is intended to apply to cases when transport slices share underlying infrastructure ”.
There is a number of performance metrics that may indicate the lack of isolation but that, in my view, can be attributed to under-isolation (for the lack of better term at the moment) between slices as the result of root cause analysis of increased latency and/or packet loss.
I think here hides some basic logic behind the debate: if the isolation could be described indirectly by other SLO attribute, whether we still need it as an independent concept. My answer is: the hypothetical part of the question is incorrect, because isolation can’t be described by other attributes, although it influences other attributes. A further conclusion is that : Deterioration of other SLO metrics is neither sufficient nor necessary for isolation absence. Two simple examples to defense this:

1.       When isolation is perfectly executed that there is no interfere among different slices, the performance could still be very terrible if the resource inside the slice is exhausted.

2.       When there is no isolation among slices and all the resource is shared, the performance could still be very great if the resource is sufficient for all the slices.
So the trick here is: other SLO attributes (delay, jitter, loss…) depend on whether there is enough cake to make everybody happy, and isolation prevents other guys to touch my cake. They're relevant, but they're different, and not interchangeable.
That is why I agree that isolation should be clearly defined in draft-nsdt-teas-transport-slice-definition, not in Appendix.

Regards,
Xuesong

From: Greg Mirsky [mailto:[email-masked]]
Sent: Sunday, August 30, 2020 5:38 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>; TEAS WG <[email-masked]>; Jari Arkko <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

Hi Xuesong,
I assume that the term "isolation" is not simply a replacement for "dedicated" and is intended to apply to cases when transport slices share underlying infrastructure. If that is the case,  I think there's a sort of contradiction between statements "isolation is SLO" and "isolation is not directly measurable [calculable GIM]". I wonder, What is the opposite of isolation as a TS characteristic? I imagine that one example of that would be a case when the flow from one slice is using resources from another, i.e., interference between slices. There is a number of performance metrics that may indicate the lack of isolation but that, in my view, can be attributed to under-isolation (for the lack of better term at the moment) between slices as the result of root cause analysis of increased latency and/or packet loss. And even if interference from another slice doesn't result in observable quality degradation, an operator can compare the offered load from the customer with the available BW. And that information doesn't have to be measured by the client but reported by the operator in the agreed intervals and aggregated on an hourly and daily basis. Certainly, we can have more cases that constitute the un-isolationism of slices but that, I suspect, still will be observable, measurable, calculable through other SLOs and only the analysis will point to the inadequate isolation of resources.
But back to the isolation. I believe that the proposal from WG Chairs is the best way forward. Let us explore our interpretations of the term and work on formulating one we can build consensus (rough) around. And if so happens that there is none, then we all get a better understanding of the problem and may get it in the new document.

Regards,
Greg

On Tue, Aug 25, 2020 at 7:40 PM Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>> wrote:
+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:[email-masked]<mailto:[email-masked]>] On Behalf Of Jeff Tantsura

Cheers,
Jeff

Design team discussions:

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

Personal perspective:

Jari

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 30 Aug 2020 23:31:27 -0400

Assuming the description you give below, I have two related questions.
If the performance is great, why would the transport user care whether 
it is not actually isolated?
Conversely, if the performance does not meet the needs, then why would 
the transport user care that isolation has been preserved?

Yours,
Joel

On 8/30/2020 11:11 PM, Gengxuesong (Geng Xuesong) wrote:
> "dedicated" and is intended to apply to cases when transport slices 
> share underlying infrastructure.
> 
> I agree about your description of isolation. Although there may be other 
> kinds of understanding which will broaden the scope of this concept. I 
> will leave it to the authors and WG. The discussions below based on the 
> assumption that “isolation is intended to apply to cases when transport 
> slices share underlying infrastructure ”.
> 
> There is a number of performance metrics that may indicate the lack of 
> isolation but that, in my view, can be attributed to under-isolation 
> (for the lack of better term at the moment) between slices as the result 
> of root cause analysis of increased latency and/or packet loss.
> 
> I think here hides some basic logic behind the debate: if the isolation 
> could be described indirectly by other SLO attribute, whether we still 
> need it as an independent concept. My answer is: the hypothetical part 
> of the question is incorrect, because *isolation can’t be described by 
> other attributes, although it influences other attributes.* A further 
> conclusion is that : *Deterioration of other SLO metrics is neither 
> sufficient nor necessary for isolation absence*. Two simple examples to 
> defense this:
> 
> 1.When isolation is perfectly executed that there is no interfere among 
> different slices, the performance could still be very terrible if the 
> resource inside the slice is exhausted.
> 
> 2.When there is no isolation among slices and all the resource is 
> shared, the performance could still be very great if the resource is 
> sufficient for all the slices.
> 
> So the trick here is: other SLO attributes (delay, jitter, loss…) depend 
> on whether there is enough cake to make everybody happy, and isolation 
> prevents other guys to touch my cake. They're relevant, but they're 
> different, and not interchangeable.
> 
> That is why I agree that isolation should be clearly defined in 
> draft-nsdt-teas-transport-slice-definition, not in Appendix.
> 
> Regards,
> 
> Xuesong
> 
> *From:*Greg Mirsky [mailto:[email-masked]]
> *Sent:* Sunday, August 30, 2020 5:38 AM
> *To:* Gengxuesong (Geng Xuesong) <[email-masked]>
> *Cc:* Jeff Tantsura <[email-masked]>; TEAS WG <[email-masked]>; 
> Jari Arkko <[email-masked]>; Vishnu Pavan Beeram 
> <[email-masked]>
> "dedicated" and is intended to apply to cases when transport slices 
> share underlying infrastructure. If that is the case,  I think there's a 
> sort of contradiction between statements "isolation is SLO" and 
> "isolation is not directly measurable [calculable GIM]". I wonder, What 
> is the opposite of isolation as a TS characteristic? I imagine that one 
> example of that would be a case when the flow from one slice is using 
> resources from another, i.e., interference between slices. There is a 
> number of performance metrics that may indicate the lack of isolation 
> but that, in my view, can be attributed to under-isolation (for the lack 
> of better term at the moment) between slices as the result of root cause 
> analysis of increased latency and/or packet loss. And even if 
> interference from another slice doesn't result in observable quality 
> degradation, an operator can compare the offered load from the customer 
> with the available BW. And that information doesn't have to be measured 
> by the client but reported by the operator in the agreed intervals and 
> aggregated on an hourly and daily basis. Certainly, we can have more 
> cases that constitute the un-isolationism of slices but that, I suspect, 
> still will be observable, measurable, calculable through other SLOs and 
> only the analysis will point to the inadequate isolation of resources.
> 
> happens that there is none, then we all get a better understanding of 
> the problem and may get it in the new document.
> 
> Regards,
> 
> Greg
> 
> On Tue, Aug 25, 2020 at 7:40 PM Gengxuesong (Geng Xuesong) 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     +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:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Jeff Tantsura
>     *To:* TEAS WG <[email-masked] <mailto:[email-masked]>>; Jari Arkko
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Vishnu Pavan Beeram <[email-masked]
>     <mailto:[email-masked]>>
>     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.
>     separation/isolation - finance for security reasons,  DCI for
>     resiliency, etc.
> 
>     find an appropriate and acceptable to the WG description as the
>     document evolves.
> 
>     Cheers,
> 
>     Jeff
> 
>         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”..
> 
>         My impression of customer requirements and how they get
>         represented matches with what Joel has been saying in this thread.
> 
>         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
>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Mon, 31 Aug 2020 04:00:30 +0000

Hi Joel,

Good question. Answers inline.

Regards

Xuesong

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Monday, August 31, 2020 11:31 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>
Cc: TEAS WG <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

If the performance is great, why would the transport user care whether it is not actually isolated?

Conversely, if the performance does not meet the needs, then why would the transport user care that isolation has been preserved?

2 perspectives:

1.       The essence of performance measurement is sampling. Network changes all the time. Good performance at 8 o'clock doesn’t mean good performance at 9 o'clock. Isolation shows the fact to the transport user: no matter when, my performance won’t be bothered by other users.

2.       Further assumption is: the traffic in my slice is under my control, but I can't keep my neighbors from overloading. In the context of isolation ensuring, if the user is still not satisfied with the performance, limit traffic or increase capacity inside the slice. Fair game.

Yours,

Joel

> Thank you for directing the discussion to the technical nature of

> isolation. Please find comments below:

> I agree about your description of isolation. Although there may be

> other kinds of understanding which will broaden the scope of this

> concept. I will leave it to the authors and WG. The discussions below

> based on the assumption that “isolation is intended to apply to cases

> when transport slices share underlying infrastructure ”.

> (for the lack of better term at the moment) between slices as the

> result of root cause analysis of increased latency and/or packet loss.

> I think here hides some basic logic behind the debate: if the

> isolation could be described indirectly by other SLO attribute,

> whether we still need it as an independent concept. My answer is: the

> hypothetical part of the question is incorrect, because *isolation

> can’t be described by other attributes, although it influences other

> attributes.* A further conclusion is that : *Deterioration of other

> SLO metrics is neither sufficient nor necessary for isolation

> absence*. Two simple examples to defense this:

> 1.When isolation is perfectly executed that there is no interfere

> among different slices, the performance could still be very terrible

> if the resource inside the slice is exhausted.

> So the trick here is: other SLO attributes (delay, jitter, loss…)

> depend on whether there is enough cake to make everybody happy, and

> isolation prevents other guys to touch my cake. They're relevant, but

> they're different, and not interchangeable.

> *To:* Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>

> *Cc:* Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; TEAS WG

> <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan

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

> share underlying infrastructure. If that is the case,  I think there's

> a sort of contradiction between statements "isolation is SLO" and

> "isolation is not directly measurable [calculable GIM]". I wonder,

> What is the opposite of isolation as a TS characteristic? I imagine

> that one example of that would be a case when the flow from one slice

> is using resources from another, i.e., interference between slices.

> (for the lack of better term at the moment) between slices as the

> result of root cause analysis of increased latency and/or packet loss.

> And even if interference from another slice doesn't result in

> observable quality degradation, an operator can compare the offered

> load from the customer with the available BW. And that information

> doesn't have to be measured by the client but reported by the operator

> in the agreed intervals and aggregated on an hourly and daily basis.

> Certainly, we can have more cases that constitute the un-isolationism

> of slices but that, I suspect, still will be observable, measurable,

> calculable through other SLOs and only the analysis will point to the inadequate isolation of resources.

> But back to the isolation. I believe that the proposal from WG Chairs

> is the best way forward. Let us explore our interpretations of the

> term and work on formulating one we can build consensus (rough)

> around. And if so happens that there is none, then we all get a better

> understanding of the problem and may get it in the new document.

> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:

>     *To:* TEAS WG <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>; Jari Arkko

>     <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>     On Aug 25, 2020, 12:59 PM -0700, Jari Arkko <[email-masked]

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

>         I can appreciate that we may have failed in the task of writing

>         that. Delete and move on, no biggie :-)

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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2020 00:10:47 -0400

You list two points.  I am confused by both of them.  I will paraphrase 
each with my confusion.  (Posasibly my paraphrase will indicate that I 
am misunderstanding you.  If so, please clarify and accept my apologies 
for misunderstanding.

Point 1) networks change.  You then claim isolation says that my network 
changes won't affect you.  Isn't that the point of attaching a 
confidence to an SLO.  If I tell you that I will meet the requirements 
99.99% of the time, that seems to be what the custoemr is asking for. 
As I ahve said before, the custoemr does not seem to care whether a 
failure is caused by competing traffic or by a network failure or a 
backhoe or ... He is still not getting what he wants.  So I expect a 
customer to want a commitment that he will get what he has been 
promised, not merely avoidance of a specific failure mode.

Point 2) What I do in my slice (VPN, traffic set, ...) is my problem. 
Mostly agreed.  But what does that have to do with isolation?Or with 
SLO?  The one aspect on which I disagree is that in order to operate his 
network, an operator may well police high priority traffic from a 
customer to stay within the limit that the customer has agreed to.  In 
that sense, an end customer failure may make more work for the operator, 
not just the customer.  But that still has nothing to do with isolation.

Once we have a document adopted (with placeholders) I would be 
interested to see an actionable clear defintion of "isolation".  I have 
not seen one to date.  Neither the text we are removing, nor the earlier 
text that was present, constitute such a definition.  And various 
people's examples have suggested very different (if vague) definitions.

Yours,
Joel

On 8/31/2020 12:00 AM, Gengxuesong (Geng Xuesong) wrote:
> 1.The essence of performance measurement is sampling. Network changes 
> all the time. Good performance at 8 o'clock doesn’t mean good 
> performance at 9 o'clock. Isolation shows the fact to the transport 
> user: no matter when, my performance won’t be bothered by other users.
> 
> 2.Further assumption is: the traffic in my slice is under my control, 
> but I can't keep my neighbors from overloading. In the context of 
> isolation ensuring, if the user is still not satisfied with the 
> performance, limit traffic or increase capacity inside the slice. Fair game.
> 
> Yours,
> 
> Joel
> 
>> "dedicated" andis intended to apply to cases when transport slices
> 
>> *To:* Gengxuesong (Geng Xuesong) <[email-masked] <mailto:[email-masked]>>
> 
>> *Cc:* Jeff Tantsura <[email-masked] <mailto:[email-masked]>>; TEAS WG
> 
>> <[email-masked] <mailto:[email-masked]>>; Jari Arkko <[email-masked] 
> <mailto:[email-masked]>>; Vishnu Pavan
> 
>> Beeram <[email-masked] <mailto:[email-masked]>>
> 
>> "dedicated" andis intended to apply to cases when transport slices
> 
>> share underlying infrastructure. If that is the case,I think there's
> 
>> load from the customer with the availableBW. And that information
> 
>> in the agreed intervals and aggregated on an hourlyand dailybasis.
> 
>> Certainly, we can have more cases thatconstitute the un-isolationism
> 
>> calculable through other SLOs and only the analysis will point to the inadequate isolationof resources.
> 
>> 
> 
>> <[email-masked] <mailto:[email-masked] 
> <mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:
> 
>> 
> 
>>     +1
> 
>> 
> 
>>     *To:* TEAS WG <[email-masked] <mailto:[email-masked] 
> <mailto:[email-masked]%20%3cmailto:[email-masked]>>>; Jari Arkko
> 
>>     <[email-masked] <mailto:[email-masked] 
> <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
> 
>>     It is also a viable constrain to be used ina path computation logic.
> 
>>     separation/isolation - finance for security reasons,DCI for
> 
>>     resiliency, etc.
> 
>> 
> 
>>         the primary characteristics —such as that we promise you n
> 
>>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> 
>>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Mon, 31 Aug 2020 07:36:24 +0000

Some comments inline.

Regards

Xuesong

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, August 31, 2020 12:11 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>
Cc: TEAS WG <[email-masked]>
Subject: Re: [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition - Appendix

You list two points.  I am confused by both of them.  I will paraphrase each with my confusion.  (Posasibly my paraphrase will indicate that I am misunderstanding you.  If so, please clarify and accept my apologies for misunderstanding.

Point 1) networks change.  You then claim isolation says that my network changes won't affect you.  Isn't that the point of attaching a confidence to an SLO.  If I tell you that I will meet the requirements 99.99% of the time, that seems to be what the custoemr is asking for.

As I ahve said before, the custoemr does not seem to care whether a failure is caused by competing traffic or by a network failure or a backhoe or ... He is still not getting what he wants.  So I expect a customer to want a commitment that he will get what he has been promised, not merely avoidance of a specific failure mode.

A crude example for illustrative purposes only : When SLO couldn’t be met, 50% of the cases is caused by myself and 50% of the cases is caused by others. Isolation could eliminate half of the failure cases. If others are always rude and greedy, the benefits from isolation may be more obvious. Basically, isolation guarantees people only get the part they have paid and decreases the probability of SLO ruining. That’s the benefit for the customer.

I like the expression of “attaching a confidence to an SLO”, if “confidence” here means “confidence level” mathematically . I think no SLO guarantee could be achieved(technically strict rather than experience value) without isolation, considering that behavior of others could not be expected. We could never provide network service with 0 loss, 20ms latency, 5ms jitter, when we share the network with another guy who filling too much traffic to the network all the time. That’s the benefit for providing other SLO attributes.

Mostly agreed.  But what does that have to do with isolation?Or with SLO? The one aspect on which I disagree is that in order to operate his network, an operator may well police high priority traffic from a customer to stay within the limit that the customer has agreed to.  In that sense, an end customer failure may make more work for the operator, not just the customer.  But that still has nothing to do with isolation.

It is a good point. I agree that if the access control of high priority traffic, which takes up only a very small fraction of the network bandwidth, is well executed, for this part of the traffic, the most of the problem may not be inside the operator’s network. However, this method is not so easy as it looks like, some issues should be considered:

1.       How to “well police” the high priority in the whole network, where every hop could be the bottleneck theoretically;

2.       If the traffic is simply divided into high priority and low priority, whether different kinds of requirements from different applications could be satisfied;

3.       With more traffic requires SLO guarantee, the percentage of high-priority traffic in the network will rise accordingly, whether “well police” still works with more traffic competes for limited network resource;

Isolation matters considering all these cases.

Once we have a document adopted (with placeholders) I would be interested to see an actionable clear defintion of "isolation".  I have not seen one to date.  Neither the text we are removing, nor the earlier text that was present, constitute such a definition.  And various people's examples have suggested very different (if vague) definitions.

I’m looking forward to a clear definition too, although it is not easy to handle all these different opinions.

Yours,

Joel

> To: Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>

> Cc: TEAS WG <[email-masked]<mailto:[email-masked]>>

>> There is a number of performance metrics that may indicate the lack

>> of

>> *To:* Gengxuesong (Geng Xuesong) <[email-masked]

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

>> *Cc:* Jeff Tantsura <[email-masked]

>> <mailto:[email-masked]>>; TEAS WG

>> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>; Jari Arkko

>> <[email-masked]

>> Beeram <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>> There is a number of performance metrics that may indicate the lack

>> of

>> doesn't have to be measured by the client but reported by the

>> operator

>> around. And if so happens that there is none, then we all get a

>> better

>>     defined precisely. People are asking whether TE link is isolated

>>     not. It could be clarified by some deep analysis, good

>>discussions

>>     legally binding requirement wrt service provided, could be

>>expressed

>>     There are connectivity RFIs that explciteily require full

>>physical

>>     We could pretend it doesn’t exist (which is the complete removal)

>>         High-level bit: I would like to see the document adopted.

>>With

>>         just for preparing proposals. Authority to do stuff is

>>entirely

>>         When it comes to the isolation topic, however, FWIW, I wanted

>>to

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

>>         the bandwidth and other requirements, and that there are

>>several

>>         having your neighbour affect the bandwidth the service

>>provider

>>         felt that the top-level SLOs should be the requirement and

>>are

>>         sufficient by themselves. The appendix only attempts to say

>>that

>>         I can appreciate that we may have failed in the task of

>>writing

>>         GB/s. Then I would write a footnote or appendix somewhere

>>that

>>         characteristics, and hence need not be discussed further in

>>this

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

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

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

Teas mailing list

---

From: John E Drake <[email-masked]>
Date: Mon, 31 Aug 2020 13:39:48 +0000

Precisely

Yours Irrespectively,

John

Juniper Business Use Only

> Sent: Sunday, August 30, 2020 11:31 PM
> [External Email. Be cautious of content]
> 
> 
> Conversely, if the performance does not meet the needs, then why would the
> transport user care that isolation has been preserved?
> 
> Yours,
> Joel
> 
> > *Cc:* Jeff Tantsura <[email-masked]>; TEAS WG
> > <[email-masked]>; Jari Arkko <[email-masked]>; Vishnu Pavan
> > Beeram <[email-masked]>
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!Ugj_X1TkAhoanpKNU7xBQ3HnkOoF3uHpZW4-
> 2d0WPcdGw12Cw8M1k
> > PJeT478yjU$
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!Ugj_X1TkAhoanpKNU7xBQ3HnkOoF3uHpZW4-
> 2d0WPcdGw12Cw8M1k
> > PJeT478yjU$
> >
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!Ugj_X1TkAhoanpKNU7xBQ3HnkOoF3uHpZW4-
> 2d0WPcdGw12Cw8M1k
> > PJeT478yjU$
> >
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!Ugj_X1TkAhoanpKNU7xBQ3HnkOoF3uHpZW4-
> 2d0WPcdGw12Cw8M1kPJeT478yjU$