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]
m> 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
