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

One more attempt…

The question being asked in this thread is “Should draft-ietf-lsr-isis-sr-vtn-mt proceed to WG Last Call?”.

It has been noted that the relevance – indeed even the need for the draft - depends upon several documents which are in various stages of discussion including:

https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-08
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-for-enhanced-vpn-06
https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-17
https://datatracker.ietf.org/doc/html/draft-ietf-teas-nrp-scalability-03
https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-10

The eventual progression of these documents is not only necessary in order to satisfy the dependencies in this draft, it may also determine whether the draft is even relevant to the defined NRP solutions.

Regardless of whether you approve of the content of draft-ietf-lsr-isis-sr-vtn-mt and/or think the document is “mature”, it is simply premature to proceed to WG last call.


(As an aside, the wisdom of defining multiple solutions to NRP – some of which might only be suitable at “low scale” – needs to be discussed.
The cost – both in development and deployment – of multiple solutions for the same problem space is considerable. This should not be accepted casually.

Jie – you and I clearly don’t agree on how this should be approached – and in particular on the meaning of this discussion in the nrp-scalability draft.
Fair enough. But this is an issue of significance and needs to be openly discussed – though not in the context of this thread.)

   Les



From: Les Ginsberg (ginsberg) <ginsberg=[e-mail]>
Sent: Friday, January 19, 2024 11:37 AM
To: Les Ginsberg (ginsberg) <[e-mail]>; Acee Lindem <[e-mail]>
Cc: Chongfeng Xie <[e-mail]>; TEAS WG <[e-mail]>; lsr <[e-mail]>
Subject: 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


(Update - Avee - I now see the shepherds email that you sent a short while ago. It got stored in a different folder in my mailer due to the addition of other WGs on the TO list. ☹)

But it doesn’t change my response.)



   Les





> -----Original Message-----

> From: Teas <[e-mail]<mailto:[e-mail]>> On Behalf Of Les Ginsberg (ginsberg)

> Sent: Friday, January 19, 2024 11:30 AM

> To: Acee Lindem <[e-mail]<mailto:[e-mail]>>

> Cc: Chongfeng Xie <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>;

> lsr <[e-mail]<mailto:[e-mail]>>

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

>

> 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]<mailto:[e-mail]>>

> > Sent: Friday, January 19, 2024 11:05 AM

> > To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>

> > Cc: Chongfeng Xie <[e-mail]<mailto:[e-mail]>>; Les Ginsberg (ginsberg)

> > <[e-mail]<mailto:[e-mail]>>; jmh <[e-mail]<mailto:[e-mail]>>; TEAS WG

> > <[e-mail]<mailto:[e-mail]>>; lsr <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Chongfeng Xie

> > > Sent: Wednesday, January 10, 2024 7:41 PM

> > > To: Les Ginsberg (ginsberg) <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>; jmh

> > <[e-mail]<mailto:[e-mail]>>; Acee Lindem <[e-mail]<mailto:[e-mail]>>; TEAS WG

> > <[e-mail]<mailto:[e-mail]>>; lsr <[e-mail]<mailto:[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]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Joel Halpern

> > > Sent: Wednesday, January 10, 2024 3:22 PM

> > > To: Acee Lindem <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>

> > > https://www.ietf.org/mailman/listinfo/teas

>

> _______________________________________________

> Teas mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/teas