Thanks for the feedback. In fact it is a joint discovery with some of my colleagues; basically I implemented the "latter", when fixing the switch against the oftest cases, while they expected the "former", based on the specification :o).
Anyway, I'll make a somewhat formal proposal so that it can make it to OpenFlow x.y. Regards, Zoltan. > -----Original Message----- > From: Rob Sherwood [mailto:[email protected]] > Sent: Monday, August 29, 2011 4:41 PM > To: Zoltán Lajos Kis > Cc: [email protected] > Subject: Re: [openflow-discuss] OpenFlow 1.1 pipeline clarification > > 2011/8/29 Zoltán Lajos Kis <[email protected]>: > > I think the expected behavior is to execute the table > configured default, i.e., one of : > OFPTC_TABLE_MISS_CONTROLLER , /* Send to controller. */ > OFPTC_TABLE_MISS_CONTINUE /* Continue to the > next table */ > OFPTC_TABLE_MISS_DROP > > But that does seem to preclude "stop processing and just > execute current action set" . > > > So the question is: which is the expected behavior; and if > the answer > > is "either", should we add a new table config, like > > OFPTC_TABLE_MISS_EXECUTE, to make explicit distinction > between the two > > possible? > > IMHO, the behavior/spec is clear, but the current spec does > not allow you to do the very reasonable thing that you want. > Given that, I think adding a OFPTC_TABLE_MISS_EXECUTE is > probably the right thing. > My first thought was to say that "if that's the behavior the > controller wants, you can always specific a low-priority > match all in table 1", but it's my understanding that it's > not simple to specify a "match all" for all types of table > hardware, e.g., I'm not sure you could do that with a > non-TCAM-based L2 table, so another > OFPTC_TABLE_MISS_* constant seems like the right thing. > > Good catch Zoltan, > > - Rob > . > _______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
