[OCCAID] routing

[James Jun]

> IPv6 trace seems to indicate that the network behind it is not
> reachable. But I assume that you normally announce it per BGP and then
> that would make sense.

> same here.  I was waiting for the EWR decomission email going over
> migration options prior to permanent shutdown:

Well, I guess this is what happens when transport circuits go dark before
their scheduled cancellation dates (2/7/07).

> BTW i sent an email 2006-06-02 about joining NBONE.  If it exists I'm
> still interested in that.  I have a colo on 100Mbit/s in lower
> manhattan that was a stable 2 - 4ms from EWR2:

I don't think NBONE really exists anymore unless I'm mistaken, and I've been
out of touch with that project since early '06 due to other priorities and
work projects.  Whatever technical resources are available for new projects
between staff here currently are committed to OCCAID2 deployments which have
started recently.

> and two people connected to me already, willing to host others.  not
> sure what options James had in mind, but I'm willing & able to help
> aggregate some legacy EWR2-neighborhood OCCAID members from the
> experimental days if it works out!

That's fine with us, less work load.

> What if the various SixXS PoPs would have a BGP listener&speaker. Folks
> could then request one or multiple tunnels to the various PoPs, as
> OCCAID has multiple, and then announce their own prefix toward the PoP.
> If tunnel fails, one fails over their prefix automagically to another
> tunnel. The PoP would only announce a single default route though, maybe
> more specifics could be done also optionally.

I support this and it would make a lot of long-time users who had
connections since 2001 happy without overburdening staff resources.  (well I
suppose it adds burden on your side :P but you guys automate heavily anyway,
which is good thing(tm)..)

> 
> The PoP speaks BGP upstream to the OCCAID backbone, announcing the
> prefixes from the endusers.
> 
> Of course only OCCAID prefixes under 2001:4830::/32 would be accepted
> for this to keep aggregation easy. Altough, it could be used to also
> accept other /48's etc, but mark them no-export towards the rest of the
> world.

Yup, route-maps automatically mark anything longer than /32 (with exception
of RIR-approved PI ranges and manually exempted prefixes) with our own
global no-export tag (0:40000).  SixXS routers could also be configured to
send 0:40000 if desired.

> 
> Note, that I propose this only for PoPs participating in OCCAID, as
> those PoPs all fall under the same 30071 ASN. It can't work for other
> SixXS PoPs as that would mean that the PoPs would have to backhaul
> traffic amongst them, which is inefficient and doesn't solve the case
> where the PoP goes down or becomes unreachable in another way.

Indeed.

> 
> Anybody comments on this?

Just let me know what kind of resources or cooperation we will need to
perform at our end and will be glad to see this work.


Regards,
james