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

Ignas Bagdonas <ibagdona.ietf@gmail.com> Fri, 02 December 2016 06:31 UTC

Return-Path: <ibagdona.ietf@gmail.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 3D7931288B8; Thu, 1 Dec 2016 22:31:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JmB2AExiKpMA; Thu, 1 Dec 2016 22:31:16 -0800 (PST)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772481294B2; Thu, 1 Dec 2016 22:31:16 -0800 (PST)
Received: by mail-pg0-x229.google.com with SMTP id 3so104105287pgd.0; Thu, 01 Dec 2016 22:31:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=AxR641LP+dkIZU/aUSRq6srm0YjQswBBm16Efi+P5t8=; b=06Wi0LbPofsDGvE0z6UWZcjHFHi3/xv9O7kUg48aqYzzQnxh7yF8NPk0rwu8JTC9Qr awCI2ehcjUeptEqKVcjO/vNYEcUqN3Rhx7aNGaN4jhLdfMfHgObC2APd+VJtKYmVnkPm Mz9HnTFB5WvHl2gkodRaL9AxqaLOQfeTS0IFSln+kBF4GBqyF1j1hF6jQIc/Kq4n//qo Yks/C4mle+22DFZRQgDLkjhH2IRBPMq7gtaCObWsEMKsJGysV/QNFqVw9zIygVfnZW3e R0gmpPhgMflilpzee4hvWb0Y5+o5iO0ANjcPiXbAFfoofljrfbKjriBt6BZnX6ofA9+T 2zsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=AxR641LP+dkIZU/aUSRq6srm0YjQswBBm16Efi+P5t8=; b=B35aE8dBO/23fNpUmurPf8JCDR1Zf3ZMFILjQQGHD1gVxODZY8LFCPxZNATDh4qIKi EQHQHGnwnrbaVqr93w0xZQGSA6osr30do2Vgw1UVG3mocQLvrH2f4Niflmif9yyMKuko TGWnfSGxB+Nv5sk199bRI5qYblBQfBK4KNV5AvgILTK0UBtYFr++xEj5ydq7LN0eCjH2 IkGjHvLVVcwb9fd/iS3Ojnzc2WSDUrgE2DneruW/40pfcecBBHrwAYQAIOdnHBkgx34I xa9gpgW9ytUvOyGS/LFeEZfk4SCv0TqEclPyvQRqh+vSSyUyBRMflw+0l6MTmNYHcKc+ XpmQ==
X-Gm-Message-State: AKaTC03MPFJz6xdRF9umfsjTAqeyS9FUpCXVwjIO0PoIfsuPMhm47g3bS2bhqNfO++YidA==
X-Received: by 10.84.218.8 with SMTP id q8mr93057317pli.138.1480660275814; Thu, 01 Dec 2016 22:31:15 -0800 (PST)
Received: from [172.16.184.157] ([101.100.166.67]) by smtp.gmail.com with ESMTPSA id g22sm4522955pgn.20.2016.12.01.22.31.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 22:31:15 -0800 (PST)
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com>
From: Ignas Bagdonas <ibagdona.ietf@gmail.com>
Message-ID: <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com>
Date: Fri, 2 Dec 2016 06:31:12 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com>
Content-Type: multipart/alternative; boundary="------------DD3D3E085AC9643C76A8347D"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zW_sBk7WW_hQbOtGHCTxwaCYEEs>
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 06:31:18 -0000

Hi Alvaro,

Thank you for your review!


On 02/12/2016 04:04, Alvaro Retana (aretana) wrote:
>
> 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.
>
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.


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

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

Will edit those.

Thank you.

Ignas