Spencer Dawkins wrote:
Hi, Jason,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.Since end hosts lack routing state, there will need to be another mechinism to determine shortest path leveraging the forwarding plane. One method is to measure the latency in the forwarding path. This seems that this solution should be closely aligned to forwarding path failure detection problem space.Are we talking about basing path selection on current latency (I thought I understood, later in this thread, RTT latency)?I would be concerned about what frequency you are measuring this over, and how often you think path selection based on RTT might change.There's a lot of protocols that have had to add dampening to avoid oscillation, and I'm hoping Shim6 won't be defined so that it changes preferred paths very often, because it's too easy to have multiple senders all figure out that destination B is the high-performance destination - until all the other senders start using destination B, so now destination C is the right answer, and then...
I don't think this is part of shim6 at all. It's a way shim6 might
be managed or tuned - and of course you're correct that a tuning
system that results in the "dancing in your own shadow" form
of oscillation would be a Very Bad Thing, but that is outside
shim6 itself.
Brian
My apologies if I misunderstood what was being proposed. Spencer