[Idr] AD Review of draft-ietf-idr-large-community-09

"Alvaro Retana (aretana)" <aretana@cisco.com> Fri, 02 December 2016 04:04 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433B8129A8C; Thu, 1 Dec 2016 20:04:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Level:
X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, 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 aJwYYB-lBuse; Thu, 1 Dec 2016 20:04:24 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4DD129437; Thu, 1 Dec 2016 20:04:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10626; q=dns/txt; s=iport; t=1480651464; x=1481861064; h=from:to:cc:subject:date:message-id:mime-version; bh=xci/koCLcjq5oSyLOv/XhJ8IoVbhdZVB0laQ3R2sq8c=; b=cKi6kcaMqT3AtlPUQR3h0Cka4HIpGGnoLz4SA4CrK+20/LuRfLT3iha/ p642vmH0LDi44C54j/HEYqz0MI0lnvUXrZBPAj0wsR6ddlPjD8muez7Mg qnb7tKjR7VprzNJl3ImNwDNu25RlQ+43WjlJudRbYFe1CVds4f1zPi9Cm Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQAI8kBY/4kNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnNFAQEBAQEfWIENjT+mZIUiggaGIhyBcz8UAQIBAQEBAQEBYh0LhG8?= =?us-ascii?q?jVhIBSgIEMCcEDhmIW6wYgikvixEBAQEBAQEBAQEBAQEBAQEBAQEBAQEchj6Bf?= =?us-ascii?q?Yc+gm0tgjAFlHiFaQGREoFyhHyJS5IJAR83gRkxAQGDJIF+iAYGgSqBDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.33,284,1477958400"; d="scan'208,217";a="355678875"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2016 04:04:23 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB244M8V023787 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2016 04:04:23 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Dec 2016 22:04:22 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 1 Dec 2016 22:04:22 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>
Thread-Topic: AD Review of draft-ietf-idr-large-community-09
Thread-Index: AQHSTFEplUv+tL/kGUyk1NyWV0fUzQ==
Date: Fri, 2 Dec 2016 04:04:22 +0000
Message-ID: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.4]
Content-Type: multipart/alternative; boundary="_000_CE1331E43ECA41D7801F05519778E8DAciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZnYZVBTDsmpX2JYAFgOkM3N7XL4>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 04:04:26 -0000

Hi!

I just finished reading this document.  Thanks for working on it!

I do have some comments (please see below) that I want to see addressed before IESG Evaluation, but I am starting the IETF Last Call and will schedule the document in the next available Telechat.

Thanks!

Alvaro.


C1. Section 2. (BGP Large Communities Attribute) says that “Duplicate BGP Large Community values MUST NOT be transmitted.  A receiving speaker MUST silently remove duplicate BGP Large Community values from a BGP Large Community attribute.”  Given two identical Large Communities, should the receiver remove both, or just one (the duplicate of the first)?  I think the text as written is subject to interpretation.

C2. There seems to be a contradiction in the expected use of reserved Global Administrator values.  Section 2 says that the “Global Administrator field…SHOULD either be one of the reserved values as defined below, or an Autonomous System Number (ASN)”, but later Section 5 says: “The following Global Administrator values are reserved: 0, 65535, and 4294967295.  Operators SHOULD NOT use these Global Administrator values.”   IOW: “SHOULD use one if the reserved values” and “SHOULD NOT use the reserved values” contradict each other.  It seems to me that because 0, 65535, and 4294967295 are already reserved ASNs, *and* that “the Local Data Parts are to be interpreted as defined by the owner of the ASN”, then only assigned ASNs should ever be used --- *and* given that it is not an error to use an value, then there is no real advantage in reserving anything (again!). Suggestion: reference the RFCs where 0, 65535, and 4294967295 are reserved and just say that those numbers SHOULD NOT be used because if a Special Use Large Community is ever defined, those values may be used.

C3. In Section 6: s/Global Administrator field MAY contain any value/Global Administrator field may contain any value     That “MAY” is not normative, it is just expressing a fact.

C4. A Normative reference to RFC4271 should exist; tag it to the first mention of BGP.

C5. RFC1997 and RFC6793 should be Informative.