Re: [Idr] AD review and progression of draft-ietf-idr-as-migration-03

["Alvaro Retana (aretana)" <[e-mail]>]

On 2/18/15, 5:35 PM, "Alia Atlas" <[e-mail]<mailto:[e-mail]>> wrote:

An updated version also addressing IESG comments would be good.

Wes:

Hi!

I’m not sure if my comments (below) made it to you — they were part of my “AD training” for the current review period. ;-)

I  know it’s too late to change the structure of the document, so feel free to ignore those comments.  However, I would really like to see something in the text about the risk of potential loops..and the references to rfc4271 updated/corrected.

Thanks!

Alvaro.



======

I found the text a little hard to read: long sentences, the paragraphs include several ideas, etc..  The language is obviously ok, just feels heavy and complex (more than it has to be).

What I think would have been nice is to describe the migration scenario and functionality independent of the existing feature names first..and then say “BTW, the cisco features that do this are xxx..for Juniper yyy, etc.”.   Talking about specific features creates expectations that further implementations will do the exact same thing (specially when config snippets are included): as in the functionality documented at the cisco site (for example).   I started thinking of this when reading 4.1, where Juniper’s ‘Internal BGP Alias’ is discussed, and then the authors wrote: "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.”..but the operation of dual-as and the differences are not discussed.

Other comments:

  *   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?
  *   Nit: "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.”  Not needed..this may of course change, etc..  The utilization point has been made.
  *   The use case Fig 1 and2, show customers C and D..but later, when explaining the features, CE-A and CE-B are used instead.  To make it easier to follow the same names would be nice.
  *   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).  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.
  *   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.
  *   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”.
  *   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..”.
  *   In 3.3 (last paragraph) the authors talk about the CLI implementation..  As they wrote: “..command syntax is an implementation detail beyond the scope of this document”.  Stay out of it.
  *   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.  Just to keep a logical flow..
  *   4.1: s/typically to PE devices/typically connected to PE devices