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

Job Snijders <job@ntt.net> Wed, 04 January 2017 16:13 UTC

Return-Path: <job@ntt.net>
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 DD017129613; Wed, 4 Jan 2017 08:13:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.035
X-Spam-Level:
X-Spam-Status: No, score=-5.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 NMBcJ6M9BC_6; Wed, 4 Jan 2017 08:13:40 -0800 (PST)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8D312960D; Wed, 4 Jan 2017 08:13:40 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1cOoC1-0008gY-Ey (job@us.ntt.net); Wed, 04 Jan 2017 16:13:38 +0000
Date: Wed, 4 Jan 2017 18:13:29 +0200
From: Job Snijders <job@ntt.net>
To: Benoit Claise <bclaise@cisco.com>
Message-ID: <20170104161329.GD53926@Vurt.local>
References: <148354156226.13001.17853336045471596840.idtracker@ietfa.amsl.com> <748483d7-df5c-e961-15f5-5aa76b784a7e@gmail.com> <af1e79a9-c188-23e4-3e45-0acacac049c8@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <af1e79a9-c188-23e4-3e45-0acacac049c8@cisco.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/M_yw5ZEzkOAcS1rPuZugGoYB9sc>
Cc: idr@ietf.org, idr-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-idr-large-community@ietf.org, rick.casarez@gmail.com
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 16:13:42 -0000

Hi Benoit,

On Wed, Jan 04, 2017 at 04:39:25PM +0100, Benoit Claise wrote:
> > 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.
>
> 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.

I am under the impression that nowadays the IETF community considers all
ASNs to be four-octet ASNs, however, some of those ASNs can be encoded
as a two octet value. The Large Communities specification is suitable
for usage in Autonomous Systems from all walks of life, where as rfc1997
communities are unsuitable for all ASNs, specifically those ASNs which
cannot be encoded as two-octet values.

Kind regards,

Job