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

[Alia Atlas <[e-mail]>]

Hi Sue,



On Thu, Feb 19, 2015 at 9:48 AM, Susan Hares <[e-mail]> wrote:

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

I have removed it from today's telechat.


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

I would like to see a major rewrite - though not as strongly as Alvaro and
Adrian feel.



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

I'm far from convinced that it needs to be two drafts.  I would like to see
it more clearly divided into
clear requirements, specific required behavior, and leaving out the vendor
specifics (in an appendix
if truly necessary).

Regards,
Alia

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