Subject: Re: [savi] call for comments: savi-dhcp-01

From: "Jun Bi" <[email-masked]>
Date: Mon, 8 Mar 2010 17:14:48 +0800

Hi Marcelo,

During my presentation at IETF76, some people commented that
 it took much effort for SAVI-device to send probe packets to
handle the special case. Then in this dhcp-01 version,
we make the solution for the most recommended use case: the host
directly attached to savi device. We hope we could reach
consensus on this part then we could go further to discuss the
situation when legacy switch involved (does the cost matches the benefit?).
It also needs the savi-framework to state the user's scenarios.

thanks,
Jun Bi

>
>
> --------------------------------------------------
> From: "marcelo bagnulo braun" <[email-masked]>
> Sent: Monday, March 08, 2010 4:33 PM
> To: <[email-masked]>
> Subject: Re: [savi] call for comments:  savi-dhcp-01
>
>> Hi,
>>
>> I have a question that it was not apparent to me from the draft
>>
>> Suppose the following configuration:
>>
>> +------+      +-------------+       +-----------+       +---------------+
>> | Host |------|Legacy device|-------|SAVI device|-------|rest of the net|
>> +------+      +-------------+       +-----------+       +---------------+
>>
>> Suppose the host connects, does the DHCP exchange and the SAVI device 
>> creates the binding.
>> Suppose now that the SAVI device loose the state (e.g. it reboots or 
>> crashes)
>>
>> What happens next? Is the SAVI device able to recover the binding 
>> information?
>>
>> I guess some of the info is stored in the dhcp server, but probably not 
>> all of it (i.e.
>> the lower layer anchor info may not be present)
>>
>> Regards, marcelo
>>
>>
>>
>>
>> El 03/03/10 13:18, Bi Jun escribió:
>>> Dear WG members,
>>> This is the 01 version of savi-dhcp solution.
>>> Comments please.
>>> Thank you very much!
>>> Jun Bi
>>>
>>>
>>> _______________________________________________
>>> savi mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/savi
>>>
>>
>> _______________________________________________
>> savi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/savi
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 08 Mar 2010 10:29:26 +0100

Hi Jun,

Thanks for the answer.

So, your proposal is to simply rule out this scenario and make dhcp
based savi to require that all hosts are directly connected tot he SAVI
device?

I think this would significantly limit the solution applicabillity and
the chances of its deployment (it basically will require to upgrade most
of the switches in the network in order to run SAVI).

I don't believe this is a good approach. I think we need to define a
SAVI solution that allows for incremental deployment in the network, if
we want this to happen.

So commenting on you reply below...

El 08/03/10 10:14, Jun Bi escribió:
> handle the special case.
I don't recall that disucssion, probably i missed that one

So, could you explain to me how would you deal with that case by probing?

I mean, it is not obvious to me how the SAVI device knows who to probe,
since it has lost its state

> Then in this dhcp-01 version,
> directly attached to savi device. 
I don't think we cna limit ourselves to this specific case, as i
mentioned before
> We hope we could reach
> situation when legacy switch involved 
not sure what do you mean here...
I agree we need to discuss this and get consensus to move forward.

> (does the cost matches the benefit?).
I also agree this should be part of the framework document.

Regards, marcelo

>>> Suppose the host connects, does the DHCP exchange and the SAVI
>>> device creates the binding.
>>> I guess some of the info is stored in the dhcp server, but probably
>>> not all of it (i.e.

---

From: "Bi Jun" <[email-masked]>
Date: Mon, 8 Mar 2010 18:16:26 +0800

Hi Marcelo,

You actually bring two questions.

One question is on deployment: can we deploy a solution on legacy switch.
Another is on the user's scenario: do we need to support the case when 
latency switch is involved.

For question 1, my point is: if the solution is very simple and just need
to upgrade a software version, doesn't need to change hardware, then it will 
be yes.
The current savi-dhcp-01 is very easy to be implemented by software-only (it 
has been
proved by several switch vendors by real products, which I will report at 
IETF77),  Then it will be very easy for users to deploy it on his current 
(legacy) switch,
where CERNET is deploying it. Moreover, if the legacy switch is too old to 
upgrade
the software, because the life time of access switch hardware is about 3 
years, then
when the user purchase a new switch, the switch will be upgraded.

If the answer of question 1 is yes, then the in the most cases, then 
scenario of question 2 is less important. So my point is that we need to 
evaluate if the cost (brought to switch) matches the benefit. My proposal is 
to have one RFC for one scenario that we have consensus(e.g. the host 
directly attached to the savi switch), then if it is really needed, having 
another RFC for more complicated cases (maybe because the cost to switch, 
not many vendors really implement in the real world in recent years). 
Certainly, the scenarios will be presented in savi-framework.

By the way, the probe in my previous email meant that the savi-device send 
out packets (dad-ns, confirm, etc) to host/or might to dhcp server, 
triggered by data packets or timers. It was used to handle the case when 
host moving (and other cases) under legacy switch in my last presentation at 
IETF, it seemed that people think triggering those probes make the switch 
too complex (Joe, etc.) and the vendors also don't like the data-packet 
triggered actions based on the feedbacks when we work with vendors in the 
past months (H3C, ZTE, Ruijie, DC, etc..).

thanks,
Jun Bi
--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Monday, March 08, 2010 5:29 PM
To: "Jun Bi" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] call for comments:  savi-dhcp-01

> So, could you explain to me how would you deal with that case by probing?

Please read my ppt in IETF76 meeting.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 08 Mar 2010 11:33:48 +0100

below...

El 08/03/10 11:16, Bi Jun escribió:
> to upgrade a software version, doesn't need to change hardware, then
> it will be yes.
In any case, this approahc would impose an upgrade of most of the
switches in the network.
I argue that this may be feasible in some scenarios and not in others.
A couple of examples.

Suppose you are providing serv ice for a cmapus network and everybody
has these small hub switches in their offices, and that is perfeclty ok
with the security policy (this is the case of my university for instance)
We have a variety of small hubs, some of them are fairly old. Moreover,
some people are running virtual machines in their computers, do the hubs
is actually virtual. In this scenario, which i would argue is fairly
common, it is not trvial to update all the switches.

A second case may be the one of the dsl forum. their goal is to run savi
in the CPE. Now, many ISPs have no problem allowing the user to connect
a switch to their CPE. The thing here is that the ISP wants to deploy
SAVI, but it can certainly not mandate their cusotmers to update their
home switches.

So, i still don't think we can simply dismiss this scenario

> The current savi-dhcp-01 is very easy to be implemented by
> software-only (it has been
> proved by several switch vendors by real products, which I will report
> at IETF77), Then it will be very easy for users to deploy it on his
> current (legacy) switch,
> where CERNET is deploying it. Moreover, if the legacy switch is too
> old to upgrade
> the software, because the life time of access switch hardware is about
> 3 years, then

well, where i come from we don't upgrade office hubs every 3 years, i
can tell you that for sure.

> scenario of question 2 is less important. So my point is that we need
> to evaluate if the cost (brought to switch) matches the benefit. My
> proposal is to have one RFC for one scenario that we have consensus
i am not sure what do you mean we have consensus. I agree we need to
support this scenario, but we certainly do not have consensus on having
a solution that only supports this particular scenario

second, i am so far only talking about the dhcp based savi, in the case
of ND based savi the issues are far more severa and the soltion is
likely to support any scenario in any case.

So, i don't agree with your proposed way froward

> (e.g. the host directly attached to the savi switch), then if it is
> really needed, having another RFC for more complicated cases (maybe
> because the cost to switch, not many vendors really implement in the
> real world in recent years). Certainly, the scenarios will be
> presented in savi-framework.
>
> By the way, the probe in my previous email meant that the savi-device
> send out packets (dad-ns, confirm, etc) to host/or might to dhcp
> server, triggered by data packets or timers.
mm, so you mean that if the SAVI device receives a data packet for which
it does not have a binding, it sends the DHCP CONFIRM to the dhcp server
to see if the server validates it, it that what you meant?

that seems reasonable to me

> It was used to handle the case when host moving (and other cases)
> under legacy switch in my last presentation at IETF, it seemed that
> people think triggering those probes make the switch too complex (Joe,
> etc.) and the vendors also don't like the data-packet triggered
> actions based on the feedbacks when we work with vendors in the past
> months (H3C, ZTE, Ruijie, DC, etc..).
>
i can see that, but the question is what the overall robustness and
deployability of the alternative solution. that is imho what we need to
duscuss and understand.

Regards, marcelo

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 8 Mar 2010 12:16:50 +0100 (CET)

> SAVI, but it can certainly not mandate their cusotmers to update their 

Requiring home equipment to be rebooted or at least their dhcp lease 
renewed after an upgrade of the home gateway I think is no major problem.

If I understood the problem correctly you're worried about the end user 
outage occuring from the SAVI device is rebooted until all clients have 
renewed their DHCP bindings so the SAVI device can filter correctly?

