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

[marcelo bagnulo braun <marcelo at it.uc3m.es>]

Christian Vogt escribió:
> 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?
>   
yes, but the question is what do we do with the slaac send in the 
presence of send capable hosts.

If we want to support them, then all slaac savi devices need to 
implement the send savi, which seems an overkill for a the send protocol 
which deployment is non existent afaict
If we allow sllac savi only devices, then plugging a send host would not 
work well (in particular, the send node can be filtered by the savi 
device in some cases, making the deployment of send even harder later 
on. So this is a tough call imho

Regards, marcelo


> - 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
> >     
>
>
>
>
>