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

[David Lamparter <[e-mail]>]

On Thu, Jul 27, 2017 at 05:55:01PM +0000, Chris Bowers wrote:
> 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.

Indeed this fixes pa-multihoming's section 3 to correspond to
dst-src-routing's section A.2.

> 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.

Sure, it's a cool feature to be able to show different perspectives of
the same RIB.  The same, it's nice to be able to install this into a FIB
that is organised in a different way in silicon.

However, we need a non-ambiguous specification for the RIB (and in
extension the routing protocols).  I've had conversations at IETF99 that
consider using BGP to signal an application service provider's service
into an enterprise IS-IS domain.  To make this entire topic work without
huge kludges, we need an uniform understanding of what a (D,S) route in
the RIB means.

I think the pa-multihoming draft is actively counterproductive to this.
It doesn't even specify what a (D,S) route means to begin with, it heads
straight for installation instructions for a source-first RIB.  It makes
no mention that these generated tables aren't what the routing protocol
would advertise;  it lacks all of the larger interaction considerations
that are in dst-src-routing sections 4 and 5.

Basically, I can use pa-multihoming to put together a script for my DHCP
client that makes the appropriate calls to update some static routes and
policies in an enterprise network.  dst-src-routing tries to properly
describe the foundation of an useful dst-src routing system.  (And it
doesn't do so in an arbitrarily limited scope to set off in.)

That said, I will go through the dst-src-routing draft to edit to make
more clear that it is a behavioural specification with (at least) 3
implementation possibilities.  The mails I've been sending today have
made perfectly clear to me that this is not at all obvious from the
draft - it should be.  My bad.

> 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.

Yep, either of the 3 representations, one of which is described in
pa-multihoming, and all 3 of which are in dst-src-routing ;)

(*SCNR*)

> 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.

Absolutely, as long as we're in agreement on what specifically a (D,S)
route in the RIB means.  We seem to have consensus that this is
destination-first with fallthrough, as that's now what both drafts are
describing.

Cheers,


-David