Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI "

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 02 Apr 2010 10:38:13 -0400

This sequence started with some folks reporting that they had observed 
significant loss of DAD in certain topologies.
Now, it is possible that what I took for a report of observation was a 
theoretical analysis.
Taking, for now, that it was observed, then observing the spec quotation 
you provide, the question I would have would be "what is it about the 
reality that means this is insufficient to solve the problem?"

Declaring that there is no problem seems premature.

Yours,
Joel

Guang Yao wrote:
>  Hi Joel,
> 
> Please refer to RFC4862
> "
>    If the Neighbor Solicitation is going to be the first message sent
>    from an interface after interface (re)initialization, the node SHOULD
>    delay joining the solicited-node multicast address by a random delay
>    between 0 and MAX_RTR_SOLICITATION_DELAY as specified in [RFC4861].
>    This serves to alleviate congestion when many nodes start up on the
>    link at the same time, such as after a power failure, and may help to
>    avoid race conditions when more than one node is trying to solicit
>    for the same address at the same time.
> 
>    Even if the Neighbor Solicitation is not going to be the first
>    message sent, the node SHOULD delay joining the solicited-node
>    multicast address by a random delay between 0 and
>    MAX_RTR_SOLICITATION_DELAY if the address being checked is configured
>    by a router advertisement message sent to a multicast address.  The
>    delay will avoid similar congestion when multiple nodes are going to
>    configure addresses by receiving the same single multicast router
>    advertisement.
> "
> 
> SLAAC tries to avoid first packet loss through waiting a random delay after
> interface initialization. This will reduce the link local DAD loss
> probability greatly.
> 
> BR,
> Guang
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joel
>> M. Halpern
>> Sent: Wednesday, March 24, 2010 11:07 PM
>> To: Jun Bi
>> Cc: [email-masked]; Guang Yao
>> Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI
> "
>> I had presumed, since we are doing this enforcement on bridges, that we
>> were resposnible for controlling the allocation of link-local addresses
>> as well as global addresses.  If link-local addresses are out of scope,
>> that simplifies many things.
>>
>> Yours,
>> Joel
>>
>> Jun Bi wrote:
>>> Yes, that's a good point.
>>>
>>> Jun
>>>
>>> --------------------------------------------------
>>> From: "Guang Yao" <[email-masked]>
>>> Sent: Tuesday, March 23, 2010 8:27 PM
>>> To: <[email-masked]>
>>> Subject: [savi] One minor comments on "Analysis of Open Issues in SAVI "
>>>
>>>> On "Additional causes for DAD NSOL packets loss.
>>>> DAD NSOL is the first packet a host sends
>>>> Initial packets can potentially suffer a higher loss rate"
>>>>
>>>> It's not true for all the DAD messages. Only DAD for link local
>>>> address is
>>>> the first packet. DAD for global address will not be performed until a
>>>> RA is
>>>> received. And it may be handled through snooping MLD message.
>>>>
>>>> BR,
>>>> Guang
>>>>
>>>>
>>>> _______________________________________________
>>>> savi mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/savi
>>>>
>>> _______________________________________________
>>> 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: "Guang Yao" <[email-masked]>
Date: Fri, 2 Apr 2010 14:35:56 +0800

Hi Joel,

Please refer to RFC4862
"

BR,
Guang

Joel
"

---

From: "Guang Yao" <[email-masked]>
Date: Sat, 3 Apr 2010 17:06:18 +0800

Hi Joel,

>From our experience on testing prototypes from four vendors, two of the
prototypes did face loss of link local DAD in the early stage. Then they
found the synchronous mechanism in initialization should be implemented with
care to avoid first packet loss. All the later stage prototypes are free of
this problem.

Although this doesn't prove first DAD will never get lost, this at least
shows first DAD loss is not a event with certain probability, from
observation on reality. Currently the possibility of first DAD loss is just
proved in analysis.

DAD is not reliable, but it is still reasonable. It is not designed to be a
dispensable protocol. In general case, I think "almost certain" is enough.

We all go with the assumption that "the earth wouldn't be destroyed
tomorrow", right? This assumption doesn't have absolute 100% probability,
either. Should we spend all our savings today because of fearing of non-zero
probability fatal event?

BR,
Guang

Joel
> M. Halpern
> Sent: Friday, April 02, 2010 10:38 PM
> To: Guang Yao
> Cc: [email-masked]
"

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 03 Apr 2010 14:28:27 +0200

> care to avoid first packet loss. All the later stage prototypes are free of

that mostly proves that in your specific controlled environment, you 
didn't experience the problem
The input that the first packets have more probabilty of getting lost 
than subsequent ones and that in particular the DAD packets, is an input 
from a couple of people (cc) that have been working on related issues 
(they happen to be the co chairs of the DNA WG)
> shows first DAD loss is not a event with certain probability,
i fail to understand this sentence. The lost of DAD packet is certainly 
an event with a certain probability.
DAD is NOT reliable and it is not a reasonable approach to reduce the 
robustness of the network to this level

besides, i fail to see why we keep on agruing this point, since it seems 
to be significant amount of people that think that it is possible to 
implement data triggered actions (such as the proxy DAD procedure) using 
the approach suggested by Fred, which makes all this a non issues, since 
all we need to restore the reliability of the network is to trigger the 
DAD or the DHCP query upon the reception of one (or more) data packets 
for which we don't have a binding
>   from
we simply disagree here and everybody in the previous meeting seemed to 
disagree with this (at least nobody said anything about this in the meeting)

> tomorrow", right?
no, a DAD packet getting lost have significant more probability than 
that, i am afraid

Regards, marcelo

>   This assumption doesn't have absolute 100% probability,
>>>     between 0 and MAX_RTR_SOLICITATION_DELAY as specified in
>>>        
>> [RFC4861].
>>      
>>>     MAX_RTR_SOLICITATION_DELAY if the address being checked is
>>>        
>> configured
>>      
>>> SLAAC tries to avoid first packet loss through waiting a random delay
>>>        
> after
>    
>>>> Subject: Re: [savi] One minor comments on "Analysis of Open Issues in
>>>>          
> SAVI
>    
>>> "
>>>        
>>>>> From: "Guang Yao"<[email-masked]>
>>>>> To:<[email-masked]>
>>>>> Subject: [savi] One minor comments on "Analysis of Open Issues in SAVI
>>>>>            
> "
>    
>>>>>            
>>>>>> the first packet. DAD for global address will not be performed until
>>>>>>              
> a
>    
>>>>>> RA is

---

From: "Jun Bi" <[email-masked]>
Date: Sat, 3 Apr 2010 22:39:51 +0800

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Saturday, April 03, 2010 8:28 PM
To: <[email-masked]>; "Greg Daley" <[email-masked]>; "Suresh Krishnan" 
<[email-masked]>
Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI "

> The input that the first packets have more probabilty of getting lost than 
> subsequent ones and that in particular the DAD packets, is an input from a 
> couple of people (cc) that have been working on related issues (they 
> happen to be the co chairs of the DNA WG)
> i fail to understand this sentence. The lost of DAD packet is certainly an 
> event with a certain probability.

Hi Marcelo,

"possible" doesn't mean MUST, may mean SHOULD.

thanks,
Jun

> DAD or the DHCP query upon the reception of one (or more) data packets for 
> which we don't have a binding
>>   from
> no, a DAD packet getting lost have significant more probability than that, 
> i am afraid
>
> Regards, marcelo
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 04 Apr 2010 10:43:46 +0200

El 03/04/10 16:39, Jun Bi escribió:
>
>>
>> besides, i fail to see why we keep on agruing this point, since it 
>> seems to be significant amount of people that think that it is 
>> possible to
>
>
> Hi Marcelo,
>

The point is that we do have an implementer that says that this is 
feasible, which was the main argument against doing do. No other 
implementers have voiced in the ml that they have a problem implementing 
this in the way Fred has proposed, so i simply fail to see what are the 
arguments against doing this at this point.

This is needed in order to have the solution work properly and preserve 
the robustness of the network, and there are no arguments against doing 
it afaics.

Regards, marcelo

> thanks,
> Jun
>
>
>
>> implement data triggered actions (such as the proxy DAD procedure) 
>> using the approach suggested by Fred, which makes all this a non 
>> issues, since all we need to restore the reliability of the network 
>> is to trigger the DAD or the DHCP query upon the reception of one (or 
>> more) data packets for which we don't have a binding
>>>   from
>> we simply disagree here and everybody in the previous meeting seemed 
>> to disagree with this (at least nobody said anything about this in 
>> the meeting)
>>

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 5 Apr 2010 02:05:30 +0800

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Sunday, April 04, 2010 4:43 PM
To: "Jun Bi" <[email-masked]>
Cc: <[email-masked]>; "Greg Daley" <[email-masked]>; "Suresh Krishnan" 
<[email-masked]>
Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI "

Hi Marcelo,

Did I mean Fred's proposal is not feasible? That's counter triggered.

I meant data-triggered can't be MUST based on the feedback from vendors,
please refer to all my related emails in the past weeks.

thanks,
Jun

> the robustness of the network, and there are no arguments against doing it 
> afaics.
>
> Regards, marcelo
>
>
>> thanks,
>> Jun
>>
>>
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 04 Apr 2010 20:32:00 +0200

El 04/04/10 20:05, Jun Bi escribió:
> Cc: <[email-masked]>; "Greg Daley" <[email-masked]>; "Suresh 
> Krishnan" <[email-masked]>
> SAVI "
>> implementers have voiced in the ml that they have a problem 
>> implementing this in the way Fred has proposed, so i simply fail to 
>> see what are the arguments against doing this at this point.
>
> Hi Marcelo,
>
so, you are ok to require Fred's proposal as a MUST?

Regards, marcelo

