[savi] AD review of draft-ietf-savi-fcfs

[Jari Arkko <[e-mail]>]

I have reviewed this draft. The specification is well written, and while 
it took an entire day for me to be (relatively) convinced that the state 
machine is correct, it is easy to read.

I have sent the draft forward to an IETF last call. However, I did have 
a few suggestions and questions that I hope you can treat and if needed, 
issue a new draft version.

> Neighbour Solicitation (NSOL)
> and Neighbour Advertisement (NADV) messages

Can we use the usual abbreviations, NS and NA?

> Router Advertisement: A SAVI device MUST support discovery of on-link
> prefixes through Router Advertisement messages.  The SAVI device will
> learn the on-link prefixes following the procedure defined for a host
> to process the Prefix Information options described in section 6.3.4
> of [RFC4861] <http://tools.ietf.org/html/rfc4861#section-6.3.4> with the difference that the prefixes will be configured
> in the FCFS SAVI Prefix List rather than in the ND Prefix List.  In
> addition, when the SAVI device boots, it MUST send a Router
> Solicitation message as described in section 6.3.7 of [RFC4861] <http://tools.ietf.org/html/rfc4861#section-6.3.7>,
> using the unspecified source address.
>   

Will this process be run on all ports, or just the trusted ones? Please 
specify.

> o  If the data packet is received through a Validating port, then the
>    SAVI function checks whether the received data packet is local
>    traffic or transit traffic.  It does so by verifying if the source
>    address of the packet belongs to one of the directly connected
>    prefixes available in the receiving interface.  It does so by
>    searching the FCFS SAVI Prefix List.
>    *  If the IP source address does not belong to one of the local
>       prefixes of the receiving interface, this means that the data
>       packet is transit traffic and the packet SHOULD be discarded.
>   

You need to add a special case for supporting the unspecified address.

> This may due to an attack or to the fact that the host
> may have moved. 

... may be due to an ...

> and 250 millisconds later

Milliseconds. And please put the value to a constant in a separate section.

> The DAD_NSOL messages are sent
> through the proper Trusted Ports (as defined by the switch
> behaviour that will depend on whether it performs MLD snooping or
> not). 

The word "proper" is confusing here. How about this text instead:

The DAD_NSOL messages are sent through Trusted Ports (but of course 
subject to usual switch behavior and possible MLD snooping optimizations).

> the SAVI device MUST forward the NSOL and 250
> millisconds later it MUST execute the process of sending Neighbour
> Solicitation messages

This could be clearer. First, you forward the NSOL completely normally. 
Then you separately run the NS process *on behalf of the host*, but 
forward these NSOL messages only to TP ports. Correct?

A couple of questions, however. What's the source MAC address in such 
packets, the host's or the switch's address? And why aren't you simply 
copying the same message, separated by X ms? Finally, are you forwarding 
one message and generating two copies, altogether three messages?

Additional clarity here would be useful.

> o  DAD_NSOL packets containing IPAddr as the target address received
>    through a Trusted port are NOT forwarded through any of the
>    Validating ports but they are sent through the proper Trusted
>    Ports (as defined by the switch behaviour that will depend on
>    whether it performs MLD snooping or not)
>   

I don't understand why these  messages are only forwardded to the TPs.

> o  Neighbor Advertisement packets sent to all nodes as a reply to the
>    DAD_NSOL (hereafter called DAD_NADV) containing IPAddr as the
>    target address coming through a Validating port are discarded.
>   

This seems to break the principle of SAVI not changing network behavior 
except where a delay is necessary while you verify something. Why is it 
necessary to not forward these messages as they normally are forwarded 
through the network?

> So, when SEND is deployed, it is recommended to use SEND SAVI
> [I-D.ietf-savi-send <http://tools.ietf.org/html/draft-ietf-savi-fcfs-09#ref-I-D.ietf-savi-send>] rather than FCFS SAVI."
>   

Is there some reason why proxy SEND cannot be employed here?

Jari