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

From: Shane Amante <[email-masked]>
Date: Mon, 1 Oct 2012 20:22:22 -0600

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" <[email-masked]> 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

---

From: Shane Amante <[email-masked]>
Date: Mon, 1 Oct 2012 20:32:18 -0600

Sandy,

Adding IDR to this response, as well.  Please see below.

On Sep 27, 2012, at 5:56 PM, "Murphy, Sandra" <[email-masked]> wrote:
> wrt:
> 
>>> 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?
>> [WEG] Not exactly no. There's no additional internal eBGP session between the 
>> two ASNs on the PE, and remember that the PE has been reconfigured to be in 
>> the retained AS, not the legacy one, so this local-as and its related switches are 
>> used on the PE-CE sessions and their associated updates, not PE-PE. All it's 
>> doing is overriding the values from the global config that would normally be 
>> used to populate "MY ASN" and "AS_PATH" when generating BGP messages 
>> to a specific neighbor.
> 
> 
> No, I did not mean to suggest that there was an actual ebgp session.  I think maybe I was reading the replace-as example incorrectly.  I am not sure what the AS_PATH is when it is transmitted between PE1 and PE2 and it looked like PE1 might be adding ASNs to the AS_PATH it sent over the ibgp session to PE2.

See my previous reply, but in short I believe that AS_PATH modifications are, in this case, most likely made at the eBGP neighbor (where these AS migration configurations are applied), since that isolates modifications/state/etc. wrt the AS_PATH attribute to a single eBGP neighbor.  Of course, implementors should weigh-in if that is incorrect.  :-)

>>> 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.
>> [WEG] I think you're right that it's a typo, I'll doublecheck with my co-author.
> <skip>
>>  message.  If the check determines this is not the case, the Error
>>  Subcode MUST be set to Malformed AS_PATH."
>> I don't know if most common implementations perform this check. In fact, 
>> that's why I point out that the question needs to be answered as far as path 
>> validation is concerned - does the ASN of the established neighborship have 
>> to match the AS_Path or PATH_signatures or does it not matter as long as the 
>> signatures are all valid? Does that MAY need to be a MUST in BGPSec land?
> 
> From http://www.cisco.com/en/US/docs/ios/12_3t/ip_route/command/reference/ip2_b1gt.html#wp1080615, "bgp enforce-first-as" default is enabled and it means
> To configure a router to deny an update received from an external BGP (eBGP) peer that does not list its autonomous system (AS) number at the beginning of the AS_PATH in the incoming update, use the bgp enforce-first-as command in router configuration mode.
> 
> I think this is already a MUST in the protocol because the protocol makes sure the AS listed are the ones that the packet came through.  If the update came from the neighbor and the first AS in the path is not the neighbor's AS, then the validation will fail.  (Unless the neighbor has the keys to two ASs and uses an AS other than is used in the OPEN packet.  It's all about the keys.)

WRT the above, "bgp enforce-first-as" ... as you pointed out there was a typo in Section 4, "Replace AS", of draft-ga-idr-as-migration-00.  The last paragraph of that section should read:
---snip--- 

And, in that case, even if/when the "bgp enforce-first-as" knob is enabled at the CE router, (CE-1 in the diagram in the draft), then the CE router is *still* going to receive AS 300 as the first AS in the AS_PATH, even after the ISP A' changes their PE router to enable 'replace-as'.  Thus, this should not conflict with the "bgp enforce-first-as" knob.  Apologies for the typo.  We'll fix in the next rev.

Thanks,

-shane