> thanks,
> Jun
>
>
>
>>
>> This is needed in order to have the solution work properly and 
>> preserve the robustness of the network, and there are no arguments 
>> against doing it afaics.
>>
>> Regards, marcelo
>>
>>
>>> thanks,
>>> Jun
>>>
>>>
>>>
>>>> is to trigger the DAD or the DHCP query upon the reception of one 
>>>> (or more) data packets for which we don't have a binding
>>>>>   from
>>>> we simply disagree here and everybody in the previous meeting 
>>>> seemed to disagree with this (at least nobody said anything about 
>>>> this in the meeting)
>>>>
>>>> no, a DAD packet getting lost have significant more probability 
>>>> than that, i am afraid
>>>>
>>>> Regards, marcelo
>>>>

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 5 Apr 2010 02:38:15 +0800

Sent: Monday, April 05, 2010 2:32 AM

Hi Marcelo,

Did you read savi-dhcp-02 ?

thanks,
Jun

>>>>> issues, since all we need to restore the reliability of the network is 
>>>>> to trigger the DAD or the DHCP query upon the reception of one (or 
>>>>> to disagree with this (at least nobody said anything about this in the 
>>>>> meeting)
>>>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 04 Apr 2010 20:54:55 +0200

El 04/04/10 20:38, Jun Bi escribió:
>>>>>> besides, i fail to see why we keep on agruing this point, since 
>>>>>> it seems to be significant amount of people that think that it is 
>>>>>> possible to
>>>>>
>>>>>
>>>>> Hi Marcelo,
>>>>>
no

let me ask again, are you ok to require Fred's proposal as a MUST?

Regards, marcelo

>>>>>> implement data triggered actions (such as the proxy DAD 
>>>>>> procedure) using the approach suggested by Fred, which makes all 
>>>>>> this a non issues, since all we need to restore the reliability 
>>>>>> of the network is to trigger the DAD or the DHCP query upon the 
>>>>>> reception of one (or more) data packets for which we don't have a 
>>>>>> binding
>>>>>>>   from

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Apr 2010 10:59:48 -0700

> let me ask again, are you ok to require Fred's proposal as a MUST?

I think making my off-handed "here's one way that it could be implemented", repeatedly stated as something I don't see the value of documenting AT ALL as competent implementors will think of such things without that help, a "MUST" would be completely idiotic.

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 05 Apr 2010 21:04:29 +0200

> I think making my off-handed "here's one way that it could be implemented", repeatedly stated as something I don't see the value of documenting AT ALL as competent implementors will think of such t…

the thing is:
- There are several issues with blindly discarding data packets for 
which there is no binding in the SAVI switch, so it would make sense to 
require as MUST that SAVI switches trigger the binding creation 
procedure upon the reception of a data packet (instead of blindly 
discarding it)
- The argument against doing so is that it would be difficult to implement.
- You, in your previous note, described a way that this can be 
implemented, making this argument no longer hold.

So, the question is not whether the particular way of implementing this 
is a MUSt but the actual functionality of triggering the binding 
creation procedure is a MUST, given that the argument for not doing so 
no longer holds.

Regards, marcelo

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Apr 2010 12:16:09 -0700

Your argument below suggests that it might be listed as a "MAY". If it was going into the RFC at all, I would suggest putting it in an appendix as a possible implementation approach. 

On Apr 5, 2010, at 12:04 PM, marcelo bagnulo braun wrote:

> - There are several issues with blindly discarding data packets for which there is no binding in the SAVI switch, so it would make sense to require as MUST that SAVI switches trigger the binding creation procedure upon the reception of a data packet (instead of blindly discarding it)
> - You, in your previous note, described a way that this can be implemented, making this argument no longer hold.
> 
> So, the question is not whether the particular way of implementing this is a MUSt but the actual functionality of triggering the binding creation procedure is a MUST, given that the argument for not doing so no longer holds.
> 
> Regards, marcelo
> 
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 05 Apr 2010 22:00:05 +0200

Not sure i understand what do you mean to include as a MAY. the 
implementation approach you suggested or the functionality of triggering 
the binding creation procedure upon the recpetion of a data packet for 
which there is no binding?

If the former, i agree.
If the latter, could you explain what are the reaons behind that? I 
mean, what are the reasons for not mandating the functionality?

Regards, marcelo

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Apr 2010 13:20:10 -0700

The reason for not mandating it, as I have repeatedly stated in private and public email, is that it is not our business to tell implementors how to implement things. There may be other ways to do it in a given implementation approach that is just as good or better.

I'm very quickly becoming sorry I brought it up. This doesn't bode well for future observations I might consider making.

On Apr 5, 2010, at 1:00 PM, marcelo bagnulo braun wrote:

> Not sure i understand what do you mean to include as a MAY. the implementation approach you suggested or the functionality of triggering the binding creation procedure upon the recpetion of a data packet for which there is no binding?
> 
> If the former, i agree.
> If the latter, could you explain what are the reaons behind that? I mean, what are the reasons for not mandating the functionality?
> 
> Regards, marcelo
> 
> 
>

---

From: Greg Daley <[email-masked]>
Date: Tue, 6 Apr 2010 15:15:39 +1000

Hi Fred and Marcelo, 

I think that it's necessary to highlight to implementors that they need
to (as in MUST) implement a mechanism to bootstrap new bindings for addresses
which they do not already have, due to the fact that various link-layers may lose
vital signalling packets during the initial connection phase.

I would be happy if the mechanism itself was left to implementor's own discretion,
but none of the techniques described before in this thread ( delays introduced by
RFC4862, etc) will cope with either the 802.1D(2006) point-to-point link assessment
(3 seconds), or earlier spanning-tree delays.   It also may not handle 
802.1X authentication delays, dependent on the authentication scheme involved.

So some measure must manditorily be deployed to allow new non-conflicting bindings.

Implementation guidance is necessary outside the appendix if there is only
one way to perform the binding or there are some subtleties requiring attention.

I wasn't at the meeting, but it appears this is not strictly the case 
(Are minutes available yet?). 

We can at least place the example method in the appendix where it will get some
review. 

This would allow us to identify any protocol interactions in the domain (not the implementation itself), which may require further notice.

Greg Daley
(From his other e-mail address)

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Fred Baker
> Sent: Tuesday, 6 April 2010 6:20 AM
> To: marcelo bagnulo braun
> Cc: Greg Daley; [email-masked]; Suresh Krishnan
> The reason for not mandating it, as I have repeatedly stated 
> in private and public email, is that it is not our business 
> to tell implementors how to implement things. There may be 
> other ways to do it in a given implementation approach that 
> is just as good or better.
> 
> I'm very quickly becoming sorry I brought it up. This doesn't 
> bode well for future observations I might consider making.
> 
> 
> > Not sure i understand what do you mean to include as a MAY. 
> the implementation approach you suggested or the 
> functionality of triggering the binding creation procedure 
> upon the recpetion of a data packet for which there is no binding?
> > 
> > If the former, i agree.
> > If the latter, could you explain what are the reaons behind 
> that? I mean, what are the reasons for not mandating the 
> functionality?
> > 
> > Regards, marcelo
> > 
> > 
> > 
> >> Your argument below suggests that it might be listed as a 
> "MAY". If it was going into the RFC at all, I would suggest 
> putting it in an appendix as a possible implementation approach.
> >> 
> >>>> I think making my off-handed "here's one way that it 
> could be implemented", repeatedly stated as something I don't 
> see the value of documenting AT ALL as competent implementors 
> will think of such things without that help, a "MUST" would 
> be completely idiotic.
> >>>> 
> >>>> 
> >>>>       
> >>> the thing is:
> >>> - There are several issues with blindly discarding data 
> packets for which there is no binding in the SAVI switch, so 
> it would make sense to require as MUST that SAVI switches 
> trigger the binding creation procedure upon the reception of 
> a data packet (instead of blindly discarding it)
> >>> - You, in your previous note, described a way that this 
> can be implemented, making this argument no longer hold.
> >>> 
> >>> So, the question is not whether the particular way of 
> implementing this is a MUSt but the actual functionality of 
> triggering the binding creation procedure is a MUST, given 
> that the argument for not doing so no longer holds.
> >>> 
> >>> Regards, marcelo
> >>> 
> >>> 
> >>>

---

From: Fred Baker <[email-masked]>
Date: Tue, 6 Apr 2010 00:06:24 -0700

> We can at least place the example method in the appendix where it will get some

As an example, fine. As a MUST - I'm sorry, it's not the only way to do it.

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Tue, 06 Apr 2010 13:07:24 +0200

> As an example, fine. As a MUST - I'm sorry, it's not the only way to do it.
The question is not wether the implementation example is a MUST or not. 
It obviously cannot be... for many reasons starting with how do you know 
the implementation of a given device?
The discussion on MUST vs SHOULD or MAY is regard the principle of 
triggering a binding from the receipt of a data packet.
And Marcelo's point is: why should that not be a MUST provided that we 
all agree it's implementable in a way or another, it solves a real 
problem, and we don't have another solution that works in all the cases.
So I am really interrested in somebody who would argue that 1) it does 
not solve a real problem 2) It's not implementable 3) There is a better 
solution.
Any compeling argument on any of these 3 topics would help us making 
progress.
Eric

---

From: Fred Baker <[email-masked]>
Date: Tue, 6 Apr 2010 07:23:26 -0700

On Apr 6, 2010, at 4:07 AM, Eric Levy-Abegnoli wrote:

> The question is not wether the implementation example is a MUST or not. It obviously cannot be... for many reasons starting with how do you know the implementation of a given device?

Tell Marcello. He's the one I am responding to.

> The discussion on MUST vs SHOULD or MAY is regard the principle of triggering a binding from the receipt of a data packet.
> And Marcelo's point is: why should that not be a MUST provided that we all agree it's implementable in a way or another, it solves a real problem, and we don't have another solution that works in all the cases.
> So I am really interrested in somebody who would argue that 1) it does not solve a real problem 2) It's not implementable 3) There is a better solution.

