[Idr] Pete Resnick's Discuss on draft-ietf-idr-as-migration-03: (with DISCUSS and COMMENT)

"Pete Resnick" <presnick@qti.qualcomm.com> Thu, 19 February 2015 04:36 UTC

Return-Path: <presnick@qti.qualcomm.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 887B21A86F6; Wed, 18 Feb 2015 20:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SnDWXVrQ93Qj; Wed, 18 Feb 2015 20:36:34 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 963621A01D5; Wed, 18 Feb 2015 20:36:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Pete Resnick <presnick@qti.qualcomm.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.11.0.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150219043634.31970.79925.idtracker@ietfa.amsl.com>
Date: Wed, 18 Feb 2015 20:36:34 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/XNBIhYFchPTvmstMTm9lOPFWptg>
Cc: morrowc@ops-netman.net, idr@ietf.org, draft-ietf-idr-as-migration.all@ietf.org, idr-chairs@ietf.org
Subject: [Idr] Pete Resnick's Discuss on draft-ietf-idr-as-migration-03: (with DISCUSS and COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 19 Feb 2015 04:36:36 -0000

Pete Resnick has entered the following ballot position for
draft-ietf-idr-as-migration-03: 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 http://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:


A procedural DISCUSS, which I expect will be cleared on the call,
whatever the outcome:

RFC 2026 says this in section 5 regarding what a BCP is for:

   Historically Internet standards have generally been concerned with
   the technical specifications for hardware and software required for
   computer communication across interconnected networks.  However,
   since the Internet itself is composed of networks operated by a great
   variety of organizations, with diverse goals and rules, good user
   service requires that the operators and administrators of the
   Internet follow some common guidelines for policies and operations.
   While these guidelines are generally different in scope and style
   from protocol standards, their establishment needs a similar process
   for consensus building.

That sounds like exactly what this document is doing. Sounds like it
should be a BCP. Is there a reason it shouldn't be?


I tend to agree with Alissa's distaste for the style of the second
paragraph in section 1. This is a technical document, so I don't see the
need to get into the details of how the technology impacts business. I'm
sure the people driving the decision to use this document will be fully
aware of the business consequences, so no need to really go into them
here. Here's a suggestion by way of toning it down:

   The migration features discussed here are useful to ISPs and
   organizations of all sizes, but they are critical for ISPs'
   operations when it is necessary to seamlessly migrate both internal
   and external BGP speakers from one ASN to a second ASN, such as
   during a merger, acquisition or divestiture involving two
   organizations.  The overall goal in doing so is to simplify
   operations through consistent configurations across all BGP speakers
   in the combined network.  In addition, ISPs find it critical to
   maintain utilization of their network resources by their customers. 
   Because the BGP Path Selection algorithm selects routes with the
   shortest AS_PATH attribute, an increase in AS_PATH length during or
   after ASN migration toward downstream transit customers or
   settlement-free peers would result in significant changes to traffic
   patterns and decreased utilization by those customers.