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

[Erik Nordmark <erik.nordmark@sun.com>]

Jason Schiller (schiller@uu.net) wrote:

> Also depends on the pain involved in changing DNS (I don't have any
> insight into this)

Getting wide-spread SRV records would take some time.
First of all, the significant applications must try to look them up (so 
that when the web browser looks for www.example.com, it looks for SRV 
records at _http._tcp.www.example.com first, and if none found, it looks 
for AAAA/A records for www.example.com).
I don't know if there are already applications/systems that look for SRV 
records.

When we have that, then the DNS admins for the sites need to put the SRV 
records in their DNS servers.

But there isn't any protocol change needed to the DNS.



> > Do you see latency as being a TLV being passed around, or merely 
> > something that one of the endpoints can take into account when selecting 
> > the locator to use?
>
>
> I for see all these preference exhcanges only being shared between the
> destination and the source.  

Sure.
But they might not need to be passed around. When A and B communicate, 
then A can determine the rtt to B (and the ULP such as TCP already does 
this).
So there might not be much added benefit for A to tell B which latency 
it has observed.

> I think this works, but I'm not sure it will cover all cases and has
> flexibility for future growth.

I think in either case we can leave the door open for additional 
information. But we need to think a bit about the criteria for what 
information makes sense passing from A to B.

> With the different TLV types, additional types can easily be added so long
> as you can define how to treat when the new type collides with the
> pre-existing types at a give set level.  
>
> Say in the future you want to add another type to consider packet
> loss.  In this case you simply add another TLV type and define its
> values.  In addtion you have to clarifiy what to do when a source signals
> to ues the lowest latency and the lowest packet loss for all
> links.  Clearly one has to take precedence over the other.

I don't see a problem with the principle of having this type of 
extensibility. But I don't yet understand, as for latency, whether a 
packet loss metric would be something that A can measure and keep track 
of for its own purpose only, vs. A also being able to pass that metric 
to its peer B.

   Erik