Matthieu, I believe the tables could be similarly collapsed giving source address higher precedence than destination address. Do you disagree?
Thanks, Acee On 7/26/17, 9:05 AM, "Matthieu Boutier" <bout...@irif.fr> wrote: >Hi, > >David, you're right, and as you remark, the draft says: > >2.5: « It is also useful to note that the prefixes assigned to the site by > different ISPs will not overlap. » > >This hypothesis breaks your example. But, as you, I think that we should >not rely on such hypothesis: it seems error-prone. And I think that some >drafts (including yours) report use cases with overlapping prefixes. > >> Note that doing the source address lookup first maps directly to the >> PA multi-homing use-case. > >Acee, I strongly disagree with that, and that's all the point of section >3 of draft-ietf-rtgwg-enterprise-pa-multihoming. We have routers A and B >advertising respectively (D=::/0, S=2001:db8:a::/48) and >(D=2001:db8:a::/48, S= ::/0). This is exactly two routes. No more. A >dest-src table, like the one in the Linux kernel (IPv6 subtrees) will >handle these routes correctly: > > Destination Source Nexthop > -------------------------------------------------- > ::/0 2001:db8:a::/48 X > 2001:db8:a::/48 ::/0 Y > >Two routes are advertised, the routing table has two routes: everything is >clear. By the way, this is the simplest realistic scenario possible: > > 2001:db8:a::/48 > +------+----…---- R --- ISP > | | > H1 H2 > >So now, how to read this table? If you do source lookup first, *all* your >packets are going towards the Internet, even the one coming from the >Internet… too bad. If you do destination lookup first, everything is ok. > >Now, the purpose of section 3 of enterprise-pa-multihoming-01 is just (in >my understanding) to tell people how to configure their routers if they >don't have native source-specific tables with destination-first ordering. >In that case, you have to deal with policy routing using multiple routing >tables with trafic engineering rules over it. The result is: > > Source Destination Nexthop > --------------- ----------------------------- > (unscoped) ::/0 2001:db8:a::/48 X > > Source Destination Nexthop > --------------- ----------------------------- > 2001:db8:a::/48 ::/0 Y > 2001:db8:a::/48 X # section 3's copy > >However, section 3's method only works with disjoint source prefixes. We >provided a general solution... From a draft cited in this draft: > > [SS-ROUTING] > Boutier, M. and J. Chroboczek, "Source-Specific Routing", > August 2014. > In Proc. IFIP Networking 2015. A slightly earlier > version is available online from http://arxiv.org/ > pdf/1403.0445. > >... and an implementation.... > > https://github.com/boutier/babeld/blob/dev/disambiguation.c > >Section 3 should be more clear about its motivations, and might just be a >reference to David's draft. It's also unclear if it's the role of the >administrator to configure routing or if it's the role of the routing >protocol. Section 3 says « The method described in this document is >intended to be easy to understand for network enterprise operators while >at the same time being functionally correct ». I believe that presenting >plain dst-src tables is much easier to understand. > >Anyway. Also, the first examples of the draft use SADR domains and >"normal-routed" domain, sometimes with tunnels and so on... while saying >that having such topology may not lead to have the best route. I think >that the draft would be improved if it first present the clean solution >which is: *all the network support dst-src routing*. This is what we >really want for the long term. I think that all the discussion of 2.1 >and 2.2 about what if all my routers don't implement SADR should be >moved in an annex named "progressive deployment" (or something like that). > >Matthieu > _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
