North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: shim6 @ NANOG (forwarded note from John Payne)
On 28-feb-2006, at 16:34, Todd Vierling wrote:
A B Y C C C D Y
All else being equal, X will choose the path over A to reach Y.
There's plenty of route mangler technologies out there that provide
It's time to wake up and smell the intelligent routing trend. TheIn my experience, if anything, AS path prepending is TOO effictive: just one prepend can make a 60/40 split that you're trying to get to 50/50 into 25/75 instead. So I agree that it's not as useful as it used to be, but I blamed this on the flattening of the AS interconnection hierarchy. But maybe it's the routing/TE boxes that are responsible.
Another capability that would be hard to replicate with shim6 is selective
Now, selective announcement is something completely different -- but it's
Right. That would be hard to accomplish with shim6.
But also consider this:
- C does not advertise the prefix for Y, but it does have the next superprefix for Y (and C is "transit", so the superprefix must be considered valid);
- X's link to A dies.
So X will still try to push packets over C to reach Y, and per the existenceThis kind of thing is, as far as I can see, pretty much impossible to replicate in shim6. Mind you, even if we end up with PI in IPv6, it's unlikely that you get to do this with IPv6 because the address space and the provider aggregates are so large, that deagregating becomes a hazard rather than a nuisance. Deaggregating a /32 into /48 makes for upto 65536 additional routes, which is a third of the current IPv4 routing table (and several dozen times the current IPv6 routing table). So I think most people will use strict prefix length filters to avoid this. At least, after it has happened for the first time.
Don't think this will forever be a rare circumstance, either. The route
Traffic engineering is happening on both ends of the BGP mesh *today*, soI'm not too worried about what happens on both ends: since both ends implement the shim protocol and the two ends communicate with each other, we can build in whatever is required. The challenges are:
- getting site wide policies into the individual hosts or apply side wide policies in middleboxes in a secure way
- come up with a reasonable way to have information "in the middle" taken into account
And we have to figure out which capabilities must be present as a mandatory part of the specification on day one, and which can be optional and/or added later. (Ideally, all TE is kept outside of the base spec because modularity makes everything easier, but some stuff is only useful if it's everywhere so it either has to be mandatory or forget it, and other stuff is so important that we need it from day one.)