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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Acee -

I am not sure what your full intent is. 
There are a number of statements in the NRP scaling document regarding the use of routing protocols - you selected only one to comment on - not sure why.

The gist of the multiple comments serves to discourage the use of routing protocols as a means of supporting NRP. I support this because I think this is an inappropriate use of routing protocols.
Sure, at small scale modest impact might be the result - but I don’t see the point in developing protocol extensions (note that the use of existing MT technology is not the end of the protocol requirements - just the beginning) that only work or are acceptable at small scale.

You may disagree - but if so I would appreciate a discussion of the larger questions - not just the one sentence.

No - I have not seen your shepherd writeup - it does not seem to be visible on the document status page.

   Les


> -----Original Message-----
> From: Acee Lindem <[e-mail]>
> Sent: Friday, January 19, 2024 11:05 AM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: Chongfeng Xie <[e-mail]>; Les Ginsberg (ginsberg)
> <[e-mail]>; jmh <[e-mail]>; TEAS WG
> <[e-mail]>; lsr <[e-mail]>
> 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
> 
> Speaking as WG member:
> 
> Hi Les,
> 
> You probably saw my shepherd review of this document.
> 
> > On Jan 11, 2024, at 2:33 AM, Les Ginsberg (ginsberg) <[e-mail]>
> wrote:
> >
> > Chongfeng –
> >  We are at the stage of last call.
> > The document has been presented and discussed previously – it is time for
> WG members to render their opinions.
> >  For folks who have actively followed/participated in the discussion, it is very
> unlikely that we will alter opinions by further discussion. Which means if you
> and I have different points of view it is very unlikely that I will alter your
> opinion and very unlikely that you will alter mine.
> > In that context, I typically do not reply when someone posts their opinion
> and it is different than mine. The point of last call is to get the opinions of WG
> members.
> >  In this case, however, I will respond with some clarifications – not in the
> hopes of changing your mind – but only to provide additional clarity as to why
> I have the opinion that I do.
> >  The use of MT in support of NRP – at whatever scale – clearly requires
> additional SPF calculations – which is something which is expressly identified
> as undesirable in draft-ietf-teas-nrp-scalability.
> > draft-ietf-teas-nrp-scalability also states (as you have pointed out) that
> “control plane extensions” are seen as undesirable.
> 
> I think this needs to removed or at least softened in the NRP scaling
> document. The drawbacks of SPF calculations are greatly exaggerated
> (especially if implemented efficiently on today’s CPUs). Furthermore, it would
> be hypocritical to say that SPF calculations are to avoided and to then
> standardize features such as TI-LFA.
> 
> Thanks,
> Acee
> 
> 
> 
> 
> >  Having implemented the use of MT for purposes other than supporting the
> reserved AFI/SAFI specific topologies specified in RFC 5120, I can tell you that
> there is a significant amount of “control plane work” associated with adding
> such support. The fact that no new protocol extensions are required is not the
> same as saying no new control plane work is required. I can assure you that
> there would be a significant amount of control plane work required.
> >  So I do see that draft-ietf-lsr-isis-sr-vtn-mt is at odds with draft-ietf-teas-
> nrp-scalability.
> >  Thanx for listening.
> >      Les
> >   From: Lsr <[e-mail]> On Behalf Of Chongfeng Xie
> > Sent: Wednesday, January 10, 2024 7:41 PM
> > To: Les Ginsberg (ginsberg) <ginsberg=[e-mail]>; jmh
> <[e-mail]>; Acee Lindem <[e-mail]>; TEAS WG
> <[e-mail]>; lsr <[e-mail]>
> > 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
> >   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; [e-mail]; [e-mail]
> > 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 <[e-mail]> On Behalf Of Joel Halpern
> > Sent: Wednesday, January 10, 2024 3:22 PM
> > To: Acee Lindem <[e-mail]>; [e-mail]; [e-mail]
> > 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 <[e-mail]>
> > 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 <[e-mail]>
> >  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 list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/teas