Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[openflow-dev] OF spec + learning switch behavior questions

Martin Casado casado at cs.stanford.edu
Sun Apr 13 21:52:01 PDT 2008


What happens if you have two conflicting exact match entries with the  
same priority?

On Apr 13, 2008, at 9:49 PM, Jad Naous wrote:

> I think this might be too much of a burden on a switch. If I  
> understand
> correctly, for every wildcard entry, the switch has to check whether  
> any
> of the exact matches already in the table would conflict with it. Why
> not go with a fixed priority where exact always wins over wildcard?
>
> Jad.
>
> Justin Pettit wrote:
>>>> This isn't currently implemented in the reference implementation,  
>>>> because of
>>>> disagreements about what to do with multiple conflicting entries  
>>>> with the
>>>> same priority.  The issue was whether or not to require the  
>>>> switch to
>>>> determine if a conflict exists and generate an error message to the
>>>> controller.  That should be resolved this week.
>>>>
>>>>
>>> Probably good to summarize the discussion about conflicting  
>>> entries for
>>> the list -- I know we emailed back and forth about it, but that was
>>> before the list was created.
>>>
>>
>> The issue was about whether the switch should attempt to detect  
>> whether an
>> attempted rule insertion of a wild-carded entry would overlap with  
>> others at
>> the same priority.  In normal circumstances, the controller should  
>> prevent
>> this from happening.  However, if the switch and controller get out  
>> of sync,
>> this could cause subtle bugs.  The big question was whether this  
>> was too
>> much burden to place on OpenFlow implementers.
>>
>> In my opinion, the controller is going to have to know all the  
>> rules that
>> are in place in switches anyways, because it will have to have  
>> disambiguate
>> different rule requests from different applications.  If a controller
>> restarts and loses its state, there's already a mechanism for it to  
>> get
>> existing rules out of switches.  My concern is that when we get a  
>> switch
>> that supports hundreds of thousands of entries in hardware, it  
>> could be a
>> lot of work to find conflicts in some of these embedded CPUs.
>>
>> However, I think safety won out, and OpenFlow switches will be  
>> required to
>> detect this situation.  When it occurs, the entry is discarded and  
>> a (soon
>> to be defined) error message is sent to the controller.  If anyone  
>> has
>> strong opinions, feel free to rip open the scab again.  ;)
>>
>>
>>>> We're hoping to have a complete spec defined this week.
>>>>
>>> It would be good to get input from everyone on the list - and  
>>> edits too
>>> - on the next version of the spec. Now it's less ad-hoc and we  
>>> have a
>>> list, it would be great to get everyone's combined grey matter on  
>>> OF.
>>>
>>
>> That was the plan!
>>
>> --Justin
>>
>>
>> _______________________________________________
>> openflow-dev mailing list
>> openflow-dev at lists.stanford.edu
>> https://mailman.stanford.edu/mailman/listinfo/openflow-dev
>>
>>
>
> _______________________________________________
> openflow-dev mailing list
> openflow-dev at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/openflow-dev
>




More information about the openflow-dev mailing list