[28783] in North American Network Operators' Group
Re: Private ASN suppression
daemon@ATHENA.MIT.EDU (Howard C. Berkowitz)
Tue May 16 13:08:23 2000
Mime-Version: 1.0
Message-Id: <v0422080db5472dc784c8@[63.216.127.98]>
In-Reply-To: <200005161651.LAA16517@worf.netins.net>
Date: Tue, 16 May 2000 13:04:42 -0400
To: nanog@merit.edu
From: "Howard C. Berkowitz" <hcb@clark.net>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Errors-To: owner-nanog-outgoing@merit.edu
>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.
