Subject: [Teas] WG Adoption poll - draft-nsdt-teas-ns-framework-05

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 4 Feb 2021 07:43:26 -0600

All,

This is start of a *two* week poll on making
draft-nsdt-teas-ns-framework-05 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 February 18th.

Thank you,
Pavan and Lou

---

From: John E Drake <[email-masked]>
Date: Thu, 4 Feb 2021 13:59:14 +0000

Support

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, February 4, 2021 8:43 AM
To: TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>
Subject: [Teas] WG Adoption poll - draft-nsdt-teas-ns-framework-05

[External Email. Be cautious of content]

All,

Thank you,
Pavan and Lou

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 4 Feb 2021 10:05:34 -0500

Yes, this is a useful document and good enough to serve as a basis for 
WG effort in this space.
We should adopt it.

Yours,
Joel

On 2/4/2021 8:43 AM, Vishnu Pavan Beeram wrote:
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Kiran Makhijani <[email-masked]>
Date: Thu, 4 Feb 2021 16:13:13 +0000

Support this very important work. The recent changes are well aligned with the definitions document. Hope to see more details added in the this document going forward.
-Kiran

From: Teas <[email-masked]> on behalf of Vishnu Pavan Beeram <[email-masked]>
Date: Thursday, February 4, 2021 at 05:43
To: TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>
Subject: [Teas] WG Adoption poll - draft-nsdt-teas-ns-framework-05
All,

Thank you,
Pavan and Lou

---

From: "Luis M. Contreras" <[email-masked]>
Date: Thu, 4 Feb 2021 20:40:59 +0100

Hi all,

Despite the fact that I acknowledge the value of the document, I feel more
discussion is needed before adoption. So I don't support the adoption at
this stage. Essentially,

Some reasons for that are:

.- The document states in sec. 3.2 that the NSC from one operator could
request IETF network slices to the NSC of another operator. This has
several implications in the NSC, and as such, should require more
discussion. For instance: (1) there could be different levels of
trustiness in the relationship among operators tat could imply different
levels of abstractions, not necessarily the same as with another kind of
customer/user, then open the door to the support of different kind of
information to be supported by the NBI; (2) the relationship between
operators could come via higher level systems instead, then relaxing /
modifying considerations such security, monitoring information, etc; (3)
having a direct relationship implies that one of the the SBI
implementations of a NSC should the same as the NBI, to support this
possibility; (4) there should be a common understanding / definition of the
abstractions between operators to express the services; etc

.- The document has a specific section for ACTN (sect. 4). In fact there
was some discussion on the list about this, reflecting the fact that
several interpretations could be provided for a mapping as the intended in
Figure 1, without a single mapping of entities between ACTN and the
intended framework. Besides that, a specific document describing the
applicability of ACTN to slicing
(draft-king-teas-applicability-actn-slicing) is now work-in-progress,
making the ACTN text in the framework document redundant with that other
document. In my view, sect. 4 is more confusing than clarifying, so I
prefer to remove it from the framework document, developing the
applicability of ACTN to slicing in that other dedicated document.

.- Section 3.5 described an initial workflow on the realization of IETF
Network Slices but it focuses only on provision. Other aspects of the IETF
Network SLice lifecycle are missing, and I think it would be important to
describe since this framework will become the basis for further
specifications of functionality of the IETF NSC. For instance, capability
exposure of the NSC (what happens if some SLOs cannot be provided?),
fulfillment, assurance, etc, are not included/discussed.

This is not an exhaustive review, this is just to remark the need of more
discussion for having clear the perimeter of the document before
progressing it into adoption, from my point of view.

Best regards

Luis

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

---

From: Kiran Makhijani <[email-masked]>
Date: Thu, 4 Feb 2021 21:38:59 +0000

Hi Luis,
Good catch on section 3.2. For now we should consider cases for  network slices under one NSC.  However, we should also be clear that NSC will work with networks in different admin/operator domains using SBI. When this is not possible, higher level orchestrator may request different slices from different NSCs and connect them together.
-Kiran

