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

"Alexey Melnikov" <aamelnikov@fastmail.fm> Thu, 18 August 2016 10:08 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: isis-wg@ietf.org
Delivered-To: isis-wg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EA612D8BA; Thu, 18 Aug 2016 03:08:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147151492610.22106.79065841387065539.idtracker@ietfa.amsl.com>
Date: Thu, 18 Aug 2016 03:08:46 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/0roHWiIMY8zgswjem6cFgmu-NI8>
Cc: isis-wg@ietf.org, chopps@chopps.org, isis-chairs@ietf.org, draft-ietf-isis-rfc4971bis@ietf.org
Subject: [Isis-wg] Alexey Melnikov's Discuss on draft-ietf-isis-rfc4971bis-03: (with DISCUSS and COMMENT)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2016 10:08:46 -0000

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)
Section 2 says:
   The Router CAPABILITY TLV is OPTIONAL.  As specified in Section 3,
   more than one Router CAPABILITY TLV from the same source MAY be
   present.

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.

The word "attribute" only occurs once in the document, so it would be
better if it is replaced for clarity. Does "a given attribute" mean "a
single sub-TLV" or "all sub-TLVs included in a CAPABILITY TLV instance"?

If "a given attribute" means "a single sub-TLV", then I have the
following followup questions:

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.


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

1) In Section 4, 1st sentence: how can this specification have
requirements on implementation that don't support this extension?

As per Alia:

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

So I think the document should mention RFC 1195 and don't use RFC 2119
keywords for something which is already stated there. For example:

OLD:

Routers that do not support the Router CAPABILITY TLV MUST silently
   ignore the TLV(s) and continue processing other TLVs in the same LSP.

NEW:

As per RFC 1195, routers that do not support the Router CAPABILITY TLV
will silently
   ignore the TLV(s) and continue processing other TLVs in the same LSP.

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