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

From: Jean-Michel Combes <[email-masked]>
Date: Tue, 8 Apr 2014 12:15:15 +0200

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.

---

From: Jean-Michel Combes <[email-masked]>
Date: Wed, 16 Apr 2014 18:58:42 +0200

Folks,

just a reminder regarding this WGLC :)

Thanks in advance for your replies.

Best regards,

JMC.

2014-04-08 12:15 GMT+02:00 Jean-Michel Combes <[email-masked]>:

> 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" (

---

From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
Date: Thu, 17 Apr 2014 12:09:10 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: mardi 8 avril 2014 12:15
To: SAVI Mailing List <[email-masked]<mailto:[email-masked]>>
Cc: "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, Ted Lemon <[email-masked]<mailto:[email-masked]>>
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.

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 22 Apr 2014 11:56:51 +0800

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?

We are looking forward to your further comments, thanks!

Best regards,
Guang

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Tuesday, April 22, 2014 12:31 AM
To: Guang Yao
Cc: Eric Levy- Abegnoli (elevyabe); Jean-Michel Combes; SAVI Mailing List;
[email-masked]
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.

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 22 Apr 2014 14:23:44 +0800

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

Best Regards,

Leaf

From: savi [mailto:[email-masked]] On Behalf Of Eric Levy- Abegnoli
(elevyabe)
Sent: Thursday, April 17, 2014 8:09 PM
To: Jean-Michel Combes; SAVI Mailing List
Cc: <[email-masked]>; 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 7.5.2.1

2) Section 7.1 & 7.2

*	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 <[email-masked]>
Date: mardi 8 avril 2014 12:15
To: SAVI Mailing List <[email-masked]>
Cc: "<[email-masked]>"
<[email-masked]>, Ted Lemon <[email-masked]>
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.

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 22 Apr 2014 14:32:54 +0800

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:[email-masked]] 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: [email-masked]; 'Ted Lemon'
Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22

 

<quote>

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

Hi,

Section 7.5.2.1

2) Section 7.1 & 7.2

  Section 7.5.1.2

Eric

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

Folks,

Thanks in advance.

Best regards,

JMC.

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 22 Apr 2014 14:51:29 +0800

Guang - Whenever we use DAD, the messages are not sent to the tentative
node. Thus, SAVI-DHCP is actually different from RFC6620.

I can't read the difference you mentioned here. J

Section 7.5.1.2 @
https://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/?include_text=1 

<quote>The messages MUST NOT be sent to the attachment from which the

   triggering packet is received.</quote>

Section 3.2.3 of RFC6620 @ http://tools.ietf.org/html/rfc6620#section-3.2.3 

<quote>The DAD_NS messages are not

      sent through any of the ports configured as Validating Ports. </quote>

Best Regards,

Leaf

From: Guang Yao [mailto:[email-masked]] 
Sent: Tuesday, April 22, 2014 2:33 PM
To: 'Leaf Yeh'; 'Eric Levy- Abegnoli (elevyabe)'; 'Jean-Michel Combes';
'SAVI Mailing List'
Cc: [email-masked]; 'Ted Lemon'
Subject: RE: [savi] WGLC: draft-ietf-savi-dhcp-22

Hi Leaf and Eric,

Best regards,

Guang

 

<quote>

      milliseconds).

</quote>

 

Best Regards,

Leaf

Hi,

Section 7.5.2.1

2) Section 7.1 & 7.2

  Section 7.5.1.2

Eric

Folks,

Thanks in advance.

Best regards,

JMC.

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 22 Apr 2014 15:02:53 +0800

Well, I didn't read the sentence in RFC6620 you quoted.  If considering this
sentence, they are equivalent (since non-bound NA will be filtered on
Validating port).

Thank you for reminding!

Guang

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

 

I can't read the difference you mentioned here. :)

Section 7.5.1.2 @

 

Best Regards,

Leaf

