Subject: [savi] Points raised regarding DHCP solution

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Mar 2010 21:32:26 -0400

The large question I raised was whether it was reasonable to treat as 
knowable the question of whether the host is directly connected to the 
SAVI switch.

Regarding the specifics of the presentation, I commented that I consider 
expecting the user to repair his network connection to be unacceptable. 
    Many naive users simply do not even understand that question.

Regarding the suggestion of using short DHCP lease times, this would 
require that we ALWAYS use very short lifetimes, since the lease that 
needs to be short is the one that was sent before the failure.  This 
seems to be a very bad idea.

Yours,
Joel M. Halpern

---

From: "Guang Yao" <[email-masked]>
Date: Wed, 24 Mar 2010 11:04:35 +0800

Hi Joel,

Data-trigger is only used when topo changes or a hub attached with hosts
moves to another link in DHCP case. The first seldom happens. Or users would
have sufficient experience from bad network condition. And the later one, I
think a user that can configure a hub and change the link is not a naive
one.

However, if a pre-knowledge that users are naive is sure, and the layer 2
topo changes frequently, just configure data-trigger on all the possible
anchors.

The second problem, the lease time doesn't have to be very short. It just
requires to be short than the time that all the users learn how to repair
their network connections.

BR,
Guang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joel
> M. Halpern
> Sent: Wednesday, March 24, 2010 9:32 AM
> To: SAVI Mailing List
> Subject: [savi] Points raised regarding DHCP solution
> 
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 23 Mar 2010 21:57:58 -0700

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Tuesday, March 23, 2010 6:32 PM
To: "SAVI Mailing List" <[email-masked]>
Subject: [savi] Points raised regarding DHCP solution

> knowable the question of whether the host is directly connected to the 

May I make my point more clearly?
Switch-host connection is just one easy case to understand that Marcelo's 
case
is not the normal case in real deployment.

I meant, as an administrator, we do know the topology I manage.
In Marcelo's case are very special from deployment view point, because it 
needs
the dual-uplinks to SAVI switches. There are 3 situation I can image if I 
met this
 case as an administrator.

If Switch II is a normal switch owned by the administrator, then because 
enabling the data-triggered functions will cost the administer too much 
money (to buy a higher-end switch), then I will actually upgrade 
savi-software at that normal switch (if only implement control based 
binding, it's very light-weight just like ABC for a switch to upgrade to 
savi, based on our REAL deployment experience), or I can even buy a new low 
cost savi-switch to replace Switch II.

If Switch II is a normal switch but owned by user, then if he do dual 
uplinks, he
has to report to me the administrator because it will change the topology I 
am managing. If I permit, then I know which ports I need to configure to 
enable the
data-triggered functions. If he doesn't report to me, then he will be 
responsible
for his possible broken (one possible way is he repairs his network 
connection). (In reality, I will kindly suggest him to upgrade to 
savi-software.)

If switch II is a hub which is not upgradable. Then the packets are 
boardcasting.
Then SAVI-1 and SAVI-2 can know ALL control packets, then setup equal 
binding table for this hub. Then we actually don't need to enable 
data-triggered functions.

So my conclusion is, in reality, most of Marcelo's consideration won't 
actually happen (I think Fred Baker has the same points when he replied 
Marcelo in the mailing-list). In the worst case, if I have to enable 
data-trigger functions for some cases, I know where to configure it, I don't 
need to enable it at any port of any switch. Therefore, it should not be a 
MUST function in SAVI (both for dhcp and slaac).

Thank you very much !
Jun Bi

> needs to be short is the one that was sent before the failure.  This seems 
> to be a very bad idea.
>
> Yours,
> Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Mar 2010 02:08:58 -0400

Jun, I think I follow part of your comment, and then get lost.

For the topology change argument,it is the case that the SAVI switch 
would have to be receiving STP (or RSTP, or TRILL, or ...) packets on 
the interface on which it is applying SAVI controls.  This is clearly 
detectable, and the SAVI device can complain to management if it is not 
prepared to code with that combination.  Workable.

However, my question is how the SAVI device would determine that there 
is a hub between it and the end user machines.  Should it try to guess 
that the presence of multiple MAC addresses means a hub?  What if only 
one port in the hub is in use?  There are still probably for the system 
caused by the presence of the hub.

Yours,
Joel

Jun Bi wrote:
> Switch-host connection is just one easy case to understand that 
> Marcelo's case
> In Marcelo's case are very special from deployment view point, because 
> it needs
> the dual-uplinks to SAVI switches. There are 3 situation I can image if 
> I met this
> savi, based on our REAL deployment experience), or I can even buy a new 
> low cost savi-switch to replace Switch II.
> 
> has to report to me the administrator because it will change the 
> topology I am managing. If I permit, then I know which ports I need to 
> configure to enable the
> data-trigger functions for some cases, I know where to configure it, I 
> don't need to enable it at any port of any switch. Therefore, it should 
> not be a MUST function in SAVI (both for dhcp and slaac).
> 
> Thank you very much !
> Jun Bi
> 
>>
>> Regarding the specifics of the presentation, I commented that I 
>> consider expecting the user to repair his network connection to be 
>> unacceptable. Many naive users simply do not even understand that 
>> question.
>>

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 23 Mar 2010 23:29:48 -0700

