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

[Gert Doering <[e-mail]>]

Hi,

On Mon, Jun 02, 2014 at 06:49:13PM +0200, Philip Homburg wrote:
> One philosophical question is whether it is the host or network that is
> responsible for dealing with such brokenness?

I'm not so much concerned about philosophy, I'm an engineer.

> 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. 

This theory is very nice.  Unfortunately, it's, uh, theory, and today's
Internet does not really know very much about this.  

It *does* know about budget ISPs that are too cheap to pay engineers to 
properly monitor their network, about de-coupled control and data planes 
that advertise reachability but sink the data packets, extremely overloaded
links between ISPs fighting (de-)peering wars, and other unfriendlyness.

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

In the failure scenario I described, there is no (reasonable) way a home 
router can know that "ISP C" has messed up their MPLS network (again!) 
and it's no use sending packets out ISP A to reach host Z.

Even if it knew, other targets might work perfectly well via ISP A, while
yet other parts are broken via ISP B.  So "withdraw a prefix as soon as
something is broken upstream" will usually give you "zero working prefixes",
given that something is always broken somewhere.


[..]
> 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. 

Please understand that it's not "the link" that is broken, or even "ISP A"
- these cases are trivial, and reconfiguring the site is also quite trivial,
except - to some extent - for externally published DNS records.

[..]
> 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.

Yeah.  I can easily see *end users* do that, or router vendors update their
gear two years after it has been solved to monitor the Next Big Thing on
the Internet.

The *host* knows where it wants to connect to, and that it has multiple
options in case one doesn't work.


Coming back to your example and extending it a bit: what do you do if 
github is broken via ISP A, while netflix is broken via ISP B?  If you 
can solve that with prefix announcements, I'm all ears.  Until then, I
maintain that "dual prefixes with source address failover *plus* a way
to present the prefix selection to the application(!) user" is a more
workable way in that scenario.

(There are a number of ways such a "magic CPE" could achieve the end result
with dirty tricks, like involving NPT66 to circumvent non-working paths, but
I can't see a way to make it work without resolving to those)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: [phone]           USt-IdNr.: DE813185279