Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute
draft-ietf-idr-as-migration-06

[Ballot comment]
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.

[Ballot discuss]
Hopefully this is easy to resolve:

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.

[Ballot comment]
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!

https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-as-migration-03&url2=draft-ietf-idr-as-migration-06

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-idr-as-migration-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Autonomous System Migration Mechanisms and Their Effects on the BGP
  AS_PATH Attribute'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-09-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This draft discusses some existing commonly-used BGP mechanisms for
  ASN migration that are not formally part of the BGP4 protocol
  specification.  It is necessary to document these de facto standards
  to ensure that they are properly supported in future BGP protocol
  work.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ballot/


No IPR declarations have been submitted directly on this I-D.

Status: Proposed standard
Shepherd: Susan Hares
AD: Alvaro Retano

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This draft discusses some BGP features for ASN migration that, while
  commonly used, are not formally part of the BGP4 protocol
  specification and may be vendor-specific in exact implementation.  It
  is necessary to document these de facto standards to ensure that they
  are properly supported in future BGP protocol work such as BGPSec.

Working Group Summary

  There was no WG process to note.  Good Working Group Consensus occurred during WG Review.

Document Quality

This is not a protocol, but configuration and implementation details being codified for
  future implementers to be aware of, so operations of networks can continue. The
  document outlines processes and procedures which are used today in networks,
  most vendors implement a set of this document's features.

Personnel
Document Shepherd-1: Chris Morrow  (Grow)
Document Shepherd-2:  Susan Hares (IDR)
AD: Alvaro Retano


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Susan Hares and Chris Morrow both read this document (a few times now) and believe the document is ready for publication. Folk in the working group seem to agree, and the partner document in IDR (draft-ietf-idr-as-migration-03) is moving forward at this time as well.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

The document shepherd does not harbor any concerns about this document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

We believe the parts of this document which require specialized review have been reviewed. That review was done by IDR folk during the working group work on that document as well.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 

Nothing to be concerned about with this revision.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG consensus appears to be solid for this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There are no threats at this time.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

NITS turned up the following:
  " The draft header indicates that this document updates RFC4271, but the
    abstract doesn't seem to mention this, which it should."

- Alvaro suggests this can be updated in the next revision.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

There are not normative references to unfinished documents.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Updates RFC4271 is marked on draft.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

I reviewed the IANA considerations section in this document, there are no considerations for IANA here.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

Status: Proposed standard
Shepherd: Susan Hares
AD: Alvaro Retano

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This draft discusses some BGP features for ASN migration that, while
  commonly used, are not formally part of the BGP4 protocol
  specification and may be vendor-specific in exact implementation.  It
  is necessary to document these de facto standards to ensure that they
  are properly supported in future BGP protocol work such as BGPSec.

Working Group Summary

  There was no WG process to note.  Good Working Group Consensus occurred during WG Review.

Document Quality

This is not a protocol, but configuration and implementation details being codified for
  future implementers to be aware of, so operations of networks can continue. The
  document outlines processes and procedures which are used today in networks,
  most vendors implement a set of this document's features.

Personnel
Document Shepherd-1: Chris Morrow  (Grow)
Document Shepherd-2:  Susan Hares (IDR)
AD: Alvaro Retano


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Susan Hares and Chris Morrow both read this document (a few times now) and believe the document is ready for publication. Folk in the working group seem to agree, and the partner document in IDR (draft-ietf-idr-as-migration-03) is moving forward at this time as well.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

The document shepherd does not harbor any concerns about this document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

We believe the parts of this document which require specialized review have been reviewed. That review was done by IDR folk during the working group work on that document as well.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 

Nothing to be concerned about with this revision.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG consensus appears to be solid for this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There are no threats at this time.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

NITS turned up the following:
  " The draft header indicates that this document updates RFC4271, but the
    abstract doesn't seem to mention this, which it should."

- Alvaro suggests this can be updated in the next revision.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

There are not normative references to unfinished documents.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Updates RFC4271 is marked on draft.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

I reviewed the IANA considerations section in this document, there are no considerations for IANA here.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