> that the presence of multiple MAC addresses means a hub?  What if only one 
> port in the hub is in use?  There are still probably for the system caused 
> by the presence of the hub.

Dear Jole,

Thank you very much for your reply.

In my last email, I said if in Marcelo's case SWITCH-II is only a hub, then 
because hub will boardcast the packets (duplicate packets to both SAVI1 and 
SAVI2), then both SAVI1 and SAVI2 will know the equal binding by control 
packet based binding, then it will no the problem Marcelo mentioned.

thanks,
Jun Bi

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Tuesday, March 23, 2010 11:08 PM
To: "Jun Bi" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Subject: Re: [savi] Points raised regarding DHCP solution

> For the topology change argument,it is the case that the SAVI switch would 
> have to be receiving STP (or RSTP, or TRILL, or ...) packets on the 
> interface on which it is applying SAVI controls.  This is clearly 
> However, my question is how the SAVI device would determine that there is 
> a hub between it and the end user machines.  Should it try to guess that 
> the presence of multiple MAC addresses means a hub?  What if only one port 
> in the hub is in use?  There are still probably for the system caused by 
> the presence of the hub.
>
> Yours,
> Joel
>
> Jun Bi wrote:
>>
>>
>> has to report to me the administrator because it will change the topology 
>> I am managing. If I permit, then I know which ports I need to configure 
>> to enable the

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Mar 2010 02:49:46 -0400

My final comment, which you quoted, was not concerned with the 
specialized two-switch case.  There are many subtle arguments we can 
have over what the right handling is for the two-switch case.

I am still trying to figure out how the SAVI switch will know if a 
single hub has been placed between it and the client.

Yours,
Joel

Jun Bi wrote:
>> one port in the hub is in use?  There are still probably for the 
>> system caused by the presence of the hub.
> 
> Dear Jole,
> 
> In my last email, I said if in Marcelo's case SWITCH-II is only a hub, 
> then because hub will boardcast the packets (duplicate packets to both 
> SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the equal binding 
> by control packet based binding, then it will no the problem Marcelo 
> mentioned.
> 
> thanks,
> Jun Bi
> 
> 
>> detectable, and the SAVI device can complain to management if it is 
>> not prepared to code with that combination.  Workable.
>>
>> one port in the hub is in use?  There are still probably for the 
>> system caused by the presence of the hub.
>>
>> Yours,
>> Joel
>>
>> Jun Bi wrote:
>>>
>>>
>>>> The large question I raised was whether it was reasonable to treat 
>>>> as knowable the question of whether the host is directly connected 
>>>> to the SAVI switch.
>>>
>>> In Marcelo's case are very special from deployment view point, 
>>> because it needs
>>> the dual-uplinks to SAVI switches. There are 3 situation I can image 
>>> if I met this
>>> If Switch II is a normal switch owned by the administrator, then 
>>> because enabling the data-triggered functions will cost the 
>>> administer too much money (to buy a higher-end switch), then I will 
>>> actually upgrade savi-software at that normal switch (if only 
>>> implement control based binding, it's very light-weight just like ABC 
>>> for a switch to upgrade to savi, based on our REAL deployment 
>>> experience), or I can even buy a new low cost savi-switch to replace 
>>> Switch II.
>>>
>>> topology I am managing. If I permit, then I know which ports I need 
>>> to configure to enable the
>>> So my conclusion is, in reality, most of Marcelo's consideration 
>>> won't actually happen (I think Fred Baker has the same points when he 
>>> replied Marcelo in the mailing-list). In the worst case, if I have to 
>>> enable data-trigger functions for some cases, I know where to 
>>> configure it, I don't need to enable it at any port of any switch. 
>>> Therefore, it should not be a MUST function in SAVI (both for dhcp 
>>> and slaac).
>>>
>>> Thank you very much !
>>> Jun Bi
>>>
>>>>
>>>> require that we ALWAYS use very short lifetimes, since the lease 
>>>> that needs to be short is the one that was sent before the failure.  
>>>> This seems to be a very bad idea.
>>>>
>>>> Yours,
>>>> Joel M. Halpern

---

From: "Bi Jun" <[email-masked]>
Date: Wed, 24 Mar 2010 01:08:19 -0700

sorry for my misunderstanding.
Why you think automatically detecting a hub by a savi switch is so important 
after I have explained in Marcelo's case the hub is no problem ?

thanks,
Jun Bi

Sent: Tuesday, March 23, 2010 11:49 PM

> My final comment, which you quoted, was not concerned with the specialized 
> two-switch case.  There are many subtle arguments we can have over what 
> the right handling is for the two-switch case.
>
> I am still trying to figure out how the SAVI switch will know if a single 
> hub has been placed between it and the client.
>
> Yours,
> Joel
>
> Jun Bi wrote:
>>
>>>> because enabling the data-triggered functions will cost the administer 
>>>> too much money (to buy a higher-end switch), then I will actually 
>>>> upgrade savi-software at that normal switch (if only implement control 
>>>> based binding, it's very light-weight just like ABC for a switch to 
>>>> upgrade to savi, based on our REAL deployment experience), or I can 
>>>> even buy a new low cost savi-switch to replace Switch II.
>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Mar 2010 11:17:38 -0400

