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

"Alvaro Retana (aretana)" <aretana@cisco.com> Fri, 02 December 2016 13:46 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 30EDC1296BB; Fri, 2 Dec 2016 05:46:56 -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 qgH_yhRmjlLU; Fri, 2 Dec 2016 05:46:53 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAAEA129436; Fri, 2 Dec 2016 05:46:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21174; q=dns/txt; s=iport; t=1480686412; x=1481896012; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mv6P5f7bs5OO6lmMHzpbbp70Z7Vekw/wmfk4HSUIoiI=; b=W2ls88kh4sv2T10zVjqNQ+anYxRnpJEtSvfhXk36/7qveLP9vcl0XFjb vw/fHO6KdzikzCO+CuNqJdjsCID9GZzv6kRowSy3hVYh4wvZEIcDQTfbf T2E3WNpIDRiJobkbJij3yLSsK7ilI3U36FO8OVOP2ArykX4+R8/kYdA84 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQCyekFY/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnNFAQEBAQEfWoEGB40/lwuHc4dnhSKCBoYiAhqBfj8UAQIBAQE?= =?us-ascii?q?BAQEBYiiEaQEEASNWBQsCAQgONAICAh8RJQIEAQ0FFIhBAw8IrHOCKS+HEA2Dc?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBARyGPoF9gl6CSIIYgm0tgjAFlHqFNDUBjTW?= =?us-ascii?q?DXpA5iUyIQAEfN4EZMQEBgySBfnKGQQaBKoENAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,729,1477958400"; d="scan'208,217";a="355747060"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 13:46:51 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB2DkpgE027850 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2016 13:46:51 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; Fri, 2 Dec 2016 07:46:50 -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; Fri, 2 Dec 2016 07:46:50 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Ignas Bagdonas <ibagdona.ietf@gmail.com>, "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/kGUyk1NyWV0fUzaD0l0wAgAAl5QA=
Date: Fri, 2 Dec 2016 13:46:50 +0000
Message-ID: <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com>
In-Reply-To: <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.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_8B6BA07AD6364D8C8B02A5CB05538AAFciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Ij2LxmBbG9jtua43yq9gr2xWul4>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [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 13:46:56 -0000

On 12/2/16, 1:31 AM, "Ignas Bagdonas" <ibagdona.ietf@gmail.com>; wrote:



Ignas:



Hi!



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

>

> The intention is to react on the first instance of the duplicate community - analogous to applying

> RFC7606 to the contents of the large community path attribute itself. Would a following text address

> your comment:

>

> A receiving speaker MUST act on the first instance of duplicate BGP Large Community value, and

> MUST silently ignore any other occurrence of such duplicated values. Duplicate BGP Large

> Community values MUST NOT be transmitted.

>

> This reverses the receive and transmit handling - ignore any subsequent duplicate community values

> and do not send duplicates. Whether an implementation actually removes anything or just ignores is

> an internal matter to the implementation.



Removing and ignoring are obviously different things…  The text above is fine with me, but I would ask: what do the current implementations do?  If they remove (as originally specified), then I would suggest you keep that.







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

>

> For section 2: Global Administrator field SHOULD be an Autonomous System Number (ASN) or one of

> the reserved values defined in Section 5.

>

> For section 5: Global Administrator values corresponding to reserved use Autonomous System

> Number values of 0 [RFC7607], 65535 [RFC7300], and 4294967295 [RFC7300] are reserved.

>

> Would this work?



Question for you:  do you want the operators to use 0, 65535, and 4294967295 whenever they want (which is what the new text says), OR, do you want them not to use them because they could be used later for a special purpose (which is what the original text seemed to indicate)??



I’m having a hard time with this document “reserving” any value because the number space is not really one where values are assigned (in the typical IANA sense: create a registry, etc. – and I doubt you want to make it that way)…but the contents can be (SHOULD) what is contained in an already existing registry (ASNs) that has distributed control.



Assuming that you would prefer the operators NOT to use 0, 65535, and 4294967295, then here’s my suggestion:



OLD> (Section 2)

   The Global Administrator field is intended to allow different

   Autonomous Systems to define BGP Large Communities without collision.

   This field SHOULD either be one of the reserved values as defined

   below, or an Autonomous System Number (ASN).  If it is a reserved

   value, then the Local Data Parts are as defined by the reserved

   value.  If it is an ASN then the Local Data Parts are to be

   interpreted as defined by the owner of the ASN.



NEW>

   The Global Administrator field is intended to allow different

   Autonomous Systems to define BGP Large Communities without collision.

   This field SHOULD be an Autonomous System Number (ASN).  The use of

   Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is NOT

   RECOMMENDED.



…and then eliminate Section 5…



If you really want operators not to use the Reserved ASNs ever because a special use may be though up later, then use “MUST NOT” above.





Thanks!



Alvaro.