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

El 25/10/2004, a las 15:46, Brian E Carpenter escribió:

> [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.


Yes, this is very important in the desing of the solution.

I guess that we should really try to design the solution in such a way 
that the different components/mechanisms that build the solution can 
evolve as independently as possible.

A good excersive would be to identify which are those components that 
we will design to be able to independetly evolve.

It seems that the mechanisms used to trigger a re-homing is one of them.
Security mechanisms could be other one
mechanisms to deal with ingress filtering perhaps another one.

But we should try to make a full list since if we don't do this 
separation from scratch, it is very unlikely that we will be able to 
achieve this modular evolution later.


Regards, marcelo

>  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
>
>
------------------------------------------
Please note that my former email address
[email protected] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------