<quote>The =
messages MUST NOT be sent to the attachment from which =
the
<quote>The =
messages MUST NOT be sent to the attachment from which =
the
“   MLD =
Considerations
“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]
=93   M=
LD Considerations
=93Upon the recep=
tion 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 Duplica=
te Address Detection process as described in Section
      5.4.2 of [R=
FC4862]
=94

Maybe such designs also violate yo=
ur comments? Thank you very much!

Best regards,
Guang

From: Guang Yao [mailto:yaoguang@cernet.edu.cn]

Sent: Monday, April 21, 2014 10:20 AM

To: 'Eric Levy- Abegnoli (elevyabe)'; 'Jean-Michel Combes'; 'SAVI Ma=
iling List'

Cc: '<draf=
t-ietf-savi-dhcp@tools.ietf.org>'; 'Ted Lemon'

Subject: RE: [savi] WGLC: draft-ietf-savi-dhcp-22<=
/p>

Hi, Eric

Thank you very much for the commen=
ts!

1.

For the first one, considering the=
 whole =93data snooping process=94 is actually a =93conditional should=94(s=
7.1), the DHCP lease query process is actually
 no more than a =93conditional  should=94. The =93MUST=94 just specifi=
es if the data snooping process is to be implemented, the lease query proce=
ss will be a MUST.
Besides, it seems there is no good=
 alternative method to set up bindings without DHCP lease query; however, i=
f DHCP lease query cannot be performed,
 the whole data snooping process is meaningless. Thus, we choose =93MUST=94=
 on DHCP lease query process.

2.
We fully accept the second comment=
 and will revise the doc accordingly.

Best regards,
Guang

From: Eric Levy- Abegnoli (elevyabe) [mailto:elevyabe@cisco.com]

Sent: Thursday, April 17, 2014 8:09 PM

To: Jean-Michel Combes; SAVI Mailing List

Cc: <draft=
-ietf-savi-dhcp@tools.ietf.org>; Ted Lemon

Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22<=
/p>

Hi,

In general, the document looks good. I spot=
 a few substantial issues listed below:

1) There seem to be a requirement in severa=
l 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 DH=
CP 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 en=
try for instance).

Section  6.4.2.2, paragrap 2.1: <=
o:p>

  the SAVI device MUST send a LEA=
SEQUERY [RFC5007]

Section 7.5.2.1

  IPv4 address: Send a DHCPLEASEQUERY =
[RFC4388]

 IPv6 address: Send a LEASEQUERY [RFC5=
007]

2) Section 7.1 & 7.2<=
/p>

"To perform this process, the SAVI dev=
ice MUST join the Solicited Node

   Multicast group of the source =
address of triggering IPv6 data packet

   whenever performing duplicate =
detection."

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 o=
n top of every link it is bridging/switching.
 It has to snoop ND traffic, like it snoops DHCP traffic. <=
/span>

  Section 7.5.1.2

I won=
der what would be the end-result if the switch send a DAD or and ARP and th=
e legitimate owner interpret it as "someone already has the address&qu=
ot; (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 norm=
al DAD or ACD packets.  (some field in the header? But that would be a=
 protocol change=85).

Eric

From:
Jean-Michel Combes <jeanmichel.combes@gmail.com>

Date: mardi 8 avril 2014 12:15

To: SAVI Mailing List <savi@ietf=
.org>

Cc: "<draft-ietf-savi-dhcp@tools.ietf.org>" <draft-ietf-savi-dhcp@tools.ietf.org&=
gt;, Ted Lemon <mellon@fugue.com=
>

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

Folks,<=
/o:p>

As it has be=
en deeply modified since the last WGLC (version -06), this is a new two wee=
ks WGLC for the following document: "SAVI
 Solution for DHCP" (http://tools.ietf.org/html/draft-ietf-savi-dhcp-22).=

Please, don'=
t hesitate to give your opinion (i.e., agreement/disagreement to move forwa=
rd the document, comments, etc.)!

Thanks in ad=
vance.

Best regards=
,

JMC.

<quote>
MLD Considerations
“   =
MLD Considerations
“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]