What about recommending the SAVI device to save its state regularily (and 
before each reboot) to non volatile storage so it properly can keep SAVI 
state across reboots/power outage? Guess this might be hard to implement 
as only storage regularily used in these devices are flash drives and one 
doesn't really want to write to them all the time?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Bi Jun" <[email-masked]>
Date: Mon, 8 Mar 2010 19:24:09 +0800

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Monday, March 08, 2010 6:33 PM
To: "Bi Jun" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] call for comments:  savi-dhcp-01

> I argue that this may be feasible in some scenarios and not in others.

Actually, the savi-switches are independent. Deployment on one switch 
doesn't rely on
the deployment of other switches. So you don't need to change most switches, 
you upgrade one, then get one benefit, it's incremental deployment.

> common, it is not trvial to update all the switches.

Please note that the savi-dhcp-01 could handle the hub connection in normal 
cases.
You are actually taking about how to handle special cases.

If you are the administrator (like us), if you enforce SAVI, then you can 
ask
the users directly attached hosts to savi-switch. If some users still want 
the flexibility with a hub, then in the MOST cases there will be no problem 
(the reboot
of savi-switch in your example will be very low frequent event), then if you 
found the network has the problem, you just need to reboot your hub, you 
want the flexibility then you pay it by rebooting your own hub. We didn't 
see any problem
in our real deployment. It's the user's normal behavior in today's internet, 
if you meet a problem, you plug off you cable and plug in again.

Remember the "end-end argument" of system design: "If the application can do 
it, don’t do it at a lower layer -- anyway the application knows the best 
what it need", that's the successful philosophy of Internet. So don't make 
the system too complex to handle special cases. That's why I said we need to 
evaluate the cost and benefit.

BTW, I agree that for high-end switch, we can ask them to do more with a 
bigger solution to handle all special cases (even the special cases are low 
frequency events), that's why I said maybe we might need two RFCs (one 
simple/low cost solution for most cases, another ideal but high cost 
solution for all cases).

> SAVI, but it can certainly not mandate their cusotmers to update their

Currently, DSL is a separate scope.

> likely to support any scenario in any case.

I really doubt on a big solution trying to resolve any problems in any 
scenarios, sometimes might means impossible in engineering/practice (too 
complex to be implemented at least in most devices).

> that seems reasonable to me

Yes, we can have some way to handle it. In my last PPT in IETF76, I 
presented lots
of similar solutions.
But I still think it's not good to bring too much cost to the savi-device 
which are low-end access switch in most cases, just for some very special 
event (which can be simply fixed by users).

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 8 Mar 2010 19:53:44 +0800

Hi Mikael,

Thank you very much for you advice, we will add this (saving savi state) in 
to savi-dhcp-01 as one option.

Best Regards,
Jun Bi

--------------------------------------------------
From: "Mikael Abrahamsson" <[email-masked]>
Sent: Monday, March 08, 2010 7:16 PM
To: <[email-masked]>
Subject: Re: [savi] call for comments:  savi-dhcp-01

>> in the CPE. Now, many ISPs have no problem allowing the user to connect a 
>> switch to their CPE. The thing here is that the ISP wants to deploy SAVI, 
>> but it can certainly not mandate their cusotmers to update their home 
>> switches.
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 08 Mar 2010 14:47:09 +0100

El 08/03/10 12:16, Mikael Abrahamsson escribió:
>> A second case may be the one of the dsl forum. their goal is to run 
>> savi in the CPE. Now, many ISPs have no problem allowing the user to 
>> connect a switch to their CPE. The thing here is that the ISP wants 
>> to deploy SAVI, but it can certainly not mandate their cusotmers to 
>> update their home switches.
>
mmm, not sure this is what we are talking about.
we are talking about two things:
- one,is that host would need to renw their dhcp lease after the savi 
device is rebooted. the problem here is that the host may not know hwne 
the AVI device is rebooted, so it will loose connectivity after a reboot 
and not clear how to trouble shoot that
- the other thing is that switches connected to the device that is 
implementing SAVI will need to be upgraded, in order to be SAVI capable.

So, it is either updating equiement (posible that belong to the end 
user) or rebooting the hosts of the client when the SAVI device reboots 
(which is not clearly how to realize when that is needed)

> If I understood the problem correctly you're worried about the end 
> user outage occuring from the SAVI device is rebooted until all 
> clients have renewed their DHCP bindings so the SAVI device can filter 
> correctly?
>
right

> What about recommending the SAVI device to save its state regularily 
> (and before each reboot) to non volatile storage so it properly can 
> keep SAVI state across reboots/power outage? Guess this might be hard 
> to implement as only storage regularily used in these devices are 
> flash drives and one doesn't really want to write to them all the time?
>
that would be my guess... i expect that the SAIV binding information may 
be quite dynamic and storing it in non volatile memory would be 
challenging. I mean, if problems of loosing state could be solved by 
sotring it in non volatile memory, life would be much easeir, we 
wouldn't need RST in TCP, ongoing communications woudl be able to 
survive reboots of nat boxes and firewalls and so on...

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 08 Mar 2010 15:03:11 +0100

El 08/03/10 12:24, Bi Jun escribió:
> the deployment of other switches. So you don't need to change most
> switches, you upgrade one, then get one benefit, it's incremental
> deployment.
>
>

not really

If SAVI switches reboots imply that the communication will be
interrupted unless all switches are upgraded to support SAVI, then if
you only replace one switch, then you are breaking your netwokr. So in
order to work properly, you need to upgrade all the network.
So, this is not incrementally deployable
> Please note that the savi-dhcp-01 could handle the hub connection in
> normal cases.
what do you mean normal and special cases?
I am talking about a case where the savi switch reboots, there is
nothing special about it. My CPE at home is rebooted several times a
week, while my laptop none.

> If you are the administrator (like us), if you enforce SAVI, then you
> can ask
> the users directly attached hosts to savi-switch. 

sure, but i guess we want to define a solution that can be used by a
wider client base that can include other needs, right?

> If some users still want the flexibility with a hub, then in the MOST
> cases there will be no problem (the reboot
> of savi-switch in your example will be very low frequent event),

what do you mean that a reboot of a device is not a frequent event?
What is being argued here is that after a reboot in a switch all hosts
will be disconnected from the network. What is the reliability of the
resulting network?

> then if you found the network has the problem, you just need to reboot
> your hub, you want the flexibility then you pay it by rebooting your
> own hub.
No, if we want reliability, we design a protocol properly, in order to
make reliable.
I find hardly aceptbale to say that if you want reliability, you must
manually reboot all the hubs in my office in random moments.

what about if you are using a remote sessiona dn you are not physically
on your office to reboot it?

> We didn't see any problem
> in our real deployment. It's the user's normal behavior in today's
> internet, if you meet a problem, you plug off you cable and plug in
> again.
>
I guess we simply disagree here.
I believe in the end to end principle and all the other deisgn
architectural principles that aim to provide reliable end to end
communications. "manually reboot you hub" is not the way i think we
should design a protocol, sorry.

> Remember the "end-end argument" of system design: "If the application
> can do it, don’t do it at a lower layer 

????

the end to end principle has a simple corolary that is the fate sharing
corolary, which reccomend not to include state in the network that is
require for the end to end cmmunication, so that the fate of the end
host does not depends on the date of the soft state stored in the network.

Following an approach where there is some state (i.e. the SAVI binding)
that is stored in the network and that cannot be recovered automatically
and requires manual intervention, clearly breaks the fate sharing
principle and hence the end to end argument.

> -- anyway the application knows the best what it need", that's the
> successful philosophy of Internet. So don't make the system too
> complex to handle special cases. That's why I said we need to evaluate
> the cost and benefit.
>
> BTW, I agree that for high-end switch, we can ask them to do more with
> a bigger solution to handle all special cases (even the special cases
> are low frequency events), that's why I said maybe we might need two
> RFCs (one simple/low cost solution for most cases, another ideal but
> high cost solution for all cases).
>
again, i disagree, i don't think the ietf shoudl have a stnadrad track
rfc that relies on users manually rebooting their hubs in order to recover

> Currently, DSL is a separate scope.

how come?
i understood the the dsl forum was planing to use the SAVI specs
> scenarios, sometimes might means impossible in engineering/practice
> (too complex to be implemented at least in most devices).
>
i eprsonally doubt of a soluton that significantly reduces the
reliability of the netowkr architecture that we have

> But I still think it's not good to bring too much cost to the
> savi-device which are low-end access switch in most cases, just for
> some very special event (which can be simply fixed by users).
>
>

but, what is the cost of a solution that is non relibale? how much is
the cost of dowtime of the internet access? how much is the cost of
having to update or upgrade all the legacy equipment?

I mean, it makes no sense to say that one solution is expensive, we need
to compare the different costs.
IMHO, high reliability and backward compatibility are much better options.

Regards, marcelo

>>>>>>> | Host |------|Legacy device|-------|SAVI device|-------|rest of
>>>>>>> the
>>>>>>> net|

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 8 Mar 2010 22:42:14 +0800

Sent: Monday, March 08, 2010 10:03 PM

> So, this is not incrementally deployable

I can't agree your statement
I upgrade one access switch, enable the savi at ports that directly attach
a host. For other ports, I can decide to enable savi or not, how the this 
switch affects other switches and how it breaking my network?

> week, while my laptop none.

Certainly in an operational enterprise network or a campus network, the 
reboot of the switch will not frequent.

> should design a protocol, sorry.

I said the most recommended use case is for host directly attached to savi 
switch
in savi-dhcp-01. In this case, it's reliable.
If you want the flexibility, you can still plug in your hub, we can 
mentioned this risk in the draft, but we don't recommend.
A separate RFC might be considered if need to cover more use case with 
higher cost if the users really need (although I really doubt if it could be 
really implemented in the real work).

This is also my answer to your most similar questions below.

> i understood the the dsl forum was planing to use the SAVI specs

For DSL, it was just discussed by Mikael.
And I just sent email saying that we agree to adopt the advice from Mikael 
by storing the state if the device before savi reboot. Thanks to Mikael.

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 8 Mar 2010 23:11:10 +0800

Hi Marcelo,

The storing states before savi device rebooting
is adopted at the latest version of savi-dhcp-01 to be submitted to ietf,
to make it reliable to handle your example.

I remember Eirc had a similar suggestion.
Thanks to Mikael and Eric.

Best Regards,
Jun Bi

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 9 Mar 2010 14:19:34 +0800

IMO, if a savi device wants to restore state of not directly attached
clients from reboot, which means no control packet can be used to restore
binding, only two mechanisms can be chosen:
1. Use data packet to trigger binding set up. Then the additional overhead
is mainly cpu cost. The cost is not only resulted from the added complexity,
but also a possible data packet burst that may cause denial of service on
cpu, and the complexity logic of filtering a single packet(you can't filter
any packet until assured by server or probe in slaac scenario).
2. Store state into non violate storage manually or regularly. Then the
additional overhead is mainly storage cost.

If I can't avoid choosing one from them, I'd rather choose the second
mechanism, as suggested by Mikael Abrahamsson and Eric Levy-Abegnoli. In
general, storage chip is cheaper than processing chip.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mikael Abrahamsson
> Sent: Monday, March 08, 2010 7:17 PM
> To: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 9 Mar 2010 07:54:50 +0100 (CET)

On Mon, 8 Mar 2010, marcelo bagnulo braun wrote:

> order to work properly, you need to upgrade all the network. So, this is 
> not incrementally deployable

Hi Marcelo.

I very quickly read draft-bagnulo-savi-analysis-02.txt as you recommended, 
and as far as I can see, everything in it is correct. I guess we just see 
differently on the implications on network maintenance and stability.

I come from an ISP background and have that point of view, I don't trust 
my customers and they have no certificate or other to verify that I am who 
I am, and my customers definitely can't trust each other. Therefore I try 
to make sure that traffic between customers does a route hop thru my 
equipment, so basically there is no L2 connectivity between customers. I 
also need to know what customer/port has what IP at any given time, which 
for me means I have to use stateful DHCP so I can store this binding. 
SLAAC is just not acceptable in this scenario (because of TCAM limitations 
in my equipment I don't want my equipment connected to a customer /64 
without limitations on IPs used).

We today have this problem with the bindings, especially if the customer 
has a switch in their apartment. If we reboot the basement switch, the 
computers won't know that via link-down, and the DHCPv4/IP bindings are 
lost. I guess most people would solve this using "repair connection" in 
their Windows machine, or just plain restart it, upon which everything 
starts again. If the customer is running their machine unattended then 
it'll be unreachable until a DHCP request/discover is seen again.

So I do think we can agree that partially deploying SAVI framework on just 
some devices has its disadvantages, but I still think they can be managed 
by the network staff knowing about this downside and working around it, 
perhaps by lowering lease times on DHCP when they know they're going to 
reboot, lowering the outage time. Also, it might be an option to have a 
optional learning-only mode in SAVI for the first X minutes after startup, 
where packets are not dropped but instead allowed. When the X minutes have 
passed (perhaps X could be deducted by seeing lease times in DHCP), then 
we go into "secure mode" and start dropping packets according to the 
states we've learned.

Right now I'm inclined to think that there is no really good way to handle 
this, and any handling of it should be optional for vendors to implement 
because of the added complexity.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 09 Mar 2010 08:21:14 +0100

El 09/03/10 7:54, Mikael Abrahamsson escribió:
>> you only replace one switch, then you are breaking your netwokr. So 
>> in order to work properly, you need to upgrade all the network. So, 
>> this is not incrementally deployable
>
> Hi Marcelo.
>
> I very quickly read draft-bagnulo-savi-analysis-02.txt as you 
> recommended, and as far as I can see, everything in it is correct. I 
> guess we just see differently on the implications on network 
> maintenance and stability.
>
> I come from an ISP background and have that point of view, I don't 
> trust my customers and they have no certificate or other to verify 
> that I am who I am, and my customers definitely can't trust each 
> other. Therefore I try to make sure that traffic between customers 
> does a route hop thru my equipment, so basically there is no L2 
> connectivity between customers. I also need to know what customer/port 
> has what IP at any given time, which for me means I have to use 
> stateful DHCP so I can store this binding. SLAAC is just not 
> acceptable in this scenario (because of TCAM limitations in my 
> equipment I don't want my equipment connected to a customer /64 

right, i wasn't suggesting we drop dhcp based savi, i do agree dhcp 
based savi is needed. The issues that i am raising are related to 
specifically what shall we do when a dhcp savi device receives a packet 
for which there is no binding.
It can either drop the packet or trigger the binding creation procedure. 
I am pointing out that simply discarding the packet would result in 
reduced robustness of the overall network
>
> We today have this problem with the bindings, especially if the 
> customer has a switch in their apartment. If we reboot the basement 
> switch, the computers won't know that via link-down, and the DHCPv4/IP 
> bindings are lost.
I am not sure i understnad this example what dhcp bindings are lost? the 
host still have their addresses right?

> I guess most people would solve this using "repair connection" in 
> So I do think we can agree that partially deploying SAVI framework on 
> just some devices has its disadvantages, but I still think they can be 
> managed by the network staff knowing about this downside and working 
> around it, perhaps by lowering lease times on DHCP when they know 
> they're going to reboot, lowering the outage time.
sure, that could work, as long as the reboot is planned.
So one possibility as you said is to have a ordered reboot option in 
dhcp savi, that reduces the times in the dhcp lease, in order to make 
sure that the hosts will redo their dhcp lease once they boot again. The 
issue that i see here is that many siwtches mostly are rebooted by power 
them down, which does not allows for an ordered shut down

> Also, it might be an option to have a optional learning-only mode in 
> SAVI for the first X minutes after startup, where packets are not 
> dropped but instead allowed. When the X minutes have passed (perhaps X 
> could be deducted by seeing lease times in DHCP), then we go into 
> "secure mode" and start dropping packets according to the states we've 
> learned.
>

well, the other option would be to trigger the learning procedure when a 
data packet for which no binding exists is recieved. That bsaically 
requires the dhcp savi device to issue a dhcp confirm message to the 
dhcp server in order to veryfy that a binding exists, for instance. That 
would solve all the problems for all topologies afaict.
> Right now I'm inclined to think that there is no really good way to 
> handle this,

see above

regards, marcelo

> and any handling of it should be optional for vendors to implement

---

From: "Bi Jun" <[email-masked]>
Date: Tue, 9 Mar 2010 15:42:05 +0800

Thank you very much for the discussion.

Did you read Guang Yao's message on savi-dhcp-01?

I also prefer to trying to avoid using data-triggered actions (the vendors 
really complained the CPU cost for those actions), if savi-device has to 
resolve this issue.

Best Regards,
Jun Bi

--------------------------------------------------
From: "Guang Yao" <[email-masked]>
Sent: Tuesday, March 09, 2010 2:19 PM
To: <[email-masked]>
Subject: Re: [savi] call for comments:  savi-dhcp-01

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Tuesday, March 09, 2010 3:21 PM
To: "Mikael Abrahamsson" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] call for comments:  savi-dhcp-01

>> guess we just see differently on the implications on network maintenance 
>> and stability.
>>
>> my customers and they have no certificate or other to verify that I am 
>> who I am, and my customers definitely can't trust each other. Therefore I 
>> try to make sure that traffic between customers does a route hop thru my 
>> SLAAC is just not acceptable in this scenario (because of TCAM 
>> limitations in my equipment I don't want my equipment connected to a 
>> customer /64 without limitations on IPs used).
>
> right, i wasn't suggesting we drop dhcp based savi, i do agree dhcp based 
> savi is needed. The issues that i am raising are related to specifically 
> what shall we do when a dhcp savi device receives a packet for which there 
> is no binding.
> It can either drop the packet or trigger the binding creation procedure. I 
> am pointing out that simply discarding the packet would result in reduced 
> robustness of the overall network
>>
>> lost.
>> I guess most people would solve this using "repair connection" in their 
>> Windows machine, or just plain restart it, upon which everything starts 
>> again. If the customer is running their machine unattended then it'll be 
>> unreachable until a DHCP request/discover is seen again.
>>
>> around it, perhaps by lowering lease times on DHCP when they know they're 
>> going to reboot, lowering the outage time.
> So one possibility as you said is to have a ordered reboot option in dhcp 
> savi, that reduces the times in the dhcp lease, in order to make sure that 
> the hosts will redo their dhcp lease once they boot again. The issue that 
> i see here is that many siwtches mostly are rebooted by power them down, 
> which does not allows for an ordered shut down
>
>
>> Also, it might be an option to have a optional learning-only mode in SAVI 
>> for the first X minutes after startup, where packets are not dropped but 
>> instead allowed. When the X minutes have passed (perhaps X could be 
>> deducted by seeing lease times in DHCP), then we go into "secure mode" 
>> and start dropping packets according to the states we've learned.
>>
>
> requires the dhcp savi device to issue a dhcp confirm message to the dhcp 
> server in order to veryfy that a binding exists, for instance. That would 
> solve all the problems for all topologies afaict.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 09 Mar 2010 08:43:32 +0100

> to make it reliable to handle your example.

have you check with people implementing switches whether using non
volatile memory for storing dynamic information, that requires periodic
writing is doable?

Besides, you would still have problems, (different ones) if you use non
volatile memory, especially cause you may end up filtering based on
stalled state

consider the follwoing case:

   Consider the following case:

                +------+             +--------+       +---------------+
         +------|SAVI I|-------------|SWITCH I|-------|rest of the net|
         |      +------+             +--------+       +---------------+
         |         |                    |
     +---------+   |                 +--------+
     |SWITCHIII|   |                 | SAVI II|
     +---------+   |                 +--------+
          |        |   +----------+     |
       +------+    +---|SWITCH II |-----+
       |Host 1|        +----------+
       +------+

   Consider the case where we have SAVI I and SAVI II storing the SAVI
   state in non volatile memory.  Suppose that Host I connects to the
   network and gets IP address IP1 from the DHCP server.

   Suppose that now the power of SAVI I goes down and stays down for a
   few hours.  Suppose that Host I leaves the network and Host II
   attaches to the network in SWITCH II as depicted below.  The spanning
   tree goes SWITCH I-SAVI II-SWITCH II.

                +------+             +--------+       +---------------+
         +------|SAVI I|-------------|SWITCH I|-------|rest of the net|
         |      +------+             +--------+       +---------------+
         |         |                    |
     +---------+   |                 +--------+
     |SWITCHIII|   |                 | SAVI II|
     +---------+   |                 +--------+
                   |   +----------+     |
                   +---|SWITCH II |-----+
                       +----------+
                           |
                        +-------+
                        |Host II|
                        +-------+

   Suppose that SAVI I boots and now the spanning tree changes and goes
   SWITCH I- SAVI I- SWITCH II.  Now packets of Host II will be
   forwarded through SAVI I. But Host II has IP1 as IP address, but SAVI
   I still holds the state referring to Host I through the port through
   which SWITCH III is connected.  The result is that SAVI I will drop
   the packets coming from Host II.

>>>> savi

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 9 Mar 2010 08:44:08 +0100 (CET)

On Tue, 9 Mar 2010, marcelo bagnulo braun wrote:

> savi is needed. The issues that i am raising are related to specifically what 
> shall we do when a dhcp savi device receives a packet for which there is no 
> binding.
> It can either drop the packet or trigger the binding creation procedure. I am 
> pointing out that simply discarding the packet would result in reduced 

For me it's absolutely essential that packets that do not have DHCP 
initated bindings are dropped, so this needs to be configurable. But yes, 
having the switch punt (for example) 1 pps of packets (per port) for which 
there are no SAVI bindings and issue a DHCP confirm request for each of 
these might very well be a possibility.

> I am not sure i understnad this example what dhcp bindings are lost? the host 
> still have their addresses right?

Yes, but the SAVI device has lost its SAVI security bindings during the 
reboot.

> well, the other option would be to trigger the learning procedure when a data 
> packet for which no binding exists is recieved. That bsaically requires the 
> dhcp savi device to issue a dhcp confirm message to the dhcp server in order 
> to veryfy that a binding exists, for instance. That would solve all the 
> problems for all topologies afaict.

Yes, that is also a possibility (and sounds like a good idea), but it 
needs to be heavily ratelimited to protect against DoS attacks. I also 
think it should be an optional feature, not a must.

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 9 Mar 2010 15:47:47 +0800

> reduced robustness of the overall network

[Guang Yao] 
There is no perfect solution. Profit goes with risk and cost. Here is a
trade-off:
1. Discard the packet: low cost but may result in false positive
2. Trigger binding creation: robust but high cost(as far as I know, no
product is designed like this, thus it is hard to estimate the real
performance)

I don't think we do have to make the final choice. Clients, ISPs, and
vendors should(or must) have the right to choose themselves. They are
supposed to make different choices. At least for vendors and ISPs, 1 is
better.
> s
[Guang Yao] 
Using confirm actually has a problem here: the semanteme of confirm is not
check whether the address has been assigned, but check whether the address
can be used on the link. This means any host can confirm the address of
another node.

BR,
Guang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 09 Mar 2010 09:52:06 +0100

El 09/03/10 8:44, Mikael Abrahamsson escribió:
>> specifically what shall we do when a dhcp savi device receives a 
>> packet for which there is no binding.
>> It can either drop the packet or trigger the binding creation 
>> procedure. I am pointing out that simply discarding the packet would 
>> result in reduced robustness of the overall network
>
> initated bindings are dropped,
i fully agree with that. I wasn't suggesting that we should let 
unverified packet through. The question is what to do with packet for 
which we don't have a binding. One option is to drop them till the end 
of times (or until the host reboots). To me this would significantly 
reduce the reliability of the network.
The other option is to trigger the binding creation procedure. We may 
even drop the particular packet that trigger the procedure, but at 
least, folowing packet will not be dropped if they came from a 
legitimate user. This basicaly implies for the SAVI device to issue a 
dhcp message

> so this needs to be configurable. But yes, having the switch punt (for 
> example) 1 pps of packets (per port) for which there are no SAVI 
> bindings and issue a DHCP confirm request for each of these might very 
> well be a possibility.
>

right, this raises another interesting issue that is about rate limiting.

If we do this, both dhcp control packets and data packets may require 
processing by the SAVI device, so both of them need to be rate limited.

So, normally, the amount of data packets that require processing would 
be very low, since, as people has alreayd been stating, the usual case 
is that we see a dhcp message first.

So only a few data packet require processing, so we can severly rate 
limit it.

So, i agree with this

Please note that the impact of not processing a data packet is simply 
loose that particular packet, but we always have the oportunity to 
process the next one from the sam source.
>> I am not sure i understnad this example what dhcp bindings are lost? 
>> the host still have their addresses right?
>
> Yes, but the SAVI device has lost its SAVI security bindings during 
> the reboot.
>
right, this is what i am presenting as one argument of the reduced 
reliability of the network if we simply drop the data packets for which 
the savi device does not have a binding for

>> well, the other option would be to trigger the learning procedure 
>> when a data packet for which no binding exists is recieved. That 
>> bsaically requires the dhcp savi device to issue a dhcp confirm 
>> message to the dhcp server in order to veryfy that a binding exists, 
>> for instance. That would solve all the problems for all topologies 
>> afaict.
>
> needs to be heavily ratelimited to protect against DoS attacks.
agree

> I also think it should be an optional feature, not a must.
>
but this is what we qualify as a must in the ietf terminology. If you 
don't do this, the network breaks in different ways, right?

Regards, marcelo

---

From: "Bi Jun" <[email-masked]>
Date: Tue, 9 Mar 2010 16:52:40 +0800

--------------------------------------------------
From: "Mikael Abrahamsson" <[email-masked]>
Sent: Tuesday, March 09, 2010 3:44 PM
To: "marcelo bagnulo braun" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] call for comments:  savi-dhcp-01

>> what shall we do when a dhcp savi device receives a packet for which 
>> there is no binding.

Hi Mikael and Marcelo,

If consider it as an optional feature (data triggered actions) not a must,
I think it's OK for me.

Thanks,
Jun Bi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 09 Mar 2010 09:53:01 +0100

> Did you read Guang Yao's message on savi-dhcp-01?

yes, please read my reply to Mikael, that addresses the same issues

Regards, marcelo

>
> I also prefer to trying to avoid using data-triggered actions (the 
> vendors really complained the CPU cost for those actions), if 
> savi-device has to resolve this issue.
>
> Best Regards,
> Jun Bi
>
>>>> interrupted unless all switches are upgraded to support SAVI, then 
>>>> if you only replace one switch, then you are breaking your netwokr. 
>>>> So in order to work properly, you need to upgrade all the network. 
>>> connectivity between customers. I also need to know what 
>>> customer/port has what IP at any given time, which for me means I 
>>> have to use stateful DHCP so I can store this binding. SLAAC is just 
>>> not acceptable in this scenario (because of TCAM limitations in my 
>>> switch, the computers won't know that via link-down, and the 
>>> DHCPv4/IP bindings are lost.
>>> their Windows machine, or just plain restart it, upon which 
>>> everything starts again. If the customer is running their machine 
>>> unattended then it'll be unreachable until a DHCP request/discover 
>>> is seen again.
>>>
>>> So I do think we can agree that partially deploying SAVI framework 
>>> on just some devices has its disadvantages, but I still think they 
>>> can be managed by the network staff knowing about this downside and 
>>> working around it, perhaps by lowering lease times on DHCP when they 
>>> know they're going to reboot, lowering the outage time.
>> sure that the hosts will redo their dhcp lease once they boot again. 
>> The issue that i see here is that many siwtches mostly are rebooted 
>> by power them down, which does not allows for an ordered shut down
>>
>>
>>> dropped but instead allowed. When the X minutes have passed (perhaps 
>>> X could be deducted by seeing lease times in DHCP), then we go into 
>>> "secure mode" and start dropping packets according to the states 
>>> we've learned.
>>>
>>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 9 Mar 2010 10:46:42 +0100 (CET)

> don't do this, the network breaks in different ways, right?

I don't agree that this is a must. This breakage is limited to certain 
operational concerns, it's not a fundamental problem that makes it not 
work at all.

One can make the argument that this is a risk taken by the entity that 
chooses to deploy SAVI partially and that SAVI mandates things that are 
needed for a totally SAVI enabled network where all devices have this, and 
in the case not all of them have SAVI functionality, then things will 
break unless a MAY or SHOULD clause is implemented?

I don't like the situation where some vendors might not offer SAVI at all, 
to handle the problem you're describing.

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 9 Mar 2010 18:22:23 +0800

--------------------------------------------------
From: "Mikael Abrahamsson" <[email-masked]>
Sent: Tuesday, March 09, 2010 5:46 PM
To: <[email-masked]>
Subject: Re: [savi] call for comments:  savi-dhcp-01

> operational concerns, it's not a fundamental problem that makes it not 

I really agree with Mikael. I think both Mikael and I have the service 
provider
background (we are with CERNET running campus networks). I don't see this is
an uncovered severe problem. The current operational experience is that if 
the
user found a problem, he will try to repair his network connection first by 
himself, if he still had the problem again, then he will call the help desk. 
Again, as I stated in my past emails, the power-down of a switch is really 
low frequent event in any operational network (if the reboot is because a 
planed topology change, then the service provide has enough reason to let 
his user renew his connection) . We don't let users repair his connection 
very often. So I don't see it is a severe problem, we service providers had 
more severe problem such as users could not access network due to the 
spoofing a ARP or DHCP server in today's network, SAVI will help to resolve 
this problem.

So my opinion is if we need to do it, just add it as option, not must. 
(remember when I present savi-dhcp at IETF76, I used those probes sending 
from switch to handle those special cases, I did see some people didn't like 
it). I really doubt if it is
a good approach to bring the complexity as a MUST to the device to fix some 
very special case (e.g. the power-down of a switch). If we keep the rfc 
simplified, then more vendors will implement it. Then if the service 
provider really needs, and
if the vendor also wants, they can still implement it as optional features 
(maybe in higher-end savi-switches with better hardware).

> to handle the problem you're describing.

As one form service provider, I love this statement. I do hope more vendors 
to support SAVI, even in very low-end switch, then it will be very cheap for 
us to upgrade all switches (fully deployment at access level) with 
SAVI-functions in a short time.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Mar 2010 12:37:23 +0100

Hi Mikael,

sorry for the delay, been away for a few days

below...

> operational concerns, it's not a fundamental problem that makes it not 
Let's go back to RFC 2119 where the usage of these terms is defines:
RFC2119 reads:

* *

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
    definition is an absolute requirement of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

So, the situation is that if the triggering of the binding creation by 
data packet si not implemented, a legitimate user will be disconnected 
from the network in case the state is loss or in case a failure results 
in a change in the topology. So this actually affects interoperability.

The alternative would be a SHOULD properly qualified.

I think that for the SLAAC/ND case, it is much more likely that the 
situation occurs (due to packet loss and the non reliable nature of the 
DAD procedure), so i really think that the triggering of the SAVI 
binding creation process upon the recpetion of data packets should be a 
MUST.

For the dhcp case, the cases in whcih this fails are reduced because of 
the reliable nature of the dhcp exchange, so while i would rather go for 
a MUST, i think i can live with a SHOULD.
> chooses to deploy SAVI partially and that SAVI mandates things that 
> are needed for a totally SAVI enabled network where all devices have 
> this, and in the case not all of them have SAVI functionality, then 
> things will break unless a MAY or SHOULD clause is implemented?
>
No, a MAY is something that is completelly optional and would not affect 
interop in any way.

As i said above, in the case of dhcp, if the SHOULD is properly 
qualified, i could live with that.

> I don't like the situation where some vendors might not offer SAVI at 
> all, to handle the problem you're describing.
>
Right, i do have this concern as well, but i am very worried about the 
impact to the overall robustness fo the network.

Regards, marcelo

---

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

Hi Marcelo,

The sentence is misleading.
"So, the situation is that if the triggering of the binding creation by
data packet si not implemented, a legitimate user will be disconnected "

It only happens for some situations.
If the "MUST" only handles some situation but bring *much more* cost to the 
device (it's really because the data-triggered solution is not a low cost 
action),
then I think the right ways:

1 "MUST" for all cases, and list some limitation and guide the users.
2 "Options" for some special cases, users has the guide to buy the 
higher-end device
if they want more flexible use of savi device, (certainly, by paying higher 
price for the device.).

That's my answer to all your similar questions.

thanks,
Jun Bi

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Monday, March 15, 2010 7:37 PM
To: <[email-masked]>
Subject: Re: [savi] call for comments:  savi-dhcp-01

> from the network in case the state is loss or in case a failure results in 
> a change in the topology. So this actually affects interoperability.
>
> DAD procedure), so i really think that the triggering of the SAVI binding 
> creation process upon the recpetion of data packets should be a MUST.
>
> the reliable nature of the dhcp exchange, so while i would rather go for a 
> MUST, i think i can live with a SHOULD.
>> needed for a totally SAVI enabled network where all devices have this, 
>> and in the case not all of them have SAVI functionality, then things will 
> As i said above, in the case of dhcp, if the SHOULD is properly qualified, 
> i could live with that.
>
>

---

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

Hi Marcelo,

Venture to say, it is impossible to persuade everyone, because neither
choices take absolute advantage. This problem is obviously just a tradeoff.
Someone value robustness and some others values performance.

I sincerely suggest, leave the choice to be made by the vendors and network
administrators. The solution doesn't have to restrict every implementation
and deployment to be exactly the same. "One man's meat is another man's
poison". Please just make out the outcome of what if it is done, and the
outcome of what if it is not done.

Please just end this endless debate and move forward in the savi-slaac. 2012
is near :).

BR,
Guang

> marcelo bagnulo braun

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Mar 2010 14:59:56 +0100

> It only happens for some situations.

Right, it only happen in some situation, but that is what robustness is 
about, right?
I mean, this affects interoperability, becuase it may happen that the 
communication of a legitimate host is interrupted due to this.
> If the "MUST" only handles some situation but bring *much more* cost 
> to the device (it's really because the data-triggered solution is not 
> a low cost action),
> if they want more flexible use of savi device, (certainly, by paying 
> higher price for the device.).
>
As i said, i don't think in any case this is optional.

IMHO, this is a MUST becuase it affect interoperability.
If there is no consensus to go for a MUST, i can live with, for the dhcp 
case and only for the dhcp case, since the subset of problematic cases 
is more limited than the ND case, we could use a qualified SHOULD, which 
means that the implementation SHOULD do that and we explian what happens 
if they don't. How about that?

Regards, marcelo

>>>> but this is what we qualify as a must in the ietf terminology. If 
>>>> you don't do this, the network breaks in different ways, right?
>>>
>>> I don't agree that this is a must. This breakage is limited to 
>>> certain operational concerns, it's not a fundamental problem that 
>>> makes it not work at all.
>>>
>> So, the situation is that if the triggering of the binding creation 
>> by data packet si not implemented, a legitimate user will be 
>> disconnected from the network in case the state is loss or in case a 
>> failure results in a change in the topology. So this actually affects 
>> interoperability.
>>
>> situation occurs (due to packet loss and the non reliable nature of 
>> the DAD procedure), so i really think that the triggering of the SAVI 
>> binding creation process upon the recpetion of data packets should be 
>> a MUST.
>>
>> For the dhcp case, the cases in whcih this fails are reduced because 
>> of the reliable nature of the dhcp exchange, so while i would rather 
>> go for a MUST, i think i can live with a SHOULD.
>>> One can make the argument that this is a risk taken by the entity 
>>> that chooses to deploy SAVI partially and that SAVI mandates things 
>>> that are needed for a totally SAVI enabled network where all devices 
>>> have this, and in the case not all of them have SAVI functionality, 
>>> then things will break unless a MAY or SHOULD clause is implemented?
>>>
>> No, a MAY is something that is completelly optional and would not 
>> affect interop in any way.
>>
>>> I don't like the situation where some vendors might not offer SAVI 
>>> at all, to handle the problem you're describing.
>>>
>> Right, i do have this concern as well, but i am very worried about 
>> the impact to the overall robustness fo the network.
>>
>> Regards, marcelo
>>

