Chris -
I am a bit concerned that this is degenerating into a non-constructive argument. We can disagee but hopefully each post helps move the discussion along in some way. Please see inline. > -----Original Message----- > From: Christian Hopps <cho...@chopps.org> > Sent: Saturday, October 8, 2022 2:48 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Christian Hopps <cho...@chopps.org>; Tony Li <tony...@tony.li>; 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 > > > I simply turned your question around and asked: should conforming > implementations be penalized? [LES:] Are you claiming that the absence of an explicit statement regarding support of MP for a given TLV is equivalent to a prohibition against sending them (which fails basic logic)? If not, I do not understand what it is that you think implementations which are NOT supporting MP for a given TLV are conforming to. > > I can't imagine why you are explaining IS-IS TLVs to me, and I have never > advocated for nor even mentioned changing the encoding of TLVs so I don't > know what you're talking about with the rest of it. I found this very > distracting. > [LES:] A couple of quotes from previous emails you have sent: <snip> ... 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)... <end snip> This proposes making it illegal to send MP-TLVs unless a capability is advertised network-wide. <snip> If things would have been done correctly (i.e., documented) we also would have had the option to add a sub-tlv to the TLVs in question that indicated they were part of a set rather than replacements. <end snip> This proposes adding a sub-TLV into existing TLVs to indicate they are part of a set of MP-TLVs. ?? Les > Chris. > [as wg-member] > > "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> > writes: > > > 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<mailto:lsr-boun...@ietf.org>> On Behalf Of > >> Christian Hopps > >> Sent: Friday, October 7, 2022 4:17 PM > >> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> > >> Cc: Tony Li <tony...@tony.li<mailto:tony...@tony.li>>; Christian Hopps > >> <cho...@chopps.org<mailto:cho...@chopps.org>>; > Peter > >> Psenak (ppsenak) <ppse...@cisco.com<mailto:ppse...@cisco.com>>; Robert > >> Raszuk > >> <rob...@raszuk.net<mailto:rob...@raszuk.net>>; Henk Smit > >> <henk.i...@xs4all.nl<mailto:henk.i...@xs4all.nl>>; > >> lsr@ietf.org<mailto:lsr@ietf.org> > >> Subject: Re: [Lsr] New Version Notification for > >> draft-pkaneria-lsr-multi-tlv- > >> 01.txt > >> > >> > >> "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto: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
