RE: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing

[Chris Bowers <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, July 27, 2017 11:41 AM
To: Chris Bowers <[e-mail]>
Cc: David Lamparter <[e-mail]>; [e-mail]; Anton Smirnov <[e-mail]>; Jen Linkova <[e-mail]>
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