Re: [Teas] [Lsr] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

Hi Hent,

Thank you for your comments.  I would like to provide feedback based on the scenario and type of this document.

The approach in this document is aimed at network scenarios where the required number of NRPs is not too high. As an operator,  we believe such scenario would be typical for many deployment of NRP, so we propose it. It utilizes existing technology and information without the need for extensions to control protocols, which is its advantage, isn't it?  In this scenario, the approach has no issue of not-scaling, nor is half-baked. As an operator, we think this approach is practical and effective.  Based on this consideration, the type of this document is informative. 

You mentioned that TEAS may come up with some new solutions for larger scale NRPs, but this attempt requires new protocol extensions and some time in terms of standards and deployment. Come back to the scenario above, the solution proposed in my draft already meet the practical requirements, so we should document this solution for those who need it. 

I hope my explanation can clarify your concerns.

Thank you!

Best regards
Chongfeng

From: Henk Smit
Date: 2024-01-12 20:31
To: Chongfeng Xie; Les Ginsberg (ginsberg); jmh; Acee Lindem; TEAS WG; lsr
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
From the draft: 
=== 
> The mechanism described in this document is considered useful for network scenarios in which 
> the required number of NRP is small, as no control protocol extension is required. For network 
> scenarios where the number of required NRP is large, more scalable solution would be needed, 
> which may require further protocol extensions and enhancements. 

So the proposed draft is about a solution that doesn't scale (well). 
And then later, we might get another solution that does scale (better). 
Then we'll end up with two solutions for one problem. One bad solution, and one (hopefully) better solution. 

If that is the case, then I suggest we wait a bit, and see what else the TEAS workgroup comes up with. 
I rather have one good solution than two half-baked. Or even one good and one half-baked. Less is more. 

henk. 

On 01/11/2024 4:40 AM CET Chongfeng Xie <chongfeng.xie@foxmail.com> wrote: 

Hi Les, 

Thanks for your comments. 

This is an informational document which describes the applicability of existing IS-IS MT mechanisms for building SR based NRPs. All the normative references are either RFCs or stable WG documents. It is true that some informative references are individual documents, while they just provide additional information related to this topic, thus would not impact the stability and maturity of the proposed mechanism. 

The text you quoted from draft-ietf-teas-nrp-scalability are about the considerations when the number of NRP increases, how to minimize the impact to the routing protocols (e.g. IGP). While as described in the scalability considerations section of this document, the benefit and limitation of using this mechanism for NRP are analyzed, and it also sets the target scenarios of this mechanism: 

     “The mechanism described in this document is considered useful for network scenarios in which the required number of NRP is small” 

Thus it is clear that this solution is not recommended for network scenarios where the number of required NRP is large. 

Please note section 3 of draft-ietf-teas-nrp-scalability also mentioned that: 

      “The result of this is that different operators can choose to deploy things at different scales.” 

And 

      “In particular, we should be open to the use of approaches that do not require control plane extensions and that can be applied to deployments with limited scope.” 

 According to the above text, we believe the mechanism described in this document complies to the design principles discussed in draft-ietf-teas-nrp-scalability and provides a valid solution for building NRPs in a limited scope. 

 Hope this solves your concerns about the maturity and scalability of this mechanism. 

 Best regards, 

Chongfeng 

From: Les Ginsberg \(ginsberg\) 
Date: 2024-01-11 08:21 
To: Joel Halpern; Acee Lindem; teas@ietf.org; lsr@ietf.org 
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 
(NOTE: I am replying to Joel’s post rather than the original last call email because I share some of Joel’s concerns – though my opinion on the merits of the draft is very different.
Also, I want to be sure the TEAS WG gets to see this email.)

I oppose Last Call for draft-ietf-lsr-isis-sr-vtn-mt.

It is certainly true, as Joel points out, that this draft references many drafts which are not yet RFCs – and in some cases are not even WG documents. Therefore, it is definitely premature to last call this draft.

I also want to point out that the direction TEAS WG has moved to recommends that routing protocols NOT be used as a means of supporting NRP.

https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl states:

“…it is desirable for NRPs to have no more than small impact (zero being preferred) on the IGP information that is propagated today, and to not required additional SPF computations beyond those that are already required.”

https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-03.html#name-scalabliity-design-principl states:

“The routing protocols (IGP or BGP) do not need to be involved in any of these points, and it is important to isolate them from these aspects in order that there is no impact on scaling or stability.”

Another draft which is referenced is https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/ - which is not a WG document and – based on the recommendations in draft-ietf-teas-nrp-scalability – I would argue that the IGPs should NOT be extended as proposed in this draft. So if a WG adoption call were to initiated for draft-dong-lsr-sr-enhanced-vpn, I would oppose it.

This then puts draft-ietf-lsr-isis-sr-vtn-mt in the position of publishing information about a solution which the IETF is discouraging. I do not know why the IETF would want to do this.

If, despite all of the above, at some point it is judged not premature to publish this draft, I think the draft should at least include statements indicating that this approach is not a recommended deployment solution.

   Les

From: Lsr <lsr-bounces@ietf.org> On Behalf Of Joel Halpern
Sent: Wednesday, January 10, 2024 3:22 PM
To: Acee Lindem <acee.ietf@gmail.com>; teas@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

Given that the documents that provide the basic definitions needed for this are still active Internet Drafts, it seems premature to last call this document.
As a lesser matter, it seems odd that draft-ietf-teas-ietf-network-slices, which defines the terms needed to understand this draft, is an Informative reference.
Yours,
Joel
PS: I considered not writing this email, as it seems quite reasonable to use MT to support what I expect NRPs to be.  So in principle I think the document is a good idea.
On 1/10/2024 6:12 PM, Acee Lindem wrote:
Note that we are last calling this informational document relating to IS-IS deployment of NRPs using multi-topology. If you have comments, please send them to the LSR list. 

Thanks,
Acee

Begin forwarded message:

From: Acee Lindem <acee.ietf@gmail.com>
Subject: Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
Date: January 8, 2024 at 5:50:21 PM EST
To: Lsr <lsr@ietf.org>

This begins a two week LSR Working Group last call for the “Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)”. Please express your support or objection prior to Tuesday, January 23rd, 2024. 

Thanks,
Acee

_______________________________________________Teas mailing listTeas@ietf.orghttps://www.ietf.org/mailman/listinfo/teas
_______________________________________________ 
Lsr mailing list 
Lsr@ietf.org 
https://www.ietf.org/mailman/listinfo/lsr 