Re: [savi] A few comments on draft-vogt-savi-framework

[Christian Vogt <christian.vogt at ericsson.com>]

Alberto -

As a member of the working group, not as its chair:  You are right  
that co-existence scenarios need to be handled.  But I'm not sure that  
coexistence requires /special/ behavior.  As long as the behavior  
desired for coexistence scenarios does not preclude the behavior  
desired for non-coexistence scenarios, I think coexistence should be  
covered by the /regular/ behavior of the various SAVI protocol  
specifications.  That is, in the particular case of SLAAC/SEND co- 
existence, I think we should strive for a SAVI SEND protocol that can  
handle non-SEND-capable SAVI devices.

Does this make sense?

- Christian



On Oct 29, 2009, at 3:04, Alberto García wrote:

> My opinion is that priorization is not enough.
> I think we need to define "operation modes" (SEND-only, SLAAC-only,
> SEND-SLAAC-compatible...) and describe the state machine for each one.
>
> To support the idea of why we need a new state machine for SEND-SLAAC
> compatibility, i.e. for a domain in which both SEND hosts and non- 
> SEND hosts
> coexist, just consider what a node should do (extending naturally the
> current FCFS and SEND proposals) if a SAVI device is in NO_BIND  
> state, and a
> data packet (not DAD NSOL) is received, from a Validating port VP.  
> In this
> case, the SEND SAVI device should send
> 	- 2 (unsecured) NSOL messages through Trusted ports (according to
> FCFS SAVI)
> 	- and a secured NUD NSOL message through the Validating Port
> (according to SEND SAVI
> 	And The state is moved to TENTATIVE.
>
> In the TENTATIVE state, the SAVI device should maybe wait long  
> enough (a
> RetransTimer, which is the waiting time for NUD operation) for a  
> secured NUD
> NADV even if an unsecured DAD NSOL is received from a trusted port  
> in the
> meanwhile, to assure that SEND validated addresses have priority over
> non-SEND addresses. [Note that this may occur if a SEND host has one
> collision when performing DAD for an address, and it is not  
> withdrawing the
> second address if an unsecured DAD NSOL is received for it, as RFC  
> 3971
> says].
> Different states should be defined (VALID_SEND, VALID_NON_SEND), with
> different behavior when the valid_timeout expires.
>
>
> So I don't think this is just "ships in the night", but different  
> modes
> should be defined to integrate all the possible combinations of  
> address
> configuration mechanisms. Maybe one of these modes should be the  
> default
> one, but the administrator could set the SAVI devices to the  
> appropriate
> mode (well, they also have to define which ports are trusted or  
> not...).
>
> Does this make sense?
> Regards,
> Alberto