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

["Jun Bi" <[e-mail]>]

Dear folks,

Many thanks for your valuable review comments.
We plan to submit a new version ASAP.

Best Regards,
Jun Bi

-----Original Message-----
From: savi [mailto:[e-mail]] On Behalf Of Guang Yao
Sent: Monday, April 28, 2014 7:01 AM
To: 'Ted Lemon'; 'Pascal Thubert (pthubert)'
Cc: [e-mail]; 'SAVI Mailing List'; 'Jean-Michel Combes'
Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22

Dear folks,

Thank you very much for all the comments. Because the topic forks into multiple threads, I made a summary for the discussions, including our revision decisions. 

We are grateful to any advanced comments.  Thank you again.

Best regards,
Guang Yao

1. LQ problem

The original post from Eric:
"1) There seem to be a requirement in several places of the document (see below) to send LEASEQUERY to the DHCP server.  That is certainly useful to do so, but switches are sometimes pure layer-2 switches, and don't implement a DHCP stack not they have a layer-3 address to source traffic from.
Even when the switches have a layer-3 leg,  setting then to reach out the DHCP server is not a trivial operation, and not one which is typically done on layer-2 access switches.
Whenever the LEASEQUERY is mandated,  I'd rather have it as a SHOULD, with some alternate behavior (delete the entry for instance).
"

The discussions:

Pascal: least there should be enough options to implement some user policies. maybe we should be documenting the value / risk involved in using LQ or not?

Eric: I am not sure how to read this ("MUST" followed but "if it can't").  Isn't it contradictory? I thought "SHOULD" was exactly the way to say that. 

Eric: In the data snooping process...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?

Ted: BTW, I agree with Eric that the MUST there should be a SHOULD...

Pascal: I'm not sure that this particular FSM is the only way to implement the function and get all the necessary interoperation.

Ted: I think the added flexibility you are talking about might in theory be a good thing, but might in practice actually be a bad outcome.   In any case, it's certainly true that implementors can do this differently if they like, as long as their implementation behaves in a way that interoperate with implementations that follow the documented FSM.   

[final decision]
 (a) for the data snooping process, LQ is necessary, or else there is no need to perform the data snooping process (there is no other way to sync state with the DHCP server). Considering the whole data snooping process is a conditional MUST, the LQ is actually a conditional MUST.

		For the detection problem from Eric, the conflict detection is used to reduce times of LQ under attacks against local addresses. "If LQ is optional, and DETECTION failed to detect a conflict, then the entry should not move back right away to NO_BIND." Then if LQ is not implemented, the entry will always move back to NO_BIND. There is no need to perform data snooping process at last...

       (b) for the DHCP snooping process, LQ is used to get the lease when the binding is triggered by CONFIRM. We propose:
       		"the SAVI device SHOULD send a LEASEQUERY. In case the SAVI device is not capable of performing the DHCP leasequery process, the entry should be set a lifetime of DHCP_DEFAULT_LEASE."

       		Add a term (but not a constant)
       		"DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the binding the triggered by CONFIRM but LQ cannot be performed by the SAVI device to fetch the lease."

2. MLD problem

The original post from Eric:

"I don't think a layer-2 switch can and need to join the Solicited Node  Multicast group of the source address. It does not have a layer-3 stack on top of every link it is bridging/switching. It has to snoop ND traffic, like it snoops DHCP traffic. "

The discussions:

Guang: the similar text is found in RFC6620.
	"   The FCFS SAVI device MUST join the solicited node multicast group for
	   all the addresses with a state other than NO_BIND.  This is needed to
	   make sure that the FCFS SAVI device will receive the DAD_NS for those
	   addresses.  
	"

Ted: Do we really think there are modern layer 2 devices that will implement SAVI-DHCP that will not have IPv6 addresses? ... I think this is a non-problem.

Eric: An access switch can deal with hundreds, sometimes thousands of links (vlans) and while it will always have a layer-3 uplink for management purpose, mandating one layer-3 downlink per vlan is often not operationally acceptable.

Ted: IOW the switch can't have a link-local address per subnet? Again, if it's a managed switch, it doesn't make sense that you wouldn't want it to have a routable L3 address.   

Eric: I  find the below section very confusing.  SAVI devices are switches, hence they have other means to punt any traffic they  want to inspect to cpu level. They would not "join multicast groups". A wild guess on the intention is to get around the case where some MLD snooping device is at stake in the network. Works for addresses that you know but can't possibly work for addresses that you don't know yet and that are being DAD'ed.  MLD snooping is just incompatible with SAVI, and if we accept that fact, joining MLD solicited group is not needed. 
And it has the same issue I raised: access switches cannot reasonably have a layer-3 interface on every subnet (link/vlan) they operate on, which could be thousands.

Pascal: Anyway; whether they are private or not, there can be a great many vlans and it can become a real hassle to configure one SVI per vlan. 

Ted: Thanks for the detailed explanations—it's very helpful, since I'm a bit out of my depth when it comes to big switches.

Leaf: I also wonder a further explanation on the following statement. 

[final decision]
We found the problems for SAVI-DHCP and SAVI-FCFS are different. SAVI-DHCP does not expect a DAD NS in any state. The NA will always be received by the SAVI device. Thus it is proper to not join the MLD group. We will remove the corresponding sentence. 


3. DAD detection problem 

The original post from Eric:

"I wonder what would be the end-result if the switch send a DAD or and ARP and the legitimate owner interpret it as "someone already has the address" (always possible depending on its current state). That would seriously break DAD or ACD (rfc5227). I think we need a way to distinguish  between the packets issued by the switch and normal DAD or ACD packets.  (some field in the header? But that would be a protocol change…)."

The discussions:

Guang: the similar text is found in RFC6620.

	"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 as described in Section
	      5.4.2 of [RFC4862]
	"

Leaf: If you could agreed on the above in RFC6620, I guess you would have no doubt here for the IPv6 address. 

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.

	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.

Leaf: 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. If we believe it sounds a wrong message, would you like submit a Errata for it? 

[final decision]:
	(a) we will use a non-DAD NS with specified source (sorry for we do not find the definition for NS lookup).
	(b) Considering the l3 address problem, I propose use a "SHOULD" on the NS detection. 
		As I mention above, DAD is not an alternative of LQ. It is used to reduce the times of LQ under attacks against local addresses.



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