Hi David, 

I must admit that I had always thought that the source-routing paradigm in
draft-troan-homenet-sadr-01.txt was backward with the destination address
Longest Prefix Match (LPM) being done prior to the source address lookup.
Rather I think if were going to standardize in the RTG WG, it should be
the FIB organization described in section 3 of
draft-ietf-rtgwg-enterprise-pa-multihoming-01.txt. Note that doing the
source address lookup first  maps directly to the PA multi-homing
use-case. 

Thanks,
Acee 


On 7/19/17, 1:29 PM, "rtgwg on behalf of David Lamparter"
<[email protected] on behalf of [email protected]> 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-rou
>ting.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

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to