---

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

I beg to differ. My concern is that if we simply drop the packets for 
which there is no binding, the overall network robustness will be 
affected. And our duty as IETF is to properly design protocols to make 
the Internet work in a reliable manner. If vendors want to implement 
solutions that break the internet they can do it, but they don't get to 
do that using an IETF RFC number (or at least they shouldn't)

Regards, marcelo

---

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

OK, I make a step backwards. What if requiring vendors to implement both,
but at least giving the right of choosing to network administrators?

And I want to mention that, ingress filtering(RFC2827, RFC3704, BCP38,
BCP84) is not a mechanism that wouldn't discard any " legitimate" packet. It
may also "break the internet". Why it has RFC numbers?

BR,
Guang

> Sent: Monday, March 15, 2010 10:03 PM
> To: [email-masked]
affect

---

From: "Bi Jun" <[email-masked]>
Date: Mon, 15 Mar 2010 22:48:11 +0800

Hi Marcelo,

Hi, Marcelo,

Here we are actually talking about the trade-off between cost and the 
benefits (forgive me that I explained this option many times). If the 
solution is just a couple of lines of code, whey not we make it MUST? But 
the truth is that the data-triggered actions are heavy burden to device 
especially low end access switch. If you make them MUST, then you forbid 
those access switches implementing SAVI (those access switch could be more 
than 90% of potential savi-switches).

So my idea is:
1 make two RFCs, one for each catalog of functions used for different 
scenarios.
2 make one RFC, but make MUST for basic functions, make other functions as 
options. And provide a guideline to users:
(1) If the users want to plus a host directly a savi-device, deploy cheap 
switch only implement MUST
(2) If users want to connect host to a old hub, then connect the hub 
savi-device (like the pictures you drown), then if you think best-effort is 
OK for you (if you have problem, reboot your hub or repaired the 
host-connection, deploy the cheap switch only implement MUST
(3) in the above case, if you want 100% service quality, then buy a 
higher-end savi-device that implement options in this RFC.

thanks,
Jun
Sent: Monday, March 15, 2010 9:59 PM

>> If the "MUST" only handles some situation but bring *much more* cost to 
>> the device (it's really because the data-triggered solution is not a low 
>> cost action),
> case and only for the dhcp case, since the subset of problematic cases is 
> more limited than the ND case, we could use a qualified SHOULD, which 
>>>> and in the case not all of them have SAVI functionality, then things 
>>>> will break unless a MAY or SHOULD clause is implemented?
>>>>

---

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

> but at least giving the right of choosing to network administrators?
mmm, that is an interesting proposal
MUST implement this but MUST be configurable to turn it on/off...
I think i can also live with that for the dhcp case

Regards, marcelo

>>> choices take absolute advantage. This problem is obviously just a
>>>        
> tradeoff.
>    
>>> I sincerely suggest, leave the choice to be made by the vendors and
>>>        
> network
>    
>>> administrators. The solution doesn't have to restrict every
>>>        
> implementation
>    
>>> Please just end this endless debate and move forward in the savi-slaac.
>>>        
> 2012
>    
>>> is near :).
>>>
>>> BR,
>>> Guang
>>>
>>>
>>>        
>>>> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
>>>>          
>> there
>>      
>>>> the reliable nature of the dhcp exchange, so while i would rather go
>>>>          
> for
>

---

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

Hi Jun,

What i am talking about is how the deployment of the different SAVI 
solution will affect the overall robustness and performance of the 
Internet architecture. One of the tasks of the IETF and of the IAB is to 
preserve the overall Internet architecture and to keep its fundamental 
design principles that have granted a robust Internet.

My concern is that a SAVI solution that blindly drops data packets for 
which it has no binding for woudl deter the reliability of the network 
as a whole and we shouldn't allow that.

So, that being said, let me comment on som particular comments you make.

Below...

El 15/03/10 15:48, Bi Jun escribió:
> solution is just a couple of lines of code, whey not we make it MUST? 
> But the truth is that the data-triggered actions are heavy burden to 
> device especially low end access switch. If you make them MUST, then 
> you forbid those access switches implementing SAVI (those access 
> switch could be more than 90% of potential savi-switches).
>
Where did you get this figure from?
The feedback that i have got form vendors is that they would be able to 
implement it as long as it is rate limited.
> 2 make one RFC, but make MUST for basic functions, make other 
> functions as options. And provide a guideline to users:
> (1) If the users want to plus a host directly a savi-device, deploy 
> cheap switch only implement MUST
> savi-device (like the pictures you drown), then if you think 
> best-effort is OK for you (if you have problem, reboot your hub or 
> repaired the host-connection, deploy the cheap switch only implement MUST
Actually, i don't agree with this approach. I think we have the 
normative language as specified in RFC 2116 exactly to deal with this 
type of situations.
I don't want to have all the SAVI funcionality spread over more RFCs, we 
already have split the SAVI spec in more than we should and i don't 
think it would make sense to divide it even more.

I think we need to have one RFC for dhcp savi and one for SLAAC savi

We need to agree on what features are MUST and which ones are SHOULD.

As i suggested already,. imho the triggering of the binding creation 
mechanisms upon the reception of a data packet for whcih there is no 
binding should be a MUST for both cases.

I could live with a qualified SHOULD for the DHCP case and a MUST for 
the SLAAC case, based on the faact that the DHCP exchange is reliable 
and hence the problem of packet loss is not an issue for the DHCP case 
while it is so for the SLAAC case

I think i could also live with Guang's suggestion of having A MUST for 
both cases and also require as a MUST that the feature MUST be 
configurable on/off

Regards, marcelo

>> Right, it only happen in some situation, but that is what robustness 
>> is about, right?
>>> to the device (it's really because the data-triggered solution is 
>>> not a low cost action),
>> If there is no consensus to go for a MUST, i can live with, for the 
>> dhcp case and only for the dhcp case, since the subset of problematic 
>> cases is more limited than the ND case, we could use a qualified 
>> SHOULD, which means that the implementation SHOULD do that and we 
>> explian what happens if they don't. How about that?
>>
>> Regards, marcelo
>>
>>
>>
>>>> disconnected from the network in case the state is loss or in case 
>>>> a failure results in a change in the topology. So this actually 
>>>> affects interoperability.
>>>>
>>>> the DAD procedure), so i really think that the triggering of the 
>>>> SAVI binding creation process upon the recpetion of data packets 
>>>> should be a MUST.
>>>>
>>>> For the dhcp case, the cases in whcih this fails are reduced 
>>>> because of the reliable nature of the dhcp exchange, so while i 
>>>> would rather go for a MUST, i think i can live with a SHOULD.
>>>>> that chooses to deploy SAVI partially and that SAVI mandates 
>>>>> things that are needed for a totally SAVI enabled network where 
>>>>> all devices have this, and in the case not all of them have SAVI 
>>>>> functionality, then things will break unless a MAY or SHOULD 
>>>>> clause is implemented?
>>>>>

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 15 Mar 2010 23:18:11 +0800

I'm in favor of two RFCs. Then we can respect the opinion of each other, at
the same time reserve our own options.

IMHO, vendors have their market requirements, and they choose carefully
between RFCs. Implementing a new RFC may be valueless unless it is strongly
required by market. And on the other hand, if there is requirement for a
feature, even there is no RFC doc, it will still be implemented. Thus, I
think people should design RFC for real requirements. It's unhonored that a
RFC is rarely implemented, but rather a product supplies some function not
standardized as RFC.

BR,
Guang

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bi
> Jun
> Sent: Monday, March 15, 2010 10:48 PM
> To: marcelo bagnulo braun
> Cc: [email-masked]
> Subject: [savi] savi-dhcp-02
> 
> Hi Marcelo,
> 
> Hi, Marcelo,
> 
> scenarios
"
> > case and only for the dhcp case, since the subset of problematic cases
is
> >> That's my answer to all your similar questions.
you
> >>>> I don't agree that this is a must. This breakage is limited to
certain
the
> >>> binding creation process upon the recpetion of data packets should be
a
> >>> For the dhcp case, the cases in whcih this fails are reduced because
of
for
> >>>> One can make the argument that this is a risk taken by the entity
that
> >>>> chooses to deploy SAVI partially and that SAVI mandates things that
are
affect

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 15 Mar 2010 23:27:04 +0800

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Monday, March 15, 2010 11:13 PM
To: "Bi Jun" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] savi-dhcp-02

> which it has no binding for woudl deter the reliability of the network as 
> a whole and we shouldn't allow that.
>
>> those access switches implementing SAVI (those access switch could be 
>> more than 90% of potential savi-switches).
>>

Oh really? Please provide me who said that. You know CNGI-CERNET2 is 
deploying savi
in large scale in 100 universities. If any vendor implements data-triggered
functions in low-end access switch (we use those switch to directly connect 
hosts)
with the same price as the savi access switch that implemented 
control-packet triggered functions (we purchased about 50000 savi-switches), 
we'd like to buy more from this new vendor.

thanks!
Jun

>> 2 make one RFC, but make MUST for basic functions, make other functions 
>> as options. And provide a guideline to users:
>> savi-device (like the pictures you drown), then if you think best-effort 
>> is OK for you (if you have problem, reboot your hub or repaired the 
> Actually, i don't agree with this approach. I think we have the normative 
> language as specified in RFC 2116 exactly to deal with this type of 
> situations.
> already have split the SAVI spec in more than we should and i don't think 
> it would make sense to divide it even more.
>
> I could live with a qualified SHOULD for the DHCP case and a MUST for the 
> SLAAC case, based on the faact that the DHCP exchange is reliable and 
> hence the problem of packet loss is not an issue for the DHCP case while 
> it is so for the SLAAC case
>
>>>> the device (it's really because the data-triggered solution is not a 
>>>> low cost action),
>>>>> from the network in case the state is loss or in case a failure 
>>>>> results in a change in the topology. So this actually affects 
>>>>> interoperability.
>>>>>

---

From: "Bi Jun" <[email-masked]>
Date: Mon, 15 Mar 2010 23:33:25 +0800

By the way, the 50000 savi-switch we purchased cost 200-400USD each, with 24 
10/100M + 2 GE uplink ports.

thanks,
Jun Bi

--------------------------------------------------
From: "Jun Bi" <[email-masked]>
Sent: Monday, March 15, 2010 11:27 PM
To: "marcelo bagnulo braun" <[email-masked]>; "Bi Jun" 
<[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] savi-dhcp-02

>>> device especially low end access switch. If you make them MUST, then you 
>>> forbid those access switches implementing SAVI (those access switch 
>>> could be more than 90% of potential savi-switches).
>>>
> functions in low-end access switch (we use those switch to directly 
> connect hosts)
> control-packet triggered functions (we purchased about 50000 
> savi-switches), we'd like to buy more from this new vendor.
>
> thanks!
> Jun
>
>
>
>
>>> So my idea is:

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 15 Mar 2010 23:53:39 +0800

I'm happy that we can agree with this proposal. It's a good step, anyway.

BR,
Guang

> Sent: Monday, March 15, 2010 10:58 PM
> To: [email-masked]
you
certain
> >>>> So, the situation is that if the triggering of the binding creation
by
> >>>> from the network in case the state is loss or in case a failure
results
the
a
of
that
> >>>>> I don't like the situation where some vendors might not offer SAVI
at
the

---

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

El 15/03/10 16:27, Jun Bi escribió:
>> Internet architecture. One of the tasks of the IETF and of the IAB is 
>> to preserve the overall Internet architecture and to keep its 
>> fundamental design principles that have granted a robust Internet.
>>
>> My concern is that a SAVI solution that blindly drops data packets 
>> for which it has no binding for woudl deter the reliability of the 
>> network as a whole and we shouldn't allow that.
>>
>>> Here we are actually talking about the trade-off between cost and 
>>> the benefits (forgive me that I explained this option many times). 
>>> If the solution is just a couple of lines of code, whey not we make 
>>> it MUST? But the truth is that the data-triggered actions are heavy 
>>> burden to device especially low end access switch. If you make them 
>>> MUST, then you forbid those access switches implementing SAVI (those 
>>> access switch could be more than 90% of potential savi-switches).
>>>
>> The feedback that i have got form vendors is that they would be able 
>> to implement it as long as it is rate limited.
>
>
>

> Oh really? Please provide me who said that.

could you please tell the vendors who are not able to implement the 
triggering of the binding creation upon the reception of data packets to 
tell so in the ml, as you stated earlier?

once that happens, i will talk to the vendors who did told me that to 
speak up in the ml as well.

Regards, marcelo
> You know CNGI-CERNET2 is deploying savi
>>> 1 make two RFCs, one for each catalog of functions used for 
>>> different scenarios.
>> I don't want to have all the SAVI funcionality spread over more RFCs, 
>> we already have split the SAVI spec in more than we should and i 
>> don't think it would make sense to divide it even more.
>>
>> and hence the problem of packet loss is not an issue for the DHCP 
>> case while it is so for the SLAAC case
>>
>> I think i could also live with Guang's suggestion of having A MUST 
>> for both cases and also require as a MUST that the feature MUST be 
>> configurable on/off
>>
>> Regards, marcelo
>>
>>> thanks,
>>> Jun
>>>> Right, it only happen in some situation, but that is what 
>>>> robustness is about, right?
>>>> I mean, this affects interoperability, becuase it may happen that 
>>>> the communication of a legitimate host is interrupted due to this.
>>>>> If the "MUST" only handles some situation but bring *much more* 
>>>>> cost to the device (it's really because the data-triggered 
>>>>> solution is not a low cost action),
>>>>> if they want more flexible use of savi device, (certainly, by 
>>>>> paying higher price for the device.).
>>>>>
>>>> dhcp case and only for the dhcp case, since the subset of 
>>>> problematic cases is more limited than the ND case, we could use a 
>>>> qualified SHOULD, which means that the implementation SHOULD do 
>>>> that and we explian what happens if they don't. How about that?
>>>>
>>>> Regards, marcelo
>>>>
>>>>
>>>>
>>>>>>>> but this is what we qualify as a must in the ietf terminology. 
>>>>>>>> If you don't do this, the network breaks in different ways, right?
>>>>>>>
>>>>>>> certain operational concerns, it's not a fundamental problem 
>>>>>>> that makes it not work at all.
>>>>>>>
>>>>>> So, the situation is that if the triggering of the binding 
>>>>>> creation by data packet si not implemented, a legitimate user 
>>>>>> will be disconnected from the network in case the state is loss 
>>>>>> or in case a failure results in a change in the topology. So this 
>>>>>> actually affects interoperability.
>>>>>>
>>>>>> I think that for the SLAAC/ND case, it is much more likely that 
>>>>>> the situation occurs (due to packet loss and the non reliable 
>>>>>> nature of the DAD procedure), so i really think that the 
>>>>>> triggering of the SAVI binding creation process upon the 
>>>>>> recpetion of data packets should be a MUST.
>>>>>>
>>>>>>> One can make the argument that this is a risk taken by the 
>>>>>>> entity that chooses to deploy SAVI partially and that SAVI 
>>>>>>> mandates things that are needed for a totally SAVI enabled 
>>>>>>> network where all devices have this, and in the case not all of 
>>>>>>> them have SAVI functionality, then things will break unless a 
>>>>>>> MAY or SHOULD clause is implemented?
>>>>>>>
>>>>>>> I don't like the situation where some vendors might not offer 
>>>>>>> SAVI at all, to handle the problem you're describing.
>>>>>>>
>>>>>> Right, i do have this concern as well, but i am very worried 
>>>>>> about the impact to the overall robustness fo the network.
>>>>>>
>>>>>> Regards, marcelo
>>>>>>

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 16 Mar 2010 00:12:07 +0800

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Monday, March 15, 2010 11:55 PM
To: "Jun Bi" <[email-masked]>
Cc: "Bi Jun" <[email-masked]>; <[email-masked]>
Subject: Re: [savi] savi-dhcp-02

>>>> you forbid those access switches implementing SAVI (those access switch 

The access-level switch products of H3C(3Com), ZTE, Ruijie, Digital 
China(spinned from from Lenovo). Please pay attention to: access level 
switches, not higher-end switches.

>>>>>>> failure results in a change in the topology. So this actually 
>>>>>>>> that are needed for a totally SAVI enabled network where all 
>>>>>>>> devices have this, and in the case not all of them have SAVI 
>>>>>>>> functionality, then things will break unless a MAY or SHOULD clause 
>>>>>>>> is implemented?
>>>>>>>>

---

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

> switches, not higher-end switches.

So, basically you are saying that all these vendors are able to trigger 
the binding creation process upon the reception of a data packet, but 
only in their high end devices, is that correct? But that they cannot 
provide it in the access level, correct?

Please note that is fully compatible with the deployment model of SAVI 
with legacy devices, where you can deploy a core of SAVI devices and 
then connect a bunch of access devices that don't implement SAVI.

Another question is would these vendors be able to store the SAVI 
binding information in non volatile memory for the access devices or 
only for the high end devices?

Regards, marcelo

PS: I will ask the vendor that provided me the info to contact you 
either in the ml or privately.

>>>>> (1) If the users want to plus a host directly a savi-device, 
>>>>> deploy cheap switch only implement MUST
>>>>> (2) If users want to connect host to a old hub, then connect the 
>>>>> hub savi-device (like the pictures you drown), then if you think 
>>>>> (3) in the above case, if you want 100% service quality, then buy 
>>>>> a higher-end savi-device that implement options in this RFC.
>>>>>
>>>> normative language as specified in RFC 2116 exactly to deal with 
>>>> this type of situations.
>>>> I don't want to have all the SAVI funcionality spread over more 
>>>> RFCs, we already have split the SAVI spec in more than we should 
>>>> and i don't think it would make sense to divide it even more.
>>>>
>>>> As i suggested already,. imho the triggering of the binding 
>>>> creation mechanisms upon the reception of a data packet for whcih 
>>>> there is no binding should be a MUST for both cases.
>>>>
>>>> I could live with a qualified SHOULD for the DHCP case and a MUST 
>>>> for the SLAAC case, based on the faact that the DHCP exchange is 
>>>> reliable and hence the problem of packet loss is not an issue for 
>>>> the DHCP case while it is so for the SLAAC case
>>>>
>>>>>>> 2 "Options" for some special cases, users has the guide to buy 
>>>>>>> the higher-end device
>>>>>> If there is no consensus to go for a MUST, i can live with, for 
>>>>>> the dhcp case and only for the dhcp case, since the subset of 
>>>>>> problematic cases is more limited than the ND case, we could use 
>>>>>> a qualified SHOULD, which means that the implementation SHOULD do 
>>>>>>>>>> but this is what we qualify as a must in the ietf 
>>>>>>>>>> terminology. If you don't do this, the network breaks in 
>>>>>>>>>> different ways, right?
>>>>>>>>>
>>>>>>>> or in case a failure results in a change in the topology. So 
>>>>>>>> this actually affects interoperability.
>>>>>>>>
>>>>>>>>> network where all devices have this, and in the case not all 
>>>>>>>>> of them have SAVI functionality, then things will break unless 
>>>>>>>>> a MAY or SHOULD clause is implemented?
>>>>>>>>>
>>>>>>>> No, a MAY is something that is completelly optional and would 
>>>>>>>> not affect interop in any way.
>>>>>>>>

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 16 Mar 2010 00:56:40 +0800

Sent: Tuesday, March 16, 2010 12:41 AM

> the binding creation process upon the reception of a data packet, but only 
> in their high end devices, is that correct? But that they cannot provide 
> it in the access level, correct?
>
> with legacy devices, where you can deploy a core of SAVI devices and then 
> connect a bunch of access devices that don't implement SAVI.

I don't understand you. In my opinion, MUST functions for all switches 
including low-end, optional functions for higher-end switches will fully 
compatible with both the
implementation and deployment reality.

>
> Another question is would these vendors be able to store the SAVI binding 
> information in non volatile memory for the access devices or only for the 
> high end devices?

We are asking, seems OK for them. Every access switch in the catalog of 
low-end has the flash. We save the configuration of the IP management 
address configuration, MIB and other data in the flash.

>
> Regards, marcelo
>
> PS: I will ask the vendor that provided me the info to contact you either 
> in the ml or privately.
>
>
>>
>>
>>>
>>> Regards, marcelo
>>>>> we already have split the SAVI spec in more than we should and i don't 
>>>>>>>> cost to the device (it's really because the data-triggered solution 
>>>>>>>> is not a low cost action),
>>>>>>> qualified SHOULD, which means that the implementation SHOULD do that 
>>>>>>> and we explian what happens if they don't. How about that?
>>>>>>>
>>>>>>> Regards, marcelo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> creation by data packet si not implemented, a legitimate user will 
>>>>>>>>> be disconnected from the network in case the state is loss or in 
>>>>>>>>> case a failure results in a change in the topology. So this 
>>>>>>>>> triggering of the SAVI binding creation process upon the recpetion 
>>>>>>>>> of data packets should be a MUST.
>>>>>>>>>

---

From: Fred Baker <[email-masked]>
Date: Mon, 15 Mar 2010 18:39:44 -0400

I'm confused. Cisco, as has been noted way back when, has essentially the SAVI/SHCP draft implemented for IPv4 and has had it in live networks for a number of years. We see no such issue. Why would there be one with IPv6 if there is none with IPv4?

In networks that use the feature, hosts and routers are attached to switch ports, as are inter-switch trunk groups. There is no protection on routers or inter-switch trunks, for the simple reason that datagrams can cross those ports with any source address, routers can be configured with reverse lookup, and hosts have already been tested at their ingress ports. We can also turn off checking on any other system that we want to configure a static address on, or statically configure its port filter. Those that remain get their addresses via DHCP, and there is no reason for them to use any address that has not been assigned to them, by policy. So dropping traffic that doesn't use the DHCP-assigned address (in IPv6, dropping traffic that doesn't use *a* DHCP-assigned address), is not a reduction of robustness. It is the correct application of policy and kind of the point of this whole exercise.

What reduction in robustness do you see? In what way is that reduction in robustness not the correct application of policy?

On Mar 15, 2010, at 10:02 AM, marcelo bagnulo braun wrote:

> I beg to differ. My concern is that if we simply drop the packets for which there is no binding, the overall network robustness will be affected.

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 16 Mar 2010 06:48:25 -0400

On Mar 8, 2010, at 9:03 AM, marcelo bagnulo braun wrote:

> If SAVI switches reboots imply that the communication will be interrupted unless all switches are upgraded to support SAVI, then if you only replace one switch, then you are breaking your netwokr. So in order to work properly, you need to upgrade all the network. So, this is not incrementally deployable

Marcelo:

Is this the loss of robustness that you are asserting?

If so, you're discussing something different than Jun Bi is talking about. In the DHCP case, a switch looks only at traffic that enters the switching network on one of its ports. Since it is only protecting its own ports, there is no question of it having to have memory to represent addresses on other switches. An un-upgraded switch represents a vulnerability in the switching network - that switch doesn't prevent spoofed packets in its network - but it does not prevent other switches from protecting their ports. 

On Cisco switches, we implement SAVI using what we call the "port filter". Switches that have that capability (not all do) require a software change to provide the programming. This is the upgrade that Jun Bi mentions. For IPv4 that is pretty simple; for IPv6 is is less simple due to the number of terms available in the port filter. One may need a hardware upgrade if the port filter isn't adequate; that is a question of the specific hardware involved.

I can only speak from the perspective of deployed equipment, but in our experience DHCP-based SAVI is quite robust. I'm finding this whole thread pretty confusing as a result.

---

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

Hi Marcelo,
marcelo bagnulo braun a écrit :
>>> Internet architecture. One of the tasks of the IETF and of the IAB 
>>> is to preserve the overall Internet architecture and to keep its 
>>>> MUST, then you forbid those access switches implementing SAVI 
>>>> (those access switch could be more than 90% of potential 
>>>> savi-switches).
>>>>
> triggering of the binding creation upon the reception of data packets 
> to tell so in the ml, as you stated earlier?
>
As a vendor,
I'll tell one issue that we have with "triggering of the binding 
creation upon the reception of data packets" which I would translate 
into "punting" data packets to software.
On bigger switches, data traffic is hardware bridged. The binding table 
is pushed to the hardware (to avoid slowing down the switch). The 
rate-limiting must happen close to the hardware to drop quickly enough 
in case of attack.
In order to be efficient (simple & fast) and generic, the rate-limiters 
classify the traffic and rate limit based on this classification. For 
instance ICMP traffic can be classified as "ICMP" and rate-limited 
accordingly.
However, the data traffic we are talking about cannot be classified 
(could be anything). There are two issues with that.
1) We need to add specific logic to rate limit cache misses before 
punting to software. Can't use generic rate-limiters. This is an 
additional logic (on top of generic rate-limiters) which is going to 
have a performance hit
2) This might require some hardware change, which takes time, energy and 
money.

BTW, please I am not asking for somebody to invent whatever design to 
resolve my problem. I know exactly what to do. But as a vendor, I am 
saying this is **not**  a couple of lines of code.
It might be un-avoidable, I am not arguying. I wish we could come up 
with a different solution.
Right now the charter constrain us to keep not invent a new protocol, 
and this is turning into changing the hardware ...
Eric

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 Mar 2010 14:57:13 +0100

> Right now the charter constrain us to keep not invent a new protocol,

How would a new protocol solve the problem?

Regards, marcelo

---

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

> How would a new protocol solve the problem?
A protocol that would allow nodes to "register" their address and the 
switch to query them. Something like RFC3122 (applied to ethernet links, 
see draft-thubert-3122bis-01 
<https://datatracker.ietf.org/doc/draft-thubert-3122bis/>) or like Erik 
N. draft (see draft-nordmark-6lowpan-reg-00 
<https://datatracker.ietf.org/doc/draft-nordmark-6lowpan-reg/>).
If we had a reliable mechanism by which the switch could discover 
bindings, then we would not have to snoop, and would not be exposed to 
snoop failures.
This is excluded by the charter, so I am not arguying about considering 
these. However, on the longer term, I'd be interrested in exploring more 
robust solutions ...
Eric

---

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

However, on the longer term, I'd be interrested in exploring more
> Eric

I entirely agree with this point. Building security protocol on unreliable
protocol(especially, slaac) seems awkward.

Guang

Eric
> Levy-Abegnoli
> Sent: Tuesday, March 16, 2010 11:04 PM