[quagga-dev 11804] Re: zebra dest/src routing support

Paul Jakma paul at jakma.org
Tue Nov 25 22:08:38 GMT 2014

On Tue, 25 Nov 2014, David Lamparter wrote:

> Please don't call it source routing, theat term is used in SPRING & MPLS 
> contexts.  This is source-specific routing.

People have been using the term "source routing" in a general way since 
long before MPLS ever existed, including at least some of the people who 
went on to author MPLS. No need for newspeak.

>> The primary use-case of PA multi-homing for home/SOHO doesn't generally 
>> require complex, mixed matching: if the source is already fixed to a 
>> certain PA, then your nexthop is fixed to that ISP - no LPM needed; for 
>> the rest (i.e. SAS) a normal dst table suffices (internal, else pick an 
>> ISP, whichever ISP). Quagga doesn't need modifications for this kind of 
>> setup. So, I'd like to see what the use-cases are that need the more 
>> complex joint lookup on dst and src.

> Please look at the IETF dst-src-use-cases drafts and presentations,
> which you can find at

> http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases-01
> http://www.ietf.org/proceedings/88/slides/slides-88-rtgwg-5.pdf

I had read that draft, and re-read it before sending my email. The slides 
don't introduce any new use cases over the draft.

> Particularly the slides should help understanding.

I think I understand the proposed homenet use-cases.

For reference, I have implemented redundant PA-multihomed routing for the 
various site offices across Europe for the corporate I worked for, over a 
decade ago, back when I was a network sysadmin. ;) And that network also 
had private inter-connections to other organisations' networks that needed 
further source routing at times (and other uglyness at times - amazing how 
many networks out there think it's ok to use other people's ranges for 
internal or private-inter-connection purposes; unadvertised US mil. ranges 
are a favourite for that it seems).

The PA multihoming scenario for SOHO and home, with walled garden to 
(e.g.) content providers does not generally require the hybrid, 
dst-then-src route lookup routing table.

So, the question is, what's the use case to justify that complexity?

> In regards to src vs. dst ordering, this mailing list is not the correct
> place to discuss this.  If you have concerns, please take them to
> homenet at ietf.org or rtgwg at ietf.org.

I don't have a need to go to IETF Homenet. I'm stating what would have 
made it easier to integrate the homenet proposal with existing RIBs, to 
someone who is involved with homenet and writing drafts there, and to 
someone who is trying to persuade others (or at least, ought to be) to 
integrate code into Quagga. ;)

> (One of the relevant arguments: src-first will cause massive duplication
> of the entire table for each source prefix that has a default route.)

This is assuming that you're going to have lots of different routes common 
to different source routes. What is this scenario exactly?

In PA multi-homing, once a source is chosen, you have a very constrained 
choice of upstreams, i.e. the ISP that assigned the PA. When will a SOHO 
or home network have a large number of destinations shared between 
different source contexts?

The local networks would be shared between the sources, but those are not 
going to be large for a SOHO or home. Even for a large corporate with a 
European network, the number of shared prefixes still will not be onerous.

The only sources of large numbers of destinations is the outside world. 
But those are ISPs that assigned the PA addresses and whose ingress 
filtering requires the homenet to do source-routing. So those destinations 
then clearly can't be shared between the different source tables.

For the shared prefixes, common to all sources, to be an issue, you'd have 
some kind of very large network, like national ISP size. However, you'd 
have your own address assignment by then.

> Aside from the OSR's own IS-IS development, there are 2 more external
> project that depend on either this code (ss-babel) or need the
> functionality (ospfv3):
> https://github.com/OFabre/ss-babel
> https://github.com/t-routing/traffic-class-routing-system-based-on-OSPFv3
> Since you're voicing no concerns about the code itself, and I've pointed
> out several times that the specifications for this done and it's getting
> deployed, and not merging this will cause significant headache for 3
> external projects, my current position is still to merge this.

I have voiced concerns about the code. It's restructuring a core 
data-structure in zebra, adding complexity, changing APIs, and adding 
commands, for a use-case that isn't well-established yet (in several 
ways). It's not imprudent to see what the demand is before integrating to 

That there are other projects predicated on the same thing doesn't change 

Paul Jakma	paul at jakma.org	@pjakma	Key ID: 64A2FF6A
Stop searching forever.  Happiness is unattainable.

More information about the Quagga-dev mailing list