Subject: [savi] savi-dhcp-02 draft

From: "Bi Jun" <[email-masked]>
Date: Mon, 15 Mar 2010 20:12:36 +0800

Hi all,

This is a revised version of savi-dhcp (revised based on the discussion of 
dhcp-01 on the mailing-list in the past week), basically, make the control 
packet-triggered functions as MUST (low cost to be implemented in every 
switch), and have the data-triggered functions (more complex to be 
implemented) as optional for higher-end switches (to enable more flexible 
use of savi device).

We are consulting the vendors on the cost for those options.

please give us your comments.

thanks,
Jun Bi

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 15 Mar 2010 13:57:49 +0100

Bi Jun a écrit :
>
> Hi all,
>
> This is a revised version of savi-dhcp (revised based on the 
> discussion of dhcp-01 on the mailing-list in the past week), 
> basically, make the control packet-triggered functions as MUST (low 
> cost to be implemented in every switch), and have the data-triggered 
> functions (more complex to be implemented) as optional for higher-end 
> switches (to enable more flexible use of savi device).
>
> Jun Bi SAVI                                                      J. 
> Bi, J. Wu

Hi Jun bi,
Reading the below:

      "IPv6 address:
      Send a LEASEQUERY [RFC5007] message querying by IP address to
      All_DHCP_Relay_Agents_and_Servers multicast address or a
      configured server address. If no successful LEASEQUERY-REPLY is
      received, discard the packet; otherwise generate a new binding
      entry for the address. The SAVI device may repeat this process if
      a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in order
      to set up binding entries for all the address of the client."

I don't think the below proposal to discover IPv6 address from the savi 
device works.  DHCP messages must be sourced with an IPv6 address (can't 
be UNSPEC, must be a link-local) and in most cases, the switch does not 
have any.  That would take the switch to have a L3 interface that 
participate in the link operations (for each of its vlans), and that is 
a huge constrain.
I have real deployment examples of pure L2 switch devices with thousands 
of vlans configured (hundreds of ports in each vlan). Getting a L3 
address in each vlan would have a huge impact on the switch operations 
and performances.That does not seem acceptable.
I think the only option is to discover the binding by probing with a NDP 
DAD NS. This one is sourced with UNSPEC and hence is accpetable for a L2 
device.  Then install the binding as learnt from NDP. And later, 
"prefer" the DHCP binding when/if it shows up.
Eric

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 15 Mar 2010 21:42:29 +0800

Hi Eric,

Thanks for your suggestion. Your experience is very valuable.

In this solution, sending DHCP lease query is optional, just to handle some
special cases (in general, data triggered but rather control packet). It is
not required to be enabled. Vendors may choose to implement it on layer 3
device but not pure layer 2 device. And network administrators may not
enable this function if they find the device may be overloaded.

If binding is learnt from NDP, IMO it should be bound in savi-slaac, but not
in this solution for DHCP. And the which to prefer in case of co-existing of
NDP and DHCP, I think should be specified in the framework doc. Am I right?

BR,
Guang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric
> Levy-Abegnoli
> Sent: Monday, March 15, 2010 8:58 PM
> To: Bi Jun
> Cc: SAVI Mailing List
> Subject: Re: [savi] savi-dhcp-02 draft
> 
> Bi Jun a écrit :
> >
> > Hi all,
> >
> > Jun Bi SAVI
> J.
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 15 Mar 2010 15:13:16 +0100

Hi Guang,

> NDP and DHCP, I think should be specified in the framework doc. Am I right?
What I meant is that the proposed method (sending a leasequery to 
re-discover a binding lost in case of the switch reboot) cannot be used 
as a "general" response to the problem raised. A switch, L2-only device, 
that looses its binding table and has no non-volatile memory has just no 
way to recover it thru DHCP. It's is unfortunate since DHCP is 
considered as the only authoritative method for discovering bindings.
I would consider that at the stage, when DHCP is used, non-volatile 
memory is the only option.
Eric

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 15 Mar 2010 22:35:20 +0800

Hi Eric,

The method that save bindings in non volatile memory is described in section
21. Thanks for your previous suggestion.

The data triggered dhcp lease query is not used to restore previous
bindings, but to set up bindings the device _never_ gets known. The
scenarios include movement on local link, and layer 2 topo changes, as
discussed recently.

