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

(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]> On Behalf Of Les Ginsberg (ginsberg)

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

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

>

> 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