Subject: [savi] a question about your comment on savi-dhcp-02

From: "Jun Bi" <[email-masked]>
Date: Fri, 16 Apr 2010 15:58:03 +0800

Hi Joel,

We have a question about your comment on savi-dhcp-02, what does it mean? 

Thanks,
Jun Bi:

You wrote:
8) As currently written, there is no way to record a negative conclusion about filtering.  This means that if a host is using an improper address, every data packet will trigger validation.  Even with rate limiting, this seems unfortunate, given that we have determined that the answer is no.  (This is not a protection against a malicious host, but merely more effective handling of a host with a problem.)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 16 Apr 2010 11:28:18 -0400

The set of tables described in the document record positive DHCP
resolutions.

As discussed, there are provisions for dealing with loss of information.
 This may cause the SAVI device to react to packets with unknown source
Ipv6 addresses by undertaking verification transactions.

Suppose the verification fails.  The SAVI devices now knows that anchor
A is not allowed to use IPv6 source address B.
But there is no place to record this fact.  Which means that it will be
ignored, and the next data packet will cause another start to the
verification cycle.  This can occur either because the host is
malicious, or more likely because the host is confused.  But it is
undesirable for a confused host to trigger large amounts of control traffic.

One can argue tghat what I am asking for is a local optimization, and
does not need to be described in teh standard.  In that case, I would
want simply a few words in the text, without a table update, noting that
the SAVI device may chose to remember failed validations.  (It will
probably take more than one sentence, as we also need to not remember
such things forever.)

Yours,
Joel

Jun Bi wrote:
> 8) As currently written, there is no way to record a negative conclusion 
> about filtering.  This means that if a host is using an improper 
> address, every data packet will trigger validation.  Even with rate 
> limiting, this seems unfortunate, given that we have determined that the 
> answer is no.  (This is not a protection against a malicious host, but 
> merely more effective handling of a host with a problem.)
>  
>

---

From: "Bi Jun" <[email-masked]>
Date: Sat, 17 Apr 2010 12:22:36 +0800

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Friday, April 16, 2010 11:28 PM
To: "Jun Bi" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Subject: Re: [savi] a question about your comment on savi-dhcp-02

Hi Joel,

That's exactly the problem of data-triggered actions.(I thought you didn't 
agree it like Marcelo)
That's why I insist the data-triggered can't be the only MUST.
In reality, I believe the vendors will implement some technology with 
counter-triggered.

thanks,
Jun

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 17 Apr 2010 09:27:32 +0200

El 17/04/10 6:22, Bi Jun escribió:
> That's exactly the problem of data-triggered actions.(I thought you 
> didn't agree it like Marcelo)
i believe this is orthogonal to data trigger, counter triggered or even 
some cases of control triggered.
I understnad that Joel's point is that if the verification of binding 
results in the SAVI switch doing something, it would be useful not only 
to record positive bindings, but also negative bindings (in order to 
avoid doing the verification operation again).
This seems to simply require to record the negative bindings as well 
(for some time).
the issue that negative caching also requires resources, so i guess the 
question is whether it is worse the resurce spent in the re-verification 
or the negative cache.

Regards, marcelo

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 17 Apr 2010 10:18:51 -0400

Just for clarity, Marcelo has correctly understood and paraphrased the 
question I was raising.

Yours,
Joel

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 17 Apr 2010 16:38:32 +0200

after thinking it a bit more, i wonder if rate limiting doesn't 
partially address this issue.
I mean, negative caching implies memory consution and extra verification 
implies extra traffic geenrated by the SAVI switch. By rate lmiting, we 
eventually reduce both. But probably this needs more thought...

El 17/04/10 16:18, Joel M. Halpern escribió:
>>> In reality, I believe the vendors will implement some technology 
>>> with counter-triggered.
>>>
>> i believe this is orthogonal to data trigger, counter triggered or 
>> even some cases of control triggered.
>> results in the SAVI switch doing something, it would be useful not 
>> only to record positive bindings, but also negative bindings (in 
>> order to avoid doing the verification operation again).
>> the issue that negative caching also requires resources, so i guess 
>> the question is whether it is worse the resurce spent in the 
>> re-verification or the negative cache.
>>
>> Regards, marcelo
>>
>>
>>> thanks,
>>> Jun
>>>
>>>
>>>>

---

From: "Bi Jun" <[email-masked]>
Date: Sun, 18 Apr 2010 01:01:53 +0800

Hi Marcelo and Joel,

I am confused. Even the switch only record the positive binding,
it actually implies the negative binding is also stored:
the negative binding = the full address space - addresses in positive 
binding table.
In implementation, the positive binding is the "permit entry at ACL", the 
negative binding is "deny all at ACL". It seems that there is no extra 
action.

IMHO, I think the more fine-granularity negative binding (than deny all) is 
not useful. The finding of a host (e.g positive binding is address A) 
attached to a port currently is spoofing address B doesn't means the 
spoofing host can not spoof address C in next packet. The host can use any 
random source address on its spoofing traffic. So the savi switch should 
only permit the traffic of address A (positive binding) then drop all the 
packet not using address A. (certainly, the supplement functions are needed 
be recover the binding in the case of positive binding is missing possibly 
by loss of control packet, but the data-triggered can not be the only MUST 
function to recover, due to the issues/problems Fred Baker and others has 
discussed).

thanks,
Jun Bi

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Saturday, April 17, 2010 10:18 PM
To: "marcelo bagnulo braun" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] a question about your comment on savi-dhcp-02

>> This seems to simply require to record the negative bindings as well (for 
>> some time).

---

From: "Bi Jun" <[email-masked]>
Date: Sun, 18 Apr 2010 01:05:52 +0800

Hi Marcelo,

The rate limit could help many solutions, unfortunately, the only solution 
it could not help is the data-triggered CPU actions in most switches (as 
discussed in past weeks).

thanks,
Jun Bi

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Saturday, April 17, 2010 10:38 PM
To: "Joel M. Halpern" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] a question about your comment on savi-dhcp-02

> after thinking it a bit more, i wonder if rate limiting doesn't partially 
> address this issue.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 17 Apr 2010 20:13:23 +0200

Jun,

As i see it, from the specification perspective, the data triggered and 
counter triggered approaches are indistinguishable.
So, if this can be implemented in the counter triggered approach that 
would suffice.

Regards, marcelo

El 17/04/10 19:05, Bi Jun escribió:
> Hi Marcelo,
>
> The rate limit could help many solutions, unfortunately, the only 
> solution it could not help is the data-triggered CPU actions in most 
> switches (as discussed in past weeks).
>
> thanks,
> Jun Bi
>
>> I mean, negative caching implies memory consution and extra 
>> verification implies extra traffic geenrated by the SAVI switch. By 
>> rate lmiting, we eventually reduce both. But probably this needs more 
>> thought...
>>
>>> Just for clarity, Marcelo has correctly understood and paraphrased 
>>> the question I was raising.
>>>
>>> Yours,
>>> Joel
>>>
>>>>> That's exactly the problem of data-triggered actions.(I thought 
>>>>> you didn't agree it like Marcelo)
>>>> I understnad that Joel's point is that if the verification of 
>>>> binding results in the SAVI switch doing something, it would be 
>>>> useful not only to record positive bindings, but also negative 
>>>> bindings (in order to avoid doing the verification operation again).
>>>> This seems to simply require to record the negative bindings as 
>>>> well (for some time).

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 17 Apr 2010 20:22:39 +0200

