I'm trying to understand the problem being solved by the Cisco private AS removal feature. In particular, what advantages does it offer over confederations, which would seem to do the same thing when externally advertising customer routes? Is there a performance benefit? RFC1998-style multihoming with a private AS is a possible application, I suppose, for any routes that are NOT marked with NO-EXPORT.
I'm not sure I am looking at this the right way, but: It seems similar to confederations, but I'm not sure the stripping method is adequate for becoming a transit AS. I'm guessing that this was designed for something much simplier. The only method I could see, is that a customer is multihomed to the same AS. The customer would not likely be able to obtain a AS from ARIN since they are fall under the same routing policy. The provider could strip the fake AS, and announce the prefix with their AS. Example: --------- | AS | | 64750 | --------- / \ / \ / \ -------- -------- | AS X | | AS X | |Site A| |Site B| -------- -------- \ / \ / \ / \ / ---------- | The | |Internet| ---------- AS 64750 announces <64750> up to AS X, AS x uses it to determine routing policy. At the edge, AS X will strip it and announce just <X> to the Internet as a whole. AS 64750 would have some control over how the traffic would enter their network. This also gives them the mechinism for failover. I've used this method before, but not in the same exact way. In that method, it was a smaller part of a CIDR allocation, so they were aggregated into a larger block at the edge. No reason for the Internet to know about the topology when its all the same AS anyway. So, this is only really useful if the customer has their own blocks. For cisco to support it...someone has to be using this feature... (tm) "Howard C. Berkowitz" <hcb@clark.net> wrote
I'm trying to understand the problem being solved by the Cisco private AS removal feature. In particular, what advantages does it offer over confederations, which would seem to do the same thing when externally advertising customer routes? Is there a performance benefit?
RFC1998-style multihoming with a private AS is a possible application, I suppose, for any routes that are NOT marked with NO-EXPORT.
I'm not sure I am looking at this the right way, but:
It seems similar to confederations, but I'm not sure the stripping method is adequate for becoming a transit AS.
I'm guessing that this was designed for something much simplier.
The only method I could see, is that a customer is multihomed to the same AS. The customer would not likely be able to obtain a AS from ARIN since they are fall under the same routing policy. The provider could strip the fake AS, and announce the prefix with their AS.
RFC1998 which assumes that AS 64750 is using address space delegated to AS X, so that the AS 64750 addresses won't be explicitly advertised, but only as part of the aggregate announced by AS X. The AS 64750 routes should be marked with the NO-EXPORT community just to make things sure. As you suggest, the only reason I can see to do it is if AS 64750 had provider independent address space, then I could see (ignoring any effects on aggregation policy), a reason for AS X to advertise the PI routes.
AS 64750 announces <64750> up to AS X, AS x uses it to determine routing policy. At the edge, AS X will strip it and announce just <X> to the Internet as a whole.
AS 64750 would have some control over how the traffic would enter their network. This also gives them the mechinism for failover.
I've used this method before, but not in the same exact way. In that method, it was a smaller part of a CIDR allocation, so they were aggregated into a larger block at the edge. No reason for the Internet to know about the topology when its all the same AS anyway.
So, this is only really useful if the customer has their own blocks.
For cisco to support it...someone has to be using this feature...
Not to be flying a false flag here, I'm trying to decide if we should support this feature on Nortel Versalar routers. So far, I haven't seen a reason for supporting this in addition to confederations, but I've been wrong before. A greater area of concern is managing private AS numbers given widespread deployment of RFC 2547 VPNs, with the CE routers talking BGP to the PE routers. For a large provider, 1K isn't a lot of AS number space. I'm inclined to believe that scalability will require there must be a hierarchy of private AS numbers, essentially reserving some as aggregates.
(tm)
"Howard C. Berkowitz" <hcb@clark.net> wrote
I'm trying to understand the problem being solved by the Cisco private AS removal feature. In particular, what advantages does it offer over confederations, which would seem to do the same thing when externally advertising customer routes? Is there a performance benefit?
RFC1998-style multihoming with a private AS is a possible application, I suppose, for any routes that are NOT marked with NO-EXPORT.
I believe you can configure the Versalar router to perform this function. Just setup the announce policy to not use BGP routes as a possible route source, so that it will not check to see if an AS_path already exists. Then use advertise lists on the policy to announce the route even if its in the routing table or not. The NLRI to the customer should not matter, since you are the only route in. I've used this to avoid an AS set sneaking into our announcement when someone bleeds more specific routes out on the Internet. Considering how many unique designs there are out there, someone probably wants this. I don't mean to take the vendor specific route...but this info might be useful... (tm) "Howard C. Berkowitz" <hcb@clark.net> wrote
Not to be flying a false flag here, I'm trying to decide if we should support this feature on Nortel Versalar routers. So far, I haven't seen a reason for supporting this in addition to confederations, but I've been wrong before.
Howard, I wouldn't worry about non-confed stripping of private AS's. However the limit of 1000 private AS's is worrisome. Some providers already use one private AS per POP for doing confeds. With 2547 VPNs coming up (Juniper will support this by the end of the year. I would be very surprised if Cosine and Foundry didn't), we will need additional private AS's. The only bright spot is that I suspect many folks wanting IP VPN services won't want to run BGP and will do the route injections with statics. As long as the RFC 2547 implementations support an extension to static routes so that RD can be specificed, I suspect we'll be alright in the short term.
From reading 2547 I can't think of any reason that all VPN customers of a single ISP couldn't share a single private AS, as long as they had distinct RD numbers.
- Dan Golding On Tue, 16 May 2000, Howard C. Berkowitz wrote:
I'm not sure I am looking at this the right way, but:
It seems similar to confederations, but I'm not sure the stripping method is adequate for becoming a transit AS.
I'm guessing that this was designed for something much simplier.
The only method I could see, is that a customer is multihomed to the same AS. The customer would not likely be able to obtain a AS from ARIN since they are fall under the same routing policy. The provider could strip the fake AS, and announce the prefix with their AS.
RFC1998 which assumes that AS 64750 is using address space delegated to AS X, so that the AS 64750 addresses won't be explicitly advertised, but only as part of the aggregate announced by AS X. The AS 64750 routes should be marked with the NO-EXPORT community just to make things sure.
As you suggest, the only reason I can see to do it is if AS 64750 had provider independent address space, then I could see (ignoring any effects on aggregation policy), a reason for AS X to advertise the PI routes.
AS 64750 announces <64750> up to AS X, AS x uses it to determine routing policy. At the edge, AS X will strip it and announce just <X> to the Internet as a whole.
AS 64750 would have some control over how the traffic would enter their network. This also gives them the mechinism for failover.
I've used this method before, but not in the same exact way. In that method, it was a smaller part of a CIDR allocation, so they were aggregated into a larger block at the edge. No reason for the Internet to know about the topology when its all the same AS anyway.
So, this is only really useful if the customer has their own blocks.
For cisco to support it...someone has to be using this feature...
Not to be flying a false flag here, I'm trying to decide if we should support this feature on Nortel Versalar routers. So far, I haven't seen a reason for supporting this in addition to confederations, but I've been wrong before.
A greater area of concern is managing private AS numbers given widespread deployment of RFC 2547 VPNs, with the CE routers talking BGP to the PE routers. For a large provider, 1K isn't a lot of AS number space. I'm inclined to believe that scalability will require there must be a hierarchy of private AS numbers, essentially reserving some as aggregates.
(tm)
"Howard C. Berkowitz" <hcb@clark.net> wrote
I'm trying to understand the problem being solved by the Cisco private AS removal feature. In particular, what advantages does it offer over confederations, which would seem to do the same thing when externally advertising customer routes? Is there a performance benefit?
RFC1998-style multihoming with a private AS is a possible application, I suppose, for any routes that are NOT marked with NO-EXPORT.
On Tue, 16 May 2000 11:51:15 -0500, Tony Mumm <tonym@netins.net> said:
[snip...8<-----] Tony> So, this is only really useful if the customer has their own Tony> blocks. Tony> For cisco to support it...someone has to be using this feature... [snip...8<-----] Tony, This is exactly how we use the private as removal... -- Dave A Onvoy/Internet - Internet in Minnesota since 1987 -----/|\--------------------------------------------------------------+ - / | \ Dave Bergum, Sr. Network Engineer <bergum@MR.Net> | - /__|__\ 2829 University Av SE, Gab: (612)362-5812 | - j---'---/ Suite #200 Fax: (612)362-5899 | -~~~~~~~~~~~~~ Minneapolis, MN 55414 Beep: (612)589-6310 | ----------------------------------------------------------------------+
participants (4)
-
Daniel L. Golding -
Dave Bergum -
Howard C. Berkowitz -
Tony Mumm