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> 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
>> >>
