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

[joel jaeggli <[e-mail]>]

On 6/2/14, 1:17 AM, Gert Doering wrote:
> Hi,
> 
> 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".

No sorry I did not. What I said is that I believe you're pushing an
expectation of a certain amount of complexity onto hosts in the
interests of measurement and detection of topological corner cases. some
hosts might choose to do that in the interest of improved connectivity,
the expectation that they all should is onerous, you be should have an
expection that devices and applications will work in the absence of HE.

having a router invalidate itself as a nexthop because it has detected
that it's paritioned from a provider or the internet seems like an
incredibly basic concession that you'd want to have happen even were
everything HE enabled.

> 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 
> ISP *C*, preventing connectivity via A->C->, how exactly is the homenet
> router "router" supposed to *know* that, or even solve it?

It doesn't.

> Assuming "as long as connectivity to ISP A is there, the whole Internet
> will be reachable via ISP A" is completely ignoring reality.  Blackhole
> issues happen (where even BGP to the customer router won't help you)...

yes, bgp multihoming doesn't solve it either. that has not rendered it
unsuitable for use.

> 
> 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.
> 
> (IETF is complaining about lack of operator input.  Here is operator input.
> Don't ignore it, otherwise operators get bored and find solutions outside
> IETF space, like, with NAT)
> 
> Gert Doering
>         -- NetMaster
>