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

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

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

> john.loughney@nokia.com 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
mbagnulo@ing.uc3m.es is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------