Re: [Idr] Benoit Claise's Discuss on draft-ietf-idr-large-community-11: (with DISCUSS and COMMENT)

Benoit Claise <bclaise@cisco.com> Wed, 04 January 2017 15:39 UTC

Return-Path: <bclaise@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 4F1651295AA; Wed, 4 Jan 2017 07:39:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.622
X-Spam-Level:
X-Spam-Status: No, score=-17.622 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, 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 gudUc-OhZVdP; Wed, 4 Jan 2017 07:39:49 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030DC129593; Wed, 4 Jan 2017 07:39:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3419; q=dns/txt; s=iport; t=1483544388; x=1484753988; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ZuWSYxHF/TMjLO99r0va7s1sTp26PWUY8Tze2qli88Y=; b=mNIHraBG5gEg7104GC5hhehzEKhdc5rCXNwFCp5P3dPhQeBRNykyWsyW +ppf/b3I9x5YSS0p4bEKQIXt2WG9n7YDOWzft7cV2HJtD0sOiJ+1Jve4g biFG1yutAV4VCheNK8eIhzTOxaYmUgSt5I4OxZQY0ZVnEA8Vsjk1CCKQG w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAQDDFm1Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAX4vXY1XcpNTkxOCD4IIKoV4AoITFAECAQEBAQEBAWM?= =?us-ascii?q?ohGkBBSMVQRALDgoCAiYCAlcGAQwIAQEQiFwOry6CJYoxAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGAWBC4U6ggKCX4QYEQGDIYJeBYhuBZIWhlaDEodZgXaFCIMnhjS?= =?us-ascii?q?KSod2HzhoIBYNhBICAxwYgUc9NAGGA4IuAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,459,1477958400"; d="scan'208";a="691058695"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2017 15:39:26 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v04FdPUg030284; Wed, 4 Jan 2017 15:39:26 GMT
To: Ignas Bagdonas <ibagdona.ietf@gmail.com>, The IESG <iesg@ietf.org>
References: <148354156226.13001.17853336045471596840.idtracker@ietfa.amsl.com> <748483d7-df5c-e961-15f5-5aa76b784a7e@gmail.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <af1e79a9-c188-23e4-3e45-0acacac049c8@cisco.com>
Date: Wed, 4 Jan 2017 16:39:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <748483d7-df5c-e961-15f5-5aa76b784a7e@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/D87L8TgPMDDoC48bTUE6KeWlIA4>
Cc: idr@ietf.org, draft-ietf-idr-large-community@ietf.org, rick.casarez@gmail.com, idr-chairs@ietf.org
Subject: Re: [Idr] Benoit Claise's Discuss on draft-ietf-idr-large-community-11: (with DISCUSS and COMMENT)
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: Wed, 04 Jan 2017 15:39:50 -0000

Ignas,
> Hi Benoit,
>
> Thank you for reviewing.
>
> Global Administrator field is a 4 octet integer that is used to carry 
> AS number but it is not mandatory to interpret it as an AS number only 
> (while a typical use case is for carrying AS number) - two peers can 
> agree on any value that has meaning between those peers. 
> Representation on the wire is in network byte order, and 2 byte AS 
> number will get naturally padded with two zero bytes in front. 
> Virtually all deployments today are AS4 capable and use AS4 encoding 
> even for AS number values that fit into 16 bit value range therefore 
> AS number is a 4 octet entity already.
Thanks Ignas.
Then this sentence in the abstract "The attribute is suitable for use 
with four-octet ASNs." is misleading, right? At least to me.
The attribute is suitable for four-octets ASNs and two-octets ASNs 
encoded in four-octets.
This would be more in line with "This field SHOULD be an Autonomous 
System Number (ASN)" later on.

Regards, B.
>
> The topics of 2 byte padding and any integer value in global 
> administrator field have been discussed in the WG.
>
> Ignas
>
>
>
> On 04/01/2017 14:52, Benoit Claise wrote:
>> Benoit Claise has entered the following ballot position for
>> draft-ietf-idr-large-community-11: Discuss
>>
>> 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-idr-large-community/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> I see from the abstract: "The attribute is suitable for use with
>> four-octet ASNs."
>> I also see this text, which doesn't mention four-octet ASNs
>>
>>     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), in which
>> case
>>     the Local Data Parts are to be interpreted as defined by the owner
>> of
>>     the ASN.  The use of Reserved ASNs (0 [RFC7607], 65535 and
>> 4294967295
>>     [RFC7300]) is NOT RECOMMENDED.
>>
>> What if the ASN is two bytes, we use padding? How?
>> Even if we would say: "This field SHOULD be an four-octet Autonomous
>> System Number (ASN)", it doesn't preclude inserting a two-octet ASN in
>> the Global Administrator field.
>> Isn't it better to specify how?
>>
>> >From RFC 6793:
>>
>>     Currently assigned two-octet AS numbers are converted into
>> four-octet
>>     AS numbers by setting the two high-order octets of the four-octet
>>     field to zero.  Such a four-octet AS number is said to be mappable
>> to
>>     a two-octet AS number.
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thanks John for an excellent shepherd writeup.
>>
>>
>
> .
>