"Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes:
Chris - With respect, if you want to move this discussion forward then please make a proposal.
Please see below..
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.
I wanted to make sure that I wasn't misunderstanding you, Having an understanding is the only way to move forward productively. Thanks, Chris.
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. > >
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