status: Proposed RFC
Shepherd: Susan Hares

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This draft discusses some BGP features for ASN migration that, while
  commonly used, are not formally part of the BGP4 protocol
  specification and may be vendor-specific in exact implementation.  It
  is necessary to document these de facto standards to ensure that they
  are properly supported in future BGP protocol work such as BGPSec.

Working Group Summary

  There was no WG process to note.  Good Working Group Consensus occurred during WG Review.

Document Quality

This is not a protocol, but configuration and implementation details being codified for
  future implementers to be aware of, so operations of networks can continue. The
  document outlines processes and procedures which are used today in networks,
  most vendors implement a set of this document's features.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document Shepherd: Chris Morrow (1st revision),
Document Shepherd:  Susan Hares (2nd revision)
AD: Alvaro Retano


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I read the document (a few times now) and believe the document is ready for publication. Folk in the working group seem to agree, and the partner document in IDR (draft-ietf-idr-as-migration-03) is moving forward at this time as well.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

The document shepherd does not harbor any concerns about this document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

I believe the parts of this document which require specialized review have been reviewed. That review was done by IDR folk during the working group work on that document as well.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I'm not concerned about this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG consensus appears to be solid for this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There are no threats at this time.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The idnits process turned up:
  An old date (30 days ago).
  1 downref to RFC5398 (which seems ok in this case)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

There are not normative references to unfinished documents.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

RFC5398 is referenced in this document, because AS numbers are used in the document, numbers which are from the reserved AS number space. Noting that the numbers used in this document are private/reserved seems to be on point, and the references seem to be relevant to the flow and intent of the document.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

I reviewed the IANA considerations section in this document, there are no considerations for IANA here.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

[Ballot comment]
(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:

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

[Ballot comment]
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
changes.

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

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: "..it 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

[Ballot comment]
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.

[Ballot discuss]
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?

[Ballot comment]
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:

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

[Ballot comment]
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.

[Ballot comment]
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:"?

[Ballot comment]
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.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-idr-as-migration-03, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Autonomous System Migration Features and Their Effects on the BGP AS_PATH Attribute) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Autonomous System Migration Features and Their Effects on the BGP
  AS_PATH Attribute'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-02-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This draft discusses some BGP features for ASN migration that, while
  commonly used, are not formally part of the BGP4 protocol
  specification and may be vendor-specific in exact implementation.  It
  is necessary to document these de facto standards to ensure that they
  are properly supported in future BGP protocol work such as BGPSec.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This draft discusses some BGP features for ASN migration that, while
  commonly used, are not formally part of the BGP4 protocol
  specification and may be vendor-specific in exact implementation.  It
  is necessary to document these de facto standards to ensure that they
  are properly supported in future BGP protocol work such as BGPSec.

Working Group Summary

  There was no WG process to note.  Good Working Group Consensus occurred during WG Review.

Document Quality

This is not a protocol, but configuration and implementation details being codified for
  future implementers to be aware of, so operations of networks can continue. The
  document outlines processes and procedures which are used today in networks,
  most vendors implement a set of this document's features.
Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document Shepherd: Chris Morrow
AD: Alia Atlas

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I read the document (a few times now) and believe the document is ready for publication. Folk in the working group seem to agree, and the partner document in IDR (draft-ietf-idr-as-migration-03) is moving forward at this time as well.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

The document shepherd does not harbor any concerns about this document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

I believe the parts of this document which require specialized review have been reviewed. That review was done by IDR folk during the working group work on that document as well.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I'm not concerned about this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG consensus appears to be solid for this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There are no threats at this time.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The idnits process turned up:
  An old date (30 days ago).
  1 downref to RFC5398 (which seems ok in this case)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

There are not normative references to unfinished documents.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

RFC5398 is referenced in this document, because AS numbers are used in the document, numbers which are from the reserved AS number space. Noting that the numbers used in this document are private/reserved seems to be on point, and the references seem to be relevant to the flow and intent of the document.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

I reviewed the IANA considerations section in this document, there are no considerations for IANA here.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A