Re: shim6 @ NANOG (forwarded note from John Payne)

[Geoff Huston <gih@apnic.net>]

Reposted on behalf of Iljitsch van Beijnum

(It appears that we have a rather aggressive mail list manager that eats 
messages with
control words such as "sub scribe")

  Geoff


> From: Iljitsch van Beijnum <iljitsch@muada.com>
> Subject: Re: shim6 @ NANOG   (forwarded note from John Payne)
> Date: Tue, 28 Feb 2006 13:31:36 +0100
> To: Jason Schiller (schiller@uu.net) <jason.schiller@mci.com>
>
> [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 sub scribe to both.]
On 27-feb-2006, at 22:13, Jason Schiller (schiller@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?