I simply turned your question around and asked: should conforming
implementations be penalized?
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.
Chris.
[as wg-member]
"Les Ginsberg (ginsberg)" <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> 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
