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

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 16 Aug 2016 08:43:22 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-isis-rfc4971bis-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-rfc4971bis/

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

2) In Section 4, 1st sentence: how can this specification have
requirements on implementation that don't support this extension? If this
behaviour is already prescribed by another specification, then you should
not use RFC 2118 keyword and you should reference the relevant
specification.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Should subTLVs have an IANA registry? Or is there an existing one
already?

---

From: Alia Atlas <[email-masked]>
Date: Tue, 16 Aug 2016 12:03:22 -0400

Hi Alexey,

> https://datatracker.ietf.org/doc/draft-ietf-isis-rfc4971bis/

The end of Section 3 says " 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."

This bis is to update the handling for IPv6; there was no discussion about
changing the basic details (such as this)
in the updated version.

> not use RFC 2118 keyword and you should reference the relevant

RFC1195 says
"   Any codes in a received PDU that are not recognised shall be ignored
   and, for those packets which are forwarded (specifically Link State
   Packets), passed on unchanged."

A reference would be fine - but this is basic well-known behavior for IS-IS.
The authors may have more details.

It's already there -
http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242
but it does look like an updated reference to rfc4971bis would be a good
idea.

Regards,
Alia

>
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 16 Aug 2016 17:16:04 +0100

Hi Alia,

On Tue, Aug 16, 2016, at 05:03 PM, Alia Atlas wrote:
> Hi Alexey,
>
> On Tue, Aug 16, 2016 at 11:43 AM, Alexey Melnikov
> <[email-masked]> wrote:
>>
>>
> The end of Section 3 says " 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."

Ok, I wasn't sure that this was talking about the same thing.

So just to double check: using multiple CAPABILITY TLVs with different
S and D flags is Ok (and described), but use of multiple CAPABILITY
TLVs with identical S and D flags is undefined as per the sentence you
quoted above?

>
> This bis is to update the handling for IPv6; there was no discussion
> about changing the basic details (such as this)
> in the updated version.
>

My problem was that the document seemed to impose new requirements. I
think the sentence needs to be reworded to say "As per RFC 1195, ..."
and don't use RFC 2119 language.

> but it does look like an updated reference to rfc4971bis would be a
> good idea.
Indeed.

---

From: Alia Atlas <[email-masked]>
Date: Tue, 16 Aug 2016 12:18:35 -0400

On Tue, Aug 16, 2016 at 12:16 PM, Alexey Melnikov <[email-masked]>
wrote:

> So just to double check: using multiple CAPABILITY TLVs with different S
> and D flags is Ok (and described), but use of multiple CAPABILITY TLVs with
> identical S and D flags is undefined as per the sentence you quoted above?
>

They have to have the same attribute - which could be a sub-TLV.

> think the sentence needs to be reworded to say "As per RFC 1195, ..." and
> don't use RFC 2119 language.
>
>
> It's already there - http://www.iana.org/assignments/isis-tlv-
> codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 16 Aug 2016 16:56:37 +0000

Alexey -

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Tuesday, August 16, 2016 8:43 AM
> To: The IESG
> Cc: [email-masked]; Christian Hopps; [email-masked];
> [email-masked]; [email-masked]
> Subject: Alexey Melnikov's Discuss on draft-ietf-isis-rfc4971bis-03: (with
> DISCUSS and COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> I would like to get clarification on the following points before recommending
> approval of this document:
> 

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

> 
> 2) In Section 4, 1st sentence: how can this specification have requirements
> on implementation that don't support this extension? If this behaviour is
> already prescribed by another specification, then you should not use RFC
> 2118 keyword and you should reference the relevant specification.
> 

[Les:] Ignoring TLVs/sub-TLVs that are not understood is fundamental to the IS-IS protocol and defined in the base spec ISO 10589 (which is referenced). Repeating this is strictly speaking unnecessary - but was done in the original RFC as a point of emphasis.

> Should subTLVs have an IANA registry? Or is there an existing one already?
> 

[Les:] http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242
It has already been noted that the registry should be updated to point to the new RFC once it is published.

   Les

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Aug 2016 10:58:44 +0100

Hi Les,

> Alexey -

 [snip]
> 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.

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Aug 2016 11:05:08 +0100

Hi Alia,