From: Teas <[email-masked]> on behalf of Luis M. Contreras <[email-masked]>
Date: Thursday, February 4, 2021 at 11:41
To: Vishnu Pavan Beeram <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>, TEAS WG <[email-masked]>
Subject: Re: [Teas] WG Adoption poll - draft-nsdt-teas-ns-framework-05
Hi all,

Despite the fact that I acknowledge the value of the document, I feel more discussion is needed before adoption. So I don't support the adoption at this stage. Essentially,

.- The document states in sec. 3.2 that the NSC from one operator could request IETF network slices to the NSC of another operator. This has several implications in the NSC, and as such, should require more discussion. For instance: (1) there could be different levels of trustiness in the relationship among operators tat could imply different levels of abstractions, not necessarily the same as with another kind of customer/user, then open the door to the support of different kind of information to be supported by the NBI; (2) the relationship between operators could come via higher level systems instead, then relaxing / modifying considerations such security, monitoring information, etc; (3) having a direct relationship implies that one of the the SBI implementations of a NSC should the same as the NBI, to support this possibility; (4) there should be a common understanding / definition of the abstractions between operators to express the services; etc

.- The document has a specific section for ACTN (sect. 4). In fact there was some discussion on the list about this, reflecting the fact that several interpretations could be provided for a mapping as the intended in Figure 1, without a single mapping of entities between ACTN and the intended framework. Besides that, a specific document describing the applicability of ACTN to slicing (draft-king-teas-applicability-actn-slicing) is now work-in-progress, making the ACTN text in the framework document redundant with that other document. In my view, sect. 4 is more confusing than clarifying, so I prefer to remove it from the framework document, developing the applicability of ACTN to slicing in that other dedicated document.

.- Section 3.5 described an initial workflow on the realization of IETF Network Slices but it focuses only on provision. Other aspects of the IETF Network SLice lifecycle are missing, and I think it would be important to describe since this framework will become the basis for further specifications of functionality of the IETF NSC. For instance, capability exposure of the NSC (what happens if some SLOs cannot be provided?), fulfillment, assurance, etc, are not included/discussed.

This is not an exhaustive review, this is just to remark the need of more discussion for having clear the perimeter of the document before progressing it into adoption, from my point of view.

Best regards

Luis

El jue, 4 feb 2021 a las 14:43, Vishnu Pavan Beeram (<[email-masked]<mailto:[email-masked]>>) escribió:
All,

Thank you,
Pavan and Lou
_______________________________________________
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=04%7C01%7Ckiranm%40futurewei.com%7C40e820c3ec854e6b9d9108d8c944d814%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637480644849753933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V75quyh0btdcMfGeOI2WEnqvXO3mECoYM%2FQc%2Bc%2Bw9qI%3D&reserved=0>

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 5 Feb 2021 10:28:56 -0000

Hi Pavan, others,

I agree with the three points that Luis makes about this draft, and I think it will need a good deal of future work, but I don’t agree with Luis’s conclusion.

It seems to me that this document is a good enough starting point for the WG. We seem to have agreed that the WG should have a framework that addresses network slicing, and this is definitely advanced enough and consistent with the terminology work such that the WG can start to shape the text once the draft is adopted.

I hope we can speedily adopt the draft and then move on to list and resolve the issues that we have.

Best,

Adrian

Sent: 04 February 2021 13:43

All,

Thank you,
Pavan and Lou

---

From: John E Drake <[email-masked]>
Date: Fri, 5 Feb 2021 15:50:37 +0000

Hi,

I agree with Adrian.  WG adoption means that the draft is providing a starting point and a direction for further work.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Adrian Farrel
Sent: Friday, February 5, 2021 5:29 AM
To: [email-masked] <[email-masked]>; 'TEAS WG' <[email-masked]>
Cc: 'TEAS WG Chairs' <[email-masked]>
Subject: Re: [Teas] WG Adoption poll - draft-nsdt-teas-ns-framework-05

