[quagga-dev 11804] Re: zebra dest/src routing support
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
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):
> 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