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
