RE: Re: Lack of packets from other end

> 
> In fact, it would be *impossible* for the SG to recover from 
> it, because it has no other address for the peer in the case 
> that you mention above. The only question we have on the 
> table is whether an indication from the DPD causes a change 
> in the currently preferred address,
> *if* the peer has previously indicated that it has several 
> addresses. Past practise (SCTP) and ongoing designs (HIP,
> MULTI6) all have the approach where the preferred address 
> would be changed in a situation like that.
> 
> (Another question would be whether the client or the SG needs 
> is responsible for detecting and correcting a choice.
> I don't want to open that discussion yet, but in general I 
> like the client or the initiator to be responsible for as 
> much as possible, unless protocol symmetry requires
> otherwise.)
> 
> --Jari
> 
> 

Jari, I think we are in agreement, I would like to keep
the SG as simple as possible. It needs to have enough smarts to clean-up
garbage state, but if the client has switched to an alternate address,
I think it should __really__ let the SG know. We may need some
logic to do Make-before-break type switch like is common on cell phone
networks.

Thanks

Bora