I understand that what Joel was after would be something like the following:
A SAVI device can have essentially 3 types of addresses:
- An address for which it has a binding with a given lower layer anchor.
- an address for which it has no lower layer an anchor and has never 
received any packets related to that address
- an address for which it has no binding, but for which it has trigger 
the binding creation procedure and the procedure has failed. (an example 
of this is suppose that a savi switch receives one or more data packets 
fro a given source address for which it has no binding and that results 
in triggering the binding creation procedure. Suppose that the address 
is actually defended by some other host that is connected to another 
SAVI device. The result is that no binding will be created for this 
address in the initial SAVI device. The question i understnad Joel is 
asking is whether this SAVI device caches info realted tot he failed 
binding creation procedure.

I don't know the answer to that one, i haven't made my mind just yet.
As i said, it is a tradeoff between using memory (for the negative 
caching) versus bandwidth (re doing the binding creation procedure)
That is why i think rate limiting may help (for the latter, of course)

Regards, marcelo

El 17/04/10 19:01, Bi Jun escribió:
> In implementation, the positive binding is the "permit entry at ACL", 
> the negative binding is "deny all at ACL". It seems that there is no 
> extra action.
>
> IMHO, I think the more fine-granularity negative binding (than deny 
> all) is not useful. The finding of a host (e.g positive binding is 
> address A) attached to a port currently is spoofing address B doesn't 
> means the spoofing host can not spoof address C in next packet. The 
> host can use any random source address on its spoofing traffic. So the 
> savi switch should only permit the traffic of address A (positive 
> binding) then drop all the packet not using address A. (certainly, the 
> supplement functions are needed be recover the binding in the case of 
> positive binding is missing possibly by loss of control packet, but 
> the data-triggered can not be the only MUST function to recover, due 
> to the issues/problems Fred Baker and others has discussed).
>
> thanks,
> Jun Bi
>
>

---

From: "Jun Bi" <[email-masked]>
Date: Sun, 18 Apr 2010 02:24:33 +0800

Hi Marcelo,

But I think the data-triggered and counter triggered are quit different,
depending on the fundamental principle of the specification.

thanks,
Jun

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Sunday, April 18, 2010 2:13 AM
To: "Bi Jun" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] a question about your comment on savi-dhcp-02

>>>>> only to record positive bindings, but also negative bindings (in order 
>>>>> to avoid doing the verification operation again).

---

From: "Bi Jun" <[email-masked]>
Date: Sun, 18 Apr 2010 02:40:35 +0800

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Sunday, April 18, 2010 2:22 AM
To: "Bi Jun" <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>; <[email-masked]>
Subject: Re: [savi] a question about your comment on savi-dhcp-02

> - an address for which it has no binding, but for which it has trigger the 
> binding creation procedure and the procedure has failed.

Hi Marcelo,

Assuming the host is using address A, B, C in the above 3 cases.
Then may I know what't the difference between situation B and C ?

The problem is there is no explicit address exit mechanism in SLAAC. Then 
even the binding of address C was failed by the savi-switch sending out a 
probe at time t, then the host can still use address C at time t' if the new 
probe shows that the old "legal user" of C has given up the using of address 
C by without reply NA to that probe.
Then the B and C will need the same processing and there is no difference.

That's one of the problem we said SLAAC has problems to get a very idal savi 
solution, unless:
1 we can change SLAAC, or
2 the savi WG can allow the host to install a client and have a new protocol 
to sync the state of host and savi-switch.

thanks,
Jun

