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 protected] http://www.sandelman.ca/ | ruby on rails [
pgp0vuPFL81ww.pgp
Description: PGP signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
