Chris - Not trying to convince you of anything - just want to step back and summarize where we are.
MP-TLV support has been explicitly allowed in multiple cases - and in these cases no additional signaling has been specified i.e., all TLVs in the "set" are encoded the same way they would be if the there were only 1 TLV in the set and there is no signaling of MP-TLV support required in order to send MP-TLVs. Due to new features/increased scale, we now have a need to send MP-TLVs for some additional TLVs (notably Prefix Reachability and Neighbor TLVs). The RFCs defining these TLVs did not explicitly specify the use of MP-TLVs - but they also did not specify any prohibition against doing so. Some implementations have chosen to apply the same MP-TLV model used for the "explicit-MP-TLV allowed" cases to these new cases. Two possible protocol changes for these new cases have been suggested in this thread: 1)Require some additional encoding in the MP-TLVs to identify the TLV as a member of an MP-TLV set This would mean that the encoding of MP-TLVs would be different depending on the TLV type. I see no justification for this. 2)Prohibit the sending of MP-TLVs unless all nodes advertise support Even though the encoding used by these early implementations is correct, they would then be penalized and declared illegal because they did not come to the WG and "ask for permission". I find this approach at best very petty. I share the concern about how a network might behave when not all nodes support MP-TLVs for a given TLV, but this is best handled by having an implementation knob to disable the sending of MP-TLVs - thus giving the operator control. Les > -----Original Message----- > From: Christian Hopps <cho...@chopps.org> > Sent: Thursday, October 6, 2022 4:59 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Christian Hopps <cho...@chopps.org>; Peter Psenak (ppsenak) > <ppse...@cisco.com>; Tony Li <tony...@tony.li>; 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 > > > Sending multi-part TLVs where the TLV type was not defined or talked about > in the standard as supporting MP TLV behavior is not "according to existing > standards". The fact that conforming implementations can be confused by > this new behavior should be proof enough of that. But, then we have the > fact that we *were* explicit about defining MP TLV behavior for other TLV > types in other standards.. We'll have to agree to disagree here I think. > > An SE is a sales-engineer they are the engineers a vendor sends to the > customer to, among other things, help sell and integrate the product the > customer is buying with the customers network. They would be privy to, for > example, internal implementation details of the product and thus be able to > assure the customer things would "just work", regardless of what a standard > says. > > Thanks, > Chris. > > "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes: > > > Chris - > > > > Not sure what SE means but...one more significant point. > > > > Multiple implementations have successfully deployed MP-TLV without any > protocol > > extensions. We did not require a new sub-TLV, a new flag, a sequence > number...we > > simply send additional information encoded according to existing > standards. This > > isn't "luck" - it is following existing standards. > > > > For implementations which do not process MP-TLVs correctly - why does > this happen? > > On the receive side, they do not have the intelligence in their > implementation to do a merge. > > On the transmit side they do not have the intelligence to generate multiple > TLVs. > > > > You can propose protocol extensions (such as you have done) - but it will > not > > change the need for implementations to enhance their receive/generation > logic - > > and it will not make it any easier for implementations to do so. What it > > will > do > > is to introduce(sic) an interoperability problem because you will be > requiring > > implementations to understand some new advertisement in order to > send/receive > > MP-TLVs successfully. This is what Peter's point is about i.e., we MUST NOT > > break existing working MP-TLV implementations by requiring protocol > extensions > > in order to send MP-TLVs. > > > > As regards deployment controls, I have no problem with recommending > that implementations provide ways to control the enablement of the > sending of MP-TLVs. > > > > Les > > > >> -----Original Message----- > >> From: Christian Hopps <cho...@chopps.org> > >> Sent: Thursday, October 6, 2022 3:28 PM > >> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > >> Cc: Christian Hopps <cho...@chopps.org>; Peter Psenak (ppsenak) > >> <ppse...@cisco.com>; Tony Li <tony...@tony.li>; 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 > >> > >> > >> It sounds like you're talking about networks defined to work by SE not by > >> standards. I don't want to argue about this, so perhaps we can agree to > >> disagree. > >> > >> Thanks, > >> Chris. > >> [as wg-member] > >> > >> > >> "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes: > >> > >> > 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