The current proposals on the table call for different behaviors (or at 
least different requirements on capabilities) for directly connected and 
indirectly connected SAVI devices.
Thus, the device needs to be able to verify that it is using the right 
capabilities, or is unable to perform its job.
But doing so requires being able to detect the configuration.

Yours,
Joel

Bi Jun wrote:
> Why you think automatically detecting a hub by a savi switch is so 
> important after I have explained in Marcelo's case the hub is no problem ?
> 
> thanks,
> Jun Bi
> 
>>>> is a hub between it and the end user machines.  Should it try to 
>>>> guess that the presence of multiple MAC addresses means a hub?  What 
>>>> if only one port in the hub is in use?  There are still probably for 
>>>> the system caused by the presence of the hub.
>>>
>>> Dear Jole,
>>>
>>> In my last email, I said if in Marcelo's case SWITCH-II is only a 
>>> hub, then because hub will boardcast the packets (duplicate packets 
>>> to both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the 
>>> equal binding by control packet based binding, then it will no the 
>>> problem Marcelo mentioned.
>>>
>>> thanks,
>>> Jun Bi
>>>
>>>
>>>> would have to be receiving STP (or RSTP, or TRILL, or ...) packets 
>>>> on the interface on which it is applying SAVI controls.  This is 
>>>> clearly detectable, and the SAVI device can complain to management 
>>>> if it is not prepared to code with that combination.  Workable.
>>>>
>>>> However, my question is how the SAVI device would determine that 
>>>> there is a hub between it and the end user machines.  Should it try 
>>>> to guess that the presence of multiple MAC addresses means a hub?  
>>>> What if only one port in the hub is in use?  There are still 
>>>> probably for the system caused by the presence of the hub.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> Jun Bi wrote:
>>>>>
>>>>>
>>>>> the dual-uplinks to SAVI switches. There are 3 situation I can 
>>>>> image if I met this
>>>>> implement control based binding, it's very light-weight just like 
>>>>> ABC for a switch to upgrade to savi, based on our REAL deployment 
>>>>> experience), or I can even buy a new low cost savi-switch to 
>>>>> replace Switch II.
>>>>>
>>>>> If Switch II is a normal switch but owned by user, then if he do 
>>>>> dual uplinks, he
>>>>> data-triggered functions. If he doesn't report to me, then he will 
>>>>> be responsible
>>>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup 
>>>>> equal binding table for this hub. Then we actually don't need to 
>>>>> enable data-triggered functions.
>>>>>
>>>>> won't actually happen (I think Fred Baker has the same points when 
>>>>> he replied Marcelo in the mailing-list). In the worst case, if I 
>>>>> have to enable data-trigger functions for some cases, I know where 
>>>>> to configure it, I don't need to enable it at any port of any 
>>>>> switch. Therefore, it should not be a MUST function in SAVI (both 
>>>>> for dhcp and slaac).
>>>>>
>>>>> Thank you very much !
>>>>> Jun Bi
>>>>>
>>>>>>
>>>>>> Regarding the suggestion of using short DHCP lease times, this 
>>>>>> would require that we ALWAYS use very short lifetimes, since the 
>>>>>> lease that needs to be short is the one that was sent before the 
>>>>>> failure.  This seems to be a very bad idea.
>>>>>>
>>>>>> Yours,
>>>>>> Joel M. Halpern

---

From: "Bi Jun" <[email-masked]>
Date: Wed, 24 Mar 2010 11:16:59 -0700

Hi Jole,

thanks for the explanation.

But if the host is connected with a hub, then

(1) as I said in my last email, if it is dual uplinks in marcelo's ppt, it 
will be no problem.

(2) if it is single uplink hub, then under nv-memory storage at savi-switch, 
do we still need data-triggered.

thanks,
Jun Bi

Sent: Wednesday, March 24, 2010 8:17 AM

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Mar 2010 15:20:18 -0400

We are almost at the crux of my concern.
Looking at point 2, we end up saying something along the lines of

A SAVI-DHCP device SHOULD us non-volatile storage for state information 
unless it can know that it is directly connected to the client.

Now, presume that an implementor is trying to comply.  And he builds a 
SAVI-DHCP device that does not have non-volatile storage, because his 
primary market is cases where clients are directly attached.
And it gets sold to someone whose network is primarily used with clients 
directly attached to the SAVI device.  So far so good.

Now suppose that someone, possibly without authority but without 
prohibition, slaps a hub between their station and the SAVI device.  The 
SAVI device is now technically not behaving right.  It can not function 
properly.  If the SAVI device could detect this, I would say "okay, 
generate an alert.  Things happen."  But the SAVI device can't tell. 
(With the dual uplink case, the SAVI device can tell because it gets STP 
over its SAVI enforced ports.)

It is at least somewhat unusual to write a SHOULD where the exception is 
undetectable.

Yours,
Joel

Bi Jun wrote:
> (1) as I said in my last email, if it is dual uplinks in marcelo's ppt, 
> it will be no problem.
> 
> (2) if it is single uplink hub, then under nv-memory storage at 
> savi-switch, do we still need data-triggered.
> 
> thanks,
> Jun Bi
> 
>> least different requirements on capabilities) for directly connected 
>> and indirectly connected SAVI devices.
>>>>>> there
>>>>>> guess that the presence of multiple MAC addresses means a hub?  
>>>>>> For the topology change argument,it is the case that the SAVI 
>>>>>> switch would have to be receiving STP (or RSTP, or TRILL, or ...) 
>>>>>> packets on the interface on which it is applying SAVI controls.  
>>>>>> This is clearly detectable, and the SAVI device can complain to 
>>>>>> management if it is not prepared to code with that combination.  
>>>>>> Workable.
>>>>>>
>>>>>> there is a hub between it and the end user machines.  Should it 
>>>>>> try to guess that the presence of multiple MAC addresses means a 
>>>>>> hub?  What if only one port in the hub is in use?  There are still 
>>>>>>>> The large question I raised was whether it was reasonable to 
>>>>>>>> treat as knowable the question of whether the host is directly 
>>>>>>>> connected to the SAVI switch.
>>>>>>>
>>>>>>> administer too much money (to buy a higher-end switch), then I 
>>>>>>> will actually upgrade savi-software at that normal switch (if 
>>>>>>> only implement control based binding, it's very light-weight just 
>>>>>>> like ABC for a switch to upgrade to savi, based on our REAL 
>>>>>>> deployment experience), or I can even buy a new low cost 
>>>>>>> savi-switch to replace Switch II.
>>>>>>>
>>>>>>> topology I am managing. If I permit, then I know which ports I 
>>>>>>> need to configure to enable the
>>>>>>> data-triggered functions. If he doesn't report to me, then he 
>>>>>>> will be responsible
>>>>>>> for his possible broken (one possible way is he repairs his 
>>>>>>> network connection). (In reality, I will kindly suggest him to 
>>>>>>> upgrade to savi-software.)
>>>>>>>
>>>>>>> If switch II is a hub which is not upgradable. Then the packets 
>>>>>>> are boardcasting.
>>>>>>> won't actually happen (I think Fred Baker has the same points 
>>>>>>> when he replied Marcelo in the mailing-list). In the worst case, 
>>>>>>> if I have to enable data-trigger functions for some cases, I know 
>>>>>>> where to configure it, I don't need to enable it at any port of 
>>>>>>> any switch. Therefore, it should not be a MUST function in SAVI 
>>>>>>> (both for dhcp and slaac).
>>>>>>>
>>>>>>> Thank you very much !
>>>>>>> Jun Bi
>>>>>>>
>>>>>>>>
>>>>>>>> consider expecting the user to repair his network connection to 
>>>>>>>> be unacceptable. Many naive users simply do not even understand 
>>>>>>>> that question.
>>>>>>>>

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 Mar 2010 12:37:32 -0700

As we discussed in private email last week, I'm very concerned at the mention of using non-volatile RAM to store data that is ephemeral in nature. I would far rather find a way to discover the current state of the network, which may be the same or different than the state before the switch restarted, than remember something in non-volatile memory that may or may not be valid at the point it is needed or used.

Let me give you one potential implementation. Consider a switch that for whatever reason is discarding datagrams from a given port because they use an IPv6 source address that is not in its tables. For various reasons, it very likely has a counter, on the switch or VLAN if not on the port itself. It could also maintain a register or FIFO to capture the source IPv6 and MAC addresses this happened on. Without putting the logic for generating the request into the data path, it becomes quite possible for a control plane process to monitor that register and initiate DHCP queries to verify the address and obtain the state from DHCP server. This could be done at a controlled rate per port, to prevent what amounts to a DOS multiplier in which a source address "scan" results in a DHCP query assault on the server.

In the event that a switch restarts, that logic obviously happens across the board. It can result in a burst comparable in size to the number of ports on the switch in a short interval, but that is not a continuing behavior.

On Mar 24, 2010, at 12:20 PM, Joel M. Halpern wrote:

