[c-nsp] Rationale for ISIS default origination behavior

[Andrew Miehs]

On Wed, Jan 23, 2013 at 11:33 PM, Saku Ytti <saku at ytti.fi> wrote:

> On (2013-01-23 23:00 +1100), Andrew Miehs wrote:
> > Your provider (INET) should be able to announce a default for you if you
> > request it.
>
> We don't. We advertise to our customers prefix to which they static route.
> If our PE is disconnected from core, we don't have that prefix to send to
> the customer, so we don't blackhole customer.


So the reason would be to ensure that customers with multiple uplinks but
no full BGP feed survive a failure on the provider side where at least one
of the PE routers connecting the customer looses connectivity to the rest
of the Internet.

Thinking about it a little more - I would probably make a static route
announcement conditional based on the reachability of something inside the
central core of my own network - not some external host.You will probably
also have null routes for 10/8, 172.16/12 and 192.168/16 with similar
issues.

This would cause an issue for those customer should I have a complete
"uplink" outage so I would put more effort into ensuring that this complete
outage can not happen.

As a side note, if you were to use 8.8.8.8 as your "test" you need to
ensure that you do not peer directly with this network.




> > HOWEVER: If we are talking about service provider networks - what is the
> > purpose of your default route?
>
> As it recurses you can use it to your advantage to gain higher level of
> trust of default destinations ability to transport packets.
>
> Gert suggested that you static route in ASBR to your PEER IP.
>
> - static route always valid, if PEER is up. Regardless if it ARPs,
>   regardless if BGP is up.
>
> If non ASBR has
>  a) static to 8.8.8.8 (or any trustworthy, important, stable eBGP)
> and
>  b) static to ASBR anycast (worse admin than above)


Or get your upstreams to additionally announce a default to you - still not
sure I am convinced though...