> On 22.12.2014, at 13.04, Gert Doering <[email protected]> wrote:
> I was actually looking the other way, destination space - if you know
> that for, say, 2001:608::1 the path over ISP A is "better" (for whatever
> local metric), everything else inside 2001:608::/32 will have the same
> result for the same metric, as it's really a single network in a single
> city with identical routing policy for all of the /32.
>
> But this is just this particular ISP, while others might have vastly
> different routing policyies for different /48s out of the same /32, like
> “Akamai"...
Yeah, on DA side, I would not venture to aggregate any results _without_ local
data to back it up. So what I would do there is basically gather (ideally on
system level and not per application) statistics on difference in the relevant
measures (rtt, jitter, bandwidth depending on what you care about) towards
different addresses, and try to notice where there is significant change and
guess meaningful DA prefix lengths for particular SA based on that.
It does not sound too fun either :)
>> So for simplicity???s sake, I think that the per-prefix-on-link-granularity
>> is the sane level.
> I have the nagging suspicion that "permanent + temp addr" wasn't even on
> Brian's radar here (and might not actually be relevant :-) - if you have temp
> addresses, you don't connect outbound from the permanent address in the
> same prefix, no?).
Depends on how stupid (=or portable and standard-API-abiding) applications you
have. Typical stack (look at API in RFCs for example) does not expose address
lifetimes or {permanent,temp} address type to applications, as the stack is
‘just supposed to do the SA’ on behalf of applications. Now that we are
discussing either libraries or applications getting smarter, there are
potential problems there.. :p
Sure you can get that with OS specific hackery, but the standardized API is
woefully inadequate. And IETF is to blame here to some degree, as the IPv6 APIs
come mostly from here.
(Yeah, I guess you can recognize temp/perm address by looking at the bits in
the app but ugh..)
Cheers,
-Markus
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
