Re: failure detection

[Paul Jakma <paul@clubi.ie>]

On Mon, 29 Aug 2005, Erik Nordmark wrote:

> "failed" is about right. The semantics is basically a 
> recommendation to hosts to not use that prefix, and if possible 
> switch to using other prefixes.

Right.

Just not sending RAs (or not including the affected prefix in RAs) 
would achieve same effect though wouldn't it?

I'm just curious what would be wrong with a setup like:

- valid lifetime: very high (say weeks)
- preferred: low, eg 10s or 15s
- RA interval: very low, 5s or so.

If link goes down, just stop sending RAs/including prefix in RAs. In 
15s hosts start preferring other prefixes. For datagramme protocols 
with no kernel flow state (eg, potentially, shim6), the next packet 
after preferred times out would use a new source address.

You would prefer failure to be a positive thing? I think possibly 
that might be hard to ensure. Eg, what if it was not the router<->ISP 
link which failed, but the router<->local LAN link? A positive 
"failed" bit would be tricky..

I'm trying to puzzle out why "lost our link to ISP supplying external 
connectivity for that prefix" would /ever/ be at odds with "Preferred 
lifetime expired".

> But one of the tricky aspects is that the prefix might work 
> perfectly for traffic internal to the site, and it is only external 
> traffic that is effected. I don't know how easy it is to convey 
> that notion to the hosts, since the hosts don't know how large 
> prefix is assigned to the site (assuming it is and always will be a 
> /48 is probably a bad idea).

Hmm, it's probably not useful for hosts to know how far a network 
reaches. Only the routers can really have a notion of that, and 
signal which networks are available via RAs.

> But even if that is the case, we still need to handle the case when 
> the peer host doesn't support shim6.

Yep.

> You mean pinning it to a route for some external prefix? Presumably 
> we want things to work when a site has multiple exits and each ISP 
> just advertises a default route into the site.

In lieu of a dedicated multi-hop prefix-availability protocol for 
routers, there likely are implementation-local hacks which could be 
done. Eg:

- on the borders routers, make advertisement of a high-metric prefix
  covering ISPx assigned address range, conditional on some other
  route (eg, in your example, a default route with protocol X and
  nexthop corresponding to the appropriate ISP's router)

- on all routers, make sending/including RA for that prefix
  conditional on the high-metric prefix being present in IGP.

Bit hacky though.

A dedicated protocol for carrying prefix-availability information 
within an AS[1], not just per-link, would be better, likely. Did you 
say people were looking at that?

1. AS in the IGP sense.

regards,
--
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Drop that pickle!