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

[Alberto García <alberto at it.uc3m.es>]

Hi

|  -----Mensaje original-----
|  De: savi-bounces at ietf.org [mailto:savi-bounces at ietf.org] En nombre de
marcelo
|  bagnulo braun
|  Enviado el: jueves, 29 de octubre de 2009 7:50
|  Para: Christian Vogt
|  CC: SAVI Mailing List
|  Asunto: Re: [savi] A few comments on draft-vogt-savi-framework
|  
|  Christian Vogt escribió:
|  > On Oct 28, 2009, Dong Zhang wrote:
|  >
|  >
|  >> My concern is that as a vendor, it may implement the savi approaches,
|  >> including fcfs approach, cps approach and SEND approach. So how to
|  >> coordinate them needs to be considered. I mean all the approaches work
|  >> together or choose one to work. I guess it could be the latter. If so,
|  >> the condition for choosing  each approach should be illustrated
|  >> unambiguously.
|  >>
|  >
|  > Yes, I agree.
|  >
|  >
|  >> However, I assumed that there is still an exception, which means
|  >> several  address assignment methods exist in one case. How do the savi
|  >> approaches deal  with this case?
|  >>
|  >
|  > For this case, we need a prioritization of which address assignment
|  > methods take precedence over which other address assignment methods.
|  > And you are right that the definition of this prioritization will
|  > require care.
|  >
|  >
|  yes, moreover, we need to figure if it is enough with a prioritazation
|  or we need to change the mechanisms in order to interact properly. As i
|  stated earlier (and eric noted before me), we certainly need to update
|  send savi to properly interact with the slaac savi (at least, haven't
|  doen the analysis for dhcp savi yet)
|  
|  Regards, marcelo

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

|  
|  
|  
|  > Does this make sense?  Does it address your question and comment?
|  >
|  > - Christian
|  >
|  >
|  > _______________________________________________
|  > savi mailing list
|  > savi at ietf.org
|  > https://www.ietf.org/mailman/listinfo/savi
|  >
|  >
|  
|  _______________________________________________
|  savi mailing list
|  savi at ietf.org
|  https://www.ietf.org/mailman/listinfo/savi