(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 <teas-boun...@ietf.org> On Behalf Of Les Ginsberg (ginsberg) > Sent: Friday, January 19, 2024 11:30 AM > To: Acee Lindem <acee.i...@gmail.com> > Cc: Chongfeng Xie <chongfeng....@foxmail.com>; TEAS WG <t...@ietf.org>; > lsr <lsr@ietf.org> > 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 <acee.i...@gmail.com<mailto:acee.i...@gmail.com>> > > Sent: Friday, January 19, 2024 11:05 AM > > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> > > Cc: Chongfeng Xie > > <chongfeng....@foxmail.com<mailto:chongfeng....@foxmail.com>>; Les Ginsberg > > (ginsberg) > > <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; jmh > > <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; TEAS WG > > <t...@ietf.org<mailto:t...@ietf.org>>; lsr > > <lsr@ietf.org<mailto: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 > > > > 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) > <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> > > 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 <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf > > > Of Chongfeng Xie > > > Sent: Wednesday, January 10, 2024 7:41 PM > > > To: Les Ginsberg (ginsberg) > > > <ginsberg=40cisco....@dmarc.ietf.org<mailto:ginsberg=40cisco....@dmarc.ietf.org>>; > > > jmh > > <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; Acee Lindem > > <acee.i...@gmail.com<mailto:acee.i...@gmail.com>>; TEAS WG > > <t...@ietf.org<mailto:t...@ietf.org>>; lsr > > <lsr@ietf.org<mailto: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 > > > 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; t...@ietf.org<mailto:t...@ietf.org>; > > > lsr@ietf.org<mailto: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-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf > > > Of Joel Halpern > > > Sent: Wednesday, January 10, 2024 3:22 PM > > > To: Acee Lindem <acee.i...@gmail.com<mailto:acee.i...@gmail.com>>; > > > t...@ietf.org<mailto:t...@ietf.org>; lsr@ietf.org<mailto: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.i...@gmail.com<mailto:acee.i...@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<mailto: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 list > > > t...@ietf.org<mailto:t...@ietf.org> > > > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > t...@ietf.org<mailto:t...@ietf.org> > https://www.ietf.org/mailman/listinfo/teas
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
