[Idr] Fwd: Review of draft-ietf-large-community-06.txt

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Fri, 04 November 2016 14:20 UTC

Return-Path: <jheitz@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 4B112129450 for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 07:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.008
X-Spam-Level:
X-Spam-Status: No, score=-16.008 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=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, 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 wQl5evy4fJZg for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 07:20:44 -0700 (PDT)
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 7A3F61288B8 for <idr@ietf.org>; Fri, 4 Nov 2016 07:20:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=147406; q=dns/txt; s=iport; t=1478269244; x=1479478844; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=JDeZDpZzfACu5w+L89kunItYGcdQUoUqO69iexlWX9w=; b=jdJ/NrqIHPu9APMUrjgi3WsrLCmDoKkyxtZTo/boZSKaUqyz+YmREady V7CP7vcv/fux3yzLSX96ULPFVAytlJLlptXvsv7v98001mkZeDhByDXLm /tTrospLTEmArIYNLSgQq9FGFXBCMJPxw13GkGTSQElEr9/KufLoc251l g=;
X-Files: draft-ietf-idr-large-community.xml, draft-ietf-idr-large-community-07.txt, draft-ietf-idr-large-community-07-diff-from-06.html : 17835, 18213, 63837
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AXAQCumBxY/4cNJK1TChkBAQEBAQEBAQEBAQcBAQEBAYMuAQEBAQEfWHyFTYdrlwCHYIxmggUDHQEMhB+BVQMCAhqBfD8UAQIBAQEBAQEBYiiEYQEBAQQBAQEXARI5AQcXBAIBGQQBASEBBgUCAh8GCxQHAggCBAESDgYGiCQDFw6RdZ05CIMIhXANg3sBAQEBAQEBAQEBAQEBAQEBAQEBAQEODoY/gX0IglCCR4FHCwYFAwMBMxWCVDGCLwWIS4F4iEiDWnuCDjUBg0mCaoMLgwdEgzaBbhc3hCGIBIEphymBWIQghAMBHjdsgm02BRyBXXIBhTcBBQkXghYBAQE
X-IronPort-AV: E=Sophos;i="5.31,443,1473120000"; d="xml'217?txt'217?html'217,217?scan'217,217,208,217";a="344299115"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Nov 2016 14:20:41 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uA4EKfWQ020022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2016 14:20:41 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Nov 2016 09:20:40 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 4 Nov 2016 09:20:40 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: "gih@apnic.net" <gih@apnic.net>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] Review of draft-ietf-large-community-06.txt
Thread-Index: AQHSNjBz6sRcMeSZxEiIR579im5tsaDIY72wgAB9DlI=
Date: Fri, 04 Nov 2016 14:20:40 +0000
Message-ID: <40D942F5-0710-46D1-BF09-76C827377479@cisco.com>
References: <112dc01d235fd$57f9c370$07ed4a50$@ndzh.com> <C2DABF02-D3CB-4646-B869-FBCE5F05FDA1@apnic.net> <117ea01d23611$a28513e0$e78f3ba0$@ndzh.com> <CED07D95-A426-469C-85B4-DB2FBE52D14A@apnic.net>, <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com>
In-Reply-To: <6c5d83aa1d6a4a04b651b8f14f4b445b@XCH-ALN-014.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/mixed; boundary="_004_40D942F5071046D1BF0976C827377479ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/06tmTdEqK95Tk3dUUmYlXAg5_ek>
Subject: [Idr] Fwd: Review of draft-ietf-large-community-06.txt
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, 04 Nov 2016 14:20:48 -0000

Geoff,

Here is my proposed revision. I made all the changes, except the ATOMIC_AGGREGATE. If after the latest discussion, you still want it, I'll make that change too.

Thanks,
Jakob.


Begin forwarded message:

>> -----Original Message-----
>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Geoff Huston
>> Sent: Thursday, November 03, 2016 5:14 PM
>> To: IETF IDR WG <idr@ietf.org>
>> Cc: rtg-dir@ietf.org; Susan Hares <shares@ndzh.com>
>> Subject: [Idr] Review of draft-ietf-large-community-06.txt
>> 
>> I have reviewed this draft and have the following 9 suggestions. All of
>> these fall into the category of minor suggestions. I do not believe that
>> there is may major structural deficiency in this specification, and the
>> document is largely ready, in my view.
>> 
>> Here are my specific suggestions.
>> 
>> 
>> 1. ----------------
>> 
>> Title: Large BGP Communities
>> 
>> to be consistent with previous attribute specifications, how about
>> 
>> "BGP Large Communities Attribute"
>> 
>> i.e. switch the order of "Large BGP" to "BGP Large" to be consistent with
>> earlier BGP Extended Communities specification in RFC4360
>> 
>> 2. ----------------
>> 
>> "Network operators
>> attach BGP communities to routes to identify intrinsic properties of
>> these routes."
>> 
>> I don't think community attributes are an intrinsic property of a route
>> advertisement - they are more appropriately expressed as an attached attribute
>> that expresses some desired property.
>> 
>> how about:
>> 
>> "Network operators attach BGP communities to routes to associate
>> particular properties with these routes."
>> 
>> 3. ----------------
>> 
>> "and may apply to an individual route or to a group of routes."
>> 
>> I am confused - surely the attributes in an Update BGP message apply to the
>> collection of routes contained in the Update. It cannot be applied to a
>> single route when the update itself contains multiple routes. Why not
>> use the text:
>> 
>> "and is applied to all routes contained in a BGP Update Message where
>> the Communities Attribute is included."
>> 
>> 4. ----------------
>> 
>> "[RFC1997] BGP Communities attributes are four-octet values split into
>> two two-octet words."
>> 
>> This is not the case - RFC1997 says: "Communities are treated as 32 bit values"
>> I think it would be more accurate to say:
>> 
>> "BGP Communities attributes are four-octet values [RFC1997]. Common use of
>> this attribute type splits this single 32-bit value field into two 16-bit values."
>> 
>> 5. ----------------
>> 
>> "The BGP Extended Communities
>> attribute [RFC4360] is also unsuitable, as the protocol limit of six
>> octets cannot accommodate both a four-octet Global Administrator
>> value and a four-octet Local Administrator value, which precludes the
>> common operational practice of encoding a target ASN in the Local
>> Administrator field."
>> 
>> 
>> Thats a very long sentence. Try:
>> 
>> "The BGP Extended Communities attribute [RFC4360] is also unsuitable, as
>> the protocol limit of six octets for each community value cannot
>> accommodate both a four-octet Global Administrator value and a four-octet
>> Local Administrator value. This limitation precludes the common
>> operational practice of encoding a target ASN in the Local Administrator
>> field."
>> 
>> 6. ----------------
>> 
>> The aggregation section contains fewer constraints then either RFC1997 or
>> RFC4360. It also contains a confusing non-normative “should".
>> 
>> For reference, RFC4360 states: By default if a range of routes is to be
>> aggregated and the resultant aggregates path attributes do not carry the
>> ATOMIC_AGGREGATE attribute, then the resulting aggregate should have an
>> Extended Communities path attribute that contains the set union of all the
>> Extended Communities from all of the aggregated routes.  The default
>> behavior could be overridden via local configuration, in which case
>> handling the Extended Communities attribute in the presence of route
>> aggregation becomes a matter of the local policy of the BGP speaker that
>> performs the aggregation.
>> 
>> Why not use this formulation? i.e.
>> 
>> "3. Aggregation
>> 
>> If a set of routes is to be aggregated and the resulting aggregate route's
>> path attributes do not include the ATOMIC_AGGREGATE attribute, then the
>> resulting aggregate route SHOULD have a Large Communities Attribute formed
>> from the set union of all the Large Community values from all of the
>> aggregated set of routes.  This behavior MAY be overridden via local
>> configuration, in which case handling the Large Communities attribute in
>> the presence of route aggregation is determined by the local policy of the
>> BGP speaker that performs the aggregation."
>> 
>> 7. ----------------
>> 
>> 4.  Canonical Representation
>> 
>> I am confused here - this section used an example with TWO canonical
>> representations:
>> 
>>   "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)."
>> 
>> 
>> Conventionally, it's better to use a single canonical representation, so the
>> authors should pick either a colon-delimited list, or a bracketed comma+space
>> separated object.
>> 
>> 
>> 8. ----------------
>> 
>> 5.  Reserved Large BGP Community values
>> 
>> 
>> The text reads:
>> 
>> "the Global Administrator values specified above could be
>> used if there is a future need for them."
>> 
>> This is entirely unclear. Is it referring to the values that the previous
>> paragraph specified as "SHOULD NOT use”? Also "could be used" is a poor
>> choice of words for a normative specification.
>> 
>> I suggest deleting completely the paragraph that contains this quote from
>> the document.
>> 
>> 
>> 9. ----------------
>> 
>> The text reads:
>> 
>> "The error handling of Large BGP Communities is as follows:
>> 
>>   o  A Large BGP Communities attribute SHALL be considered malformed if
>>      its length is not a non-zero multiple of 12."
>> 
>> 
>> I think the author is trying to dayL
>> 
>> "The error handling of Large BGP Communities is as follows:
>> 
>>   o  A Large Communities attribute SHALL be considered malformed if the
>>     length of the Large Communities value, expressed in octets, is not a
>>     non-zero multiple of 12."
>> 
>> 
>> thanks,
>> 
>>  Geoff
>> 
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr