The Internet Exchange points ONF iSDX webinar Q&A post dives deeper into the subject matter and gives presenter Arpit Gupta & the rest of the ONF & iSDX team the chance to answer questions from the audience.
For dropping DDoS traffic at IX point, first of all, DDoS traffic needs to be identified. Identification could be tricky. If erroneously legitimate traffic is dropped, managing the situation could be tricky. Will IXs be ready to take this responsibility? Have you done any studies/research around this?
iSDX: The example we discussed talks about detecting DDoS attack traffic at victim’s end. The victims themselves and not the IXPs make the decision on what traffic to drop. In fact, some IXPs are already offering this service to their customers. SDN-based blackholing will be more fine-grained—ensuring minimal collateral damage. Check this paper for more details on current state of IXPs blackholing service
In regards to security, what is in place to prevent malicious intent with regards to traffic forwarding?
iSDX: It is possible for some remote network to make malicious forwarding request. For this reason, we plan to integrate network authorization platform called FLANC with iSDX. The idea is that we will use FLANC to only allow authorized network action (forwarding, dropping, etc. ) requests in the data plane. See this paperfor more details.
Currently, BGP route table is so huge, and its forwarding is such complexity. We can say, can SDN-based solution essentially reduce the complexity of data-plane or control-plane? How to reduce it?
iSDX: Please read the sections on reachability encoding in the paper. We believe multi-field encoding technique, described in the paper can also be applied to reduce forwarding table entries in non-SDX environments.
Can iSDX help us to use more than one controller in SDN?
iSDX: Yes. BGP-FS had been doing all of presented for a long time DDoS use cases. Are there any tests done from BGP convergence perspective?
Nick talked about convergence during the webinar. Please read our papers for more details
With the SDN controller updating all the forwarding tables, have you considered compressing the headers with a shorter VCE which would increase the capacity of existing memory?
iSDX: No, we have not considered this option. I am not aware if this feature is currently supported in SDN devices. We can dig more on this. However, if the compression is not three orders of magnitude (which looks highly unlikely), then it will not help us much. See the paper for details.
You talked about data plane scalability as a major challenge. Does that mean that the control plane is highly scalable to handle tens of thousands of unique flows, along with the policy management and topology visibility?
iSDX: The paper covers this in greater details. We designed iSDX control plane in a horizontally scalable manner and demonstrated that it can handle a typical control-plane workload reasonably well.
Do the IXP participants need to change anything from their end if an IXP is transitioned into an iSDX?
iSDX: No, the IXP members are not required to make any changes if their IXP deploys iSDX. Though, if they want to express their SDN policies in the data plane, they can use the programming interface (or UI) to do so.
What is the migration path for traditional IXPs (non-SDN) to move to SDX? Any migration test results that can be shared for brownfield IXP migration?
iSDX: We currently don’t have any results on the migration path. However, we plan to get some test results on this over the summers.
Does it work with IPv6?
iSDX: Yes, the idea and design works with some modifications also for IPv6, but so far we have only implemented IPv4 in the platform.
Arpit, in your results, what dictates a minimal number of forwarding entries (optimal)?
iSDX: Please read the paper for details. In short, we modelled policies for the IXP participants and the minimum forwarding table entries required to express participants SDN policies is shown as optimal. We cannot have table size smaller than this value.
Could this be an alternative to the TE functions that e.g. Google B4 does in its WAN networks?
iSDX: This can be one way in which WANs like Google can implement their TE policies.
I have experienced that providers do not like someone else telling them how to forward traffic, which makes traffic engineering hard. Have you had to deal with this in the exchange environments?
iSDX: No, so far we have not faced this issue. Note that in iSDX, participants (ISPs) can independently express their inbound and outbound TE policies w/o any reliance on the IXP operators.
What protocol is used to have a router forward traffic to Router B, or C1 or C2? Are these regular BGP updates from the route server that allow for more flexible rules, or is OpenFlow required?
iSDX: A, B, and C establish regular BGP session with each other. iSDX controller applies A’s and C’s SDN policies on top of their default BGP ones. To enable such fine-grained traffic control we require SDN devices in the data plane.
Will we be able to get any Application Performance statistics out of iSDX?
iSDX: For now, iSDX does not provide any statistics capabilities.
Please read our paper for details on some SDX applications’ performance.