[c-nsp] Rationale for ISIS default origination behavior

[Saku Ytti]

On (2013-01-23 10:16 +0100), Adam Vitkovsky wrote:

> What I meant to say is that "is receiving at least this prefix" and " hoping
> the edge works" is all we have right now to make a decision whether to
> originate a default route. 
> I still lack the BGP table/routing table credibility check before that
> particular node originates/advertises a default route. 

Right. Then we might be venturing into enterprisy PfR domains. If we want
something practical to deploy in multivendor SP network today and past 20
years, recursive static routes FTW.

Maybe some sort of next-hop-group could offer more robustness without very
high complexity, where you'd only choose next-hop if N networks all recurse
to same destination. Then you would choose given ASBR edge only if it
contains each of your critical destinations.
But introducing lot of complexity to deal edge cases, it's unsure which
happens more often, the problem you're trying to protect from or problem
caused by the complex setup.

If folks today are just relying on ASBR peer interface being up, which is
really poor indication of functionality, they're getting so much better
quality by pinning to some EBGP prefix.

-- 
  ++ytti