Skip to main content

Early Review of draft-ietf-idr-as-migration-02

Request Review of draft-ietf-idr-as-migration
Requested revision No specific revision (document currently at 06)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2014-09-15
Requested 2014-08-29
Authors Wesley George , Shane Amante
I-D last updated 2014-09-15
Completed reviews Secdir Last Call review of -03 by Paul Wouters (diff)
Rtgdir Early review of -02 by Thomas Morin (diff)
Rtgdir Early review of -05 by Thomas Morin (diff)
Assignment Reviewer Thomas Morin
State Completed
Request Early review on draft-ietf-idr-as-migration by Routing Area Directorate Assigned
Reviewed revision 02 (document currently at 06)
Result Has issues
Completed 2014-09-15

In the context of Routing Area QA reviews (see

 ), 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 ​

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 



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.


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.

   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 


* 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 


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


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