Re: [nznog] NZIX OpenFlow adventures phase 2
Hi Nathan; Hardware flows != OpenFlow flows. OpenFlow is an API. Some reflection on these statements may suggest an answer. Thanks, == If you hit the limit of number of flows, what happens? Does it reject the flow, or does it delete older ones to make room for it? Given there is no default route, what happens if you get a packet that doesn't match a flow? Does it drop it, or punt it to the controller? (ie. is there a default flow to drop) If it deletes older flows, and punts non-matching packets to the controller, that sounds like there's a potential for really bad performance spikes as you approach the upper limits of the flow table. If it deletes older flows and drops non-matching packets, then that's worse. If you simply reject new flows, then that's a bit better, but you've got to make sure that the route reflectors never re-advertise prefixes unless they're installed in to the flow tables successfully, or you drop packets, or punt them to the controller as above. Some interesting issues to consider! Agreed re. VPLS/etc. - but you've got to make sure your switches have reliable connectivity to your controller(s). In a network like WIX, that might be hard, not sure.
So forwarding is done based on MACs? Basically building a large virtual bridge and state is roughly O(N) where N is number of connected ISPs. Because if it's based on L3 information, then any ingress switch on the fabric will need to have forwarding entry for each distinct prefix+next hop that it's expected to forward pkts to... or I'm on the verge of learning about something new, in which case don't be cryptic please ;) On 1/8/2013 8:55 PM, Josh Bailey wrote:
Hi Nathan;
Hardware flows != OpenFlow flows. OpenFlow is an API.
Some reflection on these statements may suggest an answer.
Thanks,
==
If you hit the limit of number of flows, what happens? Does it reject the flow, or does it delete older ones to make room for it?
Given there is no default route, what happens if you get a packet that doesn't match a flow? Does it drop it, or punt it to the controller? (ie. is there a default flow to drop)
If it deletes older flows, and punts non-matching packets to the controller, that sounds like there's a potential for really bad performance spikes as you approach the upper limits of the flow table.
If it deletes older flows and drops non-matching packets, then that's worse.
If you simply reject new flows, then that's a bit better, but you've got to make sure that the route reflectors never re-advertise prefixes unless they're installed in to the flow tables successfully, or you drop packets, or punt them to the controller as above.
Some interesting issues to consider!
Agreed re. VPLS/etc. - but you've got to make sure your switches have reliable connectivity to your controller(s). In a network like WIX, that might be hard, not sure.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On 9/01/2013, at 12:53 PM, Kris Price
So forwarding is done based on MACs?
My understanding is that forwarding can be done on anything. You could forward based on ethertype, IPv6 payload length, or IPv4 header checksum if you really wanted. The idea is you get to decide what you want and Dean et al. are scratching their heads trying to work what it is they want. Cheers, Lloyd
On 1/9/2013 1:00 PM, Lloyd Parkes wrote:
On 9/01/2013, at 12:53 PM, Kris Price
wrote: So forwarding is done based on MACs?
My understanding is that forwarding can be done on anything. You could forward based on ethertype, IPv6 payload length, or IPv4 header checksum if you really wanted. The idea is you get to decide what you want and Dean et al. are scratching their heads trying to work what it is they want.
Yep, OpenFlow is flexible with what it can match and what actions it can take (dependent on hardware support of course). Only thing lacking in the OpenFlow specification I really want to see is push/pop of IP headers in order to do IP based encapsulation (limited to MAC, MPLS, and PBB encap at the moment). But, yes, I'm curious how the data plane does/will work in terms of the IX. Maybe I misunderstood and am leaping too far ahead, but I thought it was already pushing flow entries via openflow on this trial switch.
I understand what OpenFlow is.
Not sure what you mean exactly, or rather, how it relates to using OpenFlow in an IXP, or really any network with a large number of routes and traffic to all of them.
On 8/01/2013, at 8:55 PM, Josh Bailey
Hi Nathan; Hardware flows != OpenFlow flows. OpenFlow is an API. Some reflection on these statements may suggest an answer. Thanks,
== If you hit the limit of number of flows, what happens? Does it reject the flow, or does it delete older ones to make room for it?
Given there is no default route, what happens if you get a packet that doesn't match a flow? Does it drop it, or punt it to the controller? (ie. is there a default flow to drop)
If it deletes older flows, and punts non-matching packets to the controller, that sounds like there's a potential for really bad performance spikes as you approach the upper limits of the flow table.
If it deletes older flows and drops non-matching packets, then that's worse.
If you simply reject new flows, then that's a bit better, but you've got to make sure that the route reflectors never re-advertise prefixes unless they're installed in to the flow tables successfully, or you drop packets, or punt them to the controller as above.
Some interesting issues to consider!
Agreed re. VPLS/etc. - but you've got to make sure your switches have reliable connectivity to your controller(s). In a network like WIX, that might be hard, not sure.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
participants (4)
-
Josh Bailey
-
Kris Price
-
Lloyd Parkes
-
Nathan Ward