[c-nsp] Rationale for ISIS default origination behavior

[John Neiberger]

This is sort of a follow-up to a question I had a few weeks ago about how
to configure conditional default origination in IOS XR. It seems that ISIS
default origination in both IOS and IOS XR behaves in a pretty suboptimal
way. I don't have a lot of history with IS-IS, so I'm curious about this.

Take this topology as an example:

[E1]-----[RA]------[RB]-----[RC]------[RD]------[E2]

RA, RB, RC and RD are running ISIS. E1 and E2 are external BGP peers to RA
and RD. E1 and E2 are advertising a default. If you want to get the default
into ISIS, we can configure default-information originate on RA and RD.
This seems to work as expected.

Now, imagine that RD loses its link to E2. It loses the external BGP
default in the RIB and now only has a default route in ISIS that it learned
via RC. RD will start sending all traffic to RC, but RC will send all
traffic back to RD because that is the nearest default route.

It makes absolutely no sense for RD to use the ISIS default in its RIB to
originate a default, but both IOS and IOS XR will happily do just that. In
order to stop this insane behavior, you have to configure conditional
default advertisement.

OSPF does not behave in this way. If we were using OSPF, RD would not use
the OSPF default in its RIB to generate yet another default, so the routing
loop between RC and RD would never form.

Is this behavior something specific to Cisco's implementation of IS-IS, or
is there something in the standard that would suggest this behavior? It
seems like an odd choice. You certainly would not recommend to OSPF users
that they go around configuring "default-information originate always" all
the time, so why make that essentially the behavior in IS-IS?

Wouldn't it be more sensible to adopt the behavior of default origination
in OSPF for IS-IS, at least when doing it by using the "default-information
originate" command?

I've been discussing this with some other engineers at work and no one has
any idea why Cisco would implement it this way.

Thanks,
John