Re: [Isis-wg] Alexey Melnikov's Discuss on draft-ietf-isis-rfc4971bis-03: (with DISCUSS and COMMENT)

[Alexey Melnikov <[e-mail]>]

Hi Alia,

On Thu, Aug 18, 2016, at 01:32 PM, Alia Atlas wrote:
> Hi Alexey,
>
> On Thu, Aug 18, 2016 at 5:58 AM, Alexey Melnikov
> <[e-mail]> wrote:
>> Hi Les,
>>
>>  On Tue, Aug 16, 2016, at 05:56 PM, Les Ginsberg (ginsberg) wrote:
>>  > Alexey -
>>
>>  [snip]
>> > > -----------------------------------------------------------------
>> > > -----
>>  > > DISCUSS:
>>  > > ----------------------------------------------------------------
>>  > > ------
>>  > >
>>  > > I would like to get clarification on the following points before
>>  > > recommending approval of this document:
>>  > >
>>  > > 1) How do multiple CAPABILITY TLVs from the same source treated,
>>  > >    if they have the same S and D flags, but different subTLV?
>>  > >    Are the cumulative? Or this is not allowed? I am sorry if I
>>  > >    missed where this was described, let me know if I did.
>>  >
>>  > [Les:] Section 2 states:
>>  >
>>  > " The Router CAPABILITY TLV is OPTIONAL.  As specified in Section
>>  > 3,   more than one Router CAPABILITY TLV from the same source MAY
>>  > be   present."
>>  >
>>  > The only problematic case is when you have two TLVs from the same
>>  > source which have different settings for the same attribute i.e.
>>  > same sub-TLV but different values. This case is discussed in
>>  > detail in Section 3. Different sub-TLVs presents no issue of
>>  > course. Note this text is unchanged from the existing RFC.
>>
>> What happens in real world if there are two CAPABILITY TLVs which
>>  contain different attributes? Are they treated as cumulative
>>  (i.e. this
>>  is a nice trick to overcome CAPABILITY TLV length limit), does the
>>  second CAPABILITY  TLV value always overrides earlier instances
>>  of the
>>  CAPABILITY TLV?
>>
>>  I think the document should state what happens. If there is no
>>  consistent behaviour in this area, the document should says so
>>  as well.
>
> First, with IS-IS flooding, there is no defined order in which
> different TLVs can be
> assumed to be received.  It isn't possible to do a "first-in" or "last-
> in" tie-breaker
> because the TLVs can be received in different order at different
> routers.
>
> Second, the entire content of the CAPABILITY TLV is a set of flags,
> currently
> used solely to control how the TLV is distributed between IS-IS level
> 1 and IS-IS
> level 2, and optional sub-TLVs.
>
> It would be possible for additional of the reserved flags to be, in
> theory, allocated
> in which case they would also represent an "attribute" of the
> CAPABILITY TLV.
> Currently, only sub-TLVs have been defined; each individually may
> contain multiple
> pieces of information.  What is considered "the same attribute" could
> vary by sub-TLV
> or be the whole sub-TLV.  For instance, in RFC 4972, "IS-IS TE-MESH-
> GROUP sub-TLV may contain one or more mesh-group entries"
>
> The document already specifies "Where a receiving system has two
> copies of a CAPABILITY 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."
>
I think you need to include some of your clarifications in the document,
I don't believe the document is clear on the above.