[Idr] Benoit Claise's No Objection on draft-ietf-idr-large-community-11: (with COMMENT)

"Benoit Claise" <bclaise@cisco.com> Thu, 05 January 2017 08:25 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43056129484; Thu, 5 Jan 2017 00:25:55 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Benoit Claise" <bclaise@cisco.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148360475527.20665.11545913165681988756.idtracker@ietfa.amsl.com>
Date: Thu, 05 Jan 2017 00:25:55 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lRaPXdXAIHPoyLjKEUHRBsDr2hU>
Cc: idr@ietf.org, draft-ietf-idr-large-community@ietf.org, rick.casarez@gmail.com, idr-chairs@ietf.org
Subject: [Idr] Benoit Claise's No Objection on draft-ietf-idr-large-community-11: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 05 Jan 2017 08:25:55 -0000

Benoit Claise has entered the following ballot position for
draft-ietf-idr-large-community-11: No Objection

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:


Thanks John for an excellent shepherd writeup.

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
   This field SHOULD be an Autonomous System Number (ASN), in which
   the Local Data Parts are to be interpreted as defined by the owner
   the ASN.  The use of Reserved ASNs (0 [RFC7607], 65535 and

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
   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
   a two-octet AS number.

After some discussion on the idr list.

My reasoning has been:
    either you mention that two-octet ASN can be represented in
four-octets (RFC6793)
    or you mention: suitable for all ASNs (2 or 4)
It's so obvious to you guys in your community.

Ok, it seems that we're going in circle here.
You guys understood my issue. It was DISCUSSed. I believe the draft
should be clearer, but this is not DISCUSS-level point any longer.
Moving to a COMMENT, and trusting the responsible shepherd and AD.

For the record, John's proposal solveds my issue.

       The attribute is suitable for use with four-octet
       Autonomous System Numbers

       The attribute is suitable for use with all Autonomous System
Numbers including four-octet
       Autonomous System Numbers