[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: addition of TLV to locator ID or locator ID set

On 22-sep-2005, at 23:23, Jason Schiller (schiller@uu.net) wrote:

These days, 85% of the internet is reachable over either two or three hops. So "best" is largely meaningless here.

I'm not sure I agree that shortest AS path is mostly uselees because most
of the Internet is only a few ASes away. I think generally people still
think its better to transit two ASes instead of three.

What I meant is that there is a group of people for which 85% of the world is 2 ASes away and a group for which 85% is 3 ASes away.

Five years ago or so you could do some traffic engineering with path prepending, these days it's largely useless because the AS hierarchy is so flat.

BGP has many mechinisms to alter the loading of links. By default you get
shortest AS path in bound. You can get primary back-up using local pref
to different up stream ISPs,

Do people really buy lines just to use them as backups? I never understood this.

you can get primary back up whith a single upstream using MED, 

You can still do that with the shim in effect.

our you can load share by splitting your announcements
across you links.


Yuck, you should never announce more specifics for this.

You can have complex cases that combine these. 

Tell me about it...

[...]

How do you recreate this type of traffic delivery with shim6 (this is
just one example)?


I'm not sure, trying to find something for my headache...

Don't forget that you can still have BGP to manage your outgoing traffic distribution if that is what you want. Also, with the TLV mechanisms in the shim and assuming SRV records are used, static balancing and primary/backup arrangements should work well.

The only thing that the shim will NOT give you is a way to prefer shorter paths over longer ones.

I beleive shim6 needs to support something analogous to the current IPv4
traffic engineering. Many content providers have expressed that they
currently offer no content because they require multihoming and traffic
engineering.

I don't forsee too many problems for outgoing traffic: you basically retain current mechanisms (as long as you take "read only" feeds to manage your outgoing traffic there are no BGP scaling problems). Incoming could be a bit harder, but that's hard today as well. If applications start using SRV records this shouldn't be too much of a problem. Letting the shim pick up the slack isn't great because of the additional overhead, and also because only a small number of hosts may implement it, especially at first. (Most people are single homed after all.)

How do you add network wide traffic engineering preferences to the host to
host shim6 solution?

It seems to me there are three approaches:
1. Some how get the source end system to sort the locators in the correct
order by giving it additional information and having it do forwarding
plane measurements.

How would that work? Looking at delay works in some cases, but not in others. If I'm in Seattle and I have a cheap, fat link to Chicago and a smaller backup link to Palo Alto, I'm not going to be happy when half the US + asia pacific is going to send its traffic over my smaller link because the delay is better.

2. Let the end systems choose what ever locator and allow the routers to
record locator set information. Allow routers to recognize a destination
address as one out of the locator set, and replace it with a different
destination address if there is a different locator which is better (or
at least forward towards a different address if a different locator is
better). 

How would the routers know that another choice is better?

Mangeling packets on the fly by routers seems a bit scary. 

Just a bit?

In the long run, this will hopefully be moot as it should be possible to change TCP such that it (in cooperation with the shim) uses more than one path, and either picks the best one or continues to use several concurrently. With an extensible TLV mechanism we should be in reasonable shape to begin with, so I'm not too worried, although traffic engineering is of course something we need to keep an eye on.