[GBP-22] Source condition group gets aliased when implementing SFC with multiple acitons

Blocks — Fri, 15 May 2015 03:28:14 +0000

The current implementation of policy enforcement in the OpenFlow Overlay renderer for GBP only supports "allow" for action, and completely classifies and enforces the policy at the originating node. If the packet is sent across a tunnel, the receiving node adds a flag of 0xFFFFFF into the source condition group Nicira register to indicate that the packet was received from another node, and therefore already had its policy (allow) applied. This allows the packet to avoid reclassification against the original "allow" action on the destination node, and therefore the packet can simply be delivered to the destination port on the vSwitch.

Users get to define the order that actions take place, using the order field in the action references. This means that the "allow" action can happen before another action (e.g. "QoS marking"), and therefore means that the remaining policy must be enforced on the receiving node (perhaps a better example is chain – you could theoretically allow the QoS marking to be enforced on the originating node when allows is the first action, but you probably wouldn't want QoS marking to happen until it reaches the destination node when doing a chain action). However, since all packets received via the overlay tunnel port are marked with a source condition group of 0xFFFFFF, there is now ambiguity, which means you can't create a match that only selects based on the source condition group (i.e. any EPG sending traffic to that node gets the source condition group marked as 0xFFFFFF). In order to properly support distributed policy enforcement, some alternate means of marking must be used (e.g. per-source condition group mapping).

OpenDaylight JIRA

[GBP-22] Source condition group gets aliased when implementing SFC with multiple acitons