Re: [Idr] 2 Week WG LC on draft-ietf-idr-as-migration (4/9 to 4/23/2105

[Jeffrey Haas <[e-mail]>]

Alvaro,

On Mon, Apr 13, 2015 at 08:50:40PM +0000, Alvaro Retana (aretana) wrote:
> I do have one item that I think may be above ?minor?: when using ?Local AS?, when should the ASN be prepended?  When sending eBGP-received UPDATEs to iBGP neighbors (as it is specified currently), OR, then receiving those eBGP UPDATEs?  If it is not done when receiving, then the AS_PATH will be inconsistent in the AS (the border router will have a shorter AS_PATH).  I think this can lead to inconsistent route selection (given that the attributes are inconsistent inside the AS), but that of course may be mitigated by the fact that the application of Local AS may be towards stub networks in many (but not all) cases.   I would really like to hear others? (beyond the authors) opinions.  [My comments #3 and #7 in the Minor section below are related to this.]

Obviously there's a long standing history with both variations on the
feature along with a number of related but poorly (if ever) documented
behaviors to worry about.  A few here:

RFC 4271, 5.1.2 notes we don't modify the AS_PATH on advertisement to an
internal peer.  Obviously implementations do that, semantic quibbling about
doing it as part of modification of a route in adj-rib-in/loc-rib vs.
adj-rib-out aside.  Mostly a note of historical significance rather than
saying "we shouldn't do that".

Somewhat more relevant is in section 9.1.2:

:   If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
:   route should be excluded from the Phase 2 decision function.  AS loop
:   detection is done by scanning the full AS path (as specified in the
:   AS_PATH attribute), and checking that the autonomous system number of
:   the local system does not appear in the AS path.  Operations of a BGP
:   speaker that is configured to accept routes with its own autonomous
:   system number in the AS path are outside the scope of this document.

That last sentence was provided to provide the little documentation
implementations had at the time on local-as.  What is not stated is the
somewhat problematic issue of the above paragraph.

The issue has to do with where an implementation does its loop detection.
Some implementations do loop detection at every BGP speaker.  Some do them
only at an ebgp edge.  Some bias this behavior based on local-as being
enabled or not.  How you do your loop detection and when heavily biases your
choice of implementation.  In implementations that only requires local-as at
your ebgp edges but do loop detection at route reflectors/external confederation
routers, adding your local-as as part of import is a problem.

So, consistency isn't only a big deal as part of when/where you do your
local-as prepend, it's also a matter of where you do loop detection.  If
implementations in the absence of some "outside the scope" implementation
were to pedantically implement the base BGP RFC, the migration mechanisms
would be a bit biased to a given solution.

-- Jeff