Subject: multi6-functional-dec and re-homing

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 17 Jan 2005 10:42:25 +0200

Folks,

I was browsing the re-homing section of
draft-ietf-multi6-functional-dec-00.txt, and currently it says the
following:

   "...The reason for a re-homing is essentially
   that the current locator pair is no longer working.  The re-homing
   procedure involves detecting that the locator pair currently in use
   is no longer working..."

I think it would be good if the draft supported also scenarios where the
current locator pair continues working, but changing the current locator
pair becomes desirable due to availability of some more preferred access
path, for example because the current path is much slower or more
expensive than the newly available path.

So what would you think if the above text would be replaced with
something like the following?

"The re-homing procedure is initiated when a new locator pair is to be
used for the communication, and it can take place when there is a change
in connectivity between the site and its transit providers. The
re-homing procedure involves detecting a change in the site connectivity
(for example, detecting that the current locator pair is no longer
working), ...."

This would support a larger set of possible re-homing scenarios, and I
think it is compatible with the wordings of re-homing definition in
draft-ietf-multi6-architecture-03.txt.

I had a short off-list mail exchange with Marcelo and Jari and they
agreed, but recommended to solicit the list opinion as well.

Any thoughts?

Thanks,
- Pasi

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 17 Jan 2005 10:42:04 +0100

> agreed, but recommended to solicit the list opinion as well.

I have no objections to the text leaving this possibility open, but I 
have some more concerns about actually implementing this.

- - kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Jan 2005 11:36:33 +0100

Kurt Erik Lindqvist wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> I have no objections to the text leaving this possibility open,

ditto

> but I 

In a sense, it's to leave this door open that I've been arguing
over on shim6 that we should separate the state machine (and by
implication, its APIs) from the shim6 protocol.

    Brian