Early Review of draft-ietf-idr-as-migration-02
review-ietf-idr-as-migration-02-rtgdir-early-morin-2014-09-15-00

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