Well, I think that picking it up from DHCP is a better solution in networks that use DHCP, as DHCP is authoritative. In networks that don't use DHCP, I thought the working group had concluded that picking it up from uses of the address was the only workable approach.

I assert that it is implementable, and at least one way to do so is as I suggested.

I assert that while the working group consensus appears to be that FCFS is the only workable approach, it has a security problem. If the purpose of SAVI is to prevent hosts from spoofing addresses, we have to define "spoofing". Clearly if one host interface is using an address and a second host interface starts using it, the usage is incorrect and SAVI should prevent it. I assert that if a host starts using an address, it is not statically configured, and the host has not performed a duplicate address detection step, it has not correctly implemented SLAAC, and this second usage is also a problem. FCFS doesn't detect the second case; it presumes that the address was statically configured or that the switch failed to observe the DAD.

> Any compeling argument on any of these 3 topics would help us making progress.
> Eric

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Tue, 06 Apr 2010 18:03:53 +0200

Hi Fred,
> Tell Marcello. He's the one I am responding to.
Sure. Hopefully he will respond if he disagree.
> Well, I think that picking it up from DHCP is a better solution in networks that use DHCP, as DHCP is authoritative. 
Not good. On a layer2 device; quite often there is no DHCP stack. And no 
IP, including no IP to source from.

> In networks that don't use DHCP, I thought the working group had concluded that picking it up from uses of the address was the only workable approach.
>
Just trying to clarify. What is the security issue there? That the 
switch will nicely  install a binding and accept subsequent traffic? 
That is pretty much un-avoidable with SLACC, isn't it? At least we know 
which anchor this IP is bound to, and we could always trace it back. 
DHCP is defintely more secure if that's your point. For global, not 
link-locals though.
Eric

---

From: Fred Baker <[email-masked]>
Date: Tue, 6 Apr 2010 09:20:13 -0700

On Apr 6, 2010, at 9:03 AM, Eric Levy-Abegnoli wrote:
> Not good. On a layer2 device; quite often there is no DHCP stack. And no IP, including no IP to source from.

Hmm. We manage to do that for IPv4 in the field today...

> Just trying to clarify. What is the security issue there? That the switch will nicely  install a binding and accept subsequent traffic? That is pretty much un-avoidable with SLACC, isn't it?

Well, if SLAAC is actually used, it is exactly as it should be. Reread my description of the issue. Absent DAD, SLAAC has not been used; the host has simply started using an address that it has not verified. What I am saying is that a host can fire-and-forget, using up addresses as fast as it can send datagrams, and that becomes an attack on the switch (it is using up memory and filter resources, and the process is very busy). I pointed this out when we first started discussing FCFS in Dublin, and it's still a DOS attack.

There is of course a mitigation. At some point the switch either stops accepting new addresses from the host or by some algorithm starts forgetting about old ones. Both of those have built-in attacks as well; let's assume that "some algorithm" is "LRU", so that in the general case we can expect the switch to stop remembering addresses that the host is no longer using. Let's assume that most processes on the host are using a certain one, allocated yesterday using SLAAC properly. But some rogue process (virus/whatever) starts chewing through addresses at a time that none of those other processes happen to be "speaking". This becomes a DOS on the other processes on the system - the SAVI switch will not accept their traffic.

IMHO, there is no real solution here; it should simply be noted as a "Security Consideration".

> At least we know which anchor this IP is bound to, and we could always trace it back. DHCP is defintely more secure if that's your point. For global, not link-locals though.

Yes, and of course.

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 7 Apr 2010 00:58:54 +0800

Hi All,

Thanks to Fred, Eric, Greg, and others for the constructive discussion.

I think Fred Baker point out why the data-triggered can not be MUST.
Moreover, based on the feedback from vendors, and as one form operators, I 
am strongly against to have the data-triggered as a MUST, because I don't 
think it is not feasible and it can not be widely implementable (sorry to 
repeat my points so many times).

However, I have to say what Fred had proposed is not the original 
data-triggered actions, it is actually a new *counter-triggered actions* to 
help for recovering from the unexpected situation. The counter-triggered is 
implementable and is feasible to do rate limit (based on the discussions the 
past weeks, it's not feasible to rate limit for data-triggered actions).

Based on the discussions, I propose to have several alternatives we can 
state in the drafts:
1 every savi-switch MUST implement the counter-triggered (not 
data-triggered)
 alert (so that the admin can know and recover the state if he wants), and 
SHOULD implement the counter triggered probe. OR
2 Put the counter-triggered into the appendix (because as Fred and Greg 
stated, that's only one example of the feasible way). OR
3 Only state the problems in the security considerations.

Meanwhile, the data-triggered probe can be an optional function (although I 
think there will be very few real implementation on the data-triggered in 
reality, maybe only very high-end switch can implement it) in addition to 
any of the above alternative.

Best Regards,
Jun Bi

--------------------------------------------------
From: "Fred Baker" <[email-masked]>
Sent: Wednesday, April 07, 2010 12:20 AM
To: "Eric Levy-Abegnoli" <[email-masked]>
Cc: "Greg Daley" <[email-masked]>; <[email-masked]>; "Suresh 
Krishnan" <[email-masked]>
Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI "

>>> Well, I think that picking it up from DHCP is a better solution in 
>>> networks that use DHCP, as DHCP is authoritative.
>>> In networks that don't use DHCP, I thought the working group had 
>>> concluded that picking it up from uses of the address was the only 
>>> workable approach.
>>>
>>> I assert that while the working group consensus appears to be that FCFS 
>>> is the only workable approach, it has a security problem. If the purpose 
>>> of SAVI is to prevent hosts from spoofing addresses, we have to define 
>>> "spoofing". Clearly if one host interface is using an address and a 
>>> second host interface starts using it, the usage is incorrect and SAVI 
>>> should prevent it. I assert that if a host starts using an address, it 
>>> is not statically configured, and the host has not performed a duplicate 
>>> address detection step, it has not correctly implemented SLAAC, and this 
>>> second usage is also a problem. FCFS doesn't detect the second case; it 
>>> presumes that the address was statically configured or that the switch 
>>> failed to observe the DAD.
>>>
>> Just trying to clarify. What is the security issue there? That the switch 
>> will nicely  install a binding and accept subsequent traffic? That is 
>> pretty much un-avoidable with SLACC, isn't it?
>
> Well, if SLAAC is actually used, it is exactly as it should be. Reread my 
> description of the issue. Absent DAD, SLAAC has not been used; the host 
> has simply started using an address that it has not verified. What I am 
> saying is that a host can fire-and-forget, using up addresses as fast as 
> it can send datagrams, and that becomes an attack on the switch (it is 
> using up memory and filter resources, and the process is very busy). I 
> pointed this out when we first started discussing FCFS in Dublin, and it's 
> still a DOS attack.
>
> There is of course a mitigation. At some point the switch either stops 
> accepting new addresses from the host or by some algorithm starts 
> forgetting about old ones. Both of those have built-in attacks as well; 
> let's assume that "some algorithm" is "LRU", so that in the general case 
> we can expect the switch to stop remembering addresses that the host is no 
> longer using. Let's assume that most processes on the host are using a 
> certain one, allocated yesterday using SLAAC properly. But some rogue 
> process (virus/whatever) starts chewing through addresses at a time that 
> none of those other processes happen to be "speaking". This becomes a DOS 
> on the other processes on the system - the SAVI switch will not accept 
> their traffic.
>
>> At least we know which anchor this IP is bound to, and we could always 
>> trace it back. DHCP is defintely more secure if that's your point. For 
>> global, not link-locals though.
>
> Yes, and of course.
>
>> Eric
>>>
>>>
>>>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 6 Apr 2010 13:15:24 -0400

Hi Fred,
    Responding just to one of your scenarios

On 10-04-06 10:23 AM, Fred Baker wrote:
<snip>
> I assert that if a host starts using an address, it is not statically 
  > configured, and the host has not performed a duplicate address
  > detection step, it has not correctly implemented SLAAC

I agree. But, I think the problematic case is the case where the host
DID actually perform DAD but the savi device did not see the
DAD message. I know from usage that this has a non-zero probability of
happening. e.g. host interface comes up and performs DAD on the
link-local address before the DSL line becomes active and hence the savi
device in the DSL network does not see the DAD message. I would be very
unhappy if there is no mandated way for the host to ever recover from this.

Thanks
Suresh

---

From: "Bi Jun" <[email-masked]>
Date: Wed, 7 Apr 2010 01:41:01 +0800

Hi Suresh,

Thanks for the comment.

I think some problem are brought because of the problem of SLAAC itself, not 
savi-slaac. Savi-slaac may have to face to the limitation of SLAAC for 
anti-spoofing.

To find an ideal solution, there might be two alternative ways:
1 propose sth to enhance SLAAC, or
2 re-chartering SAVI WG to have a new protocol to coordinate the SLAAC-state 
in the host the savi-device. (currently the new protocol and host change are 
not permitted).

Otherwise, as stated by Jole during the WG meeting, the minimal requirement 
might be that the admin need a way to figure out there is a problem when 
this none-0 possibility event happens. For this reason, then I think a 
counter-triggered alert might be considered as a MUST.

thanks,
Jun Bi

--------------------------------------------------
From: "Suresh Krishnan" <[email-masked]>
Sent: Wednesday, April 07, 2010 1:15 AM
To: "Fred Baker" <[email-masked]>
Cc: "Greg Daley" <[email-masked]>; <[email-masked]>
Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI "

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Thu, 08 Apr 2010 11:11:10 +0200

Hi Jun,
Bi Jun a écrit :
>
> Hi Suresh,
>
> Thanks for the comment.
>
> I think some problem are brought because of the problem of SLAAC 
> itself, not savi-slaac. 
The probablity that is is causing trouble with SLACC alone is extremely 
low, as it is the combination of DAD packet loss AND a duplicated 
address. That is, SLACC could live with it happily. By blocking traffic 
just because the DAD was lost, we are actually making it a much bigger 
issue (basically 2**64 more likely to be an issue, and since the loss of 
a DAD is quite probable, it become an issue substancially probable)..
So it's a savi problem, not a slacc problem.
Eric

> Savi-slaac may have to face to the limitation of SLAAC for anti-spoofing.
>
> 2 re-chartering SAVI WG to have a new protocol to coordinate the 
> SLAAC-state in the host the savi-device. (currently the new protocol 
> and host change are not permitted).
>
> Otherwise, as stated by Jole during the WG meeting, the minimal 
> requirement might be that the admin need a way to figure out there is 
> a problem when this none-0 possibility event happens. For this reason, 
> then I think a counter-triggered alert might be considered as a MUST.
>
> thanks,
> Jun Bi
>

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 8 Apr 2010 17:34:27 +0800

Hi Eric,

I don't think it's the problem of savi. 

I'd rather to say, slaac is not suitable for savi. However, it's the only
protocol can be snooped in slaac-only scenario. Savi has no other choice.

BR,
Guang

Eric
> Levy-Abegnoli
> Sent: Thursday, April 08, 2010 5:11 PM
> To: Bi Jun
"

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Apr 2010 11:02:29 -0700

There I would agree. What might be appropriate would be for SAVI to make a comment re SLAAC to 6man. But it's 6man's problem.

---

From: Greg Daley <[email-masked]>
Date: Fri, 9 Apr 2010 12:57:43 +1000

Hi Fred and Guang,

MLDv2 can be snooped as well, but doesn't provide direct unicast IP mappings.

Greg Daley

> Sent: Friday, 9 April 2010 4:02 AM
> To: Guang Yao
> Cc: Greg Daley; [email-masked]; 'Suresh Krishnan'
> There I would agree. What might be appropriate would be for 
> SAVI to make a comment re SLAAC to 6man. But it's 6man's problem.
> 
> >>>> link-local address before the DSL line becomes active 
> and hence the
> > savi
> >>>> unhappy if there is no mandated way for the host to ever 
> recover from
> >>>> this.
> >>>> 
> >>>> Thanks
> >>>> Suresh
> >>>> 
> >>>>

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Fri, 09 Apr 2010 10:23:41 +0200

Hi Guang,
> protocol can be snooped in slaac-only scenario. Savi has no other choice.
I don't understand this statement. Or rather we are going in circles. We 
could snoop anything. We could snoop TCP for what it's worth. UDP, ICMP, 
you name it. I know, none would work for what we need, but the 
reasonning behind 1) NDP/DAD is is the only thing we can (wan't?) snoop, 
2) it does not work in all cases for savi , 3) hence DAD is broken is a 
sophism.
There has been another snooping "type" (let's not call that "protocol") 
put on the table for the last 3 IETF: that is data-snooping. Maye it's 
time to take a poll at this one?
Note that if we conclude that it is not possible to build a decent 
binding tbale by snooping whatever traffic the solution is not to fix  
DAD  to make it snoopable. DAD is not a broken protocol as far as I 
know. Instead we need savi to have its own protocol (not snooping anymore).
Eric
>>> Savi-slaac may have to face to the limitation of SLAAC for
>>>       
> anti-spoofing.
>   
>>>> link-local address before the DSL line becomes active and hence the
>>>>         
> savi
>

---

From: "Guang Yao" <[email-masked]>
Date: Fri, 9 Apr 2010 18:12:48 +0800

Hi Eric,

If RFC4862 said, the node can send a Data/TCP/UDP/ICMP instead of sending NS
when performing DAD, I will be OK with snooping other traffic. But as you
said, none would work . They have none business with address assignment
methods on standard tracks.

I admit that, if we want to build a decent binding table, DAD only snooping
is not enough for DAD loss problem raised. IMHO, a perfect solution for savi
is designing a reliable and snoopable DAD. Current DAD is not suitable for
SAVI, because of its unreliability; however, DAD snooping is still correct
and to respect existing standards. 

Currently I wonder if snooping Neighbor Unreachability Detection would work
as a supplement of DAD snooping. If a node finds a path to neighbor fails,
it would try to perform NUD. Although NUD snooping is beyond DAD snooping,
it is at least control plane focused and problem(DAD loss or layer 2 path
change) related. 

If a node persists sending Data/TCP/UDP packet without expecting response
and repairing the path, it is really suspicious.

>From RFC4861:
"
  Communication to or through a neighbor may fail for numerous reasons
   at any time, including hardware failure, hot-swap of an interface
   card, etc.  If the destination has failed, no recovery is possible
   and communication fails.  On the other hand, if it is the path that
   has failed, recovery may be possible.  Thus, a node _actively_ tracks
   the reachability "state" for the neighbors to which it is sending
   packets.
"

BR,
Guang

> From: Eric Levy-Abegnoli [mailto:[email-masked]]
> Sent: Friday, April 09, 2010 4:24 PM
> To: Guang Yao
> Cc: 'Bi Jun'; 'Greg Daley'; [email-masked]; 'Suresh Krishnan'
"
SAVI

---

From: "Bi Jun" <[email-masked]>
Date: Fri, 9 Apr 2010 19:18:05 +0800

--------------------------------------------------
From: "Eric Levy-Abegnoli" <[email-masked]>
Sent: Friday, April 09, 2010 4:23 PM
To: "Guang Yao" <[email-masked]>
Cc: "'Bi Jun'" <[email-masked]>; "'Greg Daley'" 
<[email-masked]>; <[email-masked]>; "'Suresh Krishnan'" 
<[email-masked]>
Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI "

> you name it. I know, none would work for what we need, but the reasonning 
> behind 1) NDP/DAD is is the only thing we can (wan't?) snoop, 2) it does 
> not work in all cases for savi , 3) hence DAD is broken is a sophism.

Hi Eric,

I think Fred had analyzed some problem of data-snoopping at SLAAC.
I didn't see your objection after Fred's message.

On another hand, I had expressed many times that the data-triggered actions 
(e.g. probes) will bring too much cost to switch and it's hard to do 
rate-limiting, then it
should not be a MUST. It will be useful as a optional.

thanks,
Jun Bi

> Note that if we conclude that it is not possible to build a decent binding 
> tbale by snooping whatever traffic the solution is not to fix  DAD  to 
> make it snoopable. DAD is not a broken protocol as far as I know. Instead 
> we need savi to have its own protocol (not snooping anymore).
> Eric
>> BR,
>> Guang
>>
>>

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Fri, 09 Apr 2010 14:39:44 +0200

Jun,
Bi Jun a écrit :
>> I don't understand this statement. Or rather we are going in circles. 
>> We could snoop anything. We could snoop TCP for what it's worth. UDP, 
>> ICMP, you name it. I know, none would work for what we need, but the 
>> reasonning behind 1) NDP/DAD is is the only thing we can (wan't?) 
>> snoop, 2) it does not work in all cases for savi , 3) hence DAD is 
>> broken is a sophism.
>> There has been another snooping "type" (let's not call that 
>> "protocol") put on the table for the last 3 IETF: that is 
>> data-snooping. Maye it's time to take a poll at this one?
>
> Hi Eric,
>
I don't recall any theoritical problem raised on data snooping. I recall 
one intrinsic to SLACC: it is not authoritative, so anybody can claim 
any address. By sending a DAD or a data packet. No difference to me. 
Unfortunately, the world is what it is: the vast majority of hosts use 
SLACC not DHCP to get an address.
> On another hand, I had expressed many times that the data-triggered 
> actions (e.g. probes) will bring too much cost to switch and it's hard 
> to do rate-limiting, then it
I happen to be a switch implementer. So far, I believe I am the only one 
who voiced in this mailing list. I'd be glad the hear others.
While I did raise the rate-limiting issue, I also admited that it is 
just not realistic to drop traffic when no binding exist, and snooping 
data traffic is the only solution for addresses not assigned with DHCP. 
No need to argue more with me: I have made my point. You have made 
yours. Hopefully, the WG can make a decision on this.
Eric
>> Well, if SLAAC is actually used, it is exactly as it should be. 
>> Reread my description of the issue. Absent DAD, SLAAC has not been 
>> used; the host has simply started using an address that it has not 
>> verified. What I am saying is that a host can fire-and-forget, using 
>> up addresses as fast as it can send datagrams, and that becomes an 
>> attack on the switch (it is using up memory and filter resources, and 
>> the process is very busy). I pointed this out when we first started 
>> discussing FCFS in Dublin, and it's still a DOS attack.
>>
>> There is of course a mitigation. At some point the switch either 
>> stops accepting new addresses from the host or by some algorithm 
>> starts forgetting about old ones. Both of those have built-in attacks 
>> as well; let's assume that "some algorithm" is "LRU", so that in the 
>> general case we can expect the switch to stop remembering addresses 
>> that the host is no longer using. Let's assume that most processes on 
>> the host are using a certain one, allocated yesterday using SLAAC 
>> properly. But some rogue process (virus/whatever) starts chewing 
>> through addresses at a time that none of those other processes happen 
>> to be "speaking". This becomes a DOS on the other processes on the 
>> system - the SAVI switch will not accept their traffic.
>>
>> binding tbale by snooping whatever traffic the solution is not to 
>> fix  DAD  to make it snoopable. DAD is not a broken protocol as far 
>> as I know. Instead we need savi to have its own protocol (not 
>> snooping anymore).
>> Eric
>>> BR,
>>> Guang
>>>
>>>
>>>> Behalf Of
>>>>>> unhappy if there is no mandated way for the host to ever recover 
>>>>>> from
>>>>>> this.
>>>>>>
>>>>>> Thanks
>>>>>> Suresh
>>>>>>
>>>>>>

