Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute
RFC 7705

Note: This ballot was opened for revision 03 and is now closed.

(Alia Atlas) Yes

Alvaro Retana Yes

Comment (2015-09-09)
No email
send info
To the IESG:

This document was initially considered by the IESG as version -03 (in Feb/15), but was returned to the WG to avoid it sounding like marketing material and to be precise about what is being specified.  I believe the authors have done a very good job!

(Jari Arkko) No Objection

(Richard Barnes) No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2015-09-16)
No email
send info
I've cleared my discuss position on the following. I will leave it as a comment for reference purposes:

I am confused at the purpose of this draft. The introduction says "This draft discusses some existing commonly-used BGP mechanisms" and "The deployment of these mechanisms do not need to interwork with one another to accomplish the desired results" These words suggest an informational RFC, or maybe a BCP.

On the other hand, the draft is labeled as standards track, and updates 4271 (I assume due to Brian's previous comments). Sections 3.3 and 4.2 make heavy use of 2119 keywords in a way that sounds like it is defining a standard (although I question whether these keywords in general impact interoperability per se.)

So, I think there is a misalignment. If the intent is indeed to define a standard, then I suggest the abstract and first paragraph of introduction be rewritten to align with that. If not, then it shouldn't be standards track nor update 4271.

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2015-02-18 for -03)
No email
send info
Section 9:
"This could result in a
   loss of revenue if the ISP is billing based on measured utilization
   of traffic sent to/from entities attached to its network."

Considering loss of revenue in and of itself to be a security issue is a slippery slope that we should probably not start to descend. I held my nose for the revenue-related text in Section 1, but here in Section 9 it seems particularly ill-advised.

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-02-18 for -03)
No email
send info

In the security considerations, isn't there a threat of
hijacking traffic (for whatever purpose) if an
unauthorised party can migrate?

(Brian Haberman) No Objection

Comment (2015-02-17 for -03)
No email
send info
Just one comment/question on this draft.  It would seem logical to me for this document to update 4271.  It seems like we want anyone implementing BGP4 to also implement this specification as well.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

Comment (2015-02-19 for -03)
No email
send info
I would have raised the same DISCUSS Pete did, but since he raised it I'll no object and let his DISCUSS be where the DISCUSSion happens.

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-02-17 for -03)
No email
send info
It seems like a good idea to document these features.  I found a couple of nits you might want to fix:

ASN is first expanded in section 1.2.  Although it is a well known acronym, you might want to expand it on first use instead.

Section 4.1. what is "NB:"?

(Pete Resnick) (was Discuss) No Objection

Comment (2015-02-19 for -03)
No email
send info
(Moving my DISCUSS to a comment so I don't have see new version notifications while the WG works on this.)

- 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.

(Martin Stiemerling) No Objection

(Adrian Farrel) Abstain

Comment (2015-02-19 for -03)
No email
send info
I cannot support the publication of this document in its current form.
My issues could possibly be resolved, but I do not think that minor
edits would be enough, and I suspect that after the work to produce 
the document and considering WG and IETF consensus, there will be 
enthusiasm to start again. resolving my concerns would, I think,
require the document to return to the working group.

Since I do not feel strongly enough that this document MUST NOT be
published in this form, I will not use my Discuss to insist on 

The notes below are provided to help you understand my reasoning and,
if you are minded to agree with me, to help you think about how to 
update the document.

(Some of the nits come from a "training review" done by Alvaro.)

The documentseems to address four topics:
- Requirements for and circumstances of AS migration
- Behavior needed from a BGP system when migrating AS numbers
- Mechanisms that a BGP implementation can use to provide the
- Description of the mechanisms and configuration options contained in
  specific implementations

As Alvaro wrote:

> o The Introduction is very tentative about the purpose: it wants to
> document de facto standards for future implementations and so
> that new features (BGPSec) take them into consideration..but it is
> not expecting all implementation to follow exactly (at least not the
> existing ones).  My question is: should this be Informational instead
> of Standard?

I would say that the first two bullets are classic descriptive 
requirements text. They are good to publish as Informational.

The third bullet is somewhat suspect. Maybe it is an advisory appendix,
but the list of ways to provide the function is unbounded and there is
no requirement for interoperability. I am not sure that publshing this
information is a great benefit. Maybe it is not harmful although it 
might tend to reduce innovation and give vendors and operators
expectations about mechanisms that should be used within

I find the final bullet very suspect. It goes beyond an implementation
report and enters into the world of sales. While the document makes no
explicit analysis of the pros and cons of the different implementations,
described, there is a lot between the lines. Furthermore, by not
documenting the mechanisms in other implementations, the document gives
the false impression that the three implementations described are the
benchmark for AS migration. It might be possible to move this material 
to an appendix or a separate implementation document, but as the authors
note, much or all of the information can be found on the websites of the
companies concerned, and I think that is where it should stay.

[Please note that twice, while typing this, I wrote "AD migration". That
may be a better solution to all of our problems!]

Here are the minor comments and nits...

o "ISPs bill customers based on the 95th percentile of the greater
  of the traffic sent or received, over the course of a 1-month
  period, on the customer's access circuit."  
  This information is not needed and may change at any time after the
  publication of this document. You have made the point about
  utilization: you can drop this text.

o The use case figres, Fig 1 and 2, show customers C and D. When
  explaining the features, CE-A and CE-B are used instead.  
  It would make it easier to follow if the same names were used.

o Potential loops!  Using "local-as no-prepend replace-as" results in 
  eliminating an ASN from the AS_PATH (in the example, the Old_ADN
  64510 is eliminated). If other routers in ISP B have not been migrated
  yet (very real possibility) then they may accept Updates that already
  went through their ASN (64510) resulting in potential loops.
  To be fair, the text suggests that ISP B has been migrated to the
  New_ASN before applying the "local-as no-prepend replace-as" config,
  but I think that it would be important to describe the potential 
  risk of using this feature - either as an Operational Consideration
  or in the Security section.

o The text uses "MY ASN" to indicate the ASN number in the BGP
  Open Message.  However, (1) there is no reference to rfc4271 so that
  the reader understand what they're talking about, and (2) the field in
  the Open message is called "My Autonomous System" (not MY ASN).
  This shows up in 3.3 and 4.2.

o Also in 3.3 (and 4.2), the Error Message "BAD PEER AS" is mentioned..
  Again, no reference and wrong name.  The name used in rfc4271 is
 "Bad Peer AS".  

o Other rfc4271 related nits..  The draft talks about "updates", but the
  official name is "UPDATE".  Yes, maybe OCD, but I think it is 
  important to be clear about what is being specified.  
  In some cases the use is mixed: " MUST process the update as
  normal, but it MUST append the configured ASN in the AS_PATH attribute
  before advertising the UPDATE".

o In 3.3 (last paragraph) the authors talk about the CLI implementation.

   While the exact command syntax is an implementation detail beyond the
   scope of this document, the following consideration may be helpful
   for implementers

  Suggest to stay out of this completely. It is nested "may" and that 
  really calls its value into question.

o Because the external features (Section 3) assumes that the AS being
  migrated is already using the New_ASN before using local-as, I would
  like to see the internal features (Section 4) be discussed first in 
  the text to keep a logical flow.

o 4.1: s/typically to PE devices/typically connected to PE devices