Hi all,
Following up yet again, this time on some discussions to date regarding
peering at NZIX using BGP. Just a couple of things which have sprung into
my mind...
Running OSPF and BGP simultaneously on NZIX routers will continue to be
necessary until we have gained critical mass, and have reached a stage at
which OSPF can be depreciated. Given that this is the short-term
situation, it seems to me that we need to be careful of a couple of
things. I am using CLEAR as an example only :)
1. If CLEAR is to peer with provider X over NZIX, then we will want a list
of routes from provider X so that we can build a filter for routes
received from X's BGP speaker(s). Until X's routes are entered and
maintained in a RR of some kind (like the RADB), adds moves and changes to
this list will be a manual process. [*]
2. If X makes more specific (i.e. longer prefix) advertisements using
OSPF, those are the routes we will use. This is important if CLEAR is to
peer with X somewhere else in addition to NZIX (e.g. WIX), as we will
always prefer longer-prefix routes.
3. If X makes less specific (i.e. shorter prefix) advertisements across
NZIX than they do their global transit provider, then we will likely route
to them via Australia or the US.
As we get things going, there will probably be times where routing becomes
sub-optimal (or, in fact, completely broken :) Could I suggest that people
going ahead with BGP across NZIX announce their progress to this list to
help everybody track down problems if (when) they arise?
[*] Not having route objects stored in a RR of some kind is going to make
maintaining route filters a sticky business for all concerned. There is
running code at Merit - do we have loose agreement that the RADB is a
suitable place to do this? If there is interest, I am happy to dredge
through the appropriate documentation and produce a quick-and-dirty guide
to RADB object manipulation.
Joe
--
Joe Abley