Les, all Please see inline
> From: Lsr <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg (ginsberg) > Sent: Friday, October 7, 2022 1:35 AM A bit late in the game. At least I've read all subsequent emails. > To: Christian Hopps <cho...@chopps.org> > Cc: 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 > > 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. - That protocol does not disallow the sending of multi-part (sub)-TLVs is one (good) thing. - The encoding of MP-TLVs is another thing. (encoding detail IMHO, although I understand and agree that this is not one for existing implementations) - Another aspect is the behavior expected on the receiving side. If that behavior is not specified, that's out of spec/standard in the general case, especially as in this case different spec specified different behaviors. The following example (for sub-TLVs) show that there is at least two behaviors: "undefined", "merge" "Where a receiving system has two copies of a capabilities TLV from the same system that have different settings for a given attribute, the procedure used to choose which copy shall be used is undefined." https://datatracker.ietf.org/doc/html/rfc4971#section-3 "undefined" is different from "merge". (Also note the terms "to choose which copy shall be used" could even be seen as excluding the possibility for a merge, at least in the mind of the authors) Then FlexAlgo defined "merge" for its FAD with the spec for it "In such cases, the FAD MAY be split into multiple such sub-TLVs and the content of the multiple FAD sub-TLVs combined to provide a complete FAD for the Flex-Algorithm. In such a case, the fixed portion of the FAD (see Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex- Algorithm from a given IS." And also raised the question for sub-sub-TLVs, explicitly allowing for any behavior " Any specification that introduces a new IS-IS FAD sub-sub-TLV MUST specify whether the FAD sub-TLV may appear multiple times in the set of FAD sub-TLVs for a given Flex-Algorithm from a given IS and how to handle them if multiple are allowed." https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-25#section-6 Bottom lines: - if the spec does not define the MP-TLV behavior on the receiving side by the spec, then -unless this is obvious and everyone agrees- this is out of spec. Let's not blame the receiver. - I think we should distinguish the different aspects: allowed on the sending side, the encoding, the behavior on the receiving side, the need to signal the MP capability or not, the reaction to this signal (which can simply be an alarm message in log, with no IS-IS actions). I suspect that different persons have different sensibilities on each of those points and a sensibility with one does not equal to a sensibility with all. (let's not make any disagreement bigger than it is) Thanks, --Bruno > 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 Orange Restricted _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
