QinQ related statistics in sFlow

[Lukasz Rzasik]

Hello,

I would like to start a discussion about adding QinQ related statistics to sFlow.

I was implementing the QinQ statistics reporting for Open vSwitch using extended_vlantunnel structure but Neil McKee pointed out that this is not the right place.

The bottom line was there is currently no place in sFlow to report the information. 

The patch and the discussion can be found here: https://patchwork.ozlabs.org/patch/751796/

I would suggest adding a structure similar to extended_mpls that can hold stacks of VLAN tags for received and transmitted packets.

Alternatively, the stacks could hold pushed and popped tags.

Please let me know you thoughts.

Best regards,

Lukasz Rzasik

[Peter Phaal]

I would suggest two new structures to deal with ingress/egress packet sampling and to maintain compatibility with the existing  extended_vlantunnel structure and fit with the spirit of the sFlow Tunnel Structures extension (http://sflow.org/sflow_tunnels.txt):

/* opaque = flow_data; enterprise = 0; format = 1034 */
extended_vlanin {
  unsigned int stack<>;  /* List of ingress 802.1Q TPID/TCI layers. Each
                            TPID,TCI pair is represented as a single 32 bit
                            integer. Layers listed from outermost to
                            innermost. */
}

/* opaque = flow_data; enterprise = 0; format = 1035 */
extended_vlanout {
  unsigned int stack<>;  /* List of egress 802.1Q TPID/TCI layers. Each
                            TPID,TCI pair is represented as a single 32 bit
                            integer. Layers listed from outermost to
                            innermost. */
}

In the case of the ingress sampled packet in Open vSwitch, the ingress VLAN stack is present in the packet header so only the extended_vlanout structure would be added to describe the vlan stack created by any push/pop operations performed by the switch. Any labels stripped by the network adapter could be reported in the extended_vlantunnel. 

In the case of egress packet sampling, the extended_vlanin structure would be used to describe the stack on ingress. The extended_vlanout would only be included if the sampled packet header didn't already include the information.

Does this make sense? Do you think it covers all the use cases?

[Lukasz Rzasik]

I think this should cover all the uses cases as we would have all the needed information. Both ingress and egress VLAN stack.

When do you think we can expect the changes?

Thanks a lot for a quick reply.

[Peter Phaal]

This thread is open for comments for 30 days. If there are no comments, then we can finalize the spec. In the mean time, it makes sense to go ahead with an implementation of the extended_vlanout structure in Open vSwitch to see if there are any issues.

--
You received this message because you are subscribed to the Google Groups "sFlow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sflow+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.