>(an example of this is suppose that a savi switch receives one or more data 
>packets fro a given source address for which it has no binding and that 
>results in triggering the binding creation procedure. Suppose that the 
>address is actually defended by some other host that is connected to 
>another SAVI device. The result is that no binding will be created for this 
>> IMHO, I think the more fine-granularity negative binding (than deny all) 
>> is not useful. The finding of a host (e.g positive binding is address A) 
>> spoofing host can not spoof address C in next packet. The host can use 
>> any random source address on its spoofing traffic. So the savi switch 
>> should only permit the traffic of address A (positive binding) then drop 
>> all the packet not using address A. (certainly, the supplement functions 
>> are needed be recover the binding in the case of positive binding is 
>> missing possibly by loss of control packet, but the data-triggered can 
>> not be the only MUST function to recover, due to the issues/problems Fred 
>> Baker and others has discussed).
>>
>> thanks,
>> Jun Bi
>>
>>
>>>> question is whether it is worse the resurce spent in the

---

From: "Bi Jun" <[email-masked]>
Date: Sun, 18 Apr 2010 02:42:55 +0800

Say it more clearly, the counter-based does not means FCFS (using the 
data-triggered as the fundamental principle).

thanks,
Jun Bi

--------------------------------------------------
From: "Jun Bi" <[email-masked]>
Sent: Sunday, April 18, 2010 2:24 AM
To: "marcelo bagnulo braun" <[email-masked]>; "Bi Jun" 
<[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] a question about your comment on savi-dhcp-02

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 17 Apr 2010 20:53:04 +0200

Well, as i see it, if you have a counter based triggered approach, where 
the threshold of the counter to trigger the binding creation process is 
set to 1, then the result is what you call the data triggered approach.
So, let me rephrase my previous statement, the data triggered is one 
special subcase of the more general approach which is the counter based.
 From the specification perspecitve, the difference, is whether the SAVI 
binding triggers the bindiong procedure upon the recepttion of 1 packet, 
or upon the recpetion of n packets. So, from the specificacion 
perspective, it would be to change a 1 to a n.

Regards, marcelo

El 17/04/10 20:42, Bi Jun escribió:
>>> As i see it, from the specification perspective, the data triggered 
>>> and counter triggered approaches are indistinguishable.
>>> So, if this can be implemented in the counter triggered approach 
>>> that would suffice.
>>>
>>> Regards, marcelo
>>>
>>>
>>>> solution it could not help is the data-triggered CPU actions in 
>>>> most switches (as discussed in past weeks).
>>>>
>>>> thanks,
>>>> Jun Bi
>>>>
>>>>> verification implies extra traffic geenrated by the SAVI switch. 
>>>>> By rate lmiting, we eventually reduce both. But probably this 
>>>>> needs more thought...
>>>>>
>>>>>> Just for clarity, Marcelo has correctly understood and 
>>>>>> paraphrased the question I was raising.
>>>>>>
>>>>>> Yours,
>>>>>> Joel
>>>>>>
>>>>>>>> In reality, I believe the vendors will implement some 
>>>>>>>> technology with counter-triggered.
>>>>>>>>
>>>>>>> i believe this is orthogonal to data trigger, counter triggered 
>>>>>>> or even some cases of control triggered.
>>>>>>> the issue that negative caching also requires resources, so i 
>>>>>>> guess the question is whether it is worse the resurce spent in 
>>>>>>> the re-verification or the negative cache.
>>>>>>>
>>>>>>> Regards, marcelo
>>>>>>>
>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Jun
>>>>>>>>
>>>>>>>>
>>>>>>>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 17 Apr 2010 20:55:57 +0200

El 17/04/10 20:40, Bi Jun escribió:
>> - an address for which it has no binding, but for which it has 
>> trigger the binding creation procedure and the procedure has failed.
>
> Hi Marcelo,
>
> The problem is there is no explicit address exit mechanism in SLAAC. 
> Then even the binding of address C was failed by the savi-switch 
> sending out a probe at time t, then the host can still use address C 
> at time t' if the new probe shows that the old "legal user" of C has 
> given up the using of address C by without reply NA to that probe.
right, the question is whether we impose a minimum time between t and 
t', in order to protect the SAVI switch from DoS attacks.
I mean, if the SAVI swithc has verified that the address is the C case 
at time t, then wheter it make sense to verify the same thing at t'=t+1 ms.
It seems it would make sense to make the verification process again at 
t'=t+1 day.
Regards, marcelo

>
> That's one of the problem we said SLAAC has problems to get a very 
> idal savi solution, unless:
> 2 the savi WG can allow the host to install a client and have a new 
> protocol to sync the state of host and savi-switch.
>
> thanks,
> Jun
>
>
>> (an example of this is suppose that a savi switch receives one or 
>> more data packets fro a given source address for which it has no 
>> binding and that results in triggering the binding creation 
>> procedure. Suppose that the address is actually defended by some 
>> other host that is connected to another SAVI device. The result is 
>> that no binding will be created for this address in the initial SAVI 
>> device. The question i understnad Joel is asking is whether this SAVI 
>> device caches info realted tot he failed binding creation procedure.
>>
>>> the negative binding = the full address space - addresses in 
>>> positive binding table.
>>> In implementation, the positive binding is the "permit entry at 
>>> ACL", the negative binding is "deny all at ACL". It seems that there 
>>> is no extra action.
>>>
>>> address A) attached to a port currently is spoofing address B 
>>> doesn't means the spoofing host can not spoof address C in next 
>>> packet. The host can use any random source address on its spoofing 
>>> traffic. So the savi switch should only permit the traffic of 
>>> address A (positive binding) then drop all the packet not using 
>>> address A. (certainly, the supplement functions are needed be 
>>> recover the binding in the case of positive binding is missing 
>>> possibly by loss of control packet, but the data-triggered can not 
>>> be the only MUST function to recover, due to the issues/problems 
>>> Fred Baker and others has discussed).
>>>
>>> thanks,
>>> Jun Bi
>>>
>>>
>>>>> guess the question is whether it is worse the resurce spent in the

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 17 Apr 2010 17:32:55 -0400

So lets rephrase FCFS as FAFS, meaning "First Admittedx, First Served." 
  We are not concerned with matching a mathematical interpretation of 
the draft name, but rather in achieing a useful service which recognizes 
the realities of what can be done.

As such, it seems to me that we can and should write our descriptions 
such that pure packet triggered and counter trigger are both allowed. 
It would be fine if we achieved that by writing the description in such 
  in terms of the measures we claim matter.

Yes, we could put ourselves in a box by writing the descriptions in a 
way that makes it unimplementable.  But taht would not be a sensible 
choice for the working group.

Yours,
Joel

Bi Jun wrote:
>>>>> rate lmiting, we eventually reduce both. But probably this needs 
>>>>> more thought...
>>>>>

---

From: "Jun Bi" <[email-masked]>
Date: Sun, 18 Apr 2010 17:32:51 +0800

Sent: Sunday, April 18, 2010 2:55 AM

>>> the binding creation procedure and the procedure has failed.
>>
>> Hi Marcelo,
>>
>> probe at time t, then the host can still use address C at time t' if the 
>> new probe shows that the old "legal user" of C has given up the using of 
>> address C by without reply NA to that probe.
> right, the question is whether we impose a minimum time between t and t', 
> in order to protect the SAVI switch from DoS attacks.
> I mean, if the SAVI swithc has verified that the address is the C case at 
> time t, then wheter it make sense to verify the same thing at t'=t+1 ms.

Hi Marcelo,

IMHO, this t'=t+1day theory proposed by you really sounds ridiculous for me.
What we can obey strictly is only RFC4862, did SLAAC said once an address 
DADed and find it is currently used by host X, then host Y can only use it 1 
days later?

I know it's the problem of RFC4862, but you can not make a new address 
assignment method not conform to RFC4862 when you design an savi solution. 
The only way you can change an address assignment method is to change 
RFC4862 (as I and Guang Yao stated many times in the past emails).

thanks,
Jun Bi

>
>
>
>>
>> That's one of the problem we said SLAAC has problems to get a very idal 
>> savi solution, unless:
>>> (an example of this is suppose that a savi switch receives one or more 
>>> data packets fro a given source address for which it has no binding and 
>>> that results in triggering the binding creation procedure. Suppose that 
>>> the address is actually defended by some other host that is connected to 
>>> another SAVI device. The result is that no binding will be created for 
>>> this address in the initial SAVI device. The question i understnad Joel 
>>> is asking is whether this SAVI device caches info realted tot he failed 
>>>> positive binding is missing possibly by loss of control packet, but the 
>>>> data-triggered can not be the only MUST function to recover, due to the 
>>>> issues/problems Fred Baker and others has discussed).
>>>>
>>>> thanks,
>>>> Jun Bi
>>>>
>>>>

---

From: "Bi Jun" <[email-masked]>
Date: Sun, 18 Apr 2010 17:25:40 +0800

Hi marcelo,

Now you see the data-triggered is an extreme case.

There is one more argument:
The data-triggered is an action at data plan, then the CPU knows the source 
address of the data packet directly.

The counter-triggered is not an action at data plan, so the CPU has no way 
to know the source address the data packet. Then it's perfectly to rely the 
counter-triggered actions for alert, not ideal for setting-up new binding.

thanks,
Jun

thanks,
Jun

Sent: Sunday, April 18, 2010 2:53 AM

---

From: "Bi Jun" <[email-masked]>
Date: Sun, 18 Apr 2010 17:50:01 +0800

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Sunday, April 18, 2010 5:32 AM
To: "Bi Jun" <[email-masked]>
Cc: "marcelo bagnulo braun" <[email-masked]>; <[email-masked]>
Subject: Re: [savi] a question about your comment on savi-dhcp-02

> So lets rephrase FCFS as FAFS, meaning "First Admittedx, First Served." We 
> are not concerned with matching a mathematical interpretation of the draft 
> name, but rather in achieing a useful service which recognizes the 
> realities of what can be done.
>
> As such, it seems to me that we can and should write our descriptions such 
> that pure packet triggered and counter trigger are both allowed.

Hi Joel,

But allowed for what? It could not be the fundamental principle of a savi 
binding,
it can only be a supplement for recovering the binding for not-quit frequent 
case (e.g. the control packet loss).

We have to follow RFC4862. It says that the host must finish DAD first, 
before that, the address is only a "tentative address"), then the 
fundamental binding set-up rule should be control packet snooping (by 
savi-swtich watching the DAD procedure, as stated in savi-cps or savi-dhcp 
and savi-slaac which we are using at CNGI-CERNET real deployment), not FCFS. 
That's my point repeated many times. The problem is that the RFC4862 doesn't 
make the DAD procedure more reliable, then we need a supplement binding 
recovering mechanism in SAVI. But those supplement actions are not ideal 
yet(especially among them, data-triggered is a solution with more serious 
potential problem in implementation) . To seek an ideal savi solution is to 
either to make SLAAC more reliable or re-charter SAVI to permit a new 
protocol between host and savi-switch to sync states.

People can see some WG members are still be against using the data-triggered 
or counter-triggered, although personally I am OK with using one of them as 
one of the MUSTs (please see recently officially submitted savi-dhcp-02).

thanks,
Jun

> It would be fine if we achieved that by writing the description in such in 
> terms of the measures we claim matter.
>
> Yes, we could put ourselves in a box by writing the descriptions in a way 
> that makes it unimplementable.  But taht would not be a sensible choice 
> for the working group.
>
> Yours,
> Joel
>
> Bi Jun wrote:

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 18 Apr 2010 13:05:53 +0200

El 18/04/10 11:25, Bi Jun escribió:
> The data-triggered is an action at data plan, then the CPU knows the 
> source address of the data packet directly.
>
Here you are referring about how to implement it and not about the 
external behaviour, which is what is described int he specifications.
 From the specification perspective, what we need to describe is the 
external behaviour which is that upon the recpetion of one or more data 
packets containing a source address for which there is no binding, the 
SAVI device will trigger the binding creation procedure. Whether this is 
done by inspecting the packets in the data path, or by incrementing a 
counter that triggers the procedure, it is completelly transparent to 
the specification imho

> The counter-triggered is not an action at data plan, so the CPU has no 
> way to know the source address the data packet. Then it's perfectly to 
> rely the counter-triggered actions for alert, not ideal for setting-up 
> new binding.
>
I understnad you mean that the counter can trigger a procedure, such as 
the binding creation procedure, right?

Regards, marcelo

>> Well, as i see it, if you have a counter based triggered approach, 
>> where the threshold of the counter to trigger the binding creation 
>> process is set to 1, then the result is what you call the data 
>> triggered approach.
>> From the specification perspecitve, the difference, is whether the 
>> SAVI binding triggers the bindiong procedure upon the recepttion of 1 
>> packet, or upon the recpetion of n packets. So, from the 
>> specificacion perspective, it would be to change a 1 to a n.
>>
>> Regards, marcelo
>>
>>
>>> Say it more clearly, the counter-based does not means FCFS (using 
>>> the data-triggered as the fundamental principle).
>>>
>>> thanks,
>>> Jun Bi
>>>
>>>>> As i see it, from the specification perspective, the data 
>>>>> triggered and counter triggered approaches are indistinguishable.
>>>>>>>>>> That's exactly the problem of data-triggered actions.(I 
>>>>>>>>>> thought you didn't agree it like Marcelo)
>>>>>>>>> i believe this is orthogonal to data trigger, counter 
>>>>>>>>> triggered or even some cases of control triggered.
>>>>>>>>> binding results in the SAVI switch doing something, it would 
>>>>>>>>> be useful not only to record positive bindings, but also 
>>>>>>>>> negative bindings (in order to avoid doing the verification 
>>>>>>>>> operation again).
>>>>>>>>> This seems to simply require to record the negative bindings 
>>>>>>>>> as well (for some time).

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 18 Apr 2010 13:16:06 +0200

El 18/04/10 11:32, Jun Bi escribió:
>>>> - an address for which it has no lower layer an anchor and has 
>>>> never received any packets related to that address
>> I mean, if the SAVI swithc has verified that the address is the C 
>> case at time t, then wheter it make sense to verify the same thing at 
>> t'=t+1 ms.
>> It seems it would make sense to make the verification process again 
>> at t'=t+1 day.
>> Regards, marcelo
>
> Hi Marcelo,
>

FWIW, i wasn't proposing anything, i was merely trying to describe to 
you what i understood previous comments made in the list were. It seems 
i didn't make a very good job, so i will abstain to make additional 
clarifications on other people comments on this issue.

I personally don't have an opinion on this one yet.

Regards, marcelo

---

From: "Jun Bi" <[email-masked]>
Date: Sun, 18 Apr 2010 19:16:40 +0800

Sent: Sunday, April 18, 2010 7:05 PM

> counter that triggers the procedure, it is completelly transparent to the 
> specification imho

Hi Marcelo,

But you need to consider the feasibility when you ask a MUST in the 
specification, right ?

> the binding creation procedure, right?

I meant there is a difference between data plan and counter. Counter can be 
used to trigger an alert perfectly, but because it's not a data plan 
function, then it has some problem to trigger the binding creation in 
implementation.

thanks,
Jun

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 18 Apr 2010 13:20:03 +0200

El 18/04/10 13:16, Jun Bi escribió:
>> external behaviour which is that upon the recpetion of one or more 
>> data packets containing a source address for which there is no 
>> binding, the SAVI device will trigger the binding creation procedure. 
>> Whether this is done by inspecting the packets in the data path, or 
>> by incrementing a counter that triggers the procedure, it is 
>> completelly transparent to the specification imho
>
> Hi Marcelo,
>

right,
so, it has been stated several times in this ml that the data triggered 
can be implemneted in some of the architectures and it seems that the 
counter triggered can be implemented in most of the architectures (i 
haven't heard anyone saying that it cannot be implemented so far).
So, mandating  external behaviour which can be implemented in either of 
the apprpaches should be no problem.

regards, marcelo

>
>>
>>> The counter-triggered is not an action at data plan, so the CPU has 
>>> no way to know the source address the data packet. Then it's 
>>> perfectly to rely the counter-triggered actions for alert, not ideal 
>>> for setting-up new binding.
>>>
>> I understnad you mean that the counter can trigger a procedure, such 
>> as the binding creation procedure, right?
>
> I meant there is a difference between data plan and counter. Counter 
> can be used to trigger an alert perfectly, but because it's not a data 
> plan function, then it has some problem to trigger the binding 
> creation in implementation.
>

>>>> So, let me rephrase my previous statement, the data triggered is 
>>>> one special subcase of the more general approach which is the 
>>>> counter based.
>>>> SAVI binding triggers the bindiong procedure upon the recepttion of 
>>>> 1 packet, or upon the recpetion of n packets. So, from the 
>>>>>>>> The rate limit could help many solutions, unfortunately, the 
>>>>>>>> only solution it could not help is the data-triggered CPU 
>>>>>>>> actions in most switches (as discussed in past weeks).
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Jun Bi
>>>>>>>>
>>>>>>>>> after thinking it a bit more, i wonder if rate limiting 
>>>>>>>>> doesn't partially address this issue.
>>>>>>>>> verification implies extra traffic geenrated by the SAVI 
>>>>>>>>> switch. By rate lmiting, we eventually reduce both. But 
>>>>>>>>> probably this needs more thought...
>>>>>>>>>
>>>>>>>>>>> I understnad that Joel's point is that if the verification 
>>>>>>>>>>> of binding results in the SAVI switch doing something, it 
>>>>>>>>>>> would be useful not only to record positive bindings, but 
>>>>>>>>>>> also negative bindings (in order to avoid doing the 
>>>>>>>>>>> verification operation again).
>>>>>>>>>>> the issue that negative caching also requires resources, so 
>>>>>>>>>>> i guess the question is whether it is worse the resurce 
>>>>>>>>>>> spent in the re-verification or the negative cache.
>>>>>>>>>>>
>>>>>>>>>>> Regards, marcelo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> thanks,
>>>>>>>>>>>> Jun
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>

---

From: "Jun Bi" <[email-masked]>
Date: Sun, 18 Apr 2010 19:34:30 +0800

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Sunday, April 18, 2010 7:16 PM
To: "Jun Bi" <[email-masked]>
Cc: "Bi Jun" <[email-masked]>; <[email-masked]>
Subject: Re: [savi] a question about your comment on savi-dhcp-02

>>>> sending out a probe at time t, then the host can still use address C at 
>>>> time t' if the new probe shows that the old "legal user" of C has given 
>>>> up the using of address C by without reply NA to that probe.
> FWIW, i wasn't proposing anything, i was merely trying to describe to you 
> what i understood previous comments made in the list were. It seems i 
> didn't make a very good job, so i will abstain to make additional 

Hi Marcelo,

Thank you for letting me know.

Best Regards,
Jun

---

From: "Bi Jun" <[email-masked]>
Date: Sun, 18 Apr 2010 19:40:04 +0800

Sent: Sunday, April 18, 2010 7:20 PM

> can be implemneted in some of the architectures

Hi Marcelo,

IMHO, I doubt this. Maybe I missed some discussion. By whom it was stated 
the data-triggered is feasible? I recalled Fred Baker's comments on the 
problem of data-triggered on the mailing-list days ago, and I see nobody 
disagree with him.

thanks,
Jun Bi

> and it seems that the counter triggered can be implemented in most of the 
> architectures (i haven't heard anyone saying that it cannot be implemented 
> so far).
>> I meant there is a difference between data plan and counter. Counter can 
>> be used to trigger an alert perfectly, but because it's not a data plan 
>>>>> packet, or upon the recpetion of n packets. So, from the specificacion

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 18 Apr 2010 14:23:59 +0200

El 18/04/10 13:40, Bi Jun escribió:
>>>>> The data-triggered is an action at data plan, then the CPU knows 
>>>>> the source address of the data packet directly.
>>>>>
>>>> binding, the SAVI device will trigger the binding creation 
>>>> procedure. Whether this is done by inspecting the packets in the 
>>>> data path, or by incrementing a counter that triggers the 
>>>> procedure, it is completelly transparent to the specification imho
>>>
>>> Hi Marcelo,
>>>
>> so, it has been stated several times in this ml that the data 
>> triggered can be implemneted in some of the architectures
>
> Hi Marcelo,
>
> IMHO, I doubt this. Maybe I missed some discussion. By whom it was 
> stated the data-triggered is feasible?
By you.
Many times you stated that high end switches can implement the data 
triggered.

For instance, in  15/03/10 13:26, Bi Jun wrote:
Hi Marcelo,

We can guide the users in this document or in framework,
if you want to put a hub between savi-device or your host, please buy an 
more expensive savi-device that implemented the xxx options functions 
(e.g the data triggered functions listed in savi-dhcp-02, or another 
solution document).

thanks,
Jun

Later on the 15/03/10 15:48, Bi Jun wrote:
  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).

But in any case, this is irrelevant.
Then thing is that if we specify the external behaviour (whcih is what a 
spec should describe) we have different ways whch can be implemented, 
and it seems that that everybody seem to agree that ther is at least one 
possible way to implement the behaviour whcih can be externally descibed as:
- If the SAVI device recieves one or more data packets for whcih it has 
no binding, then it triggers the binding creation procedure.

Regards, marcelo

> I recalled Fred Baker's comments on the problem of data-triggered on 
> the mailing-list days ago, and I see nobody disagree with him.
>
> thanks,
> Jun Bi
>
>> and it seems that the counter triggered can be implemented in most of 
>> the architectures (i haven't heard anyone saying that it cannot be 
>> implemented so far).
>> So, mandating  external behaviour which can be implemented in either 
>> of the apprpaches should be no problem.
>>
>> regards, marcelo
>>
>>>
>>>>
>>>>> The counter-triggered is not an action at data plan, so the CPU 
>>>>> has no way to know the source address the data packet. Then it's 
>>>>> perfectly to rely the counter-triggered actions for alert, not 
>>>>> ideal for setting-up new binding.
>>>>>
>>>> I understnad you mean that the counter can trigger a procedure, 
>>>> such as the binding creation procedure, right?
>>>
>>> can be used to trigger an alert perfectly, but because it's not a 
>>> data plan function, then it has some problem to trigger the binding 
>>>>>> Well, as i see it, if you have a counter based triggered 
>>>>>> approach, where the threshold of the counter to trigger the 
>>>>>> binding creation process is set to 1, then the result is what you 
>>>>>> call the data triggered approach.
>>>>>> From the specification perspecitve, the difference, is whether 
>>>>>> the SAVI binding triggers the bindiong procedure upon the 
>>>>>> recepttion of 1 packet, or upon the recpetion of n packets. So, 
>>>>>> from the specificacion perspective, it would be to change a 1 to 
>>>>>> a n.
>>>>>>
>>>>>> Regards, marcelo
>>>>>>
>>>>>>
>>>>>>> Say it more clearly, the counter-based does not means FCFS 
>>>>>>> (using the data-triggered as the fundamental principle).
>>>>>>>
>>>>>>> thanks,
>>>>>>> Jun Bi
>>>>>>>
>>>>>>>>> So, if this can be implemented in the counter triggered 
>>>>>>>>> approach that would suffice.
>>>>>>>>>
>>>>>>>>> Regards, marcelo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> This seems to simply require to record the negative 
>>>>>>>>>>>>> bindings as well (for some time).
>>>>>>>>>>>>> the issue that negative caching also requires resources, 
>>>>>>>>>>>>> so i guess the question is whether it is worse the resurce

---

From: "Bi Jun" <[email-masked]>
Date: Sun, 18 Apr 2010 21:13:13 +0800

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Sunday, April 18, 2010 8:23 PM
To: "Bi Jun" <[email-masked]>
Cc: "Jun Bi" <[email-masked]>; <[email-masked]>
Subject: Re: [savi] a question about your comment on savi-dhcp-02

>>>>> Whether this is done by inspecting the packets in the data path, or by 
>>>>> incrementing a counter that triggers the procedure, it is completelly 
>>>>> transparent to the specification imho
>>>>
>>>> Hi Marcelo,
>>>>
>> the data-triggered is feasible?
> By you.

Hi Marcelo,

Oh, you meant me. But you know what I really meant for those messages at 
that time: the data-triggered could not be the MUST.
(1)The high-end switch is very few among savi-switches, especially from 
deployers' viewpoint.
(2)it was an assuming, it was not been supported by any vendors yet.

> more expensive savi-device that implemented the xxx options functions (e.g 
> the data triggered functions listed in savi-dhcp-02, or another solution 
> document).
>
> thanks,
> Jun
>
> spec should describe) we have different ways whch can be implemented, and 
> it seems that that everybody seem to agree that ther is at least one 
> - If the SAVI device recieves one or more data packets for whcih it has no 
> binding, then it triggers the binding creation procedure.

But it's relevant to the principle of solution, if you make the 
data-triggered actions as the principle of SAVI like FCFS (First Comes First 
Serves), then I am against because it is not conform to address assignment 
mechanism and not realistic. Moreover, it seems that you didn't really 
understand why the data-triggered and counter triggered is different. Please 
see my last reply or read savi-dhcp-02.

thanks,
Jun Bi

>
> Regards, marcelo
>
>
>
>
>> I recalled Fred Baker's comments on the problem of data-triggered on the 
>> mailing-list days ago, and I see nobody disagree with him.
>>
>> thanks,
>> Jun Bi
>>
>>>> plan function, then it has some problem to trigger the binding creation 
>>>> in implementation.
>>>>
>>>
>>>> thanks,
>>>> Jun
>>>>>
>>>>> Regards, marcelo
>>>>>
>>>>>
>>>>>> thanks,
>>>>>> Jun
>>>>>>
>>>>>>
>>>>>>
>>>>>> thanks,
>>>>>> Jun
>>>>>>
>>>>>>>>>>>>>> guess the question is whether it is worse the resurce spent 
>>>>>>>>>>>>>> in the re-verification or the negative cache.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards, marcelo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 18 Apr 2010 17:45:46 +0200

El 18/04/10 15:13, Bi Jun escribió:
>>>>>> Here you are referring about how to implement it and not about 
>>>>>> the external behaviour, which is what is described int he 
>>>>>> specifications.
>>>>>> From the specification perspective, what we need to describe is 
>>>>>> the external behaviour which is that upon the recpetion of one or 
>>>>>> more data packets containing a source address for which there is 
>>>>>> no binding, the SAVI device will trigger the binding creation 
>>>>> But you need to consider the feasibility when you ask a MUST in 
>>>>> the specification, right ?
>>>>
>>>> right,
> Oh, you meant me. But you know what I really meant for those messages 
> at that time: the data-triggered could not be the MUST.
> (1)The high-end switch is very few among savi-switches, especially 
> from deployers' viewpoint.
>> if you want to put a hub between savi-device or your host, please buy 
>> an more expensive savi-device that implemented the xxx options 
>> functions (e.g the data triggered functions listed in savi-dhcp-02, 
>> or another solution document).
>>
>> thanks,
>> Jun
>>
>> Then thing is that if we specify the external behaviour (whcih is 
>> what a spec should describe) we have different ways whch can be 
>> implemented, and it seems that that everybody seem to agree that ther 
>> is at least one possible way to implement the behaviour whcih can be 
>> externally descibed as:
>> - If the SAVI device recieves one or more data packets for whcih it 
>> has no binding, then it triggers the binding creation procedure.
>
> data-triggered actions as the principle of SAVI like FCFS (First Comes 
> First Serves), then I am against because it is not conform to address 
> assignment mechanism and not realistic.

Well, it seems we need to agree to disagree.
The principle of the solution is exactly the same, we are only talking 
about the implementation of the solution.
As i stated earlier, the only difference from the specification 
perspective, would be to change that instead of receiving one data 
packet, the triggering of the binding creation procedure is upon the 
reception of n packets (where n can be one).

Regards, marcelo

> Moreover, it seems that you didn't really understand why the 
> data-triggered and counter triggered is different. Please see my last 
> reply or read savi-dhcp-02.
>

>>>> and it seems that the counter triggered can be implemented in most 
>>>> of the architectures (i haven't heard anyone saying that it cannot 
>>>> be implemented so far).
>>>> So, mandating  external behaviour which can be implemented in 
>>>> either of the apprpaches should be no problem.
>>>>
>>>> regards, marcelo
>>>>
>>>>>
>>>>>>
>>>>> I meant there is a difference between data plan and counter. 
>>>>> Counter can be used to trigger an alert perfectly, but because 
>>>>> it's not a data plan function, then it has some problem to trigger 
>>>>> the binding creation in implementation.
>>>>>
>>>>
>>>>> thanks,
>>>>> Jun
>>>>>>
>>>>>> Regards, marcelo
>>>>>>
>>>>>>
>>>>>>> thanks,
>>>>>>> Jun
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> thanks,
>>>>>>> Jun
>>>>>>>
>>>>>>>> binding creation process is set to 1, then the result is what 
>>>>>>>> you call the data triggered approach.
>>>>>>>> So, let me rephrase my previous statement, the data triggered 
>>>>>>>> is one special subcase of the more general approach which is 
>>>>>>>> the counter based.
>>>>>>>> from the specificacion perspective, it would be to change a 1 
>>>>>>>> to a n.
>>>>>>>>
>>>>>>>> Regards, marcelo
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> The rate limit could help many solutions, unfortunately, 
>>>>>>>>>>>> the only solution it could not help is the data-triggered 
>>>>>>>>>>>> CPU actions in most switches (as discussed in past weeks).
>>>>>>>>>>>>
>>>>>>>>>>>> thanks,
>>>>>>>>>>>> Jun Bi
>>>>>>>>>>>>
>>>>>>>>>>>>> I mean, negative caching implies memory consution and 
>>>>>>>>>>>>> extra verification implies extra traffic geenrated by the 
>>>>>>>>>>>>> SAVI switch. By rate lmiting, we eventually reduce both. 
>>>>>>>>>>>>> But probably this needs more thought...
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I understnad that Joel's point is that if the 
>>>>>>>>>>>>>>> verification of binding results in the SAVI switch doing 
>>>>>>>>>>>>>>> something, it would be useful not only to record 
>>>>>>>>>>>>>>> positive bindings, but also negative bindings (in order 
>>>>>>>>>>>>>>> so i guess the question is whether it is worse the 
>>>>>>>>>>>>>>> resurce spent in the re-verification or the negative cache.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards, marcelo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>

---

From: "Bi Jun" <[email-masked]>
Date: Mon, 19 Apr 2010 00:47:40 +0800

Sent: Sunday, April 18, 2010 11:45 PM

>>>>>>> data path, or by incrementing a counter that triggers the procedure, 
>>>>>>> it is completelly transparent to the specification imho
>>>>>>
>>>>>> Hi Marcelo,
>>>>>>
> perspective, would be to change that instead of receiving one data packet, 
> the triggering of the binding creation procedure is upon the reception of 
> n packets (where n can be one).

Hi Marcelo,

It seems that you still doesn't understand why I said the counter-triggered 
is not same as data-triggered, because the counter-triggered is not a data 
plan solution,
say it clearly: the counter event can not deliver the data packet to CPU of 
savi-switch.

thanks,
Jun

>>>>>>>>> SAVI binding triggers the bindiong procedure upon the recepttion 
>>>>>>>>> of 1 packet, or upon the recpetion of n packets. So, from the

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 18 Apr 2010 14:18:31 -0400

Two important points:
1) The requirement is for a SLAAC solution.  There is actually no 
requirement for a data plane solution.  In particular, I would expect 
and hope that the SLAAC solution will be primarily based on DAD.
2) The counter based mechanism, is, as I understand the English words, a 
data plane solution.  It is based on events from the data plane, without 
any need for control packet events.

Yours,
Joel M. Halpern

Bi Jun wrote:
>
> Hi Marcelo,
> 
> It seems that you still doesn't understand why I said the 
> counter-triggered is not same as data-triggered, because the 
> counter-triggered is not a data plan solution,
> say it clearly: the counter event can not deliver the data packet to CPU 
> of savi-switch.
> 
> thanks,
> Jun

---

From: "Bi Jun" <[email-masked]>
Date: Mon, 19 Apr 2010 02:56:57 +0800

Sent: Monday, April 19, 2010 2:18 AM

> requirement for a data plane solution.  In particular, I would expect and 
> hope that the SLAAC solution will be primarily based on DAD.

thanks,
Jun

Hi Joel,

but the difference is that the counter is not a full data plan concept 
because the counter can only inform the CPU the statistics, but can not 
deliver the data packet  to the CPU.
thanks,
Jun

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 18 Apr 2010 21:35:00 +0200

El 18/04/10 20:56, Bi Jun escribió:
>> 2) The counter based mechanism, is, as I understand the English 
>> words, a data plane solution.  It is based on events from the data 
>> plane, without any need for control packet events.
>
> Hi Joel,
>
> because the counter can only inform the CPU the statistics, but can 
> not deliver the data packet  to the CPU.
and why delivering the data packet to the CPU is needed in any case?
all it is needed is that if a data packet for which there is no binding 
is received, the binding creation procedure is triggered.

Regards, marcelo

>>> say it clearly: the counter event can not deliver the data packet to 
>>> CPU of savi-switch.
>>>
>>> thanks,
>>> Jun
>>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 18 Apr 2010 21:35:28 +0200

i certainly agree with both points.
regards, marcelo

El 18/04/10 20:18, Joel M. Halpern escribió:
> 2) The counter based mechanism, is, as I understand the English words, 
> a data plane solution.  It is based on events from the data plane, 
> without any need for control packet events.
>
> Yours,
> Joel M. Halpern
>
> Bi Jun wrote:
>>
>> Hi Marcelo,
>>

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 19 Apr 2010 10:49:04 +0800