BR,
Guang

Eric
> Levy-Abegnoli
> Sent: Monday, March 15, 2010 10:13 PM
> To: Guang Yao
> Cc: 'SAVI Mailing List'

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Mar 2010 17:47:16 +0100

El 15/03/10 15:13, Eric Levy-Abegnoli escribió:
> re-discover a binding lost in case of the switch reboot) cannot be 
> used as a "general" response to the problem raised. A switch, L2-only 
> device, that looses its binding table and has no non-volatile memory 
> has just no way to recover it thru DHCP. It's is unfortunate since 
> DHCP is considered as the only authoritative method for discovering 
> bindings.

How do you deal with the SAVI device not having state due to a change in 
the topology due to an outage?

See the thread called " the impact of SAVI in the overall network 
robustness" for the details

Regards, marcelo

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 15 Mar 2010 18:32:14 +0100

marcelo bagnulo braun a écrit :
> How do you deal with the SAVI device not having state due to a change 
> in the topology due to an outage?
You are describing a problem, not a solution.
Sounds like we have a problem without a solution then. Because 
discovering addresses from the switch by sourcing DHCP messages  is not 
a viable solution. Might work in some cases. Will not in most.
Eric

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Mar 2010 18:35:32 +0100

El 15/03/10 18:32, Eric Levy-Abegnoli escribió:
>>> used as a "general" response to the problem raised. A switch, 
>>> L2-only device, that looses its binding table and has no 
>>> non-volatile memory has just no way to recover it thru DHCP. It's is 
>>> unfortunate since DHCP is considered as the only authoritative 
>>> method for discovering bindings.
right

> discovering addresses from the switch by sourcing DHCP messages  is 
> not a viable solution. Might work in some cases. Will not in most.
could you expand on why it will not work?

I am not sure i have understood it from your previous emails.

Regards, marcelo

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Tue, 16 Mar 2010 13:28:32 +0100

marcelo bagnulo braun a écrit :
>>>> non-volatile memory has just no way to recover it thru DHCP. It's 
>>>> is unfortunate since DHCP is considered as the only authoritative 
>>> How do you deal with the SAVI device not having state due to a 
>>> change in the topology due to an outage?
Here is my concern. If "the" solution to the problem raised with (dhcp) 
savi-switch loosing its relies on generating a LEASEQUERY per rfc5007, 
then this solution requires:
- the switch to act as a DHCP relay (and run a DHCP stack)
- the switch to be configured with a L3 (IPv6) address on each of its 
vlan (need to source the DHCP messages)
There are huge deployments out there where this is a showstopper. Many 
switches are pure L2, whether they don't have the L3 capability, or the 
operator don't want to pay the operation price overhead of enabling IP 
on each of the vlans (large switches can have thousands of vlans and 
enabling L3 have significant operation cost).
I view this constrain on switches as a lot worse than constraining the 
topologie so that the backup switch sees (or is copied) the same traffic 
as the active and/or mandating non-volatile memory, depending on the cases.
Eric

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Tue, 16 Mar 2010 16:18:22 +0100

Hi Guang,
I have a questions regarding both the current draft and this discussion.

1) When you learn a binding by snooping DHCP REQUEST/REPLY, you read the 
client IP address out of the IADDR option, right?
Where do you get the MAC address from in case it is the anchor? Is it 
the SMAC of the request? The DMAC of the server response? Or is it the 
DUID in the clientID option? 

2)When a switch is trying to retrieve bindings that it _never_ knew, per 
the topo changes discussion, it goes to the server with a LEASEQUERY. 
Get back an Address and a ClientID (carrying a DUID). No port, right? So 
in case the anchor is the port, where is it learning the port from in 
this scenario?

3) The DUID carried in the ClientID is _not_ always the SMAC that the 
client will use to source packets for the IP address requested. If you 
disagree with that, I can develop ... So whether in 1) or 2) this cannot 
be used. For 1) we can always use the SMAC of the request (of DMAC of 
the response). For 2), what else do we have?

Thanks for clarifying all these points.
Eric