From: Guang Yao [mailto:[email-masked]] 
Sent: Tuesday, April 22, 2014 2:33 PM
To: 'Leaf Yeh'; 'Eric Levy- Abegnoli (elevyabe)'; 'Jean-Michel Combes';
'SAVI Mailing List'
Cc: [email-masked]
<mailto:[email-masked]> ; 'Ted Lemon'
Subject: RE: [savi] WGLC: draft-ietf-savi-dhcp-22

Hi Leaf and Eric,

Best regards,

Guang

From: savi [mailto:[email-masked]] 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: [email-masked]
<mailto:[email-masked]> ; 'Ted Lemon'
Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22

 

<quote>

      milliseconds).

</quote>

 

Best Regards,

Leaf

Hi,

Section 7.5.2.1

2) Section 7.1 & 7.2

  Section 7.5.1.2

Eric

Folks,

Thanks in advance.

Best regards,

JMC.

---

From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
Date: Tue, 22 Apr 2014 09:21:02 +0000

On 21/04/14 18:31, "Ted Lemon" <[email-masked]> wrote:

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

The issue is not so much whether they have layer-3 capability, but rather
how they are being deployed. The one thing we cannot impose is to have a
layer-3 stack/address in every subnet a switch is operating on. 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.
For LeaseQuery, it's a slightly different issue (should not require one
layer-3 per vlan). It drives quite an operational provisioning complexity:
configuration, security, etc wise. . It is currently not very common to
deploy DHCP on access switches when the L2/L3 boundary is one layer up (on
aggregation/distribution). And I am not talking about the one you have at
home.
Eric

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 21 Apr 2014 10:20:06 +0800

Hi, Eric

Thank you very much for the comments!

1. 

For the first one, considering the whole "data snooping process" is actually
a "conditional should"(s7.1), the DHCP lease query process is actually no
more than a "conditional  should". The "MUST" just specifies if the data
snooping process is to be implemented, the lease query process will be a
MUST.

Besides, it seems there is no good alternative method to set up bindings
without DHCP lease query; however, if DHCP lease query cannot be performed,
the whole data snooping process is meaningless. Thus, we choose "MUST" 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:[email-masked]] 

Hi,

Section 7.5.2.1

2) Section 7.1 & 7.2

  Section 7.5.1.2

Eric

Folks,

Thanks in advance.

Best regards,

JMC.

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 21 Apr 2014 10:34:58 +0800

Hi, Eric

Before we begin modifying the SAVI-DHCP, we find some related text in
RFC6620:

1.

"   MLD Considerations

   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.  Please note that it may not be enough to rely on the host

   behind the Validating Port to do so, since the node may move, and

   after a while, the packets for that particular solicited node

   multicast group will no longer be forwarded to the FCFS SAVI device.

   Therefore, the FCFS SAVI device MUST join the solicited node

   multicast groups for all the addresses that are in a state other than

   NO_BIND.

"

2.

"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]

"

Maybe such designs also violate your comments? Thank you very much!

Best regards,

Guang

From: Guang Yao [mailto:[email-masked]] 
Sent: Monday, April 21, 2014 10:20 AM
To: 'Eric Levy- Abegnoli (elevyabe)'; 'Jean-Michel Combes'; 'SAVI Mailing
List'
Cc: '<[email-masked]>'; 'Ted Lemon'
Subject: RE: [savi] WGLC: draft-ietf-savi-dhcp-22

Hi, Eric

1. 

2.

Best regards,

Guang

Hi,

Section 7.5.2.1

2) Section 7.1 & 7.2

  Section 7.5.1.2

Eric

Folks,

Thanks in advance.

Best regards,

JMC.

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 21 Apr 2014 12:16:51 +0800

Hi, Eric

I realize something is omitted:

"Section  6.4.2.2, paragrap 2.1: 

  the SAVI device MUST send a LEASEQUERY [RFC5007]"

This procedure is not in the data snooping process. I propose revising these
words to:

"the SAVI device MUST send a LEASEQUERY. In case the SAVI device is not
capable of performing the DHCP leasequery process, a DHCP_DEFAULT_LEASE
should be set on the entry."

