Re: multi6-functional-dec and re-homing

[marcelo bagnulo braun <[e-mail]>]

Hi,
a comment about the proposed draft...

El 17/01/2005, a las 13:52, <[e-mail]> 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
>
>