shim6 @ NANOG (forwarded note from John Payne)

Tue Feb 28 12:31:36 UTC 2006

[Crossposted to shim6 and NANOG lists, please don't make me regret  
this... Replies are probably best sent to just one list for people  
who don't subscribe to both.]

On 27-feb-2006, at 22:13, Jason Schiller (schiller at uu.net) wrote:

> Is it the consensus of the shim6 working group that the full suite  
> of TE
> capabilities should not be a requirement?  Or is this just the  
> opinion of
> a few vocal people?

I don't think I'm going out on a limb when I say that there is  
consensus that we need good enough traffic engineering from the  
start. (Where "start" means deployment, not necessarily the  
publication of the first RFC.)

I think basic balancing of both incoming and outgoing traffic over  
the available links is both assumed to be part of what we need to  
have and implementable without too much trouble.

Push back by transit ASes is harder. This is what I mean by that:

     A --- B
   /         \
X             Y
   \         /
     C --- D

C's link to D may be low capacity or expensive, so D would prefer it  
if X would send traffic to Y over another route if possible. C can  
make this happen in BGP by prepending its AS one or more times so X  
will see the following AS paths:

A B Y
C C C D Y

All else being equal, X will choose the path over A to reach Y.

The simple answer here is that if the multihomed site receives a BGP  
feed just like today (except that it's a read only feed) and thus  
makes outgoing path selection decisions just like today, transit ASes  
have exactly the same tools as they have today. But presumably, if  
shim6 takes off many smaller sites that aren't comfortable with BGP  
will multihome also, so this push back won't work as well anymore.  
Creating a new way to accomplish this result is probably possible,  
but not entirely non-trivial, and probably something we wouldn't want  
to deliver on day one.

Thoughts?

Another capability that would be hard to replicate with shim6 is  
selective announcement. Today, many transit ASes allow multihomed  
sites to influence the way their prefix is propagated to neighbors of  
the transit AS. For instance, in the picture above X may decide that  
the link between C and D is of low quality, and set a community on  
the prefix it sends to C that tells C either that it should perform  
AS path prepending on X's prefix ONLY towards D and not towards other  
neighbors of C, or even not announce the prefix at all.

We would need considerable extra mechanisms to replicate this  
capability, and maybe it can't even be fully replicated at all.

So how critical is this capability?