Chris - With respect, if you want to move this discussion forward then please make a proposal. If you read the thread (which is by now quite long) you will see that whenever a proposal is made I do offer my thoughts about it - and that includes proposals to use a capability advertisement.
If you are telling me that I do not need to restate that no encoding changes are required - point taken. Les > -----Original Message----- > From: Christian Hopps <cho...@chopps.org> > Sent: Tuesday, October 25, 2022 2:29 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: bruno.decra...@orange.com; 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 > > [as wg-member] > > Hi Les, > > I want to highlight a particular thing your saying below b/c I'm worried I > don't > understand it. > > > That does not mean, however, that we need to alter the encoding of > > existing TLVs to support MP. > > I could be mistaken here, but I don't think altering the TLVs is a solution > that > is on the table, or that anyone is supporting that idea. Is there a particular > proposal you're worried about? > > AFAICT what *has* been discussed is using a capability bit to somehow > manage the unfortunate situation created by vendor[s] shipping software > that does things which are incompatible with the deployed software that > follows published standards. > > Thanks, > Chris. > > "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes: > > > Bruno - > > > > > > > > I think people have posted to this thread with different intentions. > > > > > > > > Everyone agrees (I think...) that when MP-TLVs are sent for a given > > TLV and not all routers in the network support MP for that TLV that > > bad things will happen. > > > > My posts have been to emphasize that the method of encoding MP-TLVs > > requires no protocol extensions. This in no way conflicts with the > > previous sentence. > > > > > > > > Please see inline. > > > > > > > >> -----Original Message----- > > > >> From: bruno.decra...@orange.com <bruno.decra...@orange.com> > > > >> Sent: Monday, October 24, 2022 6:22 AM > > > >> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; 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 > > > >> > > > >> 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) > > > >> > > > > [LES:] You have misinterpreted this excerpt from RFC 4971 (now RFC > > 7981). > > > > > > > > Where a receiving system has two copies of an IS-IS Router CAPABILITY > > > > TLV from the same system that have conflicting information for a > > > > given sub-TLV, the procedure used to choose which copy shall be > > used > > > > is undefined. > > > > > > > > The text is talking about what an implementation should do when the > > same sub-TLV is received with two different values. > > > > It is not talking about what should be done when MP is received for a > > given TLV. > > > > > > > > > > > >> 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." > > > > > > > > [LES:] I certainly agree that it is “better” if a specification is > > explicit about whether MP is supported for a given TLV or not. > > > > That does not mean, however, that we need to alter the encoding of > > existing TLVs to support MP. > > > > > > > >> > > > >> 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. > > > > > > > > [LES:] Not sure where “blame” comes into it. > > > > Again, my point is simply that existing encoding is sufficient. > > > > What is needed is for implementations to be enhanced. > > > > I do support more explicit specification – something we should pay > > closer attention to as we write new documents. > > > > > > > > I really do not see that you and I are disagreeing about anything. > > > > > > > > Les > > > > > > > >> - 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
