Re: [savi] WGLC: draft-ietf-savi-dhcp-22

["Leaf Yeh" <[e-mail]>]

Eric - 3) The SAVI device send and ARP/DAD to look for a conflict (I guess
to the entire vlan but the receive interface).
Eric - DETECTION in general is problematic. The state in the SAVI device and
on the end-node which has the conflicting address are independent. When he
SAVI switch sends a DAD, while the end-node is right in TENTATIVE (bad
luck), this DAD would shutdown the end-node interface. Maybe that is a
problem we have to deal with, but these probe packets are causing exactly
this type of issues, seen in real life. I thought I should mention it.

This sounds also the same argue to the FSM (including the states of 'No
Bind') described in Fig.2 of RFC6620, which needs the SAVI device (or
switch) to send out DAD_NS. 

<quote>
      Upon the reception through a Validating Port (VP) of a DATA packet
      containing IPAddr as the source address, the SAVI device SHOULD
      execute the process of sending Neighbor Solicitation messages of
      the Duplicate Address Detection process ... The DAD_NS messages are
not
      sent through any of the ports configured as Validating Ports.  The
      DAD_NSOL messages are sent through Trusted Ports...
</quote> @ Page 15 of RFC6620.

Right?

Best Regards,
Leaf



-----Original Message-----
From: savi [mailto:[e-mail]] On Behalf Of Eric Levy- Abegnoli
(elevyabe)
Sent: Thursday, April 24, 2014 12:11 AM
To: Guang Yao; 'Ted Lemon'
Cc: [e-mail]; 'SAVI Mailing List'; 'Jean-Michel
Combes'
Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22

Hi Guang,

On 22/04/14 05:56, "Guang Yao" <[e-mail]> wrote:

>Hi, Ted
>
>Thank you very much for your comments! I agree with you. It's safe to 
>assume all the SAVI devices have layer-3 stack. But it seems Eric also 
>concerns the implementation of DHCP leasequery and NDP snooping.
>
>On the MLD problem mentioned by Eric, I wonder should SAVI-DHCP be 
>consistent with RFC6620, or be different?
>
>Hi, Eric
>
>On the DAD problem:
>
>I read the doc again and find DAD NS will not be sent to the tentative 
>node.
>Whenever probe should be sent to the tentative node, we use plain NS 
>instead of DAD NS. Thus would it be OK?

I am a little bit confused on the scenario we are talking about (apologies
if this is my reading of the text).
The scenario I have in mind is
 1) SAVI device gets a data packet sourced with an address not found in its
table
 2) the SAVI device creates the binding (in DETECTION)
 3) The SAVI device send and ARP/DAD to look for a conflict (I guess to the
entire vlan but the receive interface).
 4) If no conflict was detected, it does the LQ I'll tend to argue that if
LQ is required, the DETECTION state is not necessary and should be removed.
If LQ is optional, and DETECTION failed to detect a conflict, then the entry
should not move back right away to NO_BIND?

DETECTION in general is problematic. The state in the SAVI device and on the
end-node which has the conflicting address are independent. When he SAVI
switch sends a DAD, while the end-node is right in TENTATIVE (bad luck),
this DAD would shutdown the end-node interface. Maybe that is a problem we
have to deal with, but these probe packets are causing exactly this type of
issues, seen in real life. I thought I should mention it.

In your response, you said it could also send a regular NS, which I assume
is an NS lookup. I could not find a reference in the text about sending NS
lookup instead of DAD. This is certainly a good practice (we have
implemented it that way) provided that you have an address to source it
from. However (my usual objection) the access switches often don't have a
l3 address per link/vlan, not even a link-local address. So NS-lookup should
be an option. Which leaves only DAD or LQ.
 

Thank you.
Eric




>
>We are looking forward to your further comments, thanks!
>
>Best regards,
>Guang
>
>-----Original Message-----
>From: Ted Lemon [mailto:[e-mail]]
>Sent: Tuesday, April 22, 2014 12:31 AM
>To: Guang Yao
>Cc: Eric Levy- Abegnoli (elevyabe); Jean-Michel Combes; SAVI Mailing 
>List; [e-mail]
>Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22
>
>Do we really think there are modern layer 2 devices that will implement
>SAVI-DHCP that will not have IPv6 addresses?   This seems highly doubtful
>to
>me-the devices that would only have layer two addresses would be unmanaged
>switches.   I have a cheap managed switch, and it has an IPv4 address and
>a
>web server in it.   I think this is a non-problem.
>
>
>

_______________________________________________
savi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/savi