Re: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing

["Acee Lindem (acee)" <[e-mail]>]

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" <[e-mail]> 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
>