---

From: "Bi Jun" <[email-masked]>
Date: Fri, 9 Apr 2010 21:04:45 +0800

--------------------------------------------------
From: "Eric Levy-Abegnoli" <[email-masked]>
Sent: Friday, April 09, 2010 8:39 PM
To: "Bi Jun" <[email-masked]>
Cc: "Guang Yao" <[email-masked]>; "'Greg Daley'" 
<[email-masked]>; <[email-masked]>; "'Suresh Krishnan'" 
<[email-masked]>
Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI "

> one intrinsic to SLACC: it is not authoritative, so anybody can claim any 
> address. By sending a DAD or a data packet. No difference to me. 
>> actions (e.g. probes) will bring too much cost to switch and it's hard to 
>> do rate-limiting, then it

As an operator, the rate-limiting is more severe problem to us, because the 
data plan
won't deliver some important control packets to the switch under 
rate-limiting,
then the admin will have more troubles.
OK, as you know we are widely delaying SAVI in our IPv6 network, then could 
you implement an access switch with data snooping switch for me (without 
bring me those
security issues Fred Baker mentioned above)? If yes, I'd like to test one.
Otherwise, it should not be a MUST (see below for alternative solutions).

> data traffic is the only solution for addresses not assigned with DHCP.

No, this unfeasible solution is not the only way. At least the 
counter-triggered  proposed by Fred Baker can be an alternative way and more 
feasible. Guang Yao also said if a NUD is snooped at the switch then the 
switch can send probe to detect
(it is only a potential idea, need some test to verify). Saving the binding 
in NV-ram immediately after the binding is set up as a MUST is realist for 
most vendors we consulted.

> No need to argue more with me: I have made my point. You have made yours. 
> Hopefully, the WG can make a decision on this.
> Eric

I don't want to argue with you. I already proposed in my past email:
--------------------------------------------------
From: "Jun Bi" <[email-masked]>
Sent: Wednesday, April 07, 2010 12:58 AM
To: "Fred Baker" <[email-masked]>; "Eric Levy-Abegnoli" <[email-masked]>
Cc: "Greg Daley" <[email-masked]>; <[email-masked]>; "Suresh 
Krishnan" <[email-masked]>
Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI "

Based on the discussions, I propose to have several alternatives we can
state in the drafts:
1 every savi-switch MUST implement the counter-triggered (not
data-triggered) alert (so that the admin can know and recover the state if 
he wants), and SHOULD implement the counter triggered probe. OR
2 Put the counter-triggered into the appendix (because as Fred and Greg
stated, that's only one example of the feasible way). OR
3 Only state the problems in the security considerations.

Best Regards,
Jun Bi

>>> Well, if SLAAC is actually used, it is exactly as it should be. Reread 
>>> my description of the issue. Absent DAD, SLAAC has not been used; the 
>>> host has simply started using an address that it has not verified. What 
>>> I am saying is that a host can fire-and-forget, using up addresses as 
>>> fast as it can send datagrams, and that becomes an attack on the switch 
>>> (it is using up memory and filter resources, and the process is very 
>>> busy). I pointed this out when we first started discussing FCFS in 
>>> Dublin, and it's still a DOS attack.
>>>
>>> we can expect the switch to stop remembering addresses that the host is 
>>> no longer using. Let's assume that most processes on the host are using 
>>> a certain one, allocated yesterday using SLAAC properly. But some rogue 
>>> none of those other processes happen to be "speaking". This becomes a 
>>> DOS on the other processes on the system - the SAVI switch will not 
>>> accept their traffic.
>>>

---

From: "Jun Bi" <[email-masked]>
Date: Fri, 9 Apr 2010 21:11:12 +0800

a typo:

the data plan won't deliver some important control packets to the switch 
under
rate-limiting,

->
the data plan won't deliver some important control packets to the control 
plan (CPU)in a switch under rate-limiting, (I meant some important control 
packets will be lost, e.g, the SNMP,telnet packets to this switch)

--------------------------------------------------
From: "Bi Jun" <[email-masked]>
Sent: Friday, April 09, 2010 9:04 PM
To: "Eric Levy-Abegnoli" <[email-masked]>; <[email-masked]>
Cc: "'Greg Daley'" <[email-masked]>; "Guang Yao" 
<[email-masked]>; <[email-masked]>; "'Suresh Krishnan'" 
<[email-masked]>
Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI "

> As an operator, the rate-limiting is more severe problem to us, because 
> the data plan
> OK, as you know we are widely delaying SAVI in our IPv6 network, then 
> could you implement an access switch with data snooping switch for me 
> (without bring me those
> counter-triggered  proposed by Fred Baker can be an alternative way and 
> more feasible. Guang Yao also said if a NUD is snooped at the switch then 
> the switch can send probe to detect
> (it is only a potential idea, need some test to verify). Saving the 
> binding in NV-ram immediately after the binding is set up as a MUST is 
> realist for most vendors we consulted.
>
>
>>>> let's assume that "some algorithm" is "LRU", so that in the general 
>>>> case we can expect the switch to stop remembering addresses that the 
>>>> host is no longer using. Let's assume that most processes on the host 
>>>> are using a certain one, allocated yesterday using SLAAC properly. But 
>>>> some rogue process (virus/whatever) starts chewing through addresses at 
>>>> a time that none of those other processes happen to be "speaking". This 
>>>> becomes a DOS on the other processes on the system - the SAVI switch 
>>>> will not accept their traffic.
>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 09 Apr 2010 11:25:57 -0400

I believe that there is a miscommunication here.

Counter based triggering is a way of implementing data-triggered action.
If we define the data trigger requirements properly, then direct 
trigger, counter trigger, or some other mechanism that I am not clever 
enough to invent are all valid ways of implementing the spec.  RFCs 
generally try NOT to constrain implementation, but only to constrain the 
on-the-wire behavior.

As such, I beleive that Fred, Marcelo, and Eric are all willing to 
include data-triggered behavior as one of the alternatives that a device 
may use to address providing reliable support for SAVI-SLAAC.  (The 
question of whether that specific behavior is to be a singular MUST, or 
whether there is a list of alternatives at least one of which MUST be 
supported is not fully determined because we have not agreed on the full 
list of problems and their detectability.)

It seems a necessary to include in the base document that it is 
legitimate for devices to rate-limit their control response (either 
directly or indirectly) as that is something many devices will need to 
do, and that is externally observable.

If we want to describe the counter method, it would be in an informative 
  appendix discussing the various ways of supporting data plane 
triggered behavior.

Yours,
Joel

Bi Jun wrote:
>...
> more feasible. Guang Yao also said if a NUD is snooped at the switch 
> then the switch can send probe to detect

---

From: "Bi Jun" <[email-masked]>
Date: Sat, 10 Apr 2010 00:10:08 +0800

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Friday, April 09, 2010 11:25 PM
To: "Bi Jun" <[email-masked]>
Cc: "Eric Levy-Abegnoli" <[email-masked]>; <[email-masked]>; "'Greg 
Daley'" <[email-masked]>; "Guang Yao" 
<[email-masked]>; <[email-masked]>; "'Suresh Krishnan'" 
<[email-masked]>
Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI "

> If we define the data trigger requirements properly, then direct trigger, 
> counter trigger, or some other mechanism that I am not clever enough to 
> invent are all valid ways of implementing the spec.  RFCs generally try 
> NOT to constrain implementation, but only to constrain the on-the-wire 
> behavior.

Hi Joel,

We may need to discuss this. I said in my past email, this counter triggered 
is not
the original data triggered actions. At least this counter triggered is not 
FCFS mode because it doesn't assume first come first serve rule. This 
counter triggered is a supplement on top of the principle of control 
triggered binding (works for most cases) to handle some unexpected cases (to 
enhance the robustness).
Moreover, the counter triggered alert is OK to be be MUST (so that the admin 
knows
there might be unexpected cases happen), but the counter triggered probe to 
recover binding is still a open issue (can the switch find the right source 
address of the packet to send a probe when the CPU action is triggered by 
counter ? please see "section 24. Counter Triggered Binding" in 
savi-dhcp-02).

>
> As such, I beleive that Fred, Marcelo, and Eric are all willing to include 
> data-triggered behavior as one of the alternatives that a device may use 
> to address providing reliable support for SAVI-SLAAC.  (The question of 
> whether that specific behavior is to be a singular MUST, or whether there 
> is a list of alternatives at least one of which MUST be supported is not 
> fully determined because we have not agreed on the full list of problems 
> and their detectability.)

>From my point, the control based binding should be a MUST (you can say it is 
a base).
Then we have multiple ways to handle unexpected cases (although I still 
doubt
if those cases will happen in real deployment or do harms to operators. I 
think Fred Baker also said so. At least we didn't see it is a serious 
problem in our campus deployment). In savi-dhcp-02, we have made saving 
binding in NV-ram as MUST, and counter-triggered alert as MUST (those are 
implementable and can handle most of the unexpected cases and 
implementable). For others, IMHO, if we ask the vendor to MUST implement any 
of others, then I am afraid that no one real vendor will deliver the 
product.

>
> It seems a necessary to include in the base document that it is legitimate 
> for devices to rate-limit their control response (either directly or 
> indirectly) as that is something many devices will need to do, and that is 
> externally observable.

I really think this is not acceptable. IMHO, maybe you didn't really get the 
problem of rate limiting I mentioned in my past email. If you do rate 
limiting, then EVERY packet(including both control and data packet) will be 
affected. It means the access switch (not router) will failed to deliver the 
control packet to CPU. Then the manager system has to resend the control 
packet by TCP retransmit or timeout, then I have to wait a long time to get 
telnet response or snmp response. In the worse case, the retransmitted 
packet will be failed to deliver to the switch CPU again. Then in the 
management plan, that savi-switch can be considered as dead. I do think the 
loss of important management info is more more serious problem for 
operators. As an operator, a robust management plan is very important, I can 
not image to deploy a savi switch without a robust management plan.

thanks,
Jun Bi

> appendix discussing the various ways of supporting data plane triggered 
> behavior.
>
> Yours,
> Joel
>
>
> Bi Jun wrote:
>>...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 09 Apr 2010 12:30:29 -0400

Commenting on one piece of Jun Bi's reply, retained below.

When I checked with the guys I work with who might well be asked to 
support this, and I asked about data plane triggered behavior, their 
response was that it was doable, as long as I was prepared to rate limit 
the behavior.  WHich was rather what I expected.

Hence, a spec that does not permit sensible rate limiting seems a very 
BAD idea.

I am not requiring that every vendor implement rate limiting.
If you can find a vendor who can build a low end box that does not 
perform rate limiting and that does not fall over under deliberately 
hostile load, then go ahead and use them.
But I do expect that SAVI will be deployed in situations where some 
stations will be deliberately hostile.  And as such, I want to make sure 
the device is allowed to do sensible things to protect itself.

Yours,
Joel

Bi Jun wrote:
...
> I really think this is not acceptable. IMHO, maybe you didn't really get 
> the problem of rate limiting I mentioned in my past email. If you do 
> rate limiting, then EVERY packet(including both control and data packet) 
> will be affected. It means the access switch (not router) will failed to 
> deliver the control packet to CPU. Then the manager system has to resend 
> the control packet by TCP retransmit or timeout, then I have to wait a 
> long time to get telnet response or snmp response. In the worse case, 
> the retransmitted packet will be failed to deliver to the switch CPU 
> again. Then in the management plan, that savi-switch can be considered 
> as dead. I do think the loss of important management info is more more 
> serious problem for operators. As an operator, a robust management plan 
> is very important, I can not image to deploy a savi switch without a 
> robust management plan.
> 
> thanks,
> Jun Bi

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 09 Apr 2010 12:40:04 -0400

Commenting on the semantics of the counter mechanism, or data triggered 
processing, as retained below.

Yes, we could get very specific in how we write the behavior, such that 
counter based behavior was not permitted.
However, we don't need to.
It is perfectly reasoanble that although we call the system FCFS, that 
in fact it is only approximately FCFS.  We could even rename it FPFS 
(First Processed, First Served) if we wanted.  Allowing a range of 
implementations that still meet the overall goal (which is not the 
specific FCFS, but rather the prevention of certain improper behaviors) 
is a good thing.

Yes, we could write the MIB to require the counter.  And to have a 
trigger value for the counter.
But we shouldn't.  Being that specific does not do us any good at all.
Clearly defining the required behavior (including not perpetually 
blocking legitimate users) is necessary.
Describing the interaction with the protocol messages that we expect to 
achieve that is what we need to do here.  (And yes, that gets into 
something closer to implementation than we really like.)

But lets try to stay away from the actual details where we can.

Yours,
Joel

Bi Jun wrote:
>> generally try NOT to constrain implementation, but only to constrain 
>> the on-the-wire behavior.
> 
> Hi Joel,
> 
> We may need to discuss this. I said in my past email, this counter 
> triggered is not
> the original data triggered actions. At least this counter triggered is 
> not FCFS mode because it doesn't assume first come first serve rule. 
> This counter triggered is a supplement on top of the principle of 
> control triggered binding (works for most cases) to handle some 
> unexpected cases (to enhance the robustness).
> Moreover, the counter triggered alert is OK to be be MUST (so that the 
> admin knows
> there might be unexpected cases happen), but the counter triggered probe 
> to recover binding is still a open issue (can the switch find the right 
> source address of the packet to send a probe when the CPU action is 
> triggered by counter ? please see "section 24. Counter Triggered 
> Binding" in savi-dhcp-02).
> 
> 
>>
>> include data-triggered behavior as one of the alternatives that a 
>> device may use to address providing reliable support for SAVI-SLAAC.  
>> (The question of whether that specific behavior is to be a singular 
>> MUST, or whether there is a list of alternatives at least one of which 
>> MUST be supported is not fully determined because we have not agreed 
>> on the full list of problems and their detectability.)
> 
> if those cases will happen in real deployment or do harms to operators. 
> I think Fred Baker also said so. At least we didn't see it is a serious 
> binding in NV-ram as MUST, and counter-triggered alert as MUST (those 
> are implementable and can handle most of the unexpected cases and 
> implementable). For others, IMHO, if we ask the vendor to MUST implement 
> any of others, then I am afraid that no one real vendor will deliver the 
> product.
> 
> 
>>
>> If we want to describe the counter method, it would be in an 
>> informative appendix discussing the various ways of supporting data 
>> plane triggered behavior.
>>
>> Yours,
>> Joel
>>
>>
>> Bi Jun wrote:
>>> ...
>>>> just not realistic to drop traffic when no binding exist, and 
>>>> snooping data traffic is the only solution for addresses not 
>>>> assigned with DHCP.
>>>
>>> counter-triggered  proposed by Fred Baker can be an alternative way 
>>> and more feasible. Guang Yao also said if a NUD is snooped at the 
>>> switch then the switch can send probe to detect
>>> binding in NV-ram immediately after the binding is set up as a MUST 
>>> is realist for most vendors we consulted.
>>
>

---

From: "Bi Jun" <[email-masked]>
Date: Sat, 10 Apr 2010 00:56:09 +0800

Sent: Saturday, April 10, 2010 12:30 AM
Cc: <[email-masked]>

Hi Joel,

Could you please clarify that which "data plane" you mean here?
The reality is that we arranged FCFS for two years, we didn't really see a
FCFS switch. The savi-switch based on control snooping binding is already 
running
at our IPv6 network for half a year (multiple vendors implemented).
If there is a FCFS switch, I'd like to test it in our network.

> Hence, a spec that does not permit sensible rate limiting seems a very BAD 
> idea.
>
> If you can find a vendor who can build a low end box that does not perform 
> rate limiting and that does not fall over under deliberately hostile load, 
> then go ahead and use them.

But the reality is that we really can't find a low-end switch can do 
data-triggered  without that problem. The SAVI WG wanted to promote savi to 
be widely deployed, right?
The most useful place to enable savi is that enable it at the first hop 
access switch,
so that one host can be strictly traced back at one port (then as an 
operator I can exactly bill to the right host based on the traffic of source 
address. if multiple hosts share one port, one can forge the source address 
of another, because the MAC address is also spoofable, then I will have less 
incentive to deploy savi). This grade is low-end, we could not bring too 
much cost to it by a MUST. If the savi switch is very expensive layer 3 
switch then many address sharing one port, does it meaningful for an 
operator? I'd like to just simply enable ingress filtering at this layer 3 
switch to do prefix level anti-spoofing, which is low cost and work for many 
hosts sharing one port.

thanks,
Jun Bi

>> the problem of rate limiting I mentioned in my past email. If you do rate 
>> limiting, then EVERY packet(including both control and data packet) will 
>> be affected. It means the access switch (not router) will failed to 
>> long time to get telnet response or snmp response. In the worse case, the 
>> retransmitted packet will be failed to deliver to the switch CPU again. 
>> Then in the management plan, that savi-switch can be considered as dead. 
>> I do think the loss of important management info is more more serious 
>> problem for operators. As an operator, a robust management plan is very 
>> important, I can not image to deploy a savi switch without a robust 
>> management plan.
>>
>> thanks,
>> Jun Bi
>

---

From: "Jun Bi" <[email-masked]>
Date: Sat, 10 Apr 2010 01:07:57 +0800

Hi Jole,

I am confused. In the history of SAVI WG, there are two basic modes: one is 
FCFS, another is CPS (control plan snooping). FCFS (or you say FPFS) is quit 
different principle from control based snooping (CPS). In FCFS mode, the 
switch has to watch the data packet to setup binding table. In CPS mode, the 
switch watch control packet to setup binding table. So FCFS or FPFS is not 
the counter-triggered (because counter is used to report packet loss). The 
counter-triggered mode itself can't work to setup the initial binding table 
(I can't image EVERY binding entry is set up by after losing some data 
packet), so the counter-triggered has to be used in combination with other 
base solutions to resolve unexpected event (unexpected means it is not the 
most cases) after losing some packets. In savi-dhcp-02, it works so.

thanks,
Jun

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Saturday, April 10, 2010 12:40 AM
To: "Bi Jun" <[email-masked]>
Cc: <[email-masked]>; "'Greg Daley'" <[email-masked]>; "Guang 
Yao" <[email-masked]>; "'Suresh Krishnan'" 
<[email-masked]>
Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI "

> It is perfectly reasoanble that although we call the system FCFS, that in 
> fact it is only approximately FCFS.  We could even rename it FPFS (First 
> Processed, First Served) if we wanted.  Allowing a range of 
> specific FCFS, but rather the prevention of certain improper behaviors) is 
> a good thing.
>
> Yes, we could write the MIB to require the counter.  And to have a trigger 
> value for the counter.
> Clearly defining the required behavior (including not perpetually blocking 
> legitimate users) is necessary.
>> not FCFS mode because it doesn't assume first come first serve rule. This 
>> triggered binding (works for most cases) to handle some unexpected cases 
>> (to enhance the robustness).
>> triggered by counter ? please see "section 24. Counter Triggered Binding" 
>> in savi-dhcp-02).
>>
>>
>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 09 Apr 2010 14:50:22 -0400

The two documents under evaluation are DHCP based and DAD based.
In other words, as far as I know, all of the mechanisms assume that the 
primary goal is to provide control based admission and validation of users.

For both control modes, there have been arguments made that under some 
circumstances, we may miss the control packet, or forget the control 
state.  We then need to restore that state.
Again, for both control modes, folks have argued that we can not mandate 
sufficient simple control based mechanisms.

So we are trying to figure out what additional mechanisms we can offer 
such that the switch can provide SAVI enforcement without permanently 
(or for an extended period of time) blocking legitimate service usage.

This has lead folks to ask that even pure control devices have some form 
of additional data plane admission response.  One way of achieving that 
is through the counter on denials.  Another way is to cause all denials 
to be processed by the control plane.  There are more choices.
My concern is two-fold
1) We should specify as much as possible the external behavior, not the 
internal mechanism
2) We should allow behavior that allows the box to limit the rate at 
which the control processor has to handle events.

The only reason I mentioned FCFS is that it came up in one of your 
comments.  It is in fact the case that control message processing is 
probably subject to some disordering in the event of a collision.  So 
what.

If someone really thinks we need to mandate a coutner based behavior in 
some situation, please state explicitly which scenario, and why it needs 
to be mandated.

Yours,
Joel

Jun Bi wrote:
> Hi Jole,
> 
> I am confused. In the history of SAVI WG, there are two basic modes: one 
> is FCFS, another is CPS (control plan snooping). FCFS (or you say FPFS) 
> is quit different principle from control based snooping (CPS). In FCFS 
> mode, the switch has to watch the data packet to setup binding table. In 
> CPS mode, the switch watch control packet to setup binding table. So 
> FCFS or FPFS is not the counter-triggered (because counter is used to 
> report packet loss). The counter-triggered mode itself can't work to 
> setup the initial binding table (I can't image EVERY binding entry is 
> set up by after losing some data packet), so the counter-triggered has 
> to be used in combination with other base solutions to resolve 
> unexpected event (unexpected means it is not the most cases) after 
> losing some packets. In savi-dhcp-02, it works so.
> 
> thanks,
> Jun
> 
> Cc: <[email-masked]>; "'Greg Daley'" <[email-masked]>; 
> "Guang Yao" <[email-masked]>; "'Suresh Krishnan'" 
>> Commenting on the semantics of the counter mechanism, or data 
>> triggered processing, as retained below.
>>
>> Yes, we could get very specific in how we write the behavior, such 
>> that counter based behavior was not permitted.
>> specific FCFS, but rather the prevention of certain improper 
>> behaviors) is a good thing.
>>
>> Describing the interaction with the protocol messages that we expect 
>> to achieve that is what we need to do here.  (And yes, that gets into 
>>> Cc: "Eric Levy-Abegnoli" <[email-masked]>; <[email-masked]>; 
>>> "'Greg Daley'" <[email-masked]>; "Guang Yao" 
>>>> trigger, counter trigger, or some other mechanism that I am not 
>>>> clever enough to invent are all valid ways of implementing the 
>>>> spec.  RFCs generally try NOT to constrain implementation, but only 
>>>> to constrain the on-the-wire behavior.
>>>
>>> Hi Joel,
>>>
>>> the original data triggered actions. At least this counter triggered 
>>> is not FCFS mode because it doesn't assume first come first serve 
>>> rule. This counter triggered is a supplement on top of the principle 
>>> of control triggered binding (works for most cases) to handle some 
>>> Moreover, the counter triggered alert is OK to be be MUST (so that 
>>> the admin knows
>>> there might be unexpected cases happen), but the counter triggered 
>>> probe to recover binding is still a open issue (can the switch find 
>>> the right source address of the packet to send a probe when the CPU 
>>> action is triggered by counter ? please see "section 24. Counter 
>>> Triggered Binding" in savi-dhcp-02).
>>>
>>>
>>>>
>>>> device may use to address providing reliable support for 
>>>> SAVI-SLAAC.  (The question of whether that specific behavior is to 
>>>> be a singular MUST, or whether there is a list of alternatives at 
>>>> least one of which MUST be supported is not fully determined because 
>>>> we have not agreed on the full list of problems and their 
>>>> detectability.)
>>>
>>> Then we have multiple ways to handle unexpected cases (although I 
>>> still doubt
>>> if those cases will happen in real deployment or do harms to 
>>> operators. I think Fred Baker also said so. At least we didn't see it 
>>> is a serious problem in our campus deployment). In savi-dhcp-02, we 
>>> have made saving binding in NV-ram as MUST, and counter-triggered 
>>> alert as MUST (those are implementable and can handle most of the 
>>> unexpected cases and implementable). For others, IMHO, if we ask the 
>>> vendor to MUST implement any of others, then I am afraid that no one 
>>> real vendor will deliver the product.
>>>
>>>
>>>>
>>>> directly or indirectly) as that is something many devices will need 
>>>> to do, and that is externally observable.
>>>
>>> I really think this is not acceptable. IMHO, maybe you didn't really 
>>> get the problem of rate limiting I mentioned in my past email. If you 
>>> do rate limiting, then EVERY packet(including both control and data 
>>> packet) will be affected. It means the access switch (not router) 
>>> will failed to deliver the control packet to CPU. Then the manager 
>>> system has to resend the control packet by TCP retransmit or timeout, 
>>> then I have to wait a long time to get telnet response or snmp 
>>> response. In the worse case, the retransmitted packet will be failed 
>>> to deliver to the switch CPU again. Then in the management plan, that 
>>> savi-switch can be considered as dead. I do think the loss of 
>>> important management info is more more serious problem for operators. 
>>> As an operator, a robust management plan is very important, I can not 
>>> image to deploy a savi switch without a robust management plan.
>>>
>>> thanks,
>>> Jun Bi
>>>
>>>>

---

From: "Jun Bi" <[email-masked]>
Date: Sat, 10 Apr 2010 11:15:25 +0800

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Saturday, April 10, 2010 2:50 AM
To: "Jun Bi" <[email-masked]>
Cc: "Bi Jun" <[email-masked]>; <[email-masked]>; "'Greg Daley'" 
<[email-masked]>; "Guang Yao" <[email-masked]>; 
"'Suresh Krishnan'" <[email-masked]>
Subject: Re: [savi] One minor comments on "Analysis of Open Issues in SAVI "

Hi Joel,

No, the two documents were: FCFS (is data triggered based) and CPS (is NDP 
snooping based). See the attachment.

> primary goal is to provide control based admission and validation of 

If your statement is true, then the following statement should be removed 
from
savi-fcfs-02, and get rid of the name of FCFS, then rename the solution to a 
popper name, e.g. savi-slaac, then I'd like to see the merge of cps-02 with 
the fcfs-02 as one same state machine. You know
I tried many times.

   section 2.3 of savi-fcfs-02:
   "In FCFS SAVI the address ownership proof is based in the First-Come 
first
   Serve approach.  This means that the first host that claims a given
   source address is the owner of the address until further notice.
   More precisely, whenever a source address is used for the first time,
   a state is created in the device that is performing the FCFS SAVI
   function binding the source address to the layer-2 information that
   the FCFS SAVI box has available (e.g. the port in a switched LAN)."

    This does mean the savi-switch has to watch the data traffic and set up
the binding trigged by data, which is not implementable as a MUST for 
savi-switch.

> such that the switch can provide SAVI enforcement without permanently (or 
> for an extended period of time) blocking legitimate service usage.
>
> of additional data plane admission response.  One way of achieving that is 
> through the counter on denials.  Another way is to cause all denials to be 
> processed by the control plane.  There are more choices.
> My concern is two-fold

But what we say MUST in a draft should be implementable by most switches, 
right?
I am fine with the counter-based, the NV-ram saving as MUST or SHOULD.
For data-triggered like FCFS, it should be SHOULD, because it has problem.

> 2) We should allow behavior that allows the box to limit the rate at which 
> the control processor has to handle events.

I am not against to make this as a SHOULD, but it cant' to be a MUST, 
because it has problem.

>> CPS mode, the switch watch control packet to setup binding table. So FCFS 
>> or FPFS is not the counter-triggered (because counter is used to report 
>> packet loss). The counter-triggered mode itself can't work to setup the 
>> initial binding table (I can't image EVERY binding entry is set up by 
>> after losing some data packet), so the counter-triggered has to be used 
>> in combination with other base solutions to resolve unexpected event 
>> (unexpected means it is not the most cases) after losing some packets. In 
>> savi-dhcp-02, it works so.
>>
>> thanks,
>> Jun
>>
>>>> probe to recover binding is still a open issue (can the switch find the 
>>>> right source address of the packet to send a probe when the CPU action 
>>>> is triggered by counter ? please see "section 24. Counter Triggered 
>>>> implementable). For others, IMHO, if we ask the vendor to MUST 
>>>> implement any of others, then I am afraid that no one real vendor will 
>>>> deliver the product.
>>>>
>>>>
>>>>>
>>>> packet) will be affected. It means the access switch (not router) will 
>>>> failed to deliver the control packet to CPU. Then the manager system 
>>>> has to resend the control packet by TCP retransmit or timeout, then I 
>>>> have to wait a long time to get telnet response or snmp response. In 
>>>> the worse case, the retransmitted packet will be failed to deliver to 
>>>> the switch CPU again. Then in the management plan, that savi-switch can 
>>>> be considered as dead. I do think the loss of important management info 
>>>> is more more serious problem for operators. As an operator, a robust 
>>>> management plan is very important, I can not image to deploy a savi 
>>>> switch without a robust management plan.
>>>>
>>>> thanks,
>>>> Jun Bi
>>>>
>>>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 11 Apr 2010 16:34:57 +0200

just to clarify this...

