|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: shim6 @ NANOG (forwarded note from John Payne)
[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 ([email protected]) wrote: Is it the consensus of the shim6 working group that the full suite of TEI 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?
|