Hi Pavan, others,

I agree with the three points that Luis makes about this draft, and I think it will need a good deal of future work, but I don't agree with Luis's conclusion.

Best,
Adrian

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Vishnu Pavan Beeram
Sent: 04 February 2021 13:43
To: TEAS WG <[email-masked]<mailto:[email-masked]>>
Cc: TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>
Subject: [Teas] WG Adoption poll - draft-nsdt-teas-ns-framework-05

All,

Thank you,
Pavan and Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 5 Feb 2021 16:19:06 +0000

Hi Pavan, all,

Luis spotted some very good points that for sure need to be fixed, and there are many others.
However they don't look enough severe to me to prevent the adoption of the document, which provides the basis for the WG to work on.

Hence I support the adoption.

BR
Daniele

From: Teas <[email-masked]> On Behalf Of John E Drake
Sent: den 5 februari 2021 16:51
To: [email-masked]; [email-masked] <[email-masked]>; 'TEAS WG' <[email-masked]>
Cc: 'TEAS WG Chairs' <[email-masked]>
Subject: Re: [Teas] WG Adoption poll - draft-nsdt-teas-ns-framework-05

Hi,

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Adrian Farrel
Sent: Friday, February 5, 2021 5:29 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; 'TEAS WG' <[email-masked]<mailto:[email-masked]>>
Cc: 'TEAS WG Chairs' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] WG Adoption poll - draft-nsdt-teas-ns-framework-05

Hi Pavan, others,

Best,
Adrian

All,

Thank you,
Pavan and Lou

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 5 Feb 2021 08:23:39 -0800

Hi Pavan, et al.,
the document is well-written. The stated problem is real and important.
More work can be done, as pointed by Luis, but this is only an adoption
poll, not the Last Call. Yes, I support the adoption of the draft by the
TEAS WG.

Regards,
Greg

---

From: Shunsuke Homma <[email-masked]>
Date: Tue, 9 Feb 2021 01:30:27 +0900

Hi WG,

This is an important document and I support the adoption. As Luis pointed,
more work and improvement would be needed, and it can be done after the
adoption. At this time we'll need discussion with WG, not only within
NS-DT.

Regards,

Shunsuke

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 8 Feb 2021 22:29:26 -0500

This important document is well written and does a good job explaining the
framework of NS.  More work can be done to refine after WG adoption.

I support WG adoption.

Thanks

Gyan

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 8 Feb 2021 19:59:17 -0800

I support the adoption, Luis brought a number of important points that need to be addressed, however I don’t think this should stop the adoption.

Cheers,
Jeff

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 9 Feb 2021 22:35:12 -0500

I do feel as Jeff stated the draft is ready as-is for adoption, however the
issues Luis brought up for operators is an important issue related to inter
operator trust relationships related to slicing.  I don’t think that is a
significant issue as slicing in general is with RAN xHaul to core within
the providers network as once a soft handoff happens with wireless provider
being a internet service provider the slice framework can continue through
the service provider network.  The end to end slice framework is more
complicated and that is what Luis is alluding to which inter provider trust
and ns slice end to end.

In that regards even the basic concept of end to end QOS interoperability
does not exist between internet providers and that has been a inherent
pitfall for multicast over the internet using UDP which requires end to end
QOS.  So those same issues that exist with trust and coordination of QOS
policies that have existed Day 1 QOS  will definitely have that same trust
complexity for end to end network slicing over the internet.

>From an operators perspective what is in scope for network slicing is 3GPP
UI RAN xHaul to core within the operators network and once the packet
leaves the operators network goes from Verizon to Century link the slice
policy terminate at the tier 1 peering point.  I think the inter operator
network slicing is out of scope as that is more like a huge elephant in the
room to tackle and maybe better suited for GROW.

Kind Regards

Gyan

On Mon, Feb 8, 2021 at 11:00 PM Jeff Tantsura <[email-masked]>
wrote:

