Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]

[Philip Homburg <[e-mail]>]

In your letter dated Mon, 2 Jun 2014 10:17:43 +0200 you wrote:
>On Sun, Jun 01, 2014 at 07:28:12PM -0700, joel jaeggli wrote:
>> So don't asssume that every application needs to be aware of and test
>> for which path is working, not only is that needless complexity pushed
>> up into the stack. let your routers do their job and cease routing when
>> their upstream connectivity is lacking.
>
>Well.  It might not have been your intention, but what you said is very
>clear "we're not going to make multihoming in the homenet case work".
>
>In the case
>
>    host --> router --> ISP A ---->  ISP C --------+
>	       +------> ISP B ---->  ISP D ------> ISP E --> target
>
>where "host" has source addresses A and B, and there is a problem at=20
>ISP *C*, preventing connectivity via A->C->, how exactly is the homenet
>router "router" supposed to *know* that, or even solve it?
>
>OTOH, proper source address failover on "host" to source address B would
>very nicely solve this whole category of connectivity issues - and (by
>enforcing halfway symmetric return traffic via ISP B) would actually solve
>it *better* than BGP routing, which might need manual fiddling with the
>router to remove "ISP C" from the path.

One philosophical question is whether it is the host or network that is
responsible for dealing with such brokenness?

The nice thing about the IPv4 architecture is the split between the network
and the transport layer on the hosts: the network transports packets from
source to destination, occasionally dropping packets, reordering them and 
in extreme cases duplicating them.

The host transport layer retransmits and reorders packets and filters out
duplicates. Host do not know about the network, they just pass packets to 
the default router (or other routers in case of ICMP redirects).

Making the host resposible for good source address selection in case network
failures violates that model. 

If we make the router responsible dealing with failures, then it helps to 
separate mechanism from policy.

I think it would already help enormously if routers could inform hosts in a 
standard way what prefixes do and do not work. One option is to play
tricks with the preference lifetime RAs. But how does that work in the
context of DHCPv6? How do we update DNS? 

For policy, even if you would have to tell a router manually that link is 
broken, it would help already enormously if entire site would then reconfigure
automatically. 

Detecting a broken uplink can be added easily and is a very common cause of
failure.

Beyond that, many different types of pluggable detectors are possible.
If for me, say, github is important, then having a module that can poll a
website regularly would do the trick.

Beyond that having an SNMP interface would allow a separate measurement device
to inform routers about what has failed.