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
