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

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

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

Summary: support for an additional TLV is required in order to allow for
a destination (sink) to signal to a source which links should be utilized
to carry traffic inbound to the destination (sink).

You're of course completely right that something closely resembling this should be part of the shim. Thank you for writing it down explicitly.

3. Lowest latency -- paths with lower measured latency will be preferred
over paths with higher latency. A value set will be added or subtracted
to the measured value for biasing 

Hmmm...

I'm not sure we can cook something digestable from the delay, except that if we're first using address pair AX with delay N, and then pair BY has delay M where M is a lot larger than N, it probably makes sense to continue to test CZ and so on, while if M <= N there is no need to search any further.

An additional draft will need to be written to define the default
locator ID selection process, and how the TLVs will be used to modify
locator ID selection.

Please don't say "locator ID", it sound like "dry wet". We have locators and identifiers, both are addresses and some addresses are both.

Since at this stage, we're only considering the case where the initial session setup happens in a backward compatible way, the shim has no influence over the selection of the initial address pair. We also presume that it's best to engage the shim only when there is an outage. This means that for most traffic, the traffic distribution depends on regular destination and source address choices like they exist today. That's probably not good enough, though. An obvious mechanism to influence this would be SRV records in the DNS, which would need the same TLVs that you propose for the shim in your message (as far as they're missing from the current SRV specs).

Some TLVs may also rely on a forwarding component in order to sort the
locator IDs. I wanted somethin analogous to the current BGP "best" path.

Do you mean "best" by virtue of the BGP path selection algorithm left to its own devices, or "best" after having massaged the values the BGP selection algorithm takes into account?