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
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