Sent: Monday, April 19, 2010 3:35 AM

> all it is needed is that if a data packet for which there is no binding is 
> received, the binding creation procedure is triggered.

Hi Marcelo,

In data-triggered, the data packet is used by CPU of savi-switch for binding 
creation procedure. That's why.

thanks,
Jun Bi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 19 Apr 2010 08:27:03 +0200

El 19/04/10 4:49, Jun Bi escribió:
>>>> requirement for a data plane solution.  In particular, I would 
>>>> expect and hope that the SLAAC solution will be primarily based on 
>>>> DAD.
>>>
>>> thanks,
>>> Jun
>>>
>>> but the difference is that the counter is not a full data plan 
>>> concept because the counter can only inform the CPU the statistics, 
>>> but can not deliver the data packet  to the CPU.
>> all it is needed is that if a data packet for which there is no 
>> binding is received, the binding creation procedure is triggered.
>
> Hi Marcelo,
>
> In data-triggered, the data packet is used by CPU of savi-switch for 
> binding creation procedure. That's why.
>

no
both in data triggered and counter triggered, it is the reception of one 
or more data packets that trigger the binding creation procedure.

There is absolutelly no need of other data packet information other than 
the fact that a data packet arrived containing a given source address, 
which is what is needed both for data triggered and for counter triggered.

As a matter of fact, as i have been saying, the only difference is that 
in one case it is only one data packet, while in the other case it can 
be one or more

Regards, marcelo

>>>>> say it clearly: the counter event can not deliver the data packet 
>>>>> to CPU of savi-switch.
>>>>>
>>>>> thanks,
>>>>> Jun
>>>>
>>>
>>

---

From: "Bi Jun" <[email-masked]>
Date: Mon, 19 Apr 2010 16:27:52 +0800

Sent: Monday, April 19, 2010 2:27 PM

> As a matter of fact, as i have been saying, the only difference is that in 
> one case it is only one data packet, while in the other case it can be one 
> or more
>
> Regards, marcelo
>

Hi Marcelo,

If the data packet is not delivered to CPU (like the control triggered 
solution),
then how the CPU knows the source address which is used in that data packet 
to create the binding? I talked with many vendors, they told me it is not 
implmentable.

thanks,
Jun

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 19 Apr 2010 10:39:59 +0200

El 19/04/10 10:27, Bi Jun escribió:
>>>>>> expect and hope that the SLAAC solution will be primarily based 
>>>>>> on DAD.
>>>>>
>>>>> thanks,
>>>>> Jun
>>>>>
>>>>>> words, a data plane solution.  It is based on events from the 
>>>>>> data plane, without any need for control packet events.
>>>>>
>>>>> Hi Joel,
>>>>>
>>>>> concept because the counter can only inform the CPU the 
>>>>> statistics, but can not deliver the data packet  to the CPU.
>> both in data triggered and counter triggered, it is the reception of 
>> one or more data packets that trigger the binding creation procedure.
>>
>> There is absolutelly no need of other data packet information other 
>> than the fact that a data packet arrived containing a given source 
>> address, which is what is needed both for data triggered and for 
>> counter triggered.
>>
>> As a matter of fact, as i have been saying, the only difference is 
>> that in one case it is only one data packet, while in the other case 
>> it can be one or more
>>
>> Regards, marcelo
>>
>
> Hi Marcelo,
>
> then how the CPU knows the source address which is used in that data 
> packet to create the binding?
In a counter triggered solution, how does the counter is incremented for 
a given source address? It would also need the source address, right?

In other words, the counter is an indirection level that allows to 
implement the triggering of actions upon the reception of a data packet, 
which is exactly what is needed for the data triggered.

As i mentioned earlier, a counter based is a particular way to implement 
the data triggered (and can also be used to implement a more general 
case, where the process of binding creation upon the recpetion of more 
than one packet.)

Regards, marcelo

> I talked with many vendors, they told me it is not implmentable.
>
> thanks,
> Jun
>
>
>
>>
>>> thanks,
>>> Jun Bi
>>>
>>>
>>>>
>>>> Regards, marcelo
>>>>
>>>>
>>>>> thanks,
>>>>> Jun
>>>>>
>>>>>>
>>>>>> Yours,
>>>>>> Joel M. Halpern
>>>>>>
>>>>>> Bi Jun wrote:
>>>>>>>
>>>>>>> Hi Marcelo,
>>>>>>>
>>>>>>> say it clearly: the counter event can not deliver the data 
>>>>>>> packet to CPU of savi-switch.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Jun
>>>>>>
>>>>>
>>>>

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 19 Apr 2010 16:43:26 +0800

Sent: Monday, April 19, 2010 4:39 PM

> In a counter triggered solution, how does the counter is incremented for a 
> given source address? It would also need the source address, right?

Hi Marcelo,

I wonder if you have real experience to investigate the counter in switches,
it is only the port-based, not source address based.

thanks,
Jun Bi

> the data triggered (and can also be used to implement a more general case, 
> where the process of binding creation upon the recpetion of more than one 
> packet.)
>
> Regards, marcelo
>
>
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 19 Apr 2010 10:50:15 +0200

El 19/04/10 10:43, Jun Bi escribió:
>>>>>>>> 1) The requirement is for a SLAAC solution.  There is actually 
>>>>>>>> no requirement for a data plane solution.  In particular, I 
>>>>>>>> would expect and hope that the SLAAC solution will be primarily 
>>>>>>>> based on DAD.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Jun
>>>>>>>
>>>>> In data-triggered, the data packet is used by CPU of savi-switch 
>>>>> for binding creation procedure. That's why.
>>>>>
>>>>
>>>> no
>>>> both in data triggered and counter triggered, it is the reception 
>>>> of one or more data packets that trigger the binding creation 
>>>> procedure.
>>>>
>>>> that in one case it is only one data packet, while in the other 
>>>> case it can be one or more
>>>>
>>>> Regards, marcelo
>>>>
>>>
>>> Hi Marcelo,
>>>
>>> If the data packet is not delivered to CPU (like the control 
>>> triggered solution),
>> In a counter triggered solution, how does the counter is incremented 
>> for a given source address? It would also need the source address, 
>> right?
>
> Hi Marcelo,
>
>From draft-ietf-savi-dhcp-02.txt

12.2.2. Counter Triggered Process

    In this process, a counter is used to record the number of filtered
    packets by this solution or all the enabled SAVI solutions on anchor
    with SAVI-CounterTrigger attribute. A constant TRIGGER_COUNT is set
    with the counter.

    Whenever the counter reaches TRIGGER_COUNT, this event MUST be
    handled by the SAVI device. The SAVI device performs following steps:

    1. Set the counter to 0;

    2. If the SAVI device is a layer-3 device, it MUST perform LEASEQUERY
       to check whether the source address of the triggering packet can
       be bound with the triggering anchor.

So, the SAVI device will perform a check whether the source address can 
be bound to the anchor, hence it needs the source address.

Regards, marcelo

>> implement the triggering of actions upon the reception of a data 
>> packet, which is exactly what is needed for the data triggered.
>>
>> As i mentioned earlier, a counter based is a particular way to 
>> implement the data triggered (and can also be used to implement a 
>> more general case, where the process of binding creation upon the 
>> recpetion of more than one packet.)
>>
>> Regards, marcelo
>>
>>
>>
>>

---

