Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute
draft-ietf-idr-as-migration-06
Yes
(Alia Atlas)
No Objection
(Barry Leiba)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
(Terry Manderson)
Abstain
Note: This ballot was opened for revision 03 and is now closed.
Alia Atlas Former IESG member
Yes
Yes
(for -03)
Unknown
Alvaro Retana Former IESG member
Yes
Yes
(2015-09-09)
Unknown
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
Alissa Cooper Former IESG member
No Objection
No Objection
(2015-02-18 for -03)
Unknown
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.
Barry Leiba Former IESG member
No Objection
No Objection
(for -03)
Unknown
Ben Campbell Former IESG member
(was Discuss)
No Objection
No Objection
(2015-09-16)
Unknown
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 Former IESG member
No Objection
No Objection
(for -03)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(2015-02-17 for -03)
Unknown
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.
Deborah Brungard Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -03)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -03)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-02-17 for -03)
Unknown
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:"?
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -03)
Unknown
Pete Resnick Former IESG member
(was Discuss)
No Objection
No Objection
(2015-02-19 for -03)
Unknown
(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.
Richard Barnes Former IESG member
No Objection
No Objection
(for -03)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -03)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-02-18 for -03)
Unknown
In the security considerations, isn't there a threat of hijacking traffic (for whatever purpose) if an unauthorised party can migrate?
Ted Lemon Former IESG member
No Objection
No Objection
(2015-02-19 for -03)
Unknown
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 Former IESG member
No Objection
No Objection
()
Unknown
Adrian Farrel Former IESG member
Abstain
Abstain
(2015-02-19 for -03)
Unknown
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