The DHCP_DEFAULT_LEASE can be set based on the purpose of the operator. If
zero is set, the entry will be deleted. 

Is this OK?

Best regards,

Guang

Hi, Eric

1. 

2.

Best regards,

Guang

Hi,

Section 7.5.2.1

2) Section 7.1 & 7.2

  Section 7.5.1.2

Eric

Folks,

Thanks in advance.

Best regards,

JMC.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Apr 2014 12:31:29 -0400

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.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Apr 2014 07:41:38 -0400

On Apr 22, 2014, at 5:21 AM, Eric Levy- Abegnoli (elevyabe) <[email-masked]> wrote:
> The one thing we cannot impose is to have a
> layer-3 stack/address in every subnet a switch is operating on.

IOW the switch can't have a link-local address per subnet?

> configuration, security, etc wise.

Again, if it's a managed switch, it doesn't make sense that you wouldn't want it to have a routable L3 address.   You might want to constrain what L3 address it has, and yes, there are operational ramifications to this.   But are you saying that you aren't managing the switch?

> . It is currently not very common to

Of course not.   Mine doesn't do leasequery or SAVI.   I was using it as an example of the minimum functionality one might expect in a switch that _does_ do SAVI.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Apr 2014 12:01:24 +0000

> IOW the switch can't have a link-local address per subnet?

[PT] 

I've never fully made up my mind that a vlan is a subnet. E.g., we use private vlans that segregate the subnet in order to isolate some clients or defeat some unwanted linklocal scope broadcast storms (because as we know there's no such a thing as a workable linkscope MLD snooping). This is one of these multilink subnets that are not supposed to exist... 

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. On top of the operator work for CLI and management, there's also all the CPU and memory involved. It's not that the switch can't do it but rather that it's not necessarily a good idea to force the admin to configure an SVI on all vlans.

> Again, if it's a managed switch, it doesn't make sense that you wouldn't want
> it to have a routable L3 address.   You might want to constrain what L3
> address it has, and yes, there are operational ramifications to this.   But are
> you saying that you aren't managing the switch?

[PT] I actually implemented a client to lease query in our SAVI switches, that will revalidate an address as learnt through DHCP.
It turned out that a function like that can rapidly become a real hassle to configure, with dependencies between otherwise unrelated CLIs. 
So yes, there is at least one vlan with an SVI on it in a managed switch, and yes we can use it to source LQ. But it does not mean that it is an easy thing to deploy.
 
> > deploy DHCP on access switches when the L2/L3 boundary is one layer up
> > (on aggregation/distribution). And I am not talking about the one you
> > have at home.
> 
> Of course not.   Mine doesn't do leasequery or SAVI.   I was using it as an
> example of the minimum functionality one might expect in a switch that
> _does_ do SAVI.

[PT] I would not complain that the switch is expected to support the LQ based validation function, though adding a dhcpv6 client to a switch image does not necessarily come for free. It seems to me that the draft goes very deep into the implementation of the guts of the FSM as opposed to the externally observable behavior, and I'm not sure that this particular FSM is the only way to implement the function and get all the necessary interoperation. At least there should be enough options to implement some user policies such as use LQ or not to validate the SAVI state, which, all in all, looks a lot like an operator decision. 

I agree with Guang's proposed change, and maybe we should be documenting the value / risk involved in using LQ or not?

Cheers,

Pascal

> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi

---

From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
Date: Wed, 23 Apr 2014 15:10:45 +0000

Hi Guang,
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.
Sorry that I missed that in 6620.
Eric

From: Guang Yao <[email-masked]<mailto:[email-masked]>>
Date: lundi 21 avril 2014 04:34
To: elevyabe levy-abegnoli <[email-masked]<mailto:[email-masked]>>, 'Jean-Michel Combes' <[email-masked]<mailto:[email-masked]>>, 'SAVI Mailing List' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'Ted Lemon' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [savi] WGLC: draft-ietf-savi-dhcp-22

Hi, Eric

Before we begin modifying the SAVI-DHCP, we find some related text in RFC6620:

1.

“   MLD Considerations

”

2.

“Upon the reception through a Validating Port (VP) of a DATA packet

      5.4.2 of [RFC4862]
”

Best regards,
Guang

From: Guang Yao [mailto:[email-masked]]
Sent: Monday, April 21, 2014 10:20 AM
To: 'Eric Levy- Abegnoli (elevyabe)'; 'Jean-Michel Combes'; 'SAVI Mailing List'
Cc: '<[email-masked]<mailto:[email-masked]>>'; 'Ted Lemon'
Subject: RE: [savi] WGLC: draft-ietf-savi-dhcp-22

Hi, Eric

1.
For the first one, considering the whole “data snooping process” is actually a “conditional should”(s7.1), the DHCP lease query process is actually no more than a “conditional  should”. The “MUST” just specifies if the data snooping process is to be implemented, the lease query process will be a MUST.
Besides, it seems there is no good alternative method to set up bindings without DHCP lease query; however, if DHCP lease query cannot be performed, the whole data snooping process is meaningless. Thus, we choose “MUST” on DHCP lease query process.

2.

Best regards,
Guang

Cc: <[email-masked]<mailto:[email-masked]>>; Ted Lemon

Hi,

2) Section 7.1 & 7.2

Folks,

---

From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
Date: Wed, 23 Apr 2014 15:13:21 +0000

Hi Guang,
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

Date: lundi 21 avril 2014 06:16

Hi, Eric

“Section  6.4.2.2, paragrap 2.1:
  the SAVI device MUST send a LEASEQUERY [RFC5007]”

This procedure is not in the data snooping process. I propose revising these words to:

“the SAVI device MUST send a LEASEQUERY. In case the SAVI device is not capable of performing the DHCP leasequery process, a DHCP_DEFAULT_LEASE should be set on the entry.”

The DHCP_DEFAULT_LEASE can be set based on the purpose of the operator. If zero is set, the entry will be deleted.

Is this OK?

Best regards,
Guang

Cc: [email-masked]<mailto:[email-masked]>; 'Ted Lemon'

Hi, Eric

1.

2.

Best regards,
Guang

Hi,

2) Section 7.1 & 7.2

Folks,

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Apr 2014 11:31:01 -0400

On Apr 23, 2014, at 8:01 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> It seems to me that the draft goes very deep into the implementation of the guts of the FSM as opposed to the externally observable behavior, and I'm not sure that this particular FSM is the only way to implement the function and get all the necessary interoperation.

BTW, I am reluctant to weigh in on this question because I don't think there's energy to do this work.   The level of detail here seems similar to SAVI-send, and while I think in principle you may be right that there are multiple ways to solve this problem, getting the state machine right is actually pretty hard, and required a lot of review from DHCP experts.   I'm not convinced it's completely perfect, but it's improved a lot as a result of this review.   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.   There's always room for a document update later that talks about this if someone gains experience doing it.

---

From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
Date: Wed, 23 Apr 2014 16:10:59 +0000

Hi Guang,

>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

>to

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 24 Apr 2014 14:12:26 +0800

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:[email-masked]] On Behalf Of Eric Levy- Abegnoli
(elevyabe)
Sent: Thursday, April 24, 2014 12:11 AM
To: Guang Yao; 'Ted Lemon'
Cc: [email-masked]; '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" <[email-masked]> 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.
>
>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

>Cc: Eric Levy- Abegnoli (elevyabe); Jean-Michel Combes; SAVI Mailing 
>List; [email-masked]

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 24 Apr 2014 14:22:47 +0800

Hi Eric,

I also wonder a further explanation on the following statement.

<quote>
MLD Considerations

   NO_BIND.

</quote> @ page 20 of RFC6620

If we believe it sounds a wrong message, would you like submit a Errata for
it? J

Best Regards,

Leaf

From: savi [mailto:[email-masked]] On Behalf Of Eric Levy- Abegnoli
(elevyabe)
Sent: Wednesday, April 23, 2014 11:11 PM
To: Guang Yao; 'Jean-Michel Combes'; 'SAVI Mailing List'
Cc: [email-masked]; 'Ted Lemon'
Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22

Hi Guang,

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.

Eric

From: Guang Yao <[email-masked]>
Date: lundi 21 avril 2014 04:34
To: elevyabe levy-abegnoli <[email-masked]>, 'Jean-Michel Combes'
<[email-masked]>, 'SAVI Mailing List' <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, 'Ted Lemon' <[email-masked]>
Subject: RE: [savi] WGLC: draft-ietf-savi-dhcp-22

Hi, Eric

1.

"   MLD Considerations

   NO_BIND.

"

2.

"

Best regards,

Guang

Hi, Eric

1. 

2.

Best regards,

Guang

Hi,

Section 7.5.2.1

2) Section 7.1 & 7.2

  Section 7.5.1.2

Eric

Folks,

Thanks in advance.

Best regards,

JMC.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Apr 2014 11:17:58 -0400

[...]

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

> I agree with Guang's proposed change, and maybe we should be documenting the value / risk involved in using LQ or not?

Can you send text?   :)

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

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 28 Apr 2014 19:00:55 +0800

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.

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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 Apr 2014 13:17:38 +0000

Cheers,

Pascal

> Sent: lundi 28 avril 2014 13:01
> To: 'Ted Lemon'; Pascal Thubert (pthubert)
> 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.
> 
> "1) There seem to be a requirement in several places of the document (see
> 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.
> 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?
> 
> 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.

[PT] An observation that "sync state" is not the perfect wording since the best we can do is re-validate whether the server knows the address but not push a state.
I agree that in the context of DHCP only, snooping makes a lot more sense with LQ; in a general network, though, data snooping is valuable to - at least- discover that there is either a missing state or an usurpation. And from there take action which can be one of Query DHCP server, query other switches, create entry with a low trust level...

Cheers,

Pascal

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 28 Apr 2014 22:17:50 +0800

Hi, Pascal

Thank you very much for these comments!

"[PT] An observation that "sync state" is not the perfect wording since the best we can do is re-validate whether the server knows the address but not push a state.
I agree that in the context of DHCP only, snooping makes a lot more sense with LQ; in a general network, though, data snooping is valuable to - at least- discover that there is either a missing state or an usurpation. "

Guang:
I agree. But there should be some meaningful ways to recover the bindings. Or else, it is meaningless only discovering the trouble. 

"And from there take action which can be one of Query DHCP server, query other switches, create entry with a low trust level..."

Guang:
I can understand you are suggesting possible alternatives, but I'm not sure how "query other switches" works.
"create entry with a low trust level " is not in the scope of this WG.

As you noted, LQ is the most effective and direct way to recover the binding. If LQ is too heavy, maybe a lightweight LQ should be designed. Introducing other mechanisms will make this solution further complicated.

Best regards,
Guang

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Monday, April 28, 2014 9:18 PM
To: Guang Yao; 'Ted Lemon'
Cc: [email-masked]; 'SAVI Mailing List'; 'Jean-Michel Combes'
Subject: RE: [savi] WGLC: draft-ietf-savi-dhcp-22

Cheers,

Pascal

> Cc: [email-masked]; 'SAVI Mailing List'; 
> 'Jean-Michel Combes'
> 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.
> 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?
> 
> Pascal: I'm not sure that this particular FSM is the only way to 
> implement the function and get all the necessary interoperation.
> 
> 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.

Cheers,

Pascal

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 28 Apr 2014 10:19:04 -0400

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:[email-masked]] On Behalf Of Guang Yao
Sent: Monday, April 28, 2014 7:01 AM
To: 'Ted Lemon'; 'Pascal Thubert (pthubert)'
Cc: [email-masked]; 'SAVI Mailing List'; 'Jean-Michel Combes'
Subject: Re: [savi] WGLC: draft-ietf-savi-dhcp-22

Dear folks,

Best regards,
Guang Yao

1. LQ problem

The discussions:

[final decision]

2. MLD problem

The discussions:

[final decision]

3. DAD detection problem 

The discussions:

Eric:

[final decision]: