Software-Defined

IETF 86 Recap of SDN Related Activities

by pmoyer on ‎03-30-2013 09:53 AM (3,179 Views)

I recently returned from IETF 86  and would like to provide a short update on the SDN related activities. While the ONF  continues to drive standards around OpenFlow and continues to promote SDN use cases and solutions, the IETF is now becoming more involved in SDN related technologies, protocols and standards.

Here is a link to a previous blog where I talked about some standards activity related to SDN. That blog will also provide some background information on various IETF WGs.

MPLS Working Group’s

The various MPLS WG activities focus on many things specific to service provider networks; and interesting enough, there is now becoming a more evident relationship between the various MPLS WGs and the SDN solution space.

For example, in the L2VPN WG there was a discussion of a VXLAN over L2VPN Internet Draft (ID). This would provide layer-2 MPLS connectivity between data center VXLAN or NVGRE logical overlay networks. This is a pretty cool use case and it appears to be a needed solution if VXLAN/NVGRE solutions become more widely deployed in data centers. A somewhat related topic was discussed on how Ethernet VPNs (E-VPNs) could be leveraged to provide a data center overlay solution. In this context, E-VPNs are based on MPLS technologies. While this solution revolves around Network Virtualization Overlays, it was discussed in the L2VPN WG due to it leveraging MPLS technologies. This same Internet Draft was also discussed in the NVO3 WG.

In the L3VPN WG, there were also quite a few IDs that overlap with the NVO3 WG and data center overlay technologies. The general support for MPLS-based solutions for data center overlay architectures appears to be gathering momentum. This is only my personal observation after attending these meetings. But it is interesting to notice that the various MPLS WGs are becoming more involved in data center overlay solutions; often including SDN-like solutions. This makes one wonder where this might be heading ...

Specific to the L3VPN WG, drafts that could be considered related to SDN are VXLAN/NVGRE encapsulation for L3VPNs and the activity around the virtual PE and CE.

While activities in other WGs, such as PCE and ALTO, could also be considered related to the SDN solution space as well, I will discuss those in my SP community blog so please go there for additional details.

The Newer IETF Working Group’s

Now on to the more interesting (and controversial?) WG activities! Of all the WG meetings at this IETF, NVO3 was the most heavily attended. It was practically standing-room only.

As you may recall, NVO3 is focused on the data center overlay problem space and architecture. This is not to be confused with DC “underlay” architectures, such as TRILL. Ethernet fabrics, whether based on TRILL or some other protocols, are considered an underlay technology; while an overlay technology is a logical network construct that leverages the many benefits of Ethernet fabrics.

In earlier NVO3 meetings, overlay technologies such as VXLAN and NVGRE were often discussed; while more recently, a lot of the discussions now include MPLS based overlays. This particular meeting was heavily focused on the charter and framework of the NVO3 WG, rather than what an architecture or solution might look like. I believe what happened here is that there were too many solutions being offered as part of this WG; while a clear definition of the charter and the requirements of the problem space weren’t fully specified and agreed upon. So, this WG has some re-chartering to accomplish with the intent of having an architectural framework and clear requirements defined by the next IETF in Berlin. Lots of work to do here!

Also discussed in the NVO3 and L3VPN WGs was the need for “inter-subnet routing”; in other words, layer-3 routing between IP subnets and/or between logical network overlays. I kept thinking of Vyatta during these discussions.

Another WG that should also be followed by the SDN community is I2RS. Like NVO3, this WG is fairly new. The primary goal of this WG is to provide a real-time interface into the IP routing system. While some could say this activity is not SDN related, I think it’s close enough to warrant a mention here. There is also more on this topic in my SP community blog.

I’ll close this blog out with an update on the SDNRG. Brocade’s SP CTO, Dave Meyer, kicked off the meeting with a high-level architectural discussion of what SDN is really all about.  This thought provoking talk is aimed at helping to “bound” the SDN problem space. SDN means many different things to many different people, so this talk is intended to get the audience on the same page.

A presentation was made on a Software Defined Internet Exchange (SDX) proof of concept. It uses a Brocade switch as the cross-connect fabric! The idea behind a SDX is to use a controller to peer (ie. BGP) in the control plane, and use OpenFlow to instantiate the connectivity (ie. flows) in the SDX data plane. What a cool use case! This reminds me of the early days of MPLS (circa 2000’ish), when an MPLS-based Internet Exchange switch was being talked about and a similar proof of concept was tested. Although that concept did not take hold (all Internet Exchange Points or IXPs are Ethernet based), it helped promote and eventually validate MPLS as a deployable networking technology. Could this SDX proof of concept hold the same premonition for OpenFlow? Here is the diagram from the presentation.

SDX.jpg

A very interesting talk was given on Network Functions Virtualization (NFV). This work is not coming out of the SDNRG, but a fairly new organization called the Industry Specifications Group (ISG) is focusing on NFV. The ISG members are all large service provider carriers. This particular talk was about virtualizing Broadband Remote Access Server (BRAS) and Content Distribution Network (CDN) functions onto an x86 platform. It was basically an “acid test” to validate this can be done and the performance was shown to be pretty good! It didn’t have all the features and functions typically found in a BRAS, but it had enough functionality to validate the network functions virtualization capability.

A mention of the FORCES WG is worth bringing up as it relates to SDN and more importantly, OpenFlow.  A presentation was made explaining how some of the problems the OpenFlow movement are experiencing and working to solve have already been solved in various FORCES activities and implementations. So it was recommended that those folks who are developing OpenFlow solutions leverage the work and experience from the FORCES community.

So, that wraps up this short update on IETF 86 activities that are related to the SDN solution space. I hope you found it useful. And don’t forget that the ONS event is coming in April!

Onward to the SDN-enabled cloud …

Comments
by brent4
on ‎03-30-2013 08:24 PM

Thanks for the summary. Curious what Meyer was getting at when talking about OF multi-table pipeline being too complex, not implementable in HW, no architecture etc. He was hinting at I2RS overlays. Would like to hear more details on thoughts on either working to solve, what sounded as OF being a failed abstraction. I2RS is pretty narrow comparatively to OF, few of us would like to hear more of Brocade's OF thoughts since Vyatta obviously leans towards a fully distributed CP.

Respect,

-Brent

by
on ‎03-31-2013 06:48 PM

Brent,

Thanks for your comments. I can't speak for Dave but part of his talk was about the concept of "failing quicker"; which is orthogonal to OF. Regarding OF though, did you read Curt's blog (just prior to this one)? I think the industry is coming around to the concept of OF possibly being "too low level". Please stay tuned as Brocade will have some interesting things to say in the very near future regarding Vyatta and its ties to SDN.

by dmeyer
on ‎04-01-2013 09:55 AM

Hey Brent,

There is a long history of the problems of mapping OF 1.1+ (so any of the multi-table variants) to conventional ASIC h/w. The basic problem is that the Match-Action-Table (MAT) model frequently doesn't match what an ASIC has implemented. For example, a typical network ASIC (contrast NPU, flow processor, these are really software) generally has purpose built hardware for MAT (frequently an "ACL TCAM"), L2 CAMs, Longest Prefix Match hardware for L3 fowarding and uRPF processing, etc. These tables are generally connected in predetermined combinations.

In addition, the current OF abstractions are what we call "lossy" (since they lose information in one direction or another). For example, currently the controller has only limited ability to tell an OF switch that say, a packet is an L3 packet; that information is "lost" in the communication from controller to switch. Going the other direction (switch -> controller), the abstraction is "leaky". That is,  in order to use ASIC h/w the switch platform has to "leak" information about the switch (h/w) implementation to the controller if it wants to use the ASIC h/w (and it will have to do it in a non-standard way). For example, consider MAC learning and MAC forwarding. These are typically implemented in a single table with learning using <src port, src MAC> for lookups and forwarding using <dst port, dst MAC> for lookups. Now the question becomes how to represent this in OF. Well, that is pretty difficult if not impossible because OF has  currently has no concept of shared tables (to be fair, there is a proposal in the Extensibility WG to address this, sort of). In any event, in order to use the ASIC the Hardware Abstraction Layer (HAL) on the switch would have to receive the flow_mods for the various tables and somehow decompile the intent of the controller writer, which suffice it to say isn't possible. So the controller writer generally sits down with the manual for the ASIC and builds platform specific code (i.e., a "driver") into the controller. This of course is undesirable for many reasons. Another shared table example would be LPM and uRPF processing (they frequently use the same table).

A year+ ago the Google folks came along with a pretty elegant and functional proposal for what they called OpenFlow 2.0. There were many reasons why this proposal wasn't accepted but to solve these problems you have to move in that direction. The ONF's FAWG is chartered to make a small step in this direction (in particular, by adding table typing; this is what TTPs (table typing patterns) are all about). However, if you step back and look at this what you observe is that it is converging towards something that looks very much like ForCES over in the IETF.


So the switch model in which you have some number (< (2^8)-1) of undifferentiated tables connected in arbitrary  ways is hard to map to today's ASIC h/w (note that there is a goto instruction that allows jumping around in the tables as long as the table index is monotonically increasing, but this also happens at run-time which makes the HAL's job pretty tough). I mentioned that the number of paths through such a design is O(n!), which is not a term you want to see come up in your analysis of the complexity of the model. There are ways to constrain the number of paths and in fact TTPs are an attempt to further constrain the number of possibilities.


Regarding I2RS, the idea here is to make the existing control plane more programmable *and* provide better feedback to applications. In this case you use the RIB as an arbitration engine to get around the problems that exist when you have integrated (non-Ships-In-The-Night) control planes. There is a lot of work left to do on I2RS (and BGP-LS, ALTO, ...) however these approaches show a different promise, notably, that of bringing increased programmability and visibility to the {control, data} plane in an incremental fashion.


Finally, none of this is to say that OpenFlow won't find a place in networking (as we've seen). And one of the really fantastic things about the OF/SDN movement has been all the wide-open thinking about new ways of doing things and of new applications. I only see that as continuing and picking up momentum. That said, there is still work to be done.


Hope this helps. Let me know if I can expand on any of this or if there are other questions you may have.


--dmm




by
on ‎04-08-2013 04:35 PM

Just thoiught I'd add this link to more information about the OpenFlow SDN Exchange -

http://searchsdn.techtarget.com/news/2240180812/An-SDN-exchange-is-born-What-does-this-mean-for-network-interconnect