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]<mailto:[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]<mailto:[email protected]>] Sent: Thursday, April 14, 2011 1:58 PM To: Kiran Yedavalli Cc: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
_______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
