Subject: Re: [savi] Comments on draft-ietf-savi-send-03

From: Alberto García <[email-masked]>
Date: Thu, 2 Sep 2010 13:48:05 +0200

Hi,
(just catching up...)

|  -----Mensaje original-----
|  De: Tony Cheneau [mailto:[email-masked]]
|  Enviado el: miércoles, 11 de agosto de 2010 12:04
|  Para: [email-masked]
|  CC: [email-masked]
|  Asunto: Comments on draft-ietf-savi-send-03
|  
|  Hello,
|  
|  I read the document draft-ietf-savi-send-03 and I have the following
|  comments. This is mostly clarification questions actually, because I am
|  new to SAVI:
|  
|  - Section 2.2:
|   « In particular, SEND SAVI does not require any changes in the
|   hosts whose source address is to be verified. »
|   This implies that it is OK to modify routers, correct ?

The spirit of the approach and the charter is that routers should not be
modified too. 

|  
|  
|  - Section 4.1 and Section 4.3:
|  
|   +--4-----3---+
|   | SEND-SAVI1 |
|   +--1-----2---+
|      |
|    +-2-+
|    | R1|
|    +-1-+
|      |
|    +----------+
|    | SWITCH-A |
|    +----------+
|      |      |
|    +-1-+  +-1-+
|    | H1|  | H2|
|    +---+  +---+
|  
|  (this figure helps me to explain my scenario)
Well, this scenario is not suited for SAVI. SAVI devices (such as
SEND-SAVI1) operate connecting devices which belong to the same link
(layer-3), so they forward packets as layer-2 switches (although for their
operation they also use layer-3 info). 
If R1 is a router, then in the scenario there are 2 different links, and the
relationship between them is not relevant for SAVI

|  
|  I understand that in order for SEND-SAV1 to learn the prefixes that R1
|  advertise, R1 must advertise its prefixes on both of its interfaces. I
|  think it is pretty rare for a router to advertise the same prefix on
|  multiple interfaces (except when using RFC4389). My understanding is
|  that R1 will advertise its prefixes on interface 1 only. Did I miss
|  something ? Are routers modified for (SEND- ?) SAVI to behave that way ?

Answered above...

|  
|  The same comment applies for Section 4.2, the router may not answer to
|  CPS messages (as they are not received through an advertising
|  interface).
|  
|  - Section 4.3:
|   « all SEND SAVI devices MUST listen and process RADV containing the
|   SEND extensions »
|   This implies that all the SEND SAVI devices must have a (loosely)
|   synchronized clock, right ?

Yes. At this point, SEND SAVI devices process RADV messages as SEND hosts
do.

|  
|  - Section 4.4.1.1., TENTATIVE_DAD state:
|   - « While it is waiting for a possible DAD NADV »
|   It could also receive a DAD NSOL, from another node, performing a DAD
|   on the same target address, right ?

I agree that this case should be considered. 
Let's assume SEND-only operation. Then, the trigger is 'receiving a
validated DAD NSOL'. This is relevant, because the fact that DAD_NSOL is
validated gives us a lot of confidence in the trustiness of the information.
The normal case for this would be that the host issuing the DAD_NSOL which
made the state to move to TENTATIVE_DAD has moved to another port, and it is
doing again the DAD_NSOL (after detecting a link change, for example). Then,
I think the transition should be again to TENTATIVE_DAD, but with the VP
port as the port from which the last DAD_NSOL has been received.
A pathological case would be 2 hosts with the same valid CGA in the network.
SEND SAVI is not designed to solve this problem better than usual SEND
operation (although maybe logging could help)

|  
|   - « If a validated DAD NADV is received from any port [...] »
|   Same comment as above.
Yes, but i think this case is already discussed in the document, isn't it?

|  
|  - I think you should add configuration variable to set a minimum size
|    and maximum size of the key SEND nodes are authorized to use.

SEND document [RFC3971] discusses this also. My idea is that SEND SAVI is a
SEND device, so unless otherwise stated, all considerations of RFC3971 hold
(maybe, some text stating this could be added). 
Do you think that we need something specific for the SEND SAVI device,
besides usual SEND configuration? 

|  
|  I also noted some typos:
|  - through the whole document:
|    "anti-reply" => "anti-replay"
|  - Section 3.1:
|    "maily through" => "mainly through"
|  - Section 4.3:
|    "prefixes and routerare"
|  =>"prefixes and routers are"
|  
Thanks!

Regards,
Alberto

|  
|  Hope it helps.
|  
|  Regards,
|  	Tony Cheneau