[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multi6-functional-dec and re-homing

Hi,
a comment about the proposed draft...

El 17/01/2005, a las 13:52, <john.loughney@nokia.com> escribió:

Hi Brian,

The charter does need to be clarified... that's one reason we've
asked for a BOF. You're correct of course, the state machine doesn't
have to define the triggers, but it certainly defines the points at
which they will be applied.


Could I suggest a change to the current charter:

From:

	MAY 05    First draft of architectural and protocol document
	MAY 05    First draft on cryptographic locators, if required
	MAY 05    First draft on state managment

To:

	MAY 05    First draft of architectural and protocol document
	MAY 05    First draft on cryptographic locators, if required
	MAY 05    First draft on failure & rehoming event description


i am not sure that the wording is appropriate here...
I mean failure detection and rehoming involves at least the following items:
- Detecting the failure, which involves different heuristics that depnds on the apps, and other external triggers like ICMP error messages, and then probably some attempt to perform an explict reachability test, which would fail
- then exploring alternative paths and identifying one that is working
- and finally moving the communication to the new path, which probably requires a reachability test to the new locator pair (in order to prevent flooding) and perhaps a signaling message to inform about the locator change (something like a BU in mip)

Now, even though all this is involved in the failure and rehoming event, some parts of this fall within the protocol, (in particular, the messages to verify reachability, and the messages to change the locator being used), while otoh some other items belong to the state management part, like when to determine that a failuer is occurring and launch the rehoming process

I guess that we have on one hand the protocol that is needed to do this (reachanility test, alternative path exploration messages and rehoming signaling) and on the other hand we have some heuristics that will be used to determine failures and rehoming events.

Regards, marcelo


This is, of course, not considering the discussion we have had about the
potential need for a seperate architecture draft.

Anyhow, State management to me, means the internal protocol state, and
message processing rules, etc.  For example, I think
draft-arkko-multi6dt-failure-detection-00.txt might cover some of what
I'm thinking about. I also wonder if any of the work in DNA could
also be referenced here.  I'm definately interested in contributing
on this topic.

John