On Fri, Jul 28, 2017 at 3:55 AM, Chris Bowers <[email protected]> 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:[email protected]] > Sent: Thursday, July 27, 2017 11:41 AM > To: Chris Bowers <[email protected]> > Cc: David Lamparter <[email protected]>; [email protected]; Anton Smirnov > <[email protected]>; Jen Linkova <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg -- SY, Jen Linkova aka Furry _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