El 10/04/10 5:15, Jun Bi escribió:
> No, the two documents were: FCFS (is data triggered based) and CPS (is 
> NDP snooping based). See the attachment.
>
not really, when the CPS document was written (april 2009 - see 
http://tools.ietf.org/html/draft-bi-savi-cps-00), the fcfs was already a 
WG document since january 2009 (see 
http://tools.ietf.org/html/draft-ietf-savi-fcfs-00) and also, the fcfs 
document already triggered the binding creation procedure upon the 
recpetion of either control packets and data packets for which it didn't 
have a valid binding for.

>> In other words, as far as I know, all of the mechanisms assume that 
>> the primary goal is to provide control based admission and validation 
>> of users.
>
> If your statement is true, then the following statement should be 
> removed from
> savi-fcfs-02, and get rid of the name of FCFS, then rename the 
> solution to a popper name,
FCFS is the ownership principle the SLAAC SAVI works on.
(fwiw, i have no problem in chaning the name, i just want to clairfy the 
concepts that seems to be a bit confused here)

We have two very different cases here:
The DHCP case, where there is a central auhtority that decides who owns 
which address. In this case,t he ownership is defined by this auhtority 
i.e the dhcp server.
In the slaac case we don't have such authority, so we need an 
alternative mechanism to determine ownership. This mechanisms if the 
FCFS. The first one that claims the address is the one that owns it.
This means that the  SLAAC Savi device will create a binding the first 
time it sees a host using a given address. This is what fcfs stands for.

> e.g. savi-slaac, then I'd like to see the merge of cps-02 with the 
> fcfs-02 as one same state machine. You know
> I tried many times.
>

exactly, this is what i described above. Please note that the paragrpah 
above doesn't say in any place the the address is contained in the 
source address field of a data packet. THe host may be claiming an 
address by performing DAD for that address and this is supported by the 
fcfs draft that you kindly attached.

> the binding trigged by data, which is not implementable as a MUST for 
AFAICT, the counter based trigger is a way to implement the triggering 
of a binding creation procedure upon the recpetion of a data packet for 
which the savi device does not have a binding for.

>>
>> For both control modes, there have been arguments made that under 
>> some circumstances, we may miss the control packet, or forget the 
>> control state.  We then need to restore that state.
>> Again, for both control modes, folks have argued that we can not 
>> mandate sufficient simple control based mechanisms.
>>
>> So we are trying to figure out what additional mechanisms we can 
>> offer such that the switch can provide SAVI enforcement without 
>> permanently (or for an extended period of time) blocking legitimate 
>> service usage.
>>
>> This has lead folks to ask that even pure control devices have some 
>> form of additional data plane admission response.  One way of 
>> achieving that is through the counter on denials.  Another way is to 
>> cause all denials to be processed by the control plane.  There are 
>> more choices.
>> My concern is two-fold
>> 1) We should specify as much as possible the external behavior, not 
>> the internal mechanism
>
> But what we say MUST in a draft should be implementable by most 
> switches, right?
> I am fine with the counter-based,
as mentioned above, the counter based is a way to implemnet the 
triggering of the binding creation procedure upon the recpetion of a 
data packet for which source address the savi does not have a binding for.
As people have repeatedly corrected me (and i agree) we should not 
mandate implementations, but we shoudl mandate external behaviour i.e. 
the functionality.

The other way we could do this is to provide a possible implementation 
(the counter based triggering if you want) and say that any other 
implementation which external behaviour is the same is accetpable.

> the NV-ram saving as MUST or SHOULD.

I think that what needs to be a MUST is that the box MUST protect itself 
agaisnt DoS attacks. One possible way of doing this would be to rate 
limit, but if someone is able to procude a box that cannot be DoSed, 
then it should need to implement it.

Regards, marcelo

>> If someone really thinks we need to mandate a coutner based behavior 
>> in some situation, please state explicitly which scenario, and why it 
>> needs to be mandated.
>>
>> Yours,
>> Joel
>>
>> Jun Bi wrote:
>>> Hi Jole,
>>>
>>> I am confused. In the history of SAVI WG, there are two basic modes: 
>>> one is FCFS, another is CPS (control plan snooping). FCFS (or you 
>>> say FPFS) is quit different principle from control based snooping 
>>> (CPS). In FCFS mode, the switch has to watch the data packet to 
>>> setup binding table. In CPS mode, the switch watch control packet to 
>>> setup binding table. So FCFS or FPFS is not the counter-triggered 
>>> (because counter is used to report packet loss). The 
>>> counter-triggered mode itself can't work to setup the initial 
>>> binding table (I can't image EVERY binding entry is set up by after 
>>> losing some data packet), so the counter-triggered has to be used in 
>>> combination with other base solutions to resolve unexpected event 
>>> (unexpected means it is not the most cases) after losing some 
>>> packets. In savi-dhcp-02, it works so.
>>>
>>> thanks,
>>> Jun
>>>
>>>> It is perfectly reasoanble that although we call the system FCFS, 
>>>> that in fact it is only approximately FCFS.  We could even rename 
>>>> it FPFS (First Processed, First Served) if we wanted.  Allowing a 
>>>> range of implementations that still meet the overall goal (which is 
>>>> not the specific FCFS, but rather the prevention of certain 
>>>> improper behaviors) is a good thing.
>>>>
>>>> Describing the interaction with the protocol messages that we 
>>>> expect to achieve that is what we need to do here.  (And yes, that 
>>>> gets into something closer to implementation than we really like.)
>>>>
>>>>>> spec.  RFCs generally try NOT to constrain implementation, but 
>>>>>> only to constrain the on-the-wire behavior.
>>>>>
>>>>> Hi Joel,
>>>>>
>>>>> the original data triggered actions. At least this counter 
>>>>> triggered is not FCFS mode because it doesn't assume first come 
>>>>> first serve rule. This counter triggered is a supplement on top of 
>>>>> the principle of control triggered binding (works for most cases) 
>>>>> to handle some unexpected cases (to enhance the robustness).
>>>>> probe to recover binding is still a open issue (can the switch 
>>>>> find the right source address of the packet to send a probe when 
>>>>> the CPU action is triggered by counter ? please see "section 24. 
>>>>> Counter Triggered Binding" in savi-dhcp-02).
>>>>>
>>>>>
>>>>>>
>>>>>> As such, I beleive that Fred, Marcelo, and Eric are all willing 
>>>>>> to include data-triggered behavior as one of the alternatives 
>>>>>> that a device may use to address providing reliable support for 
>>>>>> least one of which MUST be supported is not fully determined 
>>>>>> because we have not agreed on the full list of problems and their 
>>>>>> detectability.)
>>>>>
>>>>> operators. I think Fred Baker also said so. At least we didn't see 
>>>>> it is a serious problem in our campus deployment). In 
>>>>> savi-dhcp-02, we have made saving binding in NV-ram as MUST, and 
>>>>> counter-triggered alert as MUST (those are implementable and can 
>>>>> handle most of the unexpected cases and implementable). For 
>>>>> others, IMHO, if we ask the vendor to MUST implement any of 
>>>>> others, then I am afraid that no one real vendor will deliver the 
>>>>> product.
>>>>>
>>>>>
>>>>>>
>>>>>> legitimate for devices to rate-limit their control response 
>>>>>> (either directly or indirectly) as that is something many devices 
>>>>>> will need to do, and that is externally observable.
>>>>>
>>>>> I really think this is not acceptable. IMHO, maybe you didn't 
>>>>> really get the problem of rate limiting I mentioned in my past 
>>>>> email. If you do rate limiting, then EVERY packet(including both 
>>>>> control and data packet) will be affected. It means the access 
>>>>> switch (not router) will failed to deliver the control packet to 
>>>>> CPU. Then the manager system has to resend the control packet by 
>>>>> TCP retransmit or timeout, then I have to wait a long time to get 
>>>>> telnet response or snmp response. In the worse case, the 
>>>>> retransmitted packet will be failed to deliver to the switch CPU 
>>>>> again. Then in the management plan, that savi-switch can be 
>>>>> considered as dead. I do think the loss of important management 
>>>>> info is more more serious problem for operators. As an operator, a 
>>>>> robust management plan is very important, I can not image to 
>>>>> deploy a savi switch without a robust management plan.
>>>>>
>>>>> thanks,
>>>>> Jun Bi
>>>>>
>>>>>>
>>>>>> informative appendix discussing the various ways of supporting 
>>>>>> data plane triggered behavior.
>>>>>>
>>>>>> Yours,
>>>>>> Joel
>>>>>>
>>>>>>
>>>>>> Bi Jun wrote:
>>>>>>> ...
>>>>>>> counter-triggered  proposed by Fred Baker can be an alternative 
>>>>>>> way and more feasible. Guang Yao also said if a NUD is snooped 
>>>>>>> at the switch then the switch can send probe to detect
>>>>>>> (it is only a potential idea, need some test to verify). Saving 
>>>>>>> the binding in NV-ram immediately after the binding is set up as 
>>>>>>> a MUST is realist for most vendors we consulted.
>>>>>>
>>>>>

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 12 Apr 2010 10:30:57 +0800

> time it sees a host using a given address. This is what fcfs stands for.

[Guang Yao] 
"The first one that claims the address is the one that owns it." : It's
right, I agree.

"SLAAC Savi device will create a binding the first time it sees a host using
a given address.": This sentence doesn't have exactly the same meaning of
the above, and I don't agree.

And I wonder how you can handle movement on local link? And layer 2 path
change? The savi device will find a second host using the bound address.

BR,
Guang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Apr 2010 08:36:18 +0200

> the above, and I don't agree.
ok, if you have an alternative phrasing that you think would better 
describe the behaviour, please propose it and i we can try to add it to 
the document

> change? The savi device will find a second host using the bound address.
Right, in order to take into account that, we should rephrase it as:

This means that the  SLAAC Savi device will trigger the procedure to create a binding the first
time it sees a host using a given address.

makes sense?

Regards, marcelo