> I support the adoption, Luis brought a number of important points that
> need to be addressed, however I don’t think this should stop the adoption.
>
> Cheers,
> Jeff
-- 

*Gyan Mishra*

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 10 Feb 2021 16:11:27 +0000

Yes, I also support this.
Having said that, a few points raised by Luis needs to be addressed in the future.

Reza

Date: Thursday, February 4, 2021 at 8:43 AM

All,

Thank you,
Pavan and Lou

---

From: Eric Gray <[email-masked]>
Date: Wed, 10 Feb 2021 13:01:31 -0500

Support as co-author...

> On Feb 4, 2021, at 8:43 AM, Vishnu Pavan Beeram <[email-masked]> wrote:
> 
> All,
>

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 18 Feb 2021 17:52:51 +0530

Hi WG,

I support adoption.
I also like the figure indicating the mapping to ACTN :)
What to do with it can be discussed as part of the normal WG process...

Thanks!
Dhruv (contributor to this I-D)

---

From: "Boris Khasanov" <[email-masked]>
Date: Thu, 18 Feb 2021 17:08:07 +0300

Hi Pavan and all,

I read this draft and support the adoption.

Luis comments (i.e. about ACTN, capability exposure),  I think, can be discussed by WG to find a resolution in the next versions.

SY,

Boris

Sent: Thursday, February 4, 2021 4:43 PM

All,

Thank you,
Pavan and Lou

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 18 Feb 2021 15:01:12 +0000

Hi Pavan, all,

I agree with Luis’s comments on this document, while this document is in the right direction, those comments and others could be resolved after it is adopted.

Thus I support the adoption.

Best regards,
Jie

From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, February 4, 2021 9:43 PM
To: TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>
Subject: [Teas] WG Adoption poll - draft-nsdt-teas-ns-framework-05

All,

Thank you,
Pavan and Lou

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 19 Feb 2021 06:36:11 -0600

All,
    The WG poll is closed.

Authors,
    Please republish draft-nsdt-teas-ns-framework-05 as
draft-ietf-teas-ns-framework-00 with only the date and file name changed.

Please continue to discuss the open items (points raised by Luis) on the
list and bring them to closure.

As stated earlier, our (the chairs') intent is for the definitions document
to be eventually rolled into the framework document. This merging can be
initiated/revisited after we reach consensus on the open items in the
definitions document.

Much Thanks to the authors, the design team and everyone else involved in
getting this document to this stage.

Regards,
-Pavan and Lou

---

From: Eric Gray <[email-masked]>
Date: Thu, 25 Feb 2021 14:59:47 -0500

Pavan,

Thanks.

The ID submission tool is currently closed until 8 March.  i will post a new version (new name and date only) as soon as the tool becomes available again.

In the meantime, a version created today is available via GitHub.  That version will have to be re-spun not earlier than 6 March as the submission tool balks if the date in the document is 3 days or more old at the time of submission.

That is only a few days from now, and obviously nothing relevant to ongoing discussions will have changed in the draft when it is posted.

—
Eric

> On Feb 19, 2021, at 7:36 AM, Vishnu Pavan Beeram <[email-masked]> wrote:
> 
> All,
>     The WG poll is closed.
> 
> Authors,
>     Please republish draft-nsdt-teas-ns-framework-05 as draft-ietf-teas-ns-framework-00 with only the date and file name changed.
> 
> Please continue to discuss the open items (points raised by Luis) on the list and bring them to closure.
> 
> As stated earlier, our (the chairs') intent is for the definitions document to be eventually rolled into the framework document. This merging can be initiated/revisited after we reach consensus on the open items in the definitions document.
> 
> Much Thanks to the authors, the design team and everyone else involved in getting this document to this stage.
> 
> Regards,
> -Pavan and Lou
> 
> 
> On Thu, Feb 4, 2021 at 7:43 AM Vishnu Pavan Beeram <[email-masked] <mailto:[email-masked]>> wrote:
> All,
>