Chris - There are two different topics under discussion - one has to do with TLV encoding - the other has to do with partial deployment issues. We need to be careful that we keep the two distinct.
TLVs necessarily have to unambiguously define the object followed by attributes of that object. If multiple TLVs are required to advertise all the attributes of an object, the encoding requirements are the same: unambiguously define the object in each TLV and then include attributes. IS-IS advertisements have never had any "ordering' requirements i.e., attributes can be advertised in any order within a given TLV and it makes no difference whether a TLV is advertised in LSP#2 or LSP#200. This means that when MP is used, there is no notion as to whether a TLV is the first in a set or the last in a set - they are simply complementary. When I say that implementations which have added support for MP-TLVs for neighbor/prefix advertisement have done the "right thing" I am simply saying they are using base protocol encoding rules as discussed above. There is another discussion that has to do with partial deployment issues and legitimate concerns about how a network might behave when not all routers support MP for a given TLV. But altering TLV encoding to address that issue does not solve a problem - it simply creates a new one. Further, introducing a new rule that prohibits advertisement of existing TLVs unless some yet to be defined feature support advertisement is present network-wide also does not solve a problem - it introduces a new one. Whether advertising features supported is useful and how it should be done is a discussion that should continue - but it MUST NOT alter the format of TLVs or the rules as to when TLVs can be advertised. Les > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Christian Hopps > Sent: Friday, October 7, 2022 4:17 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Tony Li <tony...@tony.li>; Christian Hopps <cho...@chopps.org>; Peter > Psenak (ppsenak) <ppse...@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 > > > "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes: > > > Tony - > > > > > >> > >> Your summarization is incorrect. > >> > >> The proposal is to advertise a advisory message that indicates that a node > is > >> ready to receive MP-TLVs. It prohibits nothing. > > > > [LES:] That is what you are proposing - but others in the thread have > proposed other ideas. For example, in an earlier post Chris stated: > > > >>> Once we have this info I think a stronger case might be made for actually > >>> having the router capability be used *operationally* (i.e., if you don't > see the > >>> capability advertised then that router in fact doesn't send multi-tlv tlvs > and > >>> they should be seen as replacements of each other), > > > > What I am trying to highlight is that the existing implementations of MP- > TLVs > > for the "implicit" cases should not be penalized for sending MP-TLVs that > are > > encoded consistent with how MP-TLVs for the "explicit" cases have been > done. > > They are actually doing the right thing. > > And I disagree with the word "right" here. They are doing the advantageous > thing as long as one has the correct routers and software that allows you to > advertise more than fits in a single TLV. It certainly won't be the "right" > thing > if a standards conforming implementation out there doesn't expect or deal > with one of these multi-part "implicit MP-TLV" advertisements. > > Are you saying implementations that only handle a single-part TLV are non- > conforming? To turn your question around, why should they be penalized? > > Thanks, > Chris. > > > > > If we are in agreement on that - great! > > > > Les > > > >> > >> Tony > >> _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
