Dan You are absolutely right. But in the case where hardware does not allow metadata (Kiran's case) or when you don't have multiple tables (my case), this is a valid solution even if it means lots of rules
Thanks Saurav Sorry for the short msg. Sent from iPhone On Apr 24, 2011, at 9:01 PM, Dan Talayco <[email protected]> wrote: > Thanks Saurav, for the excellent point. This is clearly a good approach. > > After I thought about it a bit more I realized that it does have a drawback > which is the old 1.0 issue of cross product rule explosion. If you want to > have a bunch of independent rules for matching on the IP addr and a bunch of > others for matching on input port, with this approach you have to take the > product of those two to cover all the possibilities. > > So I think it's a good solution, but might not scale to large sets of rules. > > -Dan > > On Friday, April 22, 2011 at 4:13 PM, Saurav Das wrote: > Hello all, >> >> Sorry - joining this a little late, but what seems to have been lost in all >> this Action Set discussion is that there is also the Action List. >> >> Kiran: Why is not possible to use a single table to match on input port and >> destination IP address and then to use the Action List to add inner label >> and then the outer label. >> >> According to the spec they will be added in the right order. >> The actions of an action list are executed in the >> order specified by the list, and are applied immediately to the packet. >> >> >> This is how we are doing our VPN implementation. >> >> Does your hardware not allow you to match on input port and dest IP at the >> same time? >> >> Thanks >> Saurav >> >> >> On Apr 18, 2011, at 10:33 AM, Rajiv Ramanathan wrote: >>> >>> >>> On Mon, Apr 18, 2011 at 9:22 AM, Kiran Yedavalli >>> <[email protected]> wrote: >>>> Sure, I agree. In a generalized case, it will get complicated. However, >>>> there are many simple case that would require 2 or 3 actions of the same >>>> kind in the action set, that are fairly simple to use. But this condition >>>> in the spec precludes even these simple case. >>>> >>>> Restricting the number of actions of the same kind to 2 or 3 max, instead >>>> of 1 as it is currently, the complexity does not increase by much. >>> >>> >>> - I think you are missing the point that Zoltan brought up. In general, I >>> agree with the issue that you raise (It does seem painful to do a single >>> label per table). >>> - Let's assume you support 2 actions of the same kind in the action set. If >>> you have a push label 1 action in table 0 and another push action 2 in >>> table 1 => What is the ordering of the labels? 1 is inner and 2 is outer? >>> What if I want the order reversed? What if I want only one label inserted >>> and actually want the other label taken out? >>> - The point is that the match would also need look into the "action set" in >>> order to figure out what instructions it needs to run and will need to be >>> able to "edit" the action set (ie use insert at position instructions). >>> This would have made the spec. even more complicated IMO. >>> - Increasing the number of actions to 2 or n would have made no difference >>> in the complications that arise. But if you have proposal that you think >>> will work, I would love to hear it. >>> >>> Rajiv >>> >>> >>>> From: Rajiv Ramanathan [mailto:[email protected]] >>>> Sent: Friday, April 15, 2011 10:15 AM >>>> To: Zoltán Lajos Kis >>>> Cc: Kiran Yedavalli; [email protected] >>>> >>>> Subject: Re: [openflow-discuss] Pushing 2 MPLS labels. >>>> >>>> Yes. Zoltan has this exactly right. >>>> >>>> On Fri, Apr 15, 2011 at 8:02 AM, Zoltán Lajos Kis >>>> <[email protected]> wrote: >>>>> The complexity would be in the protocol. The flow entries should be able >>>>> to tell not only the actions to be written, but also their exact location >>>>> among the actions already in the list (which are uknown prior to >>>>> matching), and whether the new actions replace existing ones or not. >>>>> >>>>> Regards, >>>>> Zoltan. >>>>> >>>>> >>>>> From: [email protected] >>>>> [mailto:[email protected]] On Behalf Of Kiran >>>>> Yedavalli >>>>> Sent: Friday, April 15, 2011 4:30 PM >>>>> To: Rajiv Ramanathan >>>>> >>>>> Cc: [email protected] >>>>> Subject: Re: [openflow-discuss] Pushing 2 MPLS labels. >>>>> >>>>> Its pretty complicated to handle multiple actions (if it was an >>>>> ActionList) because it involves "insertion" of actions in a specific >>>>> order on a table match. >>>>> >>>>> I think the complexity of implementation should be left to the vendor in >>>>> this case. There could be many simple cases where there is not much >>>>> complexity in implementation of this. Taking away this functionality is >>>>> reducing the flexibility of OF 1.1 implementation as such. >>>>> >>>>> From: Rajiv Ramanathan [mailto:[email protected]] >>>>> Sent: Friday, April 15, 2011 3:18 AM >>>>> To: Kiran Yedavalli >>>>> Cc: [email protected] >>>>> Subject: Re: [openflow-discuss] Pushing 2 MPLS labels. >>>>> >>>>> >>>>> >>>>> On Thu, Apr 14, 2011 at 5:04 PM, Kiran Yedavalli >>>>> <[email protected]> wrote: >>>>>> Thanks Rajiv and Dan. Looks like we need metadata in any case for this >>>>>> to work. We initially thought of this, but our platform does not support >>>>>> metadata, so was wondering if there is a way without using metadata. >>>>>> Looks like there is none. >>>>> >>>>> This is no reason not to use metadata. I don't believe your "software" >>>>> pipeline has to match your "hardware" pipeline. The switch can translate >>>>> the controller request to push 2 labels on 2 tables to pushing 2 labels >>>>> on one hardware table. I definitely understand that this could become >>>>> non-trivial. >>>>> >>>>>> >>>>>> >>>>>> Also, what is the reason why Action Set does not support more than one >>>>>> action of the same kind? >>>>> >>>>> >>>>> Its pretty complicated to handle multiple actions (if it was an >>>>> ActionList) because it involves "insertion" of actions in a specific >>>>> order on a table match. >>>>> >>>>>> >>>>>> Thanks >>>>>> Kiran >>>>>> >>>>>> From: Rajiv Ramanathan [mailto:[email protected]] >>>>>> Sent: Thursday, April 14, 2011 1:58 PM >>>>>> To: Kiran Yedavalli >>>>>> Cc: [email protected] >>>>>> Subject: Re: [openflow-discuss] Pushing 2 MPLS labels. >>>>>> >>>>>> A couple of solutions (variations of the same theme) are: >>>>>> >>>>>> Table 0: match on dest IP, set metadata >>>>>> Table 1: match on input port, push inner label >>>>>> Table 3: match on metadata, push outer label >>>>>> >>>>>> or >>>>>> >>>>>> Table 0: match on dest IP and input port, set metadata and push inner >>>>>> label >>>>>> Table 1: match on metadata, push outer labe. >>>>>> >>>>>> >>>>>> On Thu, Apr 14, 2011 at 10:37 AM, Kiran Yedavalli >>>>>> <[email protected]> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The problem is to push two MPLS labels onto a packet, the inner one >>>>>>> based on input port and the outer one based on destination IP address. >>>>>>> However, the spec does not allow this in any way. We looked at three >>>>>>> options: >>>>>>> >>>>>>> Option 1. Match on input port on table 0 and push a MPLS label, next, >>>>>>> match on dest IP address in table 1 and push a MPLS label. The spec >>>>>>> does not allows this, because we cannot look at the IP address after we >>>>>>> push a MPLS label, according to the spec. >>>>>>> >>>>>>> Option 2. Match on dest IP address on table 0 and push a MPLS label, >>>>>>> next, match on input port in table 1 and push a MPLS label. But in this >>>>>>> case, according to the spec, we can only push an outmost label >>>>>>> everytime we push. This does not work for us either. >>>>>>> >>>>>>> Option 3. Accumlate all actions in the Action Set using the >>>>>>> WriteActions Instruction. This does not work either, because the Action >>>>>>> Set cannot have more than one of the same kind of action. >>>>>>> >>>>>>> Is there any other way of accomplishing this? If not, we think this is >>>>>>> a flaw in the spec that does not allow for inserting more than one >>>>>>> label. >>>>>>> >>>>>>> Thanks >>>>>>> Kiran >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openflow-discuss mailing list >>>>>>> [email protected] >>>>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>>> >>>>> >>>>> _______________________________________________ >>>>> openflow-discuss mailing list >>>>> [email protected] >>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> _______________________________________________ >>> openflow-discuss mailing list >>> [email protected] >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> >> Saurav Das >> PhD Candidate >> Electrical Engineering >> Stanford University >> (W) 650 724 3409 >> >> >> >> >> _______________________________________________ >> openflow-discuss mailing list >> [email protected] >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> > _______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
