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

From: <[email-masked]>
Date: Mon, 25 Oct 2004 15:30:21 +0300

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.

thanks,
John

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 25 Oct 2004 15:19:02 +0200

> except for link failure ... I would agree that the API should be

I agree that an API for this is something for a later day.

However, we do need to create a reachability measuring mechanism that 
is flexible enough that it can be made smarter at some time in the 
future while maintaining backward compatibility, as having several of 
these mechanisms is a huge waste and deploying new ones will be hard 
because both ends must support it before it can do anything useful.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Oct 2004 15:46:06 +0200

> except for link failure ... I would agree that the API should be

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 26 Oct 2004 00:25:26 +0200

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

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