Re: failure detection

[Erik Nordmark <erik.nordmark@sun.com>]

Paul Jakma wrote:

> > But here is where the out-of-the-box behavior of the hosts doesn't 
> > match your expectations. The host will pick a source address that is 
> > appropriate for the network interface,
>
>
> Right.
>
> > but apart from that there isn't any correlation between the source 
> > address and the 1st hop router it is using.
>
>
> In practice, there likely is a very strong correlation between the 
> output interface and the address(es) on that interface, the latter of 
> which were used to decide which interface is appropriate for the chosen 
> next-hop. So in practice, there's a very strong correlation between 
> next-hop used and source address selected for addr-any sockets sending 
> packets that will go via that next-hop.

My point is that the correlation is for the chosen interface. If there 
are two different first-hop routers out the same interface, then which 
router is used does not effect the next-hop.

So I think we are in violent agreement on this one.


> Tunnels between routers in the /same/ IGP AS does not seem ideal. Just 
> distribute the required source-routing information to those routers 
> which need to be aware of it, eg using Opaque-LSAs. Have each border 
> router originate a "I am a packet-sink for address-range X" LSA. Would 
> require OSPF though - which isn't ideal.

Even if you extend your favorite IGP to carry information that helps the 
routers do source address based exit selection, it would be nice if you 
didn't have to fork-lift upgrade all the routers in the routing domain 
to know about this new feature.

Having the exit routers implement the new IGP thingy and encapsulate the 
packets across any routers that are between them means that the non-exit 
routers don't need to route packets on the source address.


> > This could be combined with some automatic protocol by which the 
> > border routers can inform the interior routers of which prefixes have 
> > failed, and the interior routers can advertise that in their RAs. 
> > (Something like an extension to RFC 2894 "router renumbering protocol" 
> > could be made to work.) However, such a protocol requires some 
> > security configuration, otherwise anybody on the Internet could use 
> > this to reconfigure the RAs your interior routers send.
>
>
> One would hope this would this be a link-local protocol at least.. 
> preferably with an HMAC or IPSec AH.

I don't understand how a link-local protocol can be used to carry 
information from a set of border routers to all the routers in the IGP.

> > Thus I don't think we can assume that some such, not yet invented 
> > mechanism for propagating information from border routers to interior 
> > routers, exist.
>
>
> > This leads me to conclude that we can't assume that source address 
> > selection can solve the ingress filtering interaction.
>
>
> I disagree with this. Just because the required router protocol 
> infrastructure does not exist is not a good reason to try bypass 
> developing such infrastructure.

Develop all you want; I have no problem with that.

My problem is that you want to assume that what you've developed must be 
deployed in order to deploy shim6. I think shim6 should be deployable 
with just two hosts on the Internet being able to speak shim6, and not 
require that the IGP domains those hosts are in have deployed some new 
IGP and/or router renumbering protocol.

> If there's customer demand for IPv6 multihoming (eg cause of shim6 ;) ) 
> and then customers require facilities for steering packets to right ISP 
> according to the source, and require a way to reflect 
> prefix-availability AS-wide, the router vendors will respond.

Still doesn't make the customer's deploy it. If we want a solution that 
can be easily deployed then ideally it should only require touching one 
box in the Internet. We can do multi6 solutions with that property as 
long as it is acceptable that connections fail and need to be restarted; 
when new communication starts a host can be made to try the different 
destination and source addresses until it finds a working one.
But if we want connection survivability, then we must at a minimum touch 
the two hosts at the end.
I'm arguing that *requiring* that more than those two boxes are touched 
(upgraded to some new software, reconfigured, etc) is a bad idea.
Making shim6 work better if additional boxes are touched is fine.

> And surely it's more sane to have border-routers be able to affect which 
> prefixes are posted as 'available' by interior routers within an AS, to 
> the hosts *before* they ever try pick a source?

I think it is a useful optimization, but we shouldn't make it be a 
requirement that such technology is deployed before shim6 can be deployed.

> That prefix-propogation protocol could, at the same time, be used to 
> install the required source-routes in the routers concerned to direct 
> the packets to the border-router appropriate for the prefix concerned.
>
> That seems achievable and also more proactive and sane than having hosts 
> sending a multitude of packets with every combination of source and 
> destination they have to hand, simply for the reason that "well, the 
> routers don't have that mechanism yet".

When there is a deployed mechanism to convey failed prefixes to the 
hosts, then the effect will be that the hosts will not try the source 
address that are known not to work. Thus as such a mechanism is 
deployed, shim6 would more rapidly find a working address pair.

You seem to argue that shim6 should not be allowed to have the 
capability to explore all n^2 address pairs, which doesn't make sense to 
me. Having that capability is useful to remove the constraints on the 
order of the deployment of shim6 and source-based routing, and the end 
result is still an efficient exploration of the possible paths to which 
shim6 can failover.

> I don't understand why a protocol for /tomorrows/ networks should be 
> trying to hack around a lack of functionality in /todays/ interior 
> routing, when the correct place is obviously to extend capabilities of 
> interior routing (and IPv6 RAs).

Deployment considerations.
As well as the end2end argument; the network can't reliably indicate 
which address pairs are known to work and which are not known to work. 
As a result the hosts must be prepared to explore the different address 
pairs when the current address pair is no longer working.


> > Did it work without any manual configuration of the host?
>
>
> *hosts*, and yes it did.
>
>    ISP1-gw  ISP2-gw
>         |    |
>         |    |
>         R    R
>         |    |
>      -----------
>       | | | | |
>        <hosts>
>
> The hosts were configured with an address for each PA range, the routers 
> did the magic.

Ah - I should have asked "did it work without any manual configuration?" ;-)

   Erik