Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming

[email protected] wrote:
> Brian,
> 
> 
>>>Agreed.  Even if you did this, then you would need some sort of mechanism
>>>to evaluate the paths after determining reachability. I know some people
>>>have discussed a next generation trace route that would collect statistics
>>>about the hops along a particular path.  Put that onto your "cartesian ping bomb"
>>>and you might have a solution, but at what cost?
>>
>>It seems to me that this is one of those separable functional
>>components we've been talking about, i.e. the one that triggers
>>a multihoming event. In Version 1 that component would issue a
>>trigger when connectivity vanishes for more than N seconds; in
>>version 2 it might do so when QOS drops below some threshold for
>>more than N seconds; in version 3 it might do so when observed
>>QOS drops below presumed QOS for an alternative path for more
>>than N seconds. The critical interface to be standardized isn't
>>any of that; it's the "trigger multihoming now" protocol or API,
>>IMHO.
> 
> 
> So, multihoming triggering mechanisms are out of scope for Multi6,
> except for link failure ... I would agree that the API should be
> out of scope.

I didn't say it's out of scope, I said it's separable. Actually,
after we review the design team's output in the upcoming meeting,
there will need to be a charter discussion to find out what is
in scope for which WGs*. I'm trying to keep my mind unbiased on
that question for the moment.

*Our charter ends with these words:

   Development of specific solutions will require chartering of work
   in the appropriate Area or Areas.

     Brian