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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Alexey -

> -----Original Message-----
> From: Alexey Melnikov [mailto:[e-mail]]
> Sent: Thursday, August 18, 2016 6:31 AM
> To: Les Ginsberg (ginsberg); The IESG
> Cc: [e-mail]; Christian Hopps; [e-mail];
> [e-mail]
> Subject: Re: Alexey Melnikov's Discuss on draft-ietf-isis-rfc4971bis-03: (with
> DISCUSS and COMMENT)
> 
> Hi Les,
> 
> On Thu, Aug 18, 2016, at 02:18 PM, Les Ginsberg (ginsberg) wrote:
> > Alexey -
> >
> > The document states in Section 2:
> >
> > " The Router CAPABILITY TLV is OPTIONAL.  As specified in Section 3,
> >    more than one Router CAPABILITY TLV from the same source MAY be
> >    present."
> >
> > This clearly allows multiple CAPABILITY TLVs from the same source to
> > be present. Why? Because the basic unit of advertisement in IS-IS is a
> > TLV - in this case one which is intended to include multiple sub-TLVs.
> > As the value field of a  TLV is limited in size to 255 bytes if a
> > router has more than 255 bytes of CAPABILITY information to advertise
> > then multiple TLVs will be required. This isn't a "trick" - it is
> > fundamental to the operation of IS-IS.
> 
> I was actually looking for this text in the document and didn't find it.
> Can you just say this in the document?
> 
[Les:] As I have stated publicly more than once, I avoid repeating normative statements from other documents when possible as it is either redundant or introduces unintended ambiguity. It also doesn't scale.

> > It is unclear to me how you could interpret the above text as meaning
> > that multiple CAPABILITY TLVs from the same source are either
> > disallowed or unexpected.
> 
> The text in Section 3:
> 
>    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.
> 
> is telling me that in some cases behaviour with multiple CAPABILITY TLVs is
> undefined. I was trying to figure out what are the conditions, thus all my
> questions in this thread.
> 
> So obviously I am missing something. Can you please help me understand
> how the two statements are not in conflict?
> 
[Les:] The phrase " different settings for a given attribute" is the key. If two TLVs contain information about different attributes clearly there is no conflict - it is only when the two TLVs have conflicting information for the same attribute that an issue arises.

CAPABILITY TLV is a container - sending such a TLV without any sub-TLVs is useless. So the significance of the TLV is not how many there are but what attribute information is contained in the set of TLVs which are advertised.

> > I appreciate that you may not be an expert in IS-IS and some
> > fundamentals may be unfamiliar to you. That is why the document
> > provides references to the base specifications which provide these
> > definitions.  A new implementer of the protocol could not write an
> > implementation solely based on this document - and it is not
> > reasonable to request that this document be written without
> dependencies on the base specifications.
> 
> Of course not. I was trying to get a copy of the base spec, but it looks like I
> need to pay for it.
>
[Les:] It is available without cost:  http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

   Les
 
> >    Les
> >
> > > -----Original Message-----
> > > From: Alexey Melnikov [mailto:[e-mail]]
> > > Sent: Thursday, August 18, 2016 2:59 AM
> > > To: Les Ginsberg (ginsberg); The IESG
> > > Cc: [e-mail]; Christian Hopps;
> > > [e-mail]; [e-mail]
> > > Subject: Re: Alexey Melnikov's Discuss on
> > > draft-ietf-isis-rfc4971bis-03: (with DISCUSS and COMMENT)
> > >
> > > 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.