Hello, In the context of Routing Area QA reviews (see https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ), I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​ http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-idr-as-migration-02 < http://tools.ietf.org/html/draft-name-version > Reviewer: Thomas Morin Review Date: 2014-09-11 Intended Status: standards track *Summary:* I have some minor concerns about this document that I think should be resolved before publication. *Comments: * This is overall a very well written document, with a clear goal and concisely addressing its target goal.* * Although it is all about local behavior, it makes sense to make a standard track document that (a) can be used as a reference for implementors and deployers to implement this properly, and (b) keep track of these features in future evolutions of the protocol (as motivated in the Conclusion section of the document).* * *Major Issues:* No major issues found *Minor Issues: * A) The introduction says: In particular the ISP would have to encourage those customers to change their CE router configs to use the new ASN in a very short period of time, when the customer has no business incentive to do so. Thus, it becomes critical to allow the ISP to make this process a bit more asymmetric, so that it could seamlessly migrate the ASN within its network(s), but not disturb existing customers, and allow the customers to gradually migrate to the ISP's new ASN at their leisure. However, I did not understand which part of the specs would allow the customer to change its CE configuration without coordinating a maintenance window with the ISP. Procedures in section 3, as described, won't let the customer CE connect to the router with the new ASN. See, in particular in the second § of section 3.3: "The speaker MUST NOT use the ASN configured globally within the BGP process as the value sent in MY ASN in the OPEN message. ". It seems that the goal specified in the intro will thus not be met fully. Two things would be possible: fixing the intro to state a slightly different goal, or change the procedures to let a router establish a session with the globally assigned new AS, even when 'local-as old-AS" is configured. I'm not expert enough to know if the latter would work. B) still about the intro: it seems that this intro is focused on the motivation for eBGP-related features described in section 3, but silent on iBGP and section 4 C) in section 3, second §, there is a discussion about changing the AS_PATH length ; it seems to me that there is a hidden assumption on what interconnection exist between ISP A and ISP B prior to the migration ; the text says "whereas the same RIB on ISP A' would contain AS_PATH: 64510 64496, which is an increase in AS_PATH length from previously" which seems to indicate that ISP A and ISP B are peering with each other. If this is correct, this should be stated clearly in section 2, and not be a hidden assumption. D) in section 3: " Thus, within Loc-RIB on ISP B' the AS_PATH toward customer C would appear as: 64510". I would have thought that the AS_PATH of routes learned by PE routers of ISP B in this situation (if local-as no-prepend is not used), would be "64496" or "64510 64496" rather than "64510" alone... but I could just be wrong. E) In section 2, third paragraph: First, ISP B, will change the global BGP ASN used by a PE router, from ASN 64510 to 64500. At this point, the router will no longer be able to establish eBGP sessions toward the existing CE devices that are attached to it and still using AS 64510. Second, ISP B will configure two separate, but related ASN migration features discussed in this document on all eBGP sessions toward all CE devices. These features modify the AS_PATH attribute received from a CE device when advertising it further, and modify AS_PATH when transmitted toward CE devices to achieve the desired effect of not increasing the length of the AS_PATH. This high level description of the procedures in 3 is I think missing a description of the fact that, among the features of step 2 there is also a feature, not related to fixing the as path, that aims at allowing BGP sessions to be established using ASN 64510. I would suggest rewriting the last sentence as: These features allow the establishment of sessions with the legacy ASN 64510, modify the AS_PATH attribute received from a CE device when advertising it further, and modify AS_PATH when transmitted toward CE devices to achieve the desired effect of not increasing the length of the AS_PATH. F) section 3.1: it would be worth mentioning it explicitly, at the end of the first paragraph, that alone, this change results in an interruption of service G) the naming given to ASs and routers along the document**could I think be largely improved to make the document easier to read. I would suggest the following: * In the figures 3 and 4 of section 3.1 and 3.2: invert the figure left-right to have AS64499 on the left like in figures 1 and 2 * In the figures 3 and 4 of section 3.1 and 3.2, and associated text: instead of naming the PEs and CEs with 1 and 2, name them with A and B to match the ISP they are into (PE-A,CE-A,PE-B,CE-B instead of PE-2,CE-2,PE-1,CE-1) * modify figures 1 and 2 to make PE-A,CE-A,PE-B,CE-B appear on the figures * preferring "ISP A PE routers" to "ISP A's PE routers" to increase readability, or just "PE-A" or "PE-B" which is even shorter and less confusing (as an illustration section 3.2 says "Specifically, with 'Local AS No Prepend' enabled on ISP A's PE-1, it automatically causes..." , but does it mean "ISP A PE-1" or "ISP A' PE-1"...? given that PE-1 is actually in ISP B (==ISP A'), this is probably the second which is true, but here incorrectly written as "ISP A's PE-1"...) * section 3.1 mentions ISP B' ("within Loc-RIB on ISP B' the AS_PATH toward...") , but what ISP B' can only be guessed, you may want to define it in section 2(the set of routers in ISP B after the AS migration) H) section 3.2 says "Instead, only the historical (or legacy) AS will be prepended in the outbound BGP UPDATE toward customer's network, restoring the AS_PATH length to what it what was before AS Migration occurred." ; I would suggest adding ", as configured with the 'Local AS' feature described in section 3.1," before "will be prepended" I) I know the 'PE'/'CE' terminology to be widely used in the context of BPG-based VPNs, but, unless it is also widely used for non-VPN use cases, I would think that defining these terms would make sense (I don't know these terms to be widely used outside VPN use cases, but well, they might be in which case nothing is needed) J) the last § of section 3.1 looks to me as very much redundant to what is said in the rest of the section K) section 4.1 "NB: Cisco doesn't have an exact equivalent to "Internal BGP Alias", but the combination of the Cisco features iBGP local-AS and dual-as provides similar functionality." -- This sentence would be better-placed in section 10, IMO. L) section 4.1, itemized list, item 4: a reference to section 3 would be nice M) section 10: it would be interesting to indicate, for each vendor, what are the feature names corresponding to what is described in sections 3.1, 3.2 and 4 *Nits:* - In the abstract: s/feaures/features/ - In the abstract: the title would be more readable without "(AS)"; introducing this acronym, along with "ASN" can be done for instance in the introduction - in 3.1: "ISP B needs to do this without coordinating the change of its ASN with all of its eBGP peers, simultaneously." is not very easy to read (maybe "ISP B needs to be able to do this without coordinating a simultaneous change... peers" would be better?) - in 3.1: "Within the context of ISP B's PE router, The second effect ..." -> s/The/the/ Best, -Thomas