Re: [Isis-wg] Alvaro Retana's No Objection on draft-ietf-isis-auto-conf-04: (with COMMENT)

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 07 April 2017 21:09 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 5371C127866; Fri, 7 Apr 2017 14:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.022
X-Spam-Level:
X-Spam-Status: No, score=-14.022 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, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Sn5tRMBSmatp; Fri, 7 Apr 2017 14:09:14 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE7C120454; Fri, 7 Apr 2017 14:09:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5814; q=dns/txt; s=iport; t=1491599354; x=1492808954; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OfnrruaqcEigFQ0P9ORhNfoH76blhs8pxJr/Bhp6MuA=; b=WqhRpuOUSjM3dtT9rDtBzHSpnyyV6R2CM0pSgZSybXK0QphzmvTS/Tnp A2Qlft8D+PQFV+cL+xZx8CnwXFZiuckWBOuJcdfM8xTXlo0cBAMtU3g3i P10Bs7kyzABF9G/bhAkmr8pH/p7ByeqCwwb5nVQ4kDJ2U1cdhECg69bdV g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgAd/+dY/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KE5FElVeCDyqFeAIag0M/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAyMRRQwEAgEIEQQBAQMCJgICAjAVCAgCBAENBQiKBw6qd4ImimoBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYELhUOEcIQnAREBgyKCXwWJJZNTAYZ/i0+CB4U?= =?us-ascii?q?uihSTfgEfOEozCFsVhVKBSnUBhwqBIYENAQEB?=
X-IronPort-AV: E=Sophos;i="5.37,167,1488844800"; d="scan'208";a="408133087"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 21:09:12 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v37L9Ctd029419 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Apr 2017 21:09:12 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Apr 2017 16:09:12 -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; Fri, 7 Apr 2017 16:09:11 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-isis-auto-conf@ietf.org" <draft-ietf-isis-auto-conf@ietf.org>, Hannes Gredler <hannes@gredler.at>, "isis-chairs@ietf.org" <isis-chairs@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: Alvaro Retana's No Objection on draft-ietf-isis-auto-conf-04: (with COMMENT)
Thread-Index: AQHSr93lyukgHwpKlEyiUQaYqic0d6G6Y/Kg
Date: Fri, 7 Apr 2017 21:09:11 +0000
Message-ID: <1be87fbbda1141208c4890dca41d8c46@XCH-ALN-001.cisco.com>
References: <149159706927.11119.12965682520855681020.idtracker@ietfa.amsl.com>
In-Reply-To: <149159706927.11119.12965682520855681020.idtracker@ietfa.amsl.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.94.189]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/2KIXVzx-7BZakv0Te_fcmGOcZtc>
Subject: Re: [Isis-wg] Alvaro Retana's No Objection on draft-ietf-isis-auto-conf-04: (with COMMENT)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 07 Apr 2017 21:09:16 -0000

Alvaro -

Thanx for the review.
Inline.

> -----Original Message-----
> From: Alvaro Retana (aretana)
> Sent: Friday, April 07, 2017 1:31 PM
> To: The IESG
> Cc: draft-ietf-isis-auto-conf@ietf.org; Hannes Gredler; isis-chairs@ietf.org;
> isis-wg@ietf.org
> Subject: Alvaro Retana's No Objection on draft-ietf-isis-auto-conf-04: (with
> COMMENT)
> 
> Alvaro Retana has entered the following ballot position for
> draft-ietf-isis-auto-conf-04: No Objection
> 
> 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-auto-conf/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I have a series of comments -- they don't add up to a DISCUSS, but I think it is
> important that they are solved before publication.
> 
> (1) In Section 3.3. (Router-Fingerprint TLV), the format presented doesn't
> actually show the "flags field", which is described in the text,
> but it shows its contents.   The length is defined as "the length of the
> value field", but the figure doesn't explicitly show the Value field.  It is
> probably obvious that the flags field + Router Fingerprint = Value, but it
> would be nice to be specific.
> 
> Suggestion: include the 1 octet "flags field" in the drawing -- if needed, then
> show the detail (where the S and A bits are) in the description of the field.
> 
[Les:] Bing has the pen - I will let him respond - but I am OK with your suggestion.

> 
> (2) What about the other bits in the Flag field, how should they be registered
> in the future (if needed)?  Please ask IANA to define a registry for them.
> 
[Les:] I don't think a registry is needed. If an additional flag is required then a bis draft will be required.
This is no different than many other flags fields already defined in the protocol.
Note that this is different than (for example) the flags field in RFC 7794 since it is a fixed size.


> (3) Section 3.1. (IS-IS Default Configuration) mentions several TLVs that
> MUST NOT be used...and Section 3.3. (Router-Fingerprint TLV) says that this
> TLV MUST NOT be included in an LSP with a non-zero LSP number.  What
> should a receiving node do if any of those conditions are not true?
> 
[Les:] Ignore on receipt. We can add an explicit statement.

> (4) s/3.4.3.  IS-IS System ID Duplication Detection and Resolution/3.4.3.
>  IS-IS System ID Duplication Detection
> 
[Les:] Agreed.

> (5) I thought the point of this document was for use in "unmanaged
> deployments.  It allows IS-IS to be used without the need for any
> configuration by the user."  But Section 3.5. (Additional IS-IS TLVs Usage
> Guidelines) has recommendations for configuration options, including
> manually configured adjacencies (which should not be allowed according to
> Section 3.4.2. (Adjacency Formation)).  Isn't this against the stated reasons
> for this document?
> 
[Les:] The mention of "manually configured adjacencies" is in the context of what the default metric should be for non-manual adjacencies.
We do not recommend manual configuration, but it is not illegal to do it.

> (6) Authentication is one of those features that could be manually configured
> -- but the default is no authentication.  There's a higher-than-usual risk of a
> node listening on the network (probably a bigger problem for the user
> traffic), but also one that could listen to the Hellos and purposefully trigger
> the duplicate resolution mechanism to continuously run.  This risk should be
> highlighted in the Security Considerations because it is newly introduced
> here. [Robert Sparks pointed this risk out during his GenArt review.]
>
[Les:] Let me know if the answer I provided to Robert suffices.

   Les