Subject: [homenet] Egress Routing Discussion

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 21 Feb 2013 17:22:22 +0000

In Atlanta, Mark asked Lorenzo and I to put together a draft of an approach to source/destination, and especially egress, routing. I pulled together a plan of attack that I applied to both IPv4 and IPv6, and to both IS-IS and OSPF and sought review from a limited list including Lorenzo; this includes capabilities for at least one other use case I'm looking at. Mark asked me to cut that down to make things separately implementable (which they would be anyway, but to make it apparent). So I have broken it into components.

So we have several drafts in play at this IETF.

Shu Yang documented his work in Quagga, in which he implemented source/destination routing as a multi-topology routing model.

http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing
  "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu
  Yang, Jianping Wu, Dan Wang, 18-Feb-13

Ole Troan and Lorenzo Colitti documented their model, which is strictly egress routing based on the OSPF AS-prefix-LSA and the assumption of automated prefix allocation. This is not multi-topology; it in effect tags the default route advertised as a route from an alternate universe.

http://tools.ietf.org/html/draft-troan-homenet-sadr
  "IPv6 Multihoming with Source Address Dependent Routing (SADR)", Ole
  Troan, Lorenzo Colitti, 18-Feb-13

I have documented my approach, which provides the generalized concept, is built into the routing protocols IS-IS and OSPF, and also addresses at least one other "tagged routing" option, which is to look at flow labels.

http://tools.ietf.org/html/draft-baker-ipv6-isis-automatic-prefix
  "Automated prefix allocation in IS-IS", Fred Baker, 18-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing
  "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing
  "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing
  "Using OSPFv3 with Role-Based Access Control", Fred Baker, 17-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
  "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-extensible
  "Extensible OSPF LSAs", Fred Baker, 17-Feb-13

I'll say why I think mine is the correct approach in another email, as I imagine my colleagues will for theirs. But the working group should consider the question.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Feb 2013 13:30:41 -0500

>>>>> "fred" == fred  <Baker (fred)" <[email-masked]>> writes:
    fred> In Atlanta, Mark asked Lorenzo and I to put together a draft
    fred> of an approach to source/destination, and especially egress,
    fred> routing. I pulled together a plan of attack that I applied to
    fred> both IPv4 and IPv6, and to both IS-IS and OSPF and sought
    fred> review from a limited list including Lorenzo; this includes
    fred> capabilities for at least one other use case I'm looking
    fred> at. Mark asked me to cut that down to make things separately
    fred> implementable (which they would be anyway, but to make it
    fred> apparent). So I have broken it into components.

wow, thank you for this reading list.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Ole Troan <[email-masked]>
Date: Fri, 22 Feb 2013 11:25:46 +0100

Fred,

>  Troan, Lorenzo Colitti, 18-Feb-13

to clarify, the SADR draft:
 - describes what source constrained / source address dependent routing is
 - describes a conceptual forwarding model
 - gives two alternatives to how a routers forwarding table can be populated.
   a) implicitly via other information learn from the prefix assignment protocol
   b) explicitly via one of the Baker extensions to routing protocols.

neither a nor b has any restriction to just the default route. more specific routes are supported too.
b allows flexibility to also advertise internal (S,D) routes, and S,D routes not associated with border routers.

I specifically chose single topology.

just to make it clear, I think the correct solution is to add support for (S,D) routes in the routing protocol,
I just don't want to sit on the fence and wait until that support is added and available.

cheers,
Ole

---

From: David Lamparter <[email-masked]>
Date: Sat, 23 Feb 2013 10:19:14 +0100

On Thu, Feb 21, 2013 at 05:22:22PM +0000, Fred Baker (fred) wrote:
[...snip...]
>   "Extensible OSPF LSAs", Fred Baker, 17-Feb-13

While I did not exactly review or even thoroughly read the
-ospf-extensible draft, I did just try to work with it in adding the
null route idea to -ospf-dst-src-routing.  I made these observations:

- the two drafts share the "FIB Design" appendix.  That shouldn't be in
  -extensible I presume?

- the -extensible draft says absolutely nothing about how to handle
  unknown TLVs.  I would suggest adding a bit to indicate mandatory /
  optional status, as done for example with BGP attributes.  I'm not
  sure whether cutting down on possible TLV or length values is viable,
  so maybe a third TLV header byte needs to be added for this.

- the -extensible draft references the source-prefix TLV.  This seems OK
  in general, however in 3.1.1 IPv6 Destination Prefix TLV, "The IPv6
  Destination Prefix TLV MAY be used with the IPv6 Source Prefix TLV,
  [...]" I believe it is somewhat weird to refer to a TLV that is not
  defined in that draft.

Cheers,

-David