Re: [Teas] WG adoption poll: draft-dong-teas-nrp-scalability-02

thanks Jie and John for your replies. Please see inline.

------------------------------------------------------------------------
*From:* John E Drake [mailto:jdrake@juniper.net]
*Sent:* Thursday, June 23, 2022, 5:41 AM
*To:* Dongjie (Jimmy); Kiran M; lberger@labn.net; teas@ietf.org
*Cc:* teas-chairs@ietf.org
*Subject:* [Teas] WG adoption poll: draft-dong-teas-nrp-scalability-02

> Hi,
>
> Comment inline.
>
> Yours Irrespectively,
>
> John
>
> Juniper Business Use Only
>
> *From:*Teas <teas-bounces@ietf.org> *On Behalf Of *Dongjie (Jimmy)
> *Sent:* Thursday, June 23, 2022 2:45 AM
> *To:* Kiran M <kiran.ietf@gmail.com>; lberger@labn.net; teas@ietf.org
> *Cc:* teas-chairs@ietf.org
> *Subject:* Re: [Teas] WG adoption poll: draft-dong-teas-nrp-scalability-02
>
> *[External Email. Be cautious of content]*
>
> Hi Kiran,
>
> Many thanks for your review and comments.  We will reply to them in 
> detail later.
>
> The concept and definition of NRP are described in the IETF network 
> slice draft, and the general procedure of network slice realization is 
> also described there.
>
>
[KM] I re-read section 6.1 and 6.2 before making my comment. Thought 
more explicit example on what resource and their partitioning will be 
useful. I liked this document because it does cover more than 
scalability. It also gave examples, what solutions are available if you 
don't need to scale that much (to be honest more realistic and near term 
requirement). So why not make it a comprehensive guidance on NRP? But 
that's up to the authors.

> This document mainly focuses on the scalability analysis and the 
> optimization suggestions of NRP. In my understanding the exceptions 
> and the fail-over of NRP are currently out of the scope of this 
> document. We can discuss which document they would better fit in.
>
> *//*
>
> */[JD] The presumption is that a service provider provisions an NRP 
> with sufficient resources such that it is able to survive resources 
> failures, etc., so I don’t really understand the concept of 
> NRP-failover./*
>
/*[KM] I might have missed where this is covered in the document.  The 
scenario I have in mind is what if  some part of the partition fails and 
does not deliver SLO/SLE. Then I can imagine several approaches are 
possible (e.g. redundancy or backup resource provided by ISP, redundancy 
by design of connectivity constructs etc.). In those cases would it 
still be same NRPID or different? *//*Jie says its out of scope, so 
that's fine too.*/

/*Cheers,*/

/*Kiran
*/

> Best regards,
>
> Jie
>
> *From:*Teas [mailto:teas-bounces@ietf.org 
> <mailto:teas-bounces@ietf.org>] *On Behalf Of *Kiran M
> *Sent:* Thursday, June 23, 2022 7:03 AM
> *To:* lberger@labn.net; teas@ietf.org
> *Cc:* teas-chairs@ietf.org
> *Subject:* Re: [Teas] WG adoption poll: draft-dong-teas-nrp-scalability-02
>
> Hi,
>
> This document is a useful contribution on NRP scaling concerns (both 
> on control and data plane) and mechanisms (with or without scale 
> requirements). I believe that the document should be adopted by the WG.
>
> I hope authors will consider following review comments.
>
> Minor inline comments attached (fwiw). In addition, I felt that there 
> are some assumptions made about the NRPs. e.g. authors seem to have a 
> clear idea about what an NRP description will look like or how NRP 
> life-cycle management will happen - if there is another document 
> please mention it otherwise, document's scope could be broader to 
> cover the basics of a single NRP as well.
>
> Since, we are exposing multiple slices to one NRP, I also felt that at 
> least 2 important aspects are missing from the discussion (1) on 
> exceptions (when NRP does not meet SLO), (2) backup NRPs (on fail-over).
>
> Cheers,
> Kiran
>
> ------------------------------------------------------------------------
>
> *From:*Lou Berger [mailto:lberger@labn.net <mailto:lberger@labn.net>]
>
> *Sent:*Thursday, June 16, 2022, 4:47 AM
>
> *To:*TEAS WG
>
> *Cc:*TEAS WG Chairs
>
> *Subject:*[Teas] WG adoption poll: draft-dong-teas-nrp-scalability-02
>
>     Hello,
>
>     This email begins a 2-week adoption poll for:
>     https://datatracker.ietf.org/doc/draft-dong-teas-nrp-scalability/
>     <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-dong-teas-nrp-scalability/__;!!NEt6yMaO-gk!A47Hj1wscndUQ-rrshe11oOfQ9ewAmjq2-HBRB0Rsno5FlfxnIFKz34DJPI9xH02CHUckZy1-Dgu7ONGEW3dBK_rqriCws0$>
>
>
>     Please note that IPR has been disclosed on this document:
>     https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-dong-teas-nrp-scalability
>     <https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/search/?submit=draft&id=draft-dong-teas-nrp-scalability__;!!NEt6yMaO-gk!A47Hj1wscndUQ-rrshe11oOfQ9ewAmjq2-HBRB0Rsno5FlfxnIFKz34DJPI9xH02CHUckZy1-Dgu7ONGEW3dBK_rYwLNEsc$>
>
>
>     Please voice your support or objections to adoption on the list by
>     the end of the day (any time zone) July 1.
>
>     Thank you,
>     Lou (as Co-chair)
>
>     _______________________________________________
>     Teas mailing list
>     Teas@ietf.org
>     https://www.ietf.org/mailman/listinfo/teas
>     <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!A47Hj1wscndUQ-rrshe11oOfQ9ewAmjq2-HBRB0Rsno5FlfxnIFKz34DJPI9xH02CHUckZy1-Dgu7ONGEW3dBK_rPqY6FJY$>
>
>