OpenFlow Meeting Notes 3-16-2010

From OpenFlow Wiki

Jump to: navigation, search

Rajiv presented the process slides, plus a schedule for the next few months. See the presentation slides.

[Nick]: note that we're in this together

[KK]: question about process at the end; how does a feature get included? Will feature inclusion require an implementation?

[James Kempf]: Brought up MPLS OAM; suggested to post to list

[Michael Orr]: Should we also consider multicast? Multipath/multicast very similar.

[Ed]: Hash functions are outside of the protocol.

[Ed]: Assume that switches offer multiple hashes but we won't change the hash dynamically from within OpenFlow.

[Nick]: Equal weight: should we support non-equal weight?

[Rajiv]: Can achieve this by specifying the same port multiple times.

[Michael]: Multicast: must currently explicitly specify all ports in the flow. Could mirror the multipath idea of using logical port groups.

[Ed]: Problem of distinguishing b/w multicast and multipath groups.

[Brandon]: Logical port provides atomicity of updates -- update one logical port updates all flows that use that logical port.

[KK] Why is flow mod not sufficient? A: can't be more specific than a single field; two sets of flows, for example, might not be represented by only two prefixes

[Nikhil] +1 use case: in load balancer, what happens with existing TCP flows w/anycast?

[Joe Tardo]: are groups strictly BW, or also for reliability?

[Ed]: Switch can rehash on link failure

Fast response to failover: should switch make the decision on its own, or controller? A: this is an optimization

Add "reliability" use case?

[Nick]: Is there anything special/extra needed to support this?

[James]: OAM processing in controller or switch?

[Nick]: Question of timescales -- what value?

[James]: 20ms for link failover discovery. is this a reasonable?

[Michael]: Do we only need to deal with cases where both sides to LACP?

[Michael]: Corner cases when only one side does LACP: packet loss, black holes.

Single-sided ECMP use cases?

Explicit: no response to changes in the LAG status (outside of OpenFlow)

[Michael]: LAG defined on both sides, but autonegotiation failure can cause pkt-loss/black hole situation.

both sides speak LACP, or controller needs to learn this?

link health should run on the switch, and there's no mandate

[James]: port protection mechanism -- is there a generic mechanism?

[KK]: LLDP, BFD, etc, 802.3ag, in the switch? A: unclear that this is with the scope, and we don't want to mandate a specific design

[Rajiv]: be careful of dictating network design. Don't want to mandate a design.

[Nick]: we should run less

[James]: DT won't run a network without these reliability mechanisms… it's a matter of getting the right abstractions, plus overhead and abstraction

[James]: Another use case: datacenter network. A: Just an instance of ECMP or LAG

[Nick]: Similarity between multipath, multicast, and sampling/span.

[KK] Multi-home use case

[Nikhil]: expose hashing function discussion on how to do nondisruptive rehashing - subtract requires re-hash, add is tough

[Nikhil: hash microflows

[Jean]: should phy be part of multiple groups?

[Joe]: hw limitation for LAG, port can only be a part of one vs FT, where you may want many groups

[Jean]: when a packet arrives on a L2 bonded port, don't know which virtual interface it arrives on if physical port shared between multiple groups

[Jean]: in non fat-tree situations, we may actually want multiple overlapping groups.