Re: [Idr] [sidr] comments on recent as migration drafts (draft-ga-idr-as-migration-00)

[Shane Amante <[e-mail]>]

Sandy,

Adding IDR to response, since draft-ga-idr-as-migration-00 was submitted to IDR.  Trimming down to parts only relevant to draft-ga-idr-as-migration-00.  Please see below.

On Sep 27, 2012, at 7:40 AM, "Murphy, Sandra" <[e-mail]> wrote:
> Speaking as regular ol' member.
> 
> Some comments about these drafts.

[--snip--]

> In the idr-as-migration draft, from the discussion it appears that the implementation of the local-as feature on the PE router in AS supports the local-as as something like an ebgp session inside the router.  (like it adds the old 300 ASN on AS_PATHs sent over ibgp sessions to AS 200 neighbors).  Am I understanding the examples correctly?

I believe you are referring to Section 3, "Local AS".  You are correct.

Obviously, the implementers would have an authoritative answer to your question, but I believe that the legacy ASN (AS 300) is actually applied before the Adj-RIB-In.

One important point to keep in mind is that the same PE will also have eBGP sessions with other eBGP neighbors, (which may or may not be using these AS migration features _outbound_).  Thus, the easiest thing to implement would be tacking on the legacy AS as the eBGP route is learned and before it hits the Adj-RIB-In.  This way, if it's selected as a best-path, BGP can easily propagate that route "as-is" towards both iBGP and other eBGP neighbors.


> The goal is for the AS_PATH length to be the same length in the migration interval as it was before migration.  Does it matter if that effect is accomplished some other way than the knobs currently implemented?  IE the local-as knob has a side effect of getting the 300 ASN into the AS_PATH to ibgp neighbors so the second knob no-prepend makes that go away.  Do you need both behaviors -- local-as AND local-as + no-prepend?

Yes.  Perhaps there is some confusion in the current draft talking about the two knobs independently?  In reality, the *only* behavior we want is achieved through the combination of both local-as + no-prepend, in Cisco IOS.  If it makes you feel any better, JUNOS makes you also configure two, separate (but related) knobs to get this behavior: "local-as private", in the case of inbound eBGP updates.  :-)


> Would it be OK if the side effect did not happen and you got to the no-increase-in-path-length goal without needing the no-prepend knob?

That's not possible.  IOW, the only way to achieve the "no-increase-in-path-length goal" is to enable "no-prepend" in IOS or "private" in JUNOS.  I suspect that vendors (and, operators) will not be clamoring to change the existing configuration of AS migration features this late in the game, i.e.: to just configure them more simply with just one keyword in the CLI ...


> wrt the replace-as technique.  The text says that "only the historical (or, legacy) AS will be prepended in the outbound BGP UPDATE toward the customer's network".  But the example says "After ISP A' changes PE-1 to include the "Replace AS" feature, CE-1 would receive an AS_PATH of: 200 400. " That is indeed "the same AS_PATH length pre-AS migration" as the text says, which accomplishes that goal, but it would require configuration of the CE router to accept a first-as that was different from the one used in the OPEN.  I suspect that's a typo, that is after using replace-as the AS_PATH toward the CE would be "300 400".  But it is an important point so I'd like to make sure.

You are correct, that is a typo.  Thank you for finding that.  We will fix the text to be as follows in the next rev of the draft:
---snip---
   By default, without "Replace AS" enabled, CE-1 would see an AS_PATH
   of: 300 200 400, which is artificially lengthened by the ASN
   Migration.  After ISP A' changes PE-1 to include the "Replace AS"
   feature, CE-1 would receive an AS_PATH of: 300 400, which is the same
   AS_PATH length pre-AS migration.
---snip---

Thanks for your review.

-shane