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