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

On Fri, Jul 28, 2017 at 3:55 AM, Chris Bowers <cbowers@juniper.net> wrote:
> With the proposed generalization of rule #3, together with a clarification that the source-prefix-scoped
> forwarding table should be chosen based on longest source prefix match with the source address of the packet,
> I think we are in agreement that the forwarding behavior described in rtgwg-enterprise-pa-multihoming
> Is identical to that described in rtgwg-dst-src-routing.

I've just submitted -02 version of
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-enterprise-pa-multihoming/
which addresses this persistent loop issue.

(The rule #3 is made more generic and mentions  "less specific -> more
specific source prefix" entries propagation.
The next-hop selection rule is now looks the following way:

"The forward tables produced by this process are used in the following
way to forward packets.

1) Select the most specific (longest prefix match)
source-prefix-scoped forwarding table that matches the source address
of the packet (again, the unscoped forwarding table is considered to
be scoped to ::/0).
2) Look up the destination address of the packet in the selected
forwarding table to determine the next-hop for the packet.
"

I've also updated the example in the section 3 so the unscoped table
is now considered to be scoped to ::/0.

Maybe we need to update the examples in include the case of one table
being scoped to /48 and another one to be scoped to /32...

> -----Original Message-----
> From: Matthieu Boutier [mailto:boutier@irif.fr]
> Sent: Thursday, July 27, 2017 11:41 AM
> To: Chris Bowers <cbowers@juniper.net>
> Cc: David Lamparter <equinox@diac24.net>; rtgwg@ietf.org; Anton Smirnov <as@cisco.com>; Jen Linkova <furry@google.com>
> Subject: Re: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing
>
> Hi,
>
>> Does this generalization of rule #3 resolve the discrepancy ?
>
> It's not enough, because if you have overlapping source prefix, you'll need to change the following.
>
>    1.  If the source address of the packet matches one of the source
>        prefixes, then look up the destination address of the packet in
>        the corresponding source-prefix-scoped forwarding table to
>        determine the next-hop for the packet.
>
>    2.  If the source address of the packet does NOT match one of the
>        source prefixes, then look up the destination address of the
>        packet in unscoped forwarding table to determine the next-hop for
>        the packet.
>
> Basically, you'll have to replace these two points by only one saying:
> "order your entries by prefix specificity (longest match first)".
>
> And… I have the feeling that the routing part is overcomplicated.  It should be as simple as: "put a SADR routing protocol on your network".
> And you're done.
>
> The draft discusses a lot about how to progressively deploy SADR in the network.  This should be put in a "progressive deployment" section, which would essentially say:
>
>   - have a connected SADR backbone including the edge routers,
>
>   - announce a default route from the backbone to attract packets.
>
> It's the role of the routing protocol to be backward compatible with the legacy (non-SADR) version.
>
> Also, about routing tables, section 3 clearly shows that if a packet matches two routes, it should follow the one with the most specific destination.  All the section 3 is about what to do if we don't have native destination-first SADR tables but only policy routing.  I believe it's the role of the routing protocol's implementation to deal with that (that's what we do since 2013).  Then section 3 could probably just be a reference to David's draft, since it only concerns SADR/dst-src/source-specific/etc. routing protocol implementations.
>
> Matthieu
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg

-- 
SY, Jen Linkova aka Furry