On Tue, Aug 16, 2016, at 05:18 PM, Alia Atlas wrote:
>
>
> On Tue, Aug 16, 2016 at 12:16 PM, Alexey Melnikov
>> __
>>> The end of Section 3 says " 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."
>>>
>>
>> So just to double check: using multiple CAPABILITY TLVs with
>> different S and D flags is Ok (and described), but use of multiple
>> CAPABILITY TLVs with identical S and D flags is undefined as per the
>> sentence you quoted above?
>

I don't think Les' answer agrees with yours.

The word "attribute" only occurs once in the document in the sentence
you quote.
Does "a given attribute" mean "a single sub-TLV" or "all sub-TLVs
included in a CAPABILITY TLV instance"?

---

From: Alia Atlas <[email-masked]>
Date: Thu, 18 Aug 2016 08:32:55 -0400

Hi Alexey,

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

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 18 Aug 2016 08:34:17 -0400

Hi Alexey,

Please see my earlier reply.   Attribute is correct and could apply to, in
theory, a flag, as well
as a sub-TLV or an entry in a sub-TLV.

Regards,
Alia

On Thu, Aug 18, 2016 at 6:05 AM, Alexey Melnikov <[email-masked]>
wrote:

> The word "attribute" only occurs once in the document in the sentence you
> quote.
> Does "a given attribute" mean "a single sub-TLV" or "all sub-TLVs included
> in a CAPABILITY TLV instance"?
>
>
>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Aug 2016 13:45:01 +0100

Hi Alia,

On Thu, Aug 18, 2016, at 01:34 PM, Alia Atlas wrote:
> Hi Alexey,
>
> Please see my earlier reply.   Attribute is correct and could apply
> to, in theory, a flag, as well

Can it be defined clearly to avoid confusion? For somebody who doesn't
know much about IS-IS, for example a new implementor, this is a rather
nuanced definition.
>
> Regards,
> Alia
>
> On Thu, Aug 18, 2016 at 6:05 AM, Alexey Melnikov
>>>>> The end of Section 3 says " 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."
>>>>>
>>>>
>>>> CAPABILITY TLVs with identical S and D flags is undefined as per
>>>> the sentence you quoted above?
>>>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Aug 2016 13:47:11 +0100

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
>>  > > 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.
>>
> 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
> used solely to control how the TLV is distributed between IS-IS level
> 1 and IS-IS
> 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
I think you need to include some of your clarifications in the document,
I don't believe the document is clear on the above.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 18 Aug 2016 13:18:26 +0000

Alexey -

The document states in Section 2:

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. 

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.

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.

   Les

> Sent: Thursday, August 18, 2016 2:59 AM
> To: Les Ginsberg (ginsberg); The IESG
> [email-masked]
> Subject: Re: Alexey Melnikov's Discuss on draft-ietf-isis-rfc4971bis-03: (with
> DISCUSS and COMMENT)
> 
> Hi Les,
> 
> > > 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?
> > 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.
> 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.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Aug 2016 14:31:09 +0100

Hi Les,

On Thu, Aug 18, 2016, at 02:18 PM, Les Ginsberg (ginsberg) wrote:
> 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?

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

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 18 Aug 2016 13:39:34 +0000

Alexey -

> Sent: Thursday, August 18, 2016 6:31 AM
> > 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.
> 
[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.

> > that multiple CAPABILITY TLVs from the same source are either
> > disallowed or unexpected.
> 
> The text in Section 3:
> 
> 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.
> 
[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
 
> > > Cc: [email-masked]; Christian Hopps;
> > > [email-masked]; [email-masked]
> > > Subject: Re: Alexey Melnikov's Discuss on
> > > draft-ietf-isis-rfc4971bis-03: (with DISCUSS and COMMENT)
> > >
> > > Hi Les,
> > >
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > DISCUSS:
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > >
> > > > > if they have the same S and D flags, but different subTLV? Are
> > > > > the cumulative? Or this is not allowed?
> > > > same sub-TLV but different values. This case is discussed in detail in
> Section 3.
> > > 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?
> > >

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 18 Aug 2016 22:33:39 +0530

alexey,

i second Les' observation. the TLV-adding semantics of the router-CAP TLV (and other TLVs like IP prefix TLV) are well understood  - even by junior implementers and IMO do not need explicitly be mentioned. Furthermore historically we just did document deviations ( if any)  from that rule of thumb.

/hannes

> On 18 Aug 2016, at 18:48, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Alexey -
>