> A SAVI-DHCP device SHOULD us non-volatile storage for state information unless it can know that it is directly connected to the client.
> 
> Now, presume that an implementor is trying to comply.  And he builds a SAVI-DHCP device that does not have non-volatile storage, because his primary market is cases where clients are directly attached.
> And it gets sold to someone whose network is primarily used with clients directly attached to the SAVI device.  So far so good.
> 
> Now suppose that someone, possibly without authority but without prohibition, slaps a hub between their station and the SAVI device.  The SAVI device is now technically not behaving right.  It can not function properly.  If the SAVI device could detect this, I would say "okay, generate an alert.  Things happen."  But the SAVI device can't tell. (With the dual uplink case, the SAVI device can tell because it gets STP over its SAVI enforced ports.)
> 
> It is at least somewhat unusual to write a SHOULD where the exception is undetectable.
> 
> Yours,
> Joel
> 
> Bi Jun wrote:
>> Hi Jole,
>> (1) as I said in my last email, if it is dual uplinks in marcelo's ppt, it will be no problem.
>> (2) if it is single uplink hub, then under nv-memory storage at savi-switch, do we still need data-triggered.
>> thanks,
>> Jun Bi
>>> The current proposals on the table call for different behaviors (or at least different requirements on capabilities) for directly connected and indirectly connected SAVI devices.
>>> Thus, the device needs to be able to verify that it is using the right capabilities, or is unable to perform its job.
>>>> Why you think automatically detecting a hub by a savi switch is so important after I have explained in Marcelo's case the hub is no problem ?
>>>> 
>>>> thanks,
>>>> Jun Bi
>>>> 
>>>>> My final comment, which you quoted, was not concerned with the specialized two-switch case.  There are many subtle arguments we can have over what the right handling is for the two-switch case.
>>>>> 
>>>>> I am still trying to figure out how the SAVI switch will know if a single hub has been placed between it and the client.
>>>>> 
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>> Jun Bi wrote:
>>>>>> 
>>>>>>> is a hub between it and the end user machines.  Should it try to guess that the presence of multiple MAC addresses means a hub?  What if only one port in the hub is in use?  There are still probably for the system caused by the presence of the hub.
>>>>>> 
>>>>>> Dear Jole,
>>>>>> 
>>>>>> In my last email, I said if in Marcelo's case SWITCH-II is only a hub, then because hub will boardcast the packets (duplicate packets to both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will know the equal binding by control packet based binding, then it will no the problem Marcelo mentioned.
>>>>>> 
>>>>>> thanks,
>>>>>> Jun Bi
>>>>>> 
>>>>>> 
>>>>>>> For the topology change argument,it is the case that the SAVI switch would have to be receiving STP (or RSTP, or TRILL, or ...) packets on the interface on which it is applying SAVI controls.  This is clearly detectable, and the SAVI device can complain to management if it is not prepared to code with that combination.  Workable.
>>>>>>> 
>>>>>>> However, my question is how the SAVI device would determine that there is a hub between it and the end user machines.  Should it try to guess that the presence of multiple MAC addresses means a hub?  What if only one port in the hub is in use?  There are still probably for the system caused by the presence of the hub.
>>>>>>> 
>>>>>>> Yours,
>>>>>>> Joel
>>>>>>> 
>>>>>>> Jun Bi wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> The large question I raised was whether it was reasonable to treat as knowable the question of whether the host is directly connected to the SAVI switch.
>>>>>>>> 
>>>>>>>> Switch-host connection is just one easy case to understand that Marcelo's case
>>>>>>>> In Marcelo's case are very special from deployment view point, because it needs
>>>>>>>> the dual-uplinks to SAVI switches. There are 3 situation I can image if I met this
>>>>>>>> If Switch II is a normal switch owned by the administrator, then because enabling the data-triggered functions will cost the administer too much money (to buy a higher-end switch), then I will actually upgrade savi-software at that normal switch (if only implement control based binding, it's very light-weight just like ABC for a switch to upgrade to savi, based on our REAL deployment experience), or I can even buy a new low cost savi-switch to replace Switch II.
>>>>>>>> 
>>>>>>>> If Switch II is a normal switch but owned by user, then if he do dual uplinks, he
>>>>>>>> has to report to me the administrator because it will change the topology I am managing. If I permit, then I know which ports I need to configure to enable the
>>>>>>>> data-triggered functions. If he doesn't report to me, then he will be responsible
>>>>>>>> for his possible broken (one possible way is he repairs his network connection). (In reality, I will kindly suggest him to upgrade to savi-software.)
>>>>>>>> 
>>>>>>>> If switch II is a hub which is not upgradable. Then the packets are boardcasting.
>>>>>>>> Then SAVI-1 and SAVI-2 can know ALL control packets, then setup equal binding table for this hub. Then we actually don't need to enable data-triggered functions.
>>>>>>>> 
>>>>>>>> So my conclusion is, in reality, most of Marcelo's consideration won't actually happen (I think Fred Baker has the same points when he replied Marcelo in the mailing-list). In the worst case, if I have to enable data-trigger functions for some cases, I know where to configure it, I don't need to enable it at any port of any switch. Therefore, it should not be a MUST function in SAVI (both for dhcp and slaac).
>>>>>>>> 
>>>>>>>> Thank you very much !
>>>>>>>> Jun Bi
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Regarding the specifics of the presentation, I commented that I consider expecting the user to repair his network connection to be unacceptable. Many naive users simply do not even understand that question.
>>>>>>>>> 
>>>>>>>>> Regarding the suggestion of using short DHCP lease times, this would require that we ALWAYS use very short lifetimes, since the lease that needs to be short is the one that was sent before the failure. This seems to be a very bad idea.
>>>>>>>>> 
>>>>>>>>> Yours,
>>>>>>>>> Joel M. Halpern

http://www.ipinc.net/IPv4.GIF

---

From: "Bi Jun" <[email-masked]>
Date: Wed, 24 Mar 2010 13:07:34 -0700

Hi Fred and Joel,

I think Fred is proposing to have a counter/statistics triggered alert or 
probe (instead of data-triggered).I do think it's doable.

As I presented in my CERNET2 SAVI deployment report, I reported the SAVI CLI 
or MIBs the vendors implemented, there is a statistics info on the number of 
packet dropped at a specific port (we are showing in the SAVI management 
system' user interface). So the savi-switch can get that counter then do a 
CPU action (rate controllable) by a SNMP trap to manager system or a probe 
(LEASEQUARY or DAD-NS for dhcp; DAD-NS for slaac). It's not data plan 
triggered, so the cost to switch is not too much, and by our experience, the 
vendors will accept to implement it.

thanks,
Jun

thanks,
Jun Bi

--------------------------------------------------
From: "Fred Baker" <[email-masked]>
Sent: Wednesday, March 24, 2010 12:37 PM
To: "Joel M. Halpern" <[email-masked]>
Cc: "Bi Jun" <[email-masked]>; "SAVI Mailing List" <[email-masked]>
Subject: Re: [savi] Points raised regarding DHCP solution

> As we discussed in private email last week, I'm very concerned at the 
> mention of using non-volatile RAM to store data that is ephemeral in 
> nature. I would far rather find a way to discover the current state of the 
> network, which may be the same or different than the state before the 
> switch restarted, than remember something in non-volatile memory that may 
> or may not be valid at the point it is needed or used.
>
> Let me give you one potential implementation. Consider a switch that for 
> whatever reason is discarding datagrams from a given port because they use 
> an IPv6 source address that is not in its tables. For various reasons, it 
> very likely has a counter, on the switch or VLAN if not on the port 
> itself. It could also maintain a register or FIFO to capture the source 
> IPv6 and MAC addresses this happened on. Without putting the logic for 
> generating the request into the data path, it becomes quite possible for a 
> control plane process to monitor that register and initiate DHCP queries 
> to verify the address and obtain the state from DHCP server. This could be 
> done at a controlled rate per port, to prevent what amounts to a DOS 
> multiplier in which a source address "scan" results in a DHCP query 
> assault on the server.
>
> In the event that a switch restarts, that logic obviously happens across 
> the board. It can result in a burst comparable in size to the number of 
> ports on the switch in a short interval, but that is not a continuing 
> behavior.
>
>>>>>>>>> will actually upgrade savi-software at that normal switch (if only

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 Mar 2010 13:14:21 -0700

On Mar 24, 2010, at 1:07 PM, Bi Jun wrote:

> Hi Fred and Joel,
> 
> I think Fred is proposing to have a counter/statistics triggered alert or probe (instead of data-triggered).I do think it's doable.

I suggest it is possible. I can tell you that I once implemented an ethernet switch that used that mechanism in managing its address table - the FIFO (a circular queue in which I logged the source address and port from messages I received) was used as an input to a process that searched for every such address, added them if needed, and by the way aged out addresses that were not used over time. Implementation experience, although dated, says that such an approach is feasible and has the effect of rate-limiting high rate changes.

I would not recommend that the working group specify the implementation. The point of giving a sample implementation is clarity, not requirement.

> As I presented in my CERNET2 SAVI deployment report, I reported the SAVI CLI or MIBs the vendors implemented, there is a statistics info on the number of packet dropped at a specific port (we are showing in the SAVI management system' user interface). So the savi-switch can get that counter then do a CPU action (rate controllable) by a SNMP trap to manager system or a probe (LEASEQUARY or DAD-NS for dhcp; DAD-NS for slaac). It's not data plan triggered, so the cost to switch is not too much, and by our experience, the vendors will accept to implement it.

yes

---

From: "Bi Jun" <[email-masked]>
Date: Wed, 24 Mar 2010 13:23:10 -0700

Yes, I do agree with Fred.

It's not only good for savi-dhcp, but also resolve the problem of 
savi-slaac.
(we do see the problem of data-triggered actions).

Then can we move forward with Fred's proposal?

thanks,
Jun

--------------------------------------------------
From: "Fred Baker" <[email-masked]>
Sent: Wednesday, March 24, 2010 1:14 PM
To: "Bi Jun" <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>; "SAVI Mailing List" 
<[email-masked]>
Subject: Re: [savi] Points raised regarding DHCP solution

> I suggest it is possible. I can tell you that I once implemented an 
> ethernet switch that used that mechanism in managing its address table - 
> the FIFO (a circular queue in which I logged the source address and port 
> from messages I received) was used as an input to a process that searched 
> for every such address, added them if needed, and by the way aged out 
> addresses that were not used over time. Implementation experience, 
> although dated, says that such an approach is feasible and has the effect 
> of rate-limiting high rate changes.
>
> I would not recommend that the working group specify the implementation. 
> The point of giving a sample implementation is clarity, not requirement.
>
>> As I presented in my CERNET2 SAVI deployment report, I reported the SAVI 
>> CLI or MIBs the vendors implemented, there is a statistics info on the 
>> number of packet dropped at a specific port (we are showing in the SAVI 
>> management system' user interface). So the savi-switch can get that 
>> counter then do a CPU action (rate controllable) by a SNMP trap to 
>> manager system or a probe (LEASEQUARY or DAD-NS for dhcp; DAD-NS for 
>> slaac). It's not data plan triggered, so the cost to switch is not too 
>> much, and by our experience, the vendors will accept to implement it.
>
> yes
>
>> thanks,
>> Jun
>>
>> thanks,
>> Jun Bi
>>
>>> nature. I would far rather find a way to discover the current state of 
>>> the network, which may be the same or different than the state before 
>>> the switch restarted, than remember something in non-volatile memory 
>>> that may or may not be valid at the point it is needed or used.
>>>
>>> whatever reason is discarding datagrams from a given port because they 
>>> use an IPv6 source address that is not in its tables. For various 
>>> reasons, it very likely has a counter, on the switch or VLAN if not on 
>>> the port itself. It could also maintain a register or FIFO to capture 
>>> the source IPv6 and MAC addresses this happened on. Without putting the 
>>> logic for generating the request into the data path, it becomes quite 
>>> possible for a control plane process to monitor that register and 
>>> initiate DHCP queries to verify the address and obtain the state from 
>>> DHCP server. This could be done at a controlled rate per port, to 
>>> prevent what amounts to a DOS multiplier in which a source address 
>>> "scan" results in a DHCP query assault on the server.
>>>
>>>> And it gets sold to someone whose network is primarily used with 
>>>> clients directly attached to the SAVI device.  So far so good.
>>>>
>>>> prohibition, slaps a hub between their station and the SAVI device. 
>>>> The SAVI device is now technically not behaving right.  It can not 
>>>> function properly.  If the SAVI device could detect this, I would say 
>>>> "okay, generate an alert.  Things happen."  But the SAVI device can't 
>>>> tell. (With the dual uplink case, the SAVI device can tell because it 
>>>> gets STP over its SAVI enforced ports.)
>>>>
>>>>>> The current proposals on the table call for different behaviors (or 
>>>>>> at least different requirements on capabilities) for directly 
>>>>>> connected and indirectly connected SAVI devices.
>>>>>> Thus, the device needs to be able to verify that it is using the 
>>>>>> right capabilities, or is unable to perform its job.
>>>>>>>> specialized two-switch case.  There are many subtle arguments we 
>>>>>>>> can have over what the right handling is for the two-switch case.
>>>>>>>>
>>>>>>>>> hub, then because hub will boardcast the packets (duplicate 
>>>>>>>>> packets to both SAVI1 and SAVI2), then both SAVI1 and SAVI2 will 
>>>>>>>>> know the equal binding by control packet based binding, then it 
>>>>>>>>> will no the problem Marcelo mentioned.
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> Jun Bi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> only implement control based binding, it's very light-weight 
>>>>>>>>>>> just like ABC for a switch to upgrade to savi, based on our REAL 
>>>>>>>>>>> if I have to enable data-trigger functions for some cases, I 
>>>>>>>>>>> know where to configure it, I don't need to enable it at any 
>>>>>>>>>>> port of any switch. Therefore, it should not be a MUST function 
>>>>>>>>>>> in SAVI (both for dhcp and slaac).
>>>>>>>>>>>
>>>>>>>>>>> Thank you very much !
>>>>>>>>>>> Jun Bi
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> would require that we ALWAYS use very short lifetimes, since 
>>>>>>>>>>>> the lease that needs to be short is the one that was sent 
>>>>>>>>>>>> before the failure. This seems to be a very bad idea.
>>>>>>>>>>>>
>>>>>>>>>>>> Yours,
>>>>>>>>>>>> Joel M. Halpern

---

From: "Bi Jun" <[email-masked]>
Date: Wed, 24 Mar 2010 15:12:11 -0700

Sent: Wednesday, March 24, 2010 12:20 PM

> directly attached to the SAVI device.  So far so good.

After the SAVI meeting, we consult the vendors about the implementation of 
savi switch we bought and are deploying,
the good news is that the vendors actual already save the binding table in 
NV-storage
immediately after the binding set-up, even in a very low-end access switch 
(e.g 3com E026), without our requirement. So there will be no objection from 
vendors. So we could consider to make the NV-storage as MUST in the draft, 
then I think it will satisfy your question.

thanks,
Jun

> generate an alert.  Things happen."  But the SAVI device can't tell. (With 
> the dual uplink case, the SAVI device can tell because it gets STP over 
> its SAVI enforced ports.)
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 29 Mar 2010 17:44:47 +0200

> Let me give you one potential implementation. Consider a switch that for whatever reason is discarding datagrams from a given port because they use an IPv6 source address that is not in its tables.…

let me see if i understand this idea.
The SAVI device will have a counter that will count the number of data 
packets filtered and it will also store the info about the IP address 
that the filtered packets contained.

In addition, it is possible to trigger an action, when the counter 
reaches to a certain threshold.

So, let me see if this works, according to your proposal.
The threshold is set to 1 and the action is to trigger the binding 
creation procedure (either a dhcp query or a DAD NSOL, for the address 
of the packet that was filtered).

So, suppose that a SAVI swithc receives a data packet for which it has 
no binding.
It discards the packet and it increments the counter to 1.
As the counter has reached the threshold, the SAVI will trigger the 
binding creation procedure (either a dhcp query for that address or a 
DAD NSOL for that address).
If succesful, it will create a binding and following data packets will 
be forwarded prperly.

Is that compliant with your description above?

Regards, marcelo

>>> From: "Joel M. Halpern"<[email-masked]>
>>> Cc: "SAVI Mailing List"<[email-masked]>
>>>>> From: "Joel M. Halpern"<[email-masked]>
>>>>> To: "Jun Bi"<[email-masked]>
>>>>> Cc: "SAVI Mailing List"<[email-masked]>
>>>>>>> From: "Joel M. Halpern"<[email-masked]>
>>>>>>> To: "Jun Bi"<[email-masked]>
>>>>>>> Cc: "SAVI Mailing List"<[email-masked]>
>>>>>>>>> From: "Joel M. Halpern"<[email-masked]>
>>>>>>>>> To: "SAVI Mailing List"<[email-masked]>

---

From: "Bi Jun" <[email-masked]>
Date: Tue, 30 Mar 2010 10:55:50 +0800

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Monday, March 29, 2010 11:44 PM
To: "Fred Baker" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Subject: Re: [savi] Points raised regarding DHCP solution

>> the network, which may be the same or different than the state before the
>> the port itself. It could also maintain a register or FIFO to capture the
>> source IPv6 and MAC addresses this happened on. Without putting the logic
>> for generating the request into the data path, it becomes quite possible
>> for a control plane process to monitor that register and initiate DHCP
>> queries to verify the address and obtain the state from DHCP server. This
>> could be done at a controlled rate per port, to prevent what amounts to a
>> DOS multiplier in which a source address "scan" results in a DHCP query
>> assault on the server.
>>
>
> packets filtered and it will also store the info about the IP address that
> the filtered packets contained.
>
> In addition, it is possible to trigger an action, when the counter reaches
> to a certain threshold.
>
> creation procedure (either a dhcp query or a DAD NSOL, for the address of
> the packet that was filtered).
>

Hi Marcelo,

In my option, the threshold value will be set by the network admin.
If I am the network admin, I won't set it to 1, because it's too sensitive.
I may set it as 100, but I think we will provide some experimental value at
our deployment.

As I said in previous emails, I think the threshold triggered CPU action
will
be better than data-packet triggered. Because it will easy for CPU to
control the rate limit. I propose to have the CPU actions triggered by the
threshold
event as follows:
(1) A alert (trap message) to be sent by savi-switch as MUST.
(2) A DAD-NS probe to be sent by L3 savi-switch as MUST (or SHOULD)
(3) A DAD-NS probe to be sent by L2 switch as optional function (but alert
MUST be sent so that the admin can know it).

In addition, I propose to have the NV-storage as MUST when a new binding
entry is created for both L3 or L2 savi-switch (to handle the savi-switch
reboot case).
Based on our investigation, because savi-switch needs the L3 knowledge, if
the switch is the grade of L3 knowledge-able, then it's not hard for it to
save the binding entry (this grade of switch actually already save all the
tables in
NV-storage).

thanks,
Jun Bi

> So, suppose that a SAVI swithc receives a data packet for which it has no
> binding.
> binding creation procedure (either a dhcp query for that address or a DAD
> NSOL for that address).
> If succesful, it will create a binding and following data packets will be
> forwarded prperly.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 30 Mar 2010 05:32:40 +0200 (CEST)

On Wed, 24 Mar 2010, Joel M. Halpern wrote:

> Now suppose that someone, possibly without authority but without prohibition, 
> slaps a hub between their station and the SAVI device.  The SAVI device is 
> now technically not behaving right.  It can not function properly.  If the 
> SAVI device could detect this, I would say "okay, generate an alert.  Things 
> happen."  But the SAVI device can't tell. (With the dual uplink case, the 
> SAVI device can tell because it gets STP over its SAVI enforced ports.)
>

I'd imagine there are a lot of these in standards everywhere. I don't see 
it as a problem, the user did the  wrong thing and when the SAVI device is 
rebooted the user will have to renew their DHCP lease or whatever needs to 
be done to get things working again (rebooting their computer seems to be 
the standard remedy for all problems nowadays :P ).

I don't see the case of not detecting the problem as a reason to make this 
a MUST (if I understood you correctly that you wanted this change?).

SAVI-like functionality for IPv4 has been deployed for 10 years, it works 
exactly like this, people know about it, it's not a major concern, I 
definitely don't see it needing a MUST to solve this specific problem.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Mar 2010 07:53:56 -0400

While such things do happen, they are neither common nor desirable.
When the user action to repair is obvious and simple, we tend to shrug 
and say "ok".  However, in this case the user action required to effect 
repair is not particularly obvious nor well known to most users.  That 
gap is what causes me concern.

It may be that there is no good answer to this issue.  But at the very 
least we need to recognize in the document what class of problem we are 
producing.  And we should be aware that I am not the only person likely 
to consider this problematic.

Yours,
Joel M. Halpern

Mikael Abrahamsson wrote:
> I'd imagine there are a lot of these in standards everywhere. I don't 
> see it as a problem, the user did the  wrong thing and when the SAVI 
> device is rebooted the user will have to renew their DHCP lease or 
> whatever needs to be done to get things working again (rebooting their 
> computer seems to be the standard remedy for all problems nowadays :P ).
> 
> I don't see the case of not detecting the problem as a reason to make 
> this a MUST (if I understood you correctly that you wanted this change?).
> 
> SAVI-like functionality for IPv4 has been deployed for 10 years, it 
> works exactly like this, people know about it, it's not a major concern, 
> I definitely don't see it needing a MUST to solve this specific problem.
>