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

["Susan Hares" <[e-mail]>]

Alvaro and Adrian: 

It's nice to have you chime in on this draft.  As IDR chair, may I ask we remove the draft from the IESG agenda today.  I'll need some unpacking of your reasoning. 

Are you looking for a major rewrite of this draft or to scrap this effort?  

If you are looking to scrap the effort, I need additional details on why.  It has been discussed by SIDR, Grow and IDR to be valuable for the BGP deployments. This draft provides reasoning for the SIDR work on AS migration.  Your reasoning is that the "mechanism that BGP implementation can use to provide the behavior" below .. seems to suggest it should not be documented.  New BGP implementations are arising in DC, Mobile backend networks, and Carriers that utilize these features so interoperable features are necessary. 

If you are looking for a complete rewrite, I'm happy to work with you, Alvaro, Alia and the authors to find a new acceptable form of the draft(s). 

My understanding is that you want to split to:

Informational Draft: 
- Requirements for and circumstances of AS migration, 
- Behavior needed from a BGP system when migrating AS numbers, 

Mechanism (RFC) 
- Mechanisms that a BGP implementation can use to provide the
  Behavior [mechanism in RFC] 
- Description of the mechanisms and configuration options contained in
  specific implementations [mechanism draft appendix, non-normative]  

If this is your desire, I will be happy to take this back to the authors and the WG to create this draft. 

Sue  

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Thursday, February 19, 2015 9:26 AM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Adrian Farrel's Abstain on draft-ietf-idr-as-migration-03: (with COMMENT)

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