From: "Bi Jun" <[email-masked]>
Date: Mon, 19 Apr 2010 16:55:20 +0800

Sent: Monday, April 19, 2010 4:50 PM

> So, the SAVI device will perform a check whether the source address can be 
> bound to the anchor, hence it needs the source address.
>
> Regards, marcelo

Hi Marcelo,

Does it mean the counter is based on source address?
No. the counter is still based on port. For layer 3 switch, there is a 
neighbor table, then the layer 3 switch uses the neighbor table to send 
probe.

thanks,
Jun Bi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 19 Apr 2010 11:31:02 +0200

El 19/04/10 10:55, Bi Jun escribió:
>>>>>>>>>> 1) The requirement is for a SLAAC solution.  There is 
>>>>>>>>>> actually no requirement for a data plane solution.  In 
>>>>>>>>>> particular, I would expect and hope that the SLAAC solution 
>>>>>>>>>> will be primarily based on DAD.
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> Jun
>>>>>>>>>
>>>>>>>>>> 2) The counter based mechanism, is, as I understand the 
>>>>>>>>>> English words, a data plane solution.  It is based on events 
>>>>>>>>>> from the data plane, without any need for control packet events.
>>>>>>>>>
>>>>>>>>> Hi Joel,
>>>>>>>>>
>>>>>> There is absolutelly no need of other data packet information 
>>>>>> other than the fact that a data packet arrived containing a given 
>>>>>> source address, which is what is needed both for data triggered 
>>>>>> and for counter triggered.
>>>>>>
>>>>>> As a matter of fact, as i have been saying, the only difference 
>>>>>> is that in one case it is only one data packet, while in the 
>>>>>> other case it can be one or more
>>>>>>
>>>>>> Regards, marcelo
>>>>>>
>>>>>
>>>>> Hi Marcelo,
>>>>>
>>>>> then how the CPU knows the source address which is used in that 
>>>>> data packet to create the binding?
>>>> In a counter triggered solution, how does the counter is 
>>>> incremented for a given source address? It would also need the 
>>>> source address, right?
>>>
>>> Hi Marcelo,
>>>
>> So, the SAVI device will perform a check whether the source address 
>> can be bound to the anchor, hence it needs the source address.
>>
>> Regards, marcelo
>
> Hi Marcelo,
>
> neighbor table, then the layer 3 switch uses the neighbor table to 
> send probe.
>
What if you have more than one address in your neighbour table for a 
given port? (liek in IPv6, where you are likely to have many addresses 
even if you have a single host?)

Regards, marcelo

---

From: "Bi Jun" <[email-masked]>
Date: Mon, 19 Apr 2010 17:43:13 +0800

Sent: Monday, April 19, 2010 5:31 PM

> What if you have more than one address in your neighbour table for a given 
> port? (liek in IPv6, where you are likely to have many addresses even if 
> you have a single host?)
>
> Regards, marcelo

Hi Marcelo,

Is there any problem? There is savi binding table set up by control packet 
snooping, we just need to recover those address in the neighbor list but not 
in the savi list if the number of packet loss pass the threadhold. Because 
in the normal cases the bind is setup by control packet snooping, then it is 
not a heavy burden for this binding recovering (but if fundamental binding 
set up is based on data packet, then it will be too heavy burden to the 
device).

thanks,
Jun

>>>>> implement the data triggered (and can also be used to implement a more 
>>>>> general case, where the process of binding creation upon the recpetion 
>>>>> of more than one packet.)
>>>>>
>>>>> Regards, marcelo
>>>>>
>>>>>
>>>>>
>>>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 19 Apr 2010 11:48:55 +0200

El 19/04/10 11:43, Bi Jun escribió:
>>>>>>>>>>>> English words, a data plane solution.  It is based on 
>>>>>>>>>>>> events from the data plane, without any need for control 
>>>>>>>>>>>> packet events.
>>>>>>>>>>>
>>>>>>>>>>> Hi Joel,
>>>>>>>>>>>
>>>>>>>>>>> but the difference is that the counter is not a full data 
>>>>>>>>>>> plan concept because the counter can only inform the CPU the 
>>>>>>>>>> all it is needed is that if a data packet for which there is 
>>>>>>>>>> no binding is received, the binding creation procedure is 
>>>>>>>>>> triggered.
>>>>>>>>>
>>>>>>>>> Hi Marcelo,
>>>>>>>>>
>>>>>>>>> In data-triggered, the data packet is used by CPU of 
>>>>>>>>> savi-switch for binding creation procedure. That's why.
>>>>>>>>>
>>>>>>>>
>>>>>>>> no
>>>>>>>> both in data triggered and counter triggered, it is the 
>>>>>>>> reception of one or more data packets that trigger the binding 
>>>>>>>> creation procedure.
>>>>>>>>
>>>>>>>> other than the fact that a data packet arrived containing a 
>>>>>>>> given source address, which is what is needed both for data 
>>>>>>>> triggered and for counter triggered.
>>>>>>>>
>>> No. the counter is still based on port. For layer 3 switch, there is 
>>> a neighbor table, then the layer 3 switch uses the neighbor table to 
>>> send probe.
>>>
>> given port? (liek in IPv6, where you are likely to have many 
>> addresses even if you have a single host?)
>>
>> Regards, marcelo
>
> Hi Marcelo,
>
> Is there any problem?
> There is savi binding table set up by control packet snooping, we just 
> need to recover those address in the neighbor list but not in the savi 
> list if the number of packet loss pass the threadhold. 

So, you have a way that given that data packet is received for which 
there is no binding, you can associate a source address to it, which is 
exactly what is needed.

Regards, marcelo

> Because in the normal cases the bind is setup by control packet 
> snooping, then it is not a heavy burden for this binding recovering 
> (but if fundamental binding set up is based on data packet, then it 
> will be too heavy burden to the device).
>
> thanks,
> Jun
>
>
>>
>>
>>> thanks,
>>> Jun Bi
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> thanks,
>>>>> Jun Bi
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> In other words, the counter is an indirection level that allows 
>>>>>> to implement the triggering of actions upon the reception of a 
>>>>>> data packet, which is exactly what is needed for the data triggered.
>>>>>>
>>>>>>>>>>>>> counter-triggered is not same as data-triggered, because 
>>>>>>>>>>>>> the counter-triggered is not a data plan solution,

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 19 Apr 2010 17:57:28 +0800

Sent: Monday, April 19, 2010 5:48 PM

>>>>>>>>>>>>> would expect and hope that the SLAAC solution will be 
>>>>>>>>>>>>> primarily based on DAD.
>>>>>>>>>>>>
>>>>>>>>>>>> thanks,
>>>>>>>>>>>> Jun
>>>>>>>>>>>>
> So, you have a way that given that data packet is received for which there 
> is no binding, you can associate a source address to it, which is exactly 
> what is needed.
>

Hi Marcelo,

I tell you how the process it works as a supplement to the control packet 
snooping based solution, but it doesn't mean I agree it's a pure 
data-triggered solution. You can see many control plan stuff is involved in 
the whole process.

thanks,
Jun Bi

> Regards, marcelo
>
>
>> Because in the normal cases the bind is setup by control packet snooping, 
>> then it is not a heavy burden for this binding recovering (but if 
>> fundamental binding set up is based on data packet, then it will be too 
>> heavy burden to the device).
>>
>> thanks,
>> Jun
>>
>>
>>>
>>>
>>>> thanks,
>>>> Jun Bi
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> thanks,
>>>>>> Jun Bi
>>>>>>
>>>>>>
>>>>>>
>>>>>>>