[OSPF] Extensible LSAs

["Fred Baker (fred)" <[e-mail]>]

As I started at the past IETF meeting, there has been some additional work on extensible LSAs, egress routing, and building access control into routing (which in my mind is primarily useful in data centers). Interested in your remarks.

http://tools.ietf.org/html/draft-acee-ospfv3-lsa-extend
  "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fred
  Baker, 1-May-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing
diff: http://tinyurl.com/ct9wn6g
  "Using OSPFv3 with Role-Based Access Control", Fred Baker, 2-May-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
diff: http://tinyurl.com/ctcshzb
  "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2-May-13

To diff from the previous drafts, if you want one, you want to do this following. This is what the tiny url gets you.
http://tools.ietf.org/rfcdiff?
   url1=http://tools.ietf.org/id/draft-baker-ipv6-ospf-dst-src-routing-00.txt
   &url2=http://tools.ietf.org/id/draft-baker-ipv6-ospf-dst-src-routing-02.txt

http://tools.ietf.org/rfcdiff?
   url1=http://tools.ietf.org/id/draft-baker-ipv6-ospf-dst-flowlabel-routing-00.txt
   &url2=http://tools.ietf.org/id/draft-baker-ipv6-ospf-dst-flowlabel-routing-02.txt

I'll save you one question, though. I get asked frequently why these didn't follow MT-OSPF or MI-OSPF, and commented on this in the meeting in Orlando. The reason is that neither is fundamentally a topology or instance question. MT-OSPF OSPF presumes that some non-null set of links in a topology are either absent from some of the topologies or that metrics differ, so that routes in one topology differ from those in another. This is about qualification of routes - a scalable access list or policy route, if you will. One could integrate it with MT-OSPF within a network, but the most immediate use cases aren't helped by it.

Consider egress routing in a multihomed network, the use case presented by homenet. We have a network with two or more upstreams, each of which allocates a PA prefix to the network. In homenet's case and probably for small networks, The technique described in draft-ietf-ospf-ospfv3-autoconfig-02.txt is used to allocate a /64 prefix from each PA prefix to each LAN in the domain. Links derive their metrics from bandwidth, and might in effect use hop count. So the different "topologies" are identical. What differs between them is that there are multiple default routes, and due to BCP 38 implementation upstream, we want to direct traffic using a given ISP's PA prefix to that ISP. So we want to attach a source prefix to each default (AS-external, most likely, or at least an intra-as-prefix) route. Internal routes, in that case, will likely accept "any" source including external sources, which is to say that they are advertised without a source prefix.

The concept of source/destination routing is extensible to intra-area or inter-area routing as well as egress routing. The use cases are most likely something about security - there is some domain within the network that only certain other parts of the network are permitted to reach. That is, of course, more hypothetical at this point.

As to the use of the flow label, in a multi-tenant data center, that is a *lot* of topologies. I think it has scaling issues. As to Multi-Instance, suppose I put a set of VMs on a LAN that are part of one tenant and another set of VMs in a different tenant. Yes, I probably put them into different subnets. But how do instances actually help me there? They don't, really.

What the SDN folks are doing right now is segregating the network using overlays - GRE tunnels, VLANs, or some such thing. That mostly has the effect of making it difficult for the network to do anything, or to optimize the application in any way from a network perspective. I'd like to keep the application stuff at the application layer and enable the network to support the application. So to my way of thinking, the applications should think in terms of communicating with each other as instances - names, addresses given by some controller, or whatever - and are given those by the controller that created them using whatever protocol it uses. Part of what they are given, one of half a dozen parameters they are already given, is a tenant number for access control to put into the flow label. The controller can similarly configure the OSPF instance on their favorite router to advertise the subnet(s) in question with those tenant numbers. Voila, they have communication that is supported in the network architecture, and with this they are given the communication isolation they're looking for.