Matthieu, 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.
If anyone thinks that the forwarding behaviors (after the proposed generalization and clarification in rtgwg-enterprise-pa-multihoming) are different, please speak up and provide an example. Assuming that the forwarding behaviors are identical, we can now ask the question: Is it useful to have two different representations of the same forwarding behavior? I think it is. It is not the case that "All the section 3 is about what to do if we don't have native destination-first SADR tables but only policy routing." If the two representations produce the same forwarding behavior, then one should be free to implement using either representation. I think that enterprise network operators are going to have a very difficult time understanding destination-first SADR forwarding tables. Instead, operators are very familiar with simple destination-based forwarding tables. I think that operators will find it much easier to understand and troubleshoot when this forwarding behavior is represented using a set of source-prefix-scoped destination-based forwarding tables. When routing protocols are working properly, it shouldn't matter. But when packets are not going where the network operator wants them to, they are going to want to be able to troubleshoot this by looking at the forwarding tables. Thanks, Chris -----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
