Re: [v6ops] Looking for info on IGP choices in production dual-stack networks

[Nick Hilliard <[e-mail]>]

On 06/06/2015 08:17, Mark ZZZ Smith wrote:
> Yet the inclusion of the "Known to work well" information, without any
> implementation or deployment detail, seems to be implying that the choice
> can be so simple that if you don't know what to select, just select one of
> the protocol combinations with a "Y" in that column. Given how critical an
> IGP is to the reliable operation of a network, "staying ignorant" of IGP
> implementation details such as maturity, capacity limitations etc. is
> dangerous.

maybe the root issue we're trying to figure out is what we mean by "Known
to work well".  E.g. ISIS is known to work well as both an ipv4 and ipv6
IGP unless you happen to use Netgear GSM7224 switches, in which case it
doesn't work at all - this hardware flat refuses to forward ISIS frames.

EIGRP and Babel are fine for IPv4 and IPv6 IGP operation but completely
useless the moment you enable mpls, because they're distance vector
protocols and mpls needs a full topology map in order to work.  You could
even argue that there were situations where rip/ripng made sense.  I've
even come across a single instance in my career where rip was arguably a
good choice of routing protocol in a large production network - but do we
really want to push ripv2/ripng as serious general purpose options?  I
doubt it.

Looking at the blanks in the table, I've no doubt that ISIS for ipv4 and
OSPFv3 for ipv6 would be fully appropriate for a production network which
wanted separate IGPs for each protocol for whatever reason (e.g. mpls for
ipv4 but native ipv6).

The "Hard Separation" column can disappear as it's redundant.  If you're
running the same IGP on the same interface to handle two different
protocols, it pretty much a necessity to handle this in the same IGP
instance on each side.  So Hard Separation is equivalent to running the
same protocol on each side.

The "Similar Configuration Possible" column is awkward.  I'm guessing that
this refers to old style and new style cisco ospfv2 configuration grammar.
 Do we really need this?

Quagga OSPFv3 is a bit shaky at times.  Does that qualify as "Known to work
well"?  Quagga ISIS doesn't support MT, so if the rest of the network is
running ISIS-MT, there might need to be a compatibility mechanism in place.

Perhaps as a WG we're heading towards stating truisms here, namely that
(with the potential exception of ospfv3 for ipv4 which is relatively new),
IGPs which carry a particular protocol work well for that protocol, and
that pretty much all competently-written routing stacks can mix-n-match
different IGPs for different protocols without causing problems.

Could I suggest that the existing section 2.3 be dropped and replaced with
either:

1. a couple of paragraphs which state:

- the operator needs to make a choice between whether to run the same IGP
for each protocol or a different IGP.

- it is not unusual practice to run different IGPs for different protocols
and the competence of each routing protocol is often implementation dependent.

- routing protocol choice for IPv6 often boils down to much the same
parameters as for IPv4 which might go from from NOC familiarity to existing
deployment requirements.  There may be caveats, e.g. potentially no
requirement for an ipv6 igp if the network is pure mpls+ldp.

or:

2. an description of each IGP which supports ipv6 with a brief rundown of
capabilities / limitations.

Nick