[Idr] Adrian Farrel's Abstain on draft-ietf-idr-as-migration-03: (with COMMENT)

["Adrian Farrel" <[e-mail]>]

Adrian Farrel has entered the following ballot position for
draft-ietf-idr-as-migration-03: Abstain

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:
http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/



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