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

["Guang Yao" <[e-mail]>]

Hi Leaf and Eric,

 

Maybe there are some misunderstandings... In SAVI-DHCP, as I mentioned in
the last letter, we use plain NS rather than DAD NS. Whenever we use DAD,
the messages are not sent to the tentative node. Thus, SAVI-DHCP is actually
different from RFC6620.Actually, I do think sending DAD NS to the tentative
node will cause some problem.

 

Best regards,

Guang

 

From: savi [mailto:[e-mail]] On Behalf Of Leaf Yeh
Sent: Tuesday, April 22, 2014 2:24 PM
To: 'Eric Levy- Abegnoli (elevyabe)'; 'Jean-Michel Combes'; 'SAVI Mailing
List'
Cc: [e-mail]; 'Ted Lemon'
Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22

 

Eric - Section 7.5.1.2 - 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.).

 

 

As for IPv6 address, I suppose the switch employs the same  process as that
described in section 3.2.3 of RFC6620, page 15 @
http://tools.ietf.org/html/rfc6620#section-3.2.3 

 

<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 as described in Section
<http://tools.ietf.org/html/rfc6620#section-5.4.2> 

      5.4.2 <http://tools.ietf.org/html/rfc6620#section-5.4.2>  of [RFC4862
<http://tools.ietf.org/html/rfc4862> ] for the IPAddr using the following
default

      parameters: DupAddrDetectTransmits set to 2 (i.e., 2 Neighbor

      Solicitation messages for that address will be sent by the SAVI

      device) and RetransTimer set to T_WAIT milliseconds (i.e., the

      time between two Neighbor Solicitation messages is T_WAIT

      milliseconds).

</quote>

 

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

 

 

Best Regards,

Leaf

 

 

 

From: savi [mailto:[e-mail]] On Behalf Of Eric Levy- Abegnoli
(elevyabe)
Sent: Thursday, April 17, 2014 8:09 PM
To: Jean-Michel Combes; SAVI Mailing List
Cc: <[e-mail]
<mailto:[e-mail]> >; Ted Lemon
Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22

 

Hi,

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

 

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).

 

Section  6.4.2.2, paragrap 2.1: 

  the SAVI device MUST send a LEASEQUERY [RFC5007]

Section 7.5.2.1

  IPv4 address: Send a DHCPLEASEQUERY [RFC4388]

 IPv6 address: Send a LEASEQUERY [RFC5007]

 

2) Section 7.1 & 7.2

"To perform this process, the SAVI device 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 on top of every link it is bridging/switching. It has to snoop ND
traffic, like it snoops DHCP traffic. 

  Section 7.5.1.2

*	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.).

Eric

 

From: Jean-Michel Combes <[e-mail]
<mailto:[e-mail]> >
Date: mardi 8 avril 2014 12:15
To: SAVI Mailing List <[e-mail] <mailto:[e-mail]> >
Cc: "<[e-mail]
<mailto:[e-mail]> >"
<[e-mail]
<mailto:[e-mail]> >, Ted Lemon <[e-mail]
<mailto:[e-mail]> >
Subject: [savi] WGLC: draft-ietf-savi-dhcp-22

 

Folks,

As it has been deeply modified since the last WGLC (version -06), this is a
new two weeks 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 forward the document, comments, etc.)!

Thanks in advance.

Best regards,

JMC.