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