Dear LSR WG, > MP-TLVs (explicit or implicit) are not an extension of the protocol - they are completely consistent > with the base operation of the protocol. I have always viewed lack of support for MP-TLVs as an > implementation limitation - not a gap in the protocol.
I don't agree with this assertion. For many of us resending PDU with the same key is an implicit update. Is there any text in the base ISIS spec which would suggest otherwise ? > you're talking about networks defined to work by SE not by standards It seems like it. The problem with this is that it works well in static single vendor networks where one can always blame operators for "provisioning mistakes''. We can do much better than that. I am with Tony, Chris, Bruno here. It is cool that the IETF consensus does not have a "liberum veto" (unanimity <https://en.wikipedia.org/wiki/Unanimity> voting rule). Thx, Robert. PS. And we all know how splitting the drafts will end up .. so no thank you Peter & Les for this suggestion. On Fri, Oct 7, 2022 at 12:20 AM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Chris - > > > -----Original Message----- > > From: Christian Hopps <cho...@chopps.org> > > Sent: Thursday, October 6, 2022 1:36 PM > > To: Peter Psenak (ppsenak) <ppse...@cisco.com> > > Cc: Christian Hopps <cho...@chopps.org>; Tony Li <tony...@tony.li>; Les > > Ginsberg (ginsberg) <ginsb...@cisco.com>; Robert Raszuk > > <rob...@raszuk.net>; Henk Smit <henk.i...@xs4all.nl>; lsr@ietf.org > > Subject: Re: [Lsr] New Version Notification for > draft-pkaneria-lsr-multi-tlv- > > 01.txt > > > > > > Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> writes: > > > > > Chris, > > > > > > On 06/10/2022 18:34, Christian Hopps wrote: > > >> Peter Psenak <ppse...@cisco.com> writes: > > >> > > >>> Tony, Les, > > >>> > > >>> I believe we can all agree that we do not want to change the > behavior of > > >>> existing implementations that support MP-TLVs based on the > > advertisements of the > > >>> MP-capability from other routers - it would break existing networks. > > Even the > > >>> text in the MP-TLV draft does not suggest that to be the case. > > >> Are people not looking at the spreadsheet Tony put together? > > >> Which implicit multi-part TLVs are these "existing implementations" > > >> advertising that keep getting referred to? Please let's work with > real data > > -- > > >> the spreadsheet shows a grand total of *0* TLVs that could fall in > this > > >> category. > > > > > > then the spreadsheet is incorrect. > > > > > > I know of implementation that can send and receive Multi part TLVs for > > IPv4/IPv6 > > > (MT) IP Reach, (MT) Extended IS reachability and IS-IS Router > CAPABILITY > > TLV to > > > start with. > > > > Do you know all of the implementations, and all of those that don't? If > we > > could publish that list then we presumably could explore more simple > > solutions. :) > > > > People keep talking about breaking deployed networks, but that assumes > > there are functional networks with implicit MP-TLVs in them. I am not > sure I > > accept the assertion that these networks are truly functional. > > > > AFAICT these networks are *lucky* to be working. There's no document to > > point at, there's no bit to look at, there's literally nothing to help > an operator > > or their routers know if all the routers correctly receive and process > these > > implicit MP-TLVs. These networks are one network change (even as small as > > an interface up or down event) away from failing, or may even be failing > > already but not yet in a noticeable way. This is the case regardless of > what > > type of bit or functionality this document provides. > > [LES:] I don't agree at all with your characterization. > > MP-TLVs (explicit or implicit) are not an extension of the protocol - they > are completely consistent with the base operation of the protocol. I have > always viewed lack of support for MP-TLVs as an implementation limitation - > not a gap in the protocol. > Until relatively recently, there was no need to send MP-TLVs for > neighbors/prefixes and since it is far from trivial to implement MP-TLV > support it is understandable why most(all?) implementations did not include > such support initially. > But this does not mean that the protocol itself lacks the support. > > Would it have been better if all RFCs were explicit about the possibility > of MP-TLVs? Sure - but hindsight is always easier than foresight. > And even in those cases where MP-TLV support was explicitly defined, this > did not guarantee that all implementations had that support. Vendors make > decisions based on business as to how they spend their development budget > and I think we are both familiar with decisions to defer support for some > aspects of the protocol until a stronger business case arises. > > Regarding existing networks, MP-TLVs are an aspect of scale and feature > support. If your deployment includes many flex-algos or a large number of > TE attributes or other features which add to the information needing to be > advertised, then MP-TLVs are required. > Implementations which do not support MP-TLVs cannot be deployed in such > environments - and it isn’t because of interoperability issues - it is > because they do not support the scale/features required. > > As my employer has implementations which do support MP-TLVs, I can say > that we do not depend upon luck - but we do depend upon careful planning. > We work with our customers to ensure that the design of the network - > including the capabilities of the routers deployed - is considered. > > > Les > > > > > So while looking for a solution here, I think less weight should be > placed on > > these "lucky networks". I'm not saying we should intentionally break > them, > > but they should also not count as "fully-functional" either. > > > > Thanks, > > Chris. > > [as wg-member] > > > > > > > > > > thanks, > > > Peter > > >> Thanks, > > >> Chris. > > >> > > >>> I find the discussion about advertising supported capabilities for > > management > > >>> purposes in IGPs interesting, but not specific, nor directly related > to the > > >>> MP-TLV draft. Keeping the two separate would make a lot of sense. > > >>> > > >>> > > >>> my 2c, > > >>> Peter > > >>> > > >>> > > >>> > > >>> On 05/10/2022 22:18, Tony Li wrote: > > >>>> Les, > > >>>> > > >>>>> On Oct 5, 2022, at 1:14 PM, Les Ginsberg (ginsberg) > > >>>>> <ginsberg=40cisco....@dmarc.ietf.org > > >>>>> <mailto:ginsberg=40cisco....@dmarc.ietf.org>> wrote: > > >>>>> > > >>>>> */[LES:] It is clear that we have different opinions on this – and > there > > are > > >>>>> multiple folks on both sides of this discussion./* > > >>>>> */What I would hope we can agree on is to separate the discussion > of > > adding > > >>>>> advertisement of “feature supported” from the MP-TLV draft by > > writing a > > >>>>> separate draft on this proposal./* > > >>>>> */This would allow the two pieces of work to progress independently > > – as they > > >>>>> should./* > > >>>>> *//* > > >>>>> */This makes sense to me since the proposal to advertise feature > > support is > > >>>>> clearly not limited to MP-TLV and has no bearing on how MP-TLVs are > > >>>>> encoded./* > > >>>>> *//* > > >>>>> */Can we agree on this?/* > > >>>> Sorry, I’m not on board with this. The two functions would end up > > >>>> disconnected, all the way to the field. > > >>>> T > > >>>> > > >> > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
