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

Sue Hares <> Thu, 19 February 2015 13:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 991631A87BC; Thu, 19 Feb 2015 05:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.399
X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, USER_IN_WHITELIST=-100] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jN4honUWy72n; Thu, 19 Feb 2015 05:06:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C008E1A9041; Thu, 19 Feb 2015 05:06:02 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
Date: Thu, 19 Feb 2015 08:09:03 -0500
Message-ID: <>
Importance: normal
From: Sue Hares <>
To: Pete Resnick <>, The IESG <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=""
Archived-At: <>
Subject: Re: [Idr] Pete Resnick's Discuss on draft-ietf-idr-as-migration-03: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Feb 2015 13:06:06 -0000


We debated  the bgp versus the rfc.  The problem is that these behavior change the fundamental assumptions  that bgp in away that impacts sidr.  When we first finally take time to revise the bgp specification (rfc4271) to update it to current status if we miss this draft then we will have a whole I'm the new decision tree algorithm.  This is important for the data center, mobile backhaul networks, and carrier networks.  Due to this fact we decided that bcp did not fit the case.  


Sent via the Samsung GALAXY S®4, an AT&T 4G LTE smartphone

<div>-------- Original message --------</div><div>From: Pete Resnick <> </div><div>Date:02/18/2015  11:36 PM  (GMT-05:00) </div><div>To: The IESG <> </div><div>Cc:,,, </div><div>Subject: Pete Resnick's Discuss on draft-ietf-idr-as-migration-03: (with
  DISCUSS and COMMENT) </div><div>
</div>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
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.