Subject: Re: [homenet] Egress Routing Discussion: Baker model

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Feb 2013 15:35:45 -0500

Fred, I'm not sure that foo-chairs@  needs to be CC'ed on this
discussion?  Having not been through your documents yet...

>This is that separate email. As I start, may I make the most direct possible
>apology to my colleagues with other approaches.

It would be helpful for me if you identified the different approaches.

You have taken an approach that involves extending the LSA of ISIS
(easy according to you) and of OSPF (harder, due to lack of sub-TLV).
The fundamental approach is to flood the set of all link attributes and
then:
   > The route policy is that traffic is forwarded to a stated
   > destination if and only if it also matches the other specified
   > attributes.  

> Which brings us, I suppose, to the FIB. There are many ways a FIB can
> be designed, and I would expect every vendor to do it their own way;
> this is not a matter for standardization. However, to have the
> discussion, it seems important to at least mention some possible
> approaches. In appendices in the drafts, I mention two. They are far
> from the only two; they are two.  

this is completely akin to IPsec's RFC2401/4301's need to provide a
set of functional requirements on the SPD, but not actually specify how
to implement it.... thank you for bringing this up!

> So, I can have a FIB per PA prefix, put egress default routes only
> into the FIBs for their source prefixes, and put every single
> destination route into each FIB. That results in a potentially-large
> number of FIBs, each of which contains mostly-identical
> information. 

Worse perhaps is that the FIB's are mostly optimized to have large
number of routes, and that optimization is mostly wasted here, because
the homenet has perhaps nPA * nRouters subnets + default routes.

Meanwhile, the source address selection process in Linux is mostly
implemented as a linear search, although there is nothing requiring
this.

IPsec 2401/4301 has the same problem, and we would up ordering the SPD
rather than specifying the order of evaluation for the various
longest-prefix-match searches, port and protocol parts of the SPD.
Fortuantely, most IPsec has had such lackluster uptake that outside of
the contrived examples that I wrote as test cases, few ever run into a
situation where two gateways pick different tunnels for traffic in two
directions.   I point to Appendix B of RFC4301 as a way to turn ordered
entries into something that a PATRICIA trie/LPM engine can better deal
with.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 22 Feb 2013 04:54:36 +0000

> discussion?  Having not been through your documents yet...

I wanted them to see that the discussion was happening. They have each asked me to take some time with their working groups. In one case, that will be amusing; I chair v6ops, and ospf and v6ops conflict. Yes, that's a great reason for having a co-chair.