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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 18 August 2016 13:18 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5595A12D780; Thu, 18 Aug 2016 06:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Level:
X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R4IkHz4Ndqn; Thu, 18 Aug 2016 06:18:32 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C2C12DE18; Thu, 18 Aug 2016 06:18:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3404; q=dns/txt; s=iport; t=1471526308; x=1472735908; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GbfRVXt+31y+eMC5jUBYh7p4qrgZ56foNO5usMw7ArI=; b=dsgixEqcbjA7h4ZohNLz2/D2QFtyoaIPY8Jx6gr451CU939xBVPu93et yTyddduKCmH5vhWxN0gunlUnbbOiDdRYwrLsvH18YgFa69shKTM3JNXwT dyWQD5bxoPvxj2CKj1L2E88BTQpBMjCluw3P+4KlQ3K/PjAy4mkpJwI2x A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A+AgBqtLVX/5hdJa1dg0OBUge1SIIPgX2GHQKBbTgUAgEBAQEBAQFeJ4ReAQEFOjEODAQCAQgOAwQBAQEeCQcyFAkIAgQBDQUIiCm7eQEBAQEBAQEBAQEBAQEBAQEBAQEBARyGKoRNhBwBhX4FiCqRGgGPFo9QjDuDdwEeNoIPAxwXgTVuhWgBJSB/AQEB
X-IronPort-AV: E=Sophos;i="5.28,539,1464652800"; d="scan'208";a="141884000"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2016 13:18:27 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7IDIR3C014600 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Aug 2016 13:18:27 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 18 Aug 2016 08:18:27 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Thu, 18 Aug 2016 08:18:27 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>
Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-isis-rfc4971bis-03: (with DISCUSS and COMMENT)
Thread-Index: AQHR99T2FgguQ06+B0ipCPLGFOcdOqBLzKmQgAMFtAD//97ekA==
Date: Thu, 18 Aug 2016 13:18:26 +0000
Message-ID: <f05c06635b594e0a8ce0bda59184a31a@XCH-ALN-001.cisco.com>
References: <147136220282.22903.10134856216046001373.idtracker@ietfa.amsl.com> <16512c4a95214a36972736635f275ba6@XCH-ALN-001.cisco.com> <1471514324.3079848.698914785.71D940DF@webmail.messagingengine.com>
In-Reply-To: <1471514324.3079848.698914785.71D940DF@webmail.messagingengine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.121.27]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/yi_Z1d4BO54aOAXdSB58oJ6vPZs>
Cc: "isis-wg@ietf.org" <isis-wg@ietf.org>, Christian Hopps <chopps@chopps.org>, "isis-chairs@ietf.org" <isis-chairs@ietf.org>, "draft-ietf-isis-rfc4971bis@ietf.org" <draft-ietf-isis-rfc4971bis@ietf.org>
Subject: Re: [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
Precedence: list
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 13:18:34 -0000

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. 

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

> -----Original Message-----
> From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm]
> Sent: Thursday, August 18, 2016 2:59 AM
> To: Les Ginsberg (ginsberg); The IESG
> Cc: draft-ietf-isis-rfc4971bis@ietf.org; Christian Hopps; isis-chairs@ietf.org;
> isis-wg@ietf.org
> 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.