Guang Yao a écrit :
>>> In this solution, sending DHCP lease query is optional, just to handle
>>>       
> some
>   
>>> special cases (in general, data triggered but rather control packet). It
>>>       
> is
>   
>>> not required to be enabled. Vendors may choose to implement it on layer
>>>       
> 3
>   
>>> If binding is learnt from NDP, IMO it should be bound in savi-slaac, but
>>>       
> not
>   
>>> in this solution for DHCP. And the which to prefer in case of
>>>       
> co-existing of
>   
>>> NDP and DHCP, I think should be specified in the framework doc. Am I
>>>       
> right?
>   
>>> BR,
>>> Guang
>>>
>>>       
>>>>       a LEASEQUERY-REPLY with OPTION_CLIENT_LINK is received, in
>>>>         
>> order
>>     
>>>> device works.  DHCP messages must be sourced with an IPv6 address
>>>>         
>> (can't
>>     
>>>> I have real deployment examples of pure L2 switch devices with
>>>>         
> thousands
>   
>>>> I think the only option is to discover the binding by probing with a
>>>>         
> NDP
>   
>>>> DAD NS. This one is sourced with UNSPEC and hence is accpetable for a
>>>>         
> L2
>

---

From: "Guang Yao" <[email-masked]>
Date: Wed, 17 Mar 2010 19:59:31 +0800

Hi Eric,
> >
> Agreed. For me it's clear that the SMAC is the only option (even when
> the link-layer address is present in the DUID), it may not be the one
> used to source packets with the IP address listed in the IPADDR.
> For nodes with multiple interfaces, they typically have multple SMAC,
> but one DUID.
> I would suggest that you clarify this in the draft.
[Guang Yao] 
Thanks for your suggestion. We will add this specification in the 03 edition
and the presentation of this meeting.

> >
> That clarifies. I guess my only concern with this mechanism is the fact
> that it requires the switch to operate at layer3.
>  _If_ this is a pure layer2 switch (whether it does not have L3
> capability, or the network operator does not want to pay the operation
> price of enabling the layer3, which for me is a real use case, then we
> can't use DHCP LEASEQUERY to resolve the problem of missing  bindings.
> 
[Guang Yao] 
For a pure layer2 device, the savi-datatrigger attribute will not be
implemented. In current draft, it is a "optional" attribute.
As suggested by Joel, in this situation, client should recover binding
itself, e.g., repairing the network connection.

> I would like to know what is the fallback plan then? (the question is
> not just to you but to the WG).
> Personnally, I'd suggest that we do a NDP discovery (NS DAD), and
> eventually, if we snoop a RENEW or REBIND later, replace the entry
> installed thru DAD by the DHCP one (if they are different).
[Guang Yao] 
A problem here is that, if only DHCP address is allowed, this mechanism will
let pass an address not assigned by DHCP. And the SAVI device may have to
wait a RENEW or REBIND for a long time. Maybe we can suggest set a short
DHCP lifetime? Is there any other proposal?

But, at least, in scenarios that DHCP and Slaac both are allowed, it is a
good idea.

> Thanks
> >>> The method that save bindings in non volatile memory is described in
> >>>
> > section
> >
> >>>>> special cases (in general, data triggered but rather control
packet).
> >>>>>
> > It
> >
> >>> is
> >>>
> >>>
> >>>>> not required to be enabled. Vendors may choose to implement it on
> >>>>>
> > layer
> >
> >>> 3
> >>>
> >>>
> >>>>> If binding is learnt from NDP, IMO it should be bound in savi-slaac,
> >>>>>
> > but
> >
> >>> not
> >>>
> >>>
used
> >>>> as a "general" response to the problem raised. A switch, L2-only
> >>>>
> > device,
> >
> >>>> that looses its binding table and has no non-volatile memory has just
> >>>>
> > no
> >
> >>>>>> From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of
> >>>>>>> functions (more complex to be implemented) as optional for
> >>>>>>>
> > higher-end
> >
> >>>>>>       Send a LEASEQUERY [RFC5007] message querying by IP
> address
> >>>>>>
> >> to
> >>
> >>>>>>       entry for the address. The SAVI device may repeat this
process
> > if
> >>>>>> I don't think the below proposal to discover IPv6 address from the
> >>>>>>
> > savi
> >
> >>>>>> be UNSPEC, must be a link-local) and in most cases, the switch does
> >>>>>>
> > not
> >
> >>>>>> participate in the link operations (for each of its vlans), and
that
> >>>>>> address in each vlan would have a huge impact on the switch
> >>>>>>
> > operations
> >