David, It seems to me that the example that creates a routing loop depends on having two routes where one non-default source prefix of one route contains the source prefix of the other route
Specifically, S=2001:db8::/32 contains S=2001:db8:ffff::/48. I think that we can resolve the discrepancy between the two forwarding behavior descriptions if we generalize rule #3 from section 3 of draft-ietf-rtgwg-enterprise-pa-multihoming-01 to propagate routes from each less specific source-prefix-scoped forwarding table to the more specific source-prefix-scoped forwarding tables contained in the less specific one. This can be seen as generalizing the rule to propagate routes from the unscoped (S=::/0) forwarding table to the scoped forwarding tables, since they are all contained in the S=::/0 prefix. With this generalization, the forwarding table on B scoped for S=2001:db8:ffff::/48 would inherit an extra route from the forwarding table scoped for S=2001:db8::/32 which contains it. The resulting forwarding table on B scoped for S=2001:db8:ffff::/48 would look as below. So there is no routing loop. - scope S=2001:db8:ffff::/48 2001:db8:aaaa::/48 local 2001:db8::/32 local ::/0 via A Does this generalization of rule #3 resolve the discrepancy ? Thanks, Chris -----Original Message----- From: David Lamparter [mailto:equi...@diac24.net] Sent: Thursday, July 20, 2017 2:42 AM To: rtgwg@ietf.org Cc: Anton Smirnov <a...@cisco.com>; Jen Linkova <fu...@google.com>; Chris Bowers <cbow...@juniper.net>; Fred Baker <fredbaker.i...@gmail.com> Subject: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing Gah, forgot Cc:s, resending to list so replies will inherit Cc:s (please reply on this one to get the Cc:s) On Wed, Jul 19, 2017 at 07:29:13PM +0200, David Lamparter wrote: Hello again, rtgwg, Unfortunately (and possibly contradicting earlier statements I may have made to the opposite), the routing system behaviour described in https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-01#section-3 is not compatible with the behaviour described in https://tools.ietf.org/html/draft-ietf-rtgwg-dst-src-routing and will result in loops in specific cases when mixing implementations. The failure scenario is illustrated by the following setup: Considering 2 connected routers A and B, A implementing dst-src-routing and B implementing enterprise-pa-multihoming. Have: - A advertise D=::/0, S=::/0 - B advertise D=2001:db8::/32, S=2001:db8::/32 - B advertise D=2001:db8:aaaa::/48, S=2001:db8:ffff::/48 B will build the following "scoped tables": - unscoped: ::/0 via A - scope 2001:db8::/32 2001:db8::/32 local ::/0 via A - scope 2001:db8:ffff::/48 2001:db8:aaaa::/48 local ::/0 via A Note that the last scope has no entry for 2001:db8::/32, since item 3. in the first list in section 3 of the draft only prescribes propagating unscoped entries to the scoped table. This leads to a packet with S=2001:db8:ffff::1, D=2001:db8::1 looping between the routers: - router B performs the lookup as: - longest matching scoped table is S=2001:db8:ffff::/48 - scoped table contains route to ::/0 pointing at A - router A performs the lookup as: - most specific destination match is 2001:db8::/32 - under this destination, route with S=2001:db8::/32 points to B => persistent loop. It is my understanding that this discrepancy in behaviour is accidental and the enterprise-pa-multihoming draft is attempting to describe the same behaviour in local wording. Assuming this is the case, I'm unsure how we've ended up in this situation. I've heard the rtgwg-dst-src-routing draft may be hard to understand. If there are specific concerns, I'd ask for them to be voiced so that I can address them. I've checked for such feedback and found none, if I lost any I'm terribly sorry and hope it can be resent. If there are shared unspecific concerns, I suppose I can look at different ways to argue section 3 / 3.1. Still assuming that this was intended to be identical in behaviour, I would hope the mismatch can be addressed in enterprise-pa-multihoming. Looking at, well, the title of that draft, it seems that it's trying to be complete in describing the specific application in multihomed enterprises. This may also explain the specific mismatch in behaviour; it's in fact identical as long as one only considers exit routing with non-overlapping source prefix restrictions. rtgwg-dst-src-routing argues a broader applicability of the idea and tries to be thorough in describing a routing system feature to build on. As such, I'd be very happy to see enterprise-pa-multihoming describing in detail how to apply this feature for its title. Assuming it is _not_ the case that the intention is for these to be identical, we're IMHO heading for a rather bad place. I'd rather not argue this without confirming we're indeed there. Cheers, -David P.S.: rtgwg-dst-src-routing already had a description on how to translate its routes into a form suitable for "policy routing" implementations. The version just posted adds a reference to https://hal.inria.fr/file/index/docid/947234/filename/source-sensitive-routing.pdf which argues the implementation specifics and correctness of this translation in its full mathematical gore ;) _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
