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

"Guang Yao" <yaoguang@cernet.edu.cn> Mon, 28 April 2014 11:01 UTC

Return-Path: <yaoguang@cernet.edu.cn>
X-Original-To: savi@ietfa.amsl.com
Delivered-To: savi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305911A09B4 for <savi@ietfa.amsl.com>; Mon, 28 Apr 2014 04:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.149
X-Spam-Level:
X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnMBJbS-xUOf for <savi@ietfa.amsl.com>; Mon, 28 Apr 2014 04:01:17 -0700 (PDT)
Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4031A09A9 for <savi@ietf.org>; Mon, 28 Apr 2014 04:01:16 -0700 (PDT)
Received: from AndrewYaoPC (unknown [166.111.132.217]) by centos (Coremail) with SMTP id AQAAf3BL3wTnNF5TgTwFAA--.197S2; Mon, 28 Apr 2014 19:00:57 +0800 (CST)
From: Guang Yao <yaoguang@cernet.edu.cn>
To: 'Ted Lemon' <mellon@fugue.com>, "'Pascal Thubert (pthubert)'" <pthubert@cisco.com>
References: <CF7BFCD2.38EA7%elevyabe@cisco.com> <52D2BDC7-9E55-43BC-8248-23C43DCDEF96@fugue.com> <E045AECD98228444A58C61C200AE1BD842614572@xmb-rcd-x01.cisco.com> <E12CF964-53BC-4D05-8B03-3D5543BDC60A@fugue.com>
In-Reply-To: <E12CF964-53BC-4D05-8B03-3D5543BDC60A@fugue.com>
Date: Mon, 28 Apr 2014 19:00:55 +0800
Message-ID: <000c01cf62d1$21c68920$65539b60$@cernet.edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHz29Xah5gSK3gNlrPJIuMg2SittAGPDjalAZVDszYCKNAaUZqzf7QA
Content-Language: zh-cn
X-CM-TRANSID: AQAAf3BL3wTnNF5TgTwFAA--.197S2
X-Coremail-Antispam: 1UD129KBjvJXoWxKw4fAFy3tFWrAr15uryrtFb_yoW3uF1rpa yDKa15Gw1DGw18Xw4xZw1xZryfurWkCFW3GF15GFWjvwn8uryftryS9rW5ZFWxCrn3Ca1Y vF1Y9rWDAas8ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUgjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Jr0_ Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC2 z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4x0Y4 8IcxkI7VAKI48G6xCjnVAKz4kxMxkIecxEwVAFwVW8KwCF04k20xvY0x0EwIxGrwC20s02 6c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF 0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvE c7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aV AFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuY vjxUy77aUUUUU
X-CM-SenderInfo: 51drw3xdqjquphuqv3oohg3hdfq/
Archived-At: http://mailarchive.ietf.org/arch/msg/savi/2YqoiSbLxwQynXBmijo7R9trYOs
Cc: draft-ietf-savi-dhcp@tools.ietf.org, 'SAVI Mailing List' <savi@ietf.org>, 'Jean-Michel Combes' <jeanmichel.combes@gmail.com>
Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mailing list for the SAVI working group at IETF <savi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/savi>, <mailto:savi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/savi/>
List-Post: <mailto:savi@ietf.org>
List-Help: <mailto:savi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/savi>, <mailto:savi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Apr 2014 11:01:19 -0000

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.