Re: Partial vs Full tables

["Job Snijders" <job () ntt net>]

On Tue, Jun 9, 2020, at 08:04, Mark Tinka wrote:
> On 5/Jun/20 18:49, Saku Ytti wrote:
> > The comparison isn't between full or default, the comparison is
> > between static default or dynamic default. Of course with any default
> > scenario there are more failure modes you cannot route around. But if
> > you need default, you should not want to use dynamic default.
>
> I've found this to be easier to do if your network is reasonably
> "centralized", i.e., there is one or two (or small handful) of "entry
> and exit" points.
>
> With a stretchy, relatively flat network that neither has a definite
> entry nor exit point, it's a bit difficult to decide which failure mode
> should take the default route away.

A strong case to take the default away is when the PE the customer is connected to has become entirely isolated from 
the rest of the network. This can happen as a result of multiple fiber-cuts, or the classic "oops, all the diverse 
fibers went through that one duct". 

One trick is to have each PE originating a default which depends on a route that comes from another PE (any other PE). 
This way a PE that for whatever reason has become entirely disconnected from the Autonomous System will cease 
advertising default. Make PEs with an odd-numbered loopback address depend on "ROUTE A" and PEs with an even-numbered 
loopback depend on "ROUTE B" - where A is originated only by even-numbered PEs and B is only originated by odd-numbered 
PEs. More advanced sharding strategies can be imagined, many additional failure cases too.

Back to basics: as Ytti suggested earlier in the thread, it might be more sensible to generate your own default route 
based on a 'stable anchor prefix' coming from the ISP rather than accepting the default your ISP originates towards you.

As an example: any NTT customers requesting to receive a default-route from AS 2914, will - in addition to 0.0.0.0/0 - 
also receive a route announcement for 129.250.0.0/16 (2001:418::/32 in IPv6), and if any customer loses visibility on 
129.250.0.0/16 via the direct Customer<>NTT sessions, one probably doesn't want to point default in that direction.

- If you originate defaults to your customers: try to make it so that the default is withdrawn if the node has become 
isolated.

- If you want to point default at a service provider: anchor it to a stable prefix rather than their 0.0.0.0/0 route.

The above two suggestions may seem at odds with each other :-)

Kind regards,

Job