[6bone] very drafty draft on 6bone routing mess

[Pekka Savola]

Hello,

Thanks for the comments.

On Mon, 21 Oct 2002, Rik van Riel wrote:
> On Mon, 21 Oct 2002, Pekka Savola wrote:
> 
> > http://www.netcore.fi/pekkas/ietf/6bone-messv2.txt
> 
> I like it.  The only thing I'm missing is a way for sites to
> easily see if other sites are transit sites or not, ie. should
> you accept announced transit paths from a site or not ?

I'm not sure what you mean, exactly.  

If I understood your question correctly, this should be done by you, by 
observing which paths the neighbor advertises.

After that, if you decide you want only specific, non-transit (at least 
for the whole globe) routes, you can apply route-map's in inbound, like:

AS1234 = your peer
AS5678 = your peer's customer

ip as-path access-list 50 ^1234+$
ip as-path access-list 50 ^1234+ 5678+$

(you can leave out '+' if you don't want to allow prepending, of course.)

But I'm not sure if I answered your question...?

[...]
> It boils down to a way the "serious" (whatever that is) 6bone
> sites can exclude transit via the sites that aren't suitable
> for transit, without relying on those sites for that. 

Basically, you have to ensure that those sites never get your route, 
especially without having no-export/no-advertise community tagged to it or 
before having as-path prepended so much it doesn't matter if they 
re-advertise it.

That decision is easy when those sites are your direct peers, but unless 
they are.. there may be some coordination between the parties involved, or 
you could just not advertise the route to them at all (via that path).

We could, of course, try to specify a few default communities like:

<AS-NUMBER>:<VALUE> and <AS-NUMBER>:<VALUE>, <AS-NBR>:<VALUE> , like:

6680:666
6680:667
1234:668

and the definition would be either (to be examined by every AS):
 1) if your AS is <AS-NUMBER> and <VALUE> is "666", do not announce this 
to any external peer.
 2) if your AS is <AS-NUMBER> and <VALUE> is "667" you may only announce 
this to external peers using no-export community.
 3) if your *neighbor's* AS is <AS-NBR> and <VALUE> is "668", do not 
announce this route to the neighbor at all. (This is particularly nasty 
and could be used to create total blockades :-).
  Option a) retain this community when advertising to valid peers (could get nasty..)
  Option b) clear this community when advertising to valid peers

.. but I'm not sure how useful these would be, as the whole point is 
trying to get rid of 6bone routing mess, not try to manage with it (as it 
currently is).  Also, I'm not sure how widely these would be implemented 
(as least 3 would require a lot of work) -- perhaps those who really want 
to do the best thing would do it only.

I don't think this can be done in a global scope, and I doubt reserving 
specific communities would be accepted by IESG, but in some smaller 
scopes, why not..?

> This is
> essential since some of the 6bone sites are badly administrated.
> Most 6bone sites may be administrated fine, but having routing
> messed up by a few badly run sites would suck immensely ;)

Yep, a "solution" try to avoid dealing with upstreams that have anything
to do with those badly administrative systems, but that isn't easy..

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords