Agenda: http://tools.ietf.org/agenda/87/agenda-87-sdnrg.html

Slides: http://trac.tools.ietf.org/group/irtf/trac/wiki/sdnrg

Scribe: Carlos Pignataro

#
#       SDNRG Agenda (IETF 87)
#

Software Defined Networking Research Group (sdnrg)

Monday, Morning Session I 0900-1130, Potsdam 3

CHAIR(s): David Meyer   <dmm@1-4-5.net>
          Nick Feamster <feamster@cc.gatech.edu>

AGENDA

Administriva

Dave:

• We have a full agenda, I want to steal a couple of minutes for some agenda items.
• Nick cannot make it, and so does someone else. We had a full agenda but now we have extra 15 minutes. We have time at the end, I know Tina had something wanted to share at the end.
• Mailing list:  https://www.irtf.org/mailman/listinfo/sdn
• Web:           http://trac.tools.ietf.org/group/irtf/trac/wiki/sdnrg
• Scribe (text/jabber)? Thank you Linda and Carlos
  
  
  
  

Agenda Bashing

• If someone has Agenda Bashing items, please do that now.
• I have the presentations in my laptop but feel free to use your own
• I will move Ed's I2RS talk to second.
  
  
  
  
  
  

Novel Applications for an SDN-Enabled Internet Exchange Point
Laurent Vanbever <vanbever@cs.princeton.edu>

• Thank you for being here, I will talk about deploying SDN in Internet Exchange Points.
• Why? To fix BGP -- notoriously hard to manage. 
• BGP has 3 limitations:
  • Routing: It assumes everything is destination based. You can use PRB or IGP Multitopology -- but that's a bunch of tricks.
  • BGP policies applied in BGP sessions by design. Sometimes you want to affect end-to-end paths
  • BGP gives you only indirect control of forwarding paths.
• SDN can help you here. Because it uses every packet heared field, and has direct control
• From a deployment perspective, IXPs are ideal. Greag impact even in a single IXC.
• IXP Primer: large L2 domain where BGP is used.
• What do we do?
  • We replace the switch for an SDN switch, e.g., OpenFlow.
  • Replace the route server with a controller.
  • We want to be compatible with existing technologies.
• Policies use high-level language
• Policies collected in the controller, isolation and correctness.
• as a result, OF rules pushed
• What can we do now that we could not do before?
  • novel interdomain applications: security, forwarding optimization, etc.
• Novel Apps: TE, Upstream DDos Blocking, DNS-based wide-area Load-balancing
  • Doing some of these things is CCIE-level question for BGP config.
  • Using RPKI, for your prefix, block closer to the source
  • With SDX, it's faster (no problem doue to DNS caching) and flexible (any LB algorithm)
• We have running code, and partnering with an IXP in Atlanta.
• Challenges: Need authentication mechanism. Everything can be done in BGP we put in the route server.

Questions:

• Jamal: If I own a prefix, is the only thing I can do is drop? If I can reach through underneath BGP, how do you know I am not creating problems?
• Laurent: When you see AS_PATH, there is no guarantee that will be the path. So we are not creating a problem. Creating a new access mechanism for the problem. It's a challenge, we are aware and working on it.
  
  
  
  

I2RS and SDN
Alia Atlas <akatlas@juniper.net> 
Edward Crabbe <edc@google.com>

• Dave: Talks trying to connect what the IETF and other standards orgs are doing.
• Ed: THis is a short intro to I2RS, and invitation to the research community to participate with us.
• New WG, 4 months now. Aggresive schedule. We are defining use cases requirements for info models and such. People are also doing their own set of protocol development, plus vendors moving as well.
• I2RS to dynamically augment routing. Temporally and with application awareness.
• People say "this is like OpenFlow". It does but difference is that we are leveraging the RIB management infrastructure in routers. This is more general. OF focused on forwarding plane, sometimes to its own detriment. Here also individual routing protocol RIBs (e.g., change BGP policy).
• This is like model-based networking.
• Model for what Routing? We are looking at a lot, even when the charter is pretty constraint. BGP models, Topology models, RIB models.
• Topo model is interesting because it is like a Northbound API towards a Controller.
• Use existing distributed protocols to get topology -> An on-ramp to SDN.
• We can also program ephemeral state for dynamic protocols. This is a door into SDN.
• We have targetted use-cases. We want to hear more opinions.
• I2RS enables hybrid SDN. Load-balancing, FRR, etc.
• There is clearly overlap. In developing this protocol, we should not set turf with protocol definition -- we should collaborate.
• These are tightly-constrained use cases.
• E.g. of overlap: I2RS and PCE -- stateful PCE can create LSPs.
• I2RS can create FECs
• Summary of drafts

Questions:

• Alia: the WG is getting to the point of examining protocols and data models. I'd like to encourage people to get the concept of I2RS, plug into multiple layers of the routing system, and see what you can do if you dynamically interact with the RIB.
• ... need for speed is fast; think about what a protocol needs to do. From a research perspective, are there things we are missing (incl. protocol, data model, correctness)?
• Nitin B., Juniper: there is a lot of synergy in this talk and the previous talk. You can get a copy of the topology and then use SDN to manage. You can get a lot of info using the I2RS RIB.
• Ed C.: We have a RIB model submitted to the I2RS WG. I'd posit that you can do some OF using that model, just to be incindiery.
  
  
  
  
  
  

Time-based Updates in Software Defined Networks
Tal Mizrahi <talmi@marvell.com>

• This is Tal, this is WIP, I represent two orgs.
• Time is used in many apps for years, incl. Network Management.
• Accurate time has been considered hard to implement and expensive -- but that's changing. SDN is the key change.
• This work suggests to use time as a tool for network udpates and reconfiguration.
  • This includincludes coordinated updates.
  • sequence updates.
• Example use case: Transition time during config update. Naive approach, send the change to every node, and nodes can change config. But the problem is inconsistency in which at some point, switches use old config while others use new config.
• New idea: Use time to perform update in the network. Assumption: All switches have time scynchronized +/1 Delta.
• Sequential updates -- we can mitigate the issue with a make-before-break approach. We can create a Sequential TimeConf
• Another example: Port rate reconfiguration.
• Trade-off betwen consistency and simplicity. At the lower right side "best effort", at the top left side "consistent updates". In the middle we have the two time-based approaches (Sequential TimeConf and TimeConf)
• We presented an extention to OF presented at ONF. We are presenting a time extension to NETCONF.
• This work presents a tradeoff between consistency and simplicity.

Questions:

• From a research perspective, there is research on time. Is there anything new that is SDN-specific here from a research perspective
• Tal: Usage of time exists. Now in SDN as a new architecture, the usage of time may help.
• Navin: You say you are simplifying but you do not use acknowledgements, so there is a worst case.
• Tal: We are saying that "Sequential TimeConf" we are not using acknowledgements and that's an advantage for simplicity. Naturally you can use time with acknowledgements, but it is less simple.
• Jamal: We added transactional two-stage commits tp solve this problem. However, experience has shown you can solve it with update from leaf to root and people do not use two-phase commit.
• Tal: That sounds similar to what we shown in slide 12. Go from leaf to root and it works.
• Jamal: Is that sufficient?
• Tal: not totally. That's a trade-off.
• Alia: Concern: presicion of timing and assumptions. No microsecond presicion if you say "within a second". I am concerned if this is an optimization. There is a research gap in granularity of time you are using. Concerned with feasibility.
• Tal: We are analyzing various degrees of accuracy. Smaller the delta smaller black.
• Alia: FRR and microloop avoidance. If routers would all change at *exact* same time, but that's not practical.
  
  
  
  
  
  

Formal verification for software-defined networking
Myung-Ki Shin <myungki.shin@gmail.com>

• Compiler-based SDN. Compiler translates high-level language into low-level instructions. (Source: Kireeti Kompella)
• Why should we verify? to check consistency and safety of the network configs on virtual and physical resources. E.g., no loops, no blackholes.
• SDN-specific properties: OF rule, dynamic info/stats. and legacy proto (STP) consistency
• Approach: formal verification (i.e., the semantics are formally defined)
• VeriSDN tool set presented on slide 7.
• CPS (Cyber Physical Systems) vs. SDN:
  • in both, sofrware is the key. There are same issues on verification software and its modeling.
  • ACSR developed for CPS verification (formal language with notions of Resource, Time, and Priority)
• pACSR is packet-based ACSR (packets passed as value)
• Slides 17-18 briefly showed the architecture and development environment.

Questions:

• Dave: Have you worked with Jennifer at Cornell?
• Mying-Ki Shin: We tried but not yet.
  
  

Secure and dependable Software Defined Networks
Fernando Ramos <fvramos@di.fc.ul.pt>
http://fvramos.at.di.fc.ul.pt/files/2013/07/hots067-kreutz.pdf

• I am a professor at University of Lisbon and working with Diego Kreutz and Paulo Veríssimo
• SDN can be used to secure your network.
• I will not give you context of SDN, there are many definitions, but in short, CP/DP decoupling and logical centralization let you "program your network" instead of "configure your network"
• Wait -- *others* can also program the netwrok.
• Traditional networks have "natural protections" that do not exist in SDN
• We identified some threat vectors. I do not mean that SDN is "less secure", it is different. So solve problems differently.
• 7 Threats:
  • Forged or faked traffic flows -- this can be a door for augmnenting DoS. Solution: IDS
  • Attacks on devices (switches) thempselves. Not specific to SDN, but impact augmented. Autonomic ways to mark a node as trustful or untrustful.
  • Attacks on control plane communication (OF messages) -- TLS is not enough. Flaws of OF security
  • Important: Attacks on the controllers and vulnerabilities in controllers.
  • Relationship of network apps and controller -- no way to ensure trust between these! Solution: autonomic trust management.
  • Attack on admin stations -- not new but augmented potential.
  • Lacks of trusted resources for forensics and remediation. Solutions: secure logging.
• How can we design SDN secure & dependable by design?
• Example: 
  • one controller, or 
  • multiple instances of a centralized controller (replication on the application). But switches can connect to different controllers. Master-slave controllers. We need something to distribute the data East-Westbound API (data distribution service) -> E
    • ach controller has full view of the network
    • diversity of controllers: use Floodlight, Nox, and Open Daylight
• Build SDN by design with security. Diego (my student) will present this work on HotSDN 2013.

Questions:

• Dave: Sorry, we cannot take questions, we are late.
  
  
  
  

Impacts of source routing/MPLS label stacks on SDN convergence
Peter Ashwoodsmith <Peter.AshwoodSmith@huawei.com>
http://tools.ietf.org/id/draft-sin-sdnrg-sdn-approach-03.txt

• We want to show results of research on scaling SDN. There are many slides, I will go straight to simulation results.
• We simulated a 36 node SDN network, and implemented trafitional OF with a source-routing forwarding mechanism. 
  • Green line is traditional centralized OF, and red light is Segment Routing OF.
  • We see a 3x improvement.
  • This is where the performance improvements come (from source routing), this is very similar to Segment Routing.
  • So substantial performance improvement with Source Routing.
• We played with the location of the controller.
  • Using source routing, sensitivity is reduced by 86%. Much smoother using a not hop-by-hop forwarding.
• Scale, what happens if we go to large diameters? Multiply to change radious of the network.
  • Convergence time of Source Routing vs. Hop-by-hop forwarding. We saw the curves in Slide 7.
  • SR -> Doing work in the edge -> circumpherence
  • OF -> Doing work in the surface -> area, all network.
  • We divide area / "Sir Cumpherence" and see this
• With Source Routing, not necessary to have time sync.
• Some of us working on protocol oblivious forwarding -- much richer set of actions.

Questions:

• Ed: It would have been nice to see density in slide 6.
• Peter: I will be happy to.
• Ed: There seems to be a sinusoidal pattern
• Peter: I do not know -- students did the simulation, happy to deep dive to tease out additional info. THis is intial, quite promising.
  
  
  
  

LISPflow: a SDN enabler"
Alberto Rodriguez-Natal <arnatal@ac.upc.edu>

• This is not an extension or a new protocol.
• Quick intro on LISP -- separattes Endpoint IDs (EIDs) and Routing Locatiors (RLOCs), with map-and-encap approach.
• LISP as an SDN enabled.
  • In LISP, control (mapping system) and data (xTRs) already decoupled.
  • Therefore we can use LISP with SDN
  • LISP provides scalability, centralized network state (because all the network state is stored in the mapping system), and inter-domain (you can use LISP interdomain stuff as it exists today.)
• All these LISP elements exists, we are not asking for extensions.
• What is LISPFlow? Optimizing LISP to be used based on flows (flow == 5-tuple)
• Configuration and Management -- we can use any of the existing proposals.
• The name space of LISP is extensible, so you can use a new one.
• This is not theory, we have running code. We have LISPFlow on top of the open source Linux implementation of LISP.

Questions:

• Jamal: How much updates do you do to the controller?
• Alberto: In the typical scenario, you do not need to modify your network, you update your mapping system
• Jamal: One per flow?
• Alberto: Not necessarily.
• Jamal: Give me a number
• Alberto: I do not know.
• Jamal: Dave, you are the LISP Guru :-)
  
  
  
  

Update on NfV and how it fits with other I{E,R}TF activities
Diego R. Lopez <diego@tid.es>

• Setting the ground. Network Function Virt is moving firewall and functions into virtual modules, and codifying as much as possible,
• Moving everything to the cloud.
• We have found with our experiments that current Cloud infra are not suitable for moving these functions to the cloud.
• Goal: decoupling software from hardware and having virtual functions where you deploy in a high-scale cloud with common storage and lots of switches, and manage from a central controller.
• Having resuability in space, you can enhance reusability in time. Translates in reduce of CAPEX (cheeper hardware used longer) and OPEX (reducing cost of management, people, skills, etc).
• We starting talking about it, so we created something more relaxed than a WG in ETSI with open membership (need to be member of ETSI). An ETSI NFV ISG (Industry Specification Group, more relaxed than a WG).
• We try to operate by consensus. Members of ETSI just sign an aggrement, which really is about IPR similar to the IETF's Note Well.
• We want to create white-paper-like outputs to send to standards bodies.
• So far...meeting in Bonn where WGs were established (Architecture, Traversal, E2E, goal oriented to PoCs). Operators need to demonstrate the principles (in publicly accessible labs or experimental networks).
• Use cases: what the IETF calls "Service Chains", network function virtualization (NfV) in mobile networks.
• Key for NfV to deal with the network at two layers: Infrastructure, and virtualized network services. This requires a powerful abstraction tool providing orchestration, and relating it to the real network (attachment points).
• So for IETF: SDNRG, ForCES, I2RS. Direct connection to service chains.
• Use cases: CDN, Home Environment
• Why not think about a "Virtualization Considerations" section in many docs?

Questions:

• B.K: Diego, you mentioned Network functions that you do not want to vertualize (or cloudify)
• Diego: No, I said: when I am talking "Cloudify", it is not about the current clouds. We have to change the Cloud Infra to be able to support those functions. Those are mostly related to the Data Plane. You can now move Service Plane and Control Plane. But our experience is that moving functions related to the DP pay an extremely high penalty.
• B.K: 2nd question: Which other orgs are you working with besides IETF.
• Diego: We've been formally contacted by BBF and TMF, plus we are talking with others. We are happy to find who to get engaged with.
  
  

Dave:

• Sing blue sheets, thank you very much!
  
  

Applauses, and EOF