Re: failure detection

[Paul Jakma <paul@clubi.ie>]

On Tue, 30 Aug 2005, Erik Nordmark wrote:

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

affect the /source/ right? :) Yes.

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

Well, that depends.

On Solaris, which I suspect you're accustomed to ;), a seperate 
logical interface structure is kept for each seperate address. So 
resolving a route to a next-hop and hence an interface implies 
automatically you have only one address to use as your source 
(Solaris then caches that in the kernel socket structure iirc).

On other systems, the resolution may go:

- resolve destination to next-hop
- find the local connected subnet for that next-hop

That latter resolution gives you the output interface and your source 
address (for an unspecified-source socket). An interface may have 
multiple addresses, there may be multiple next-hops out that 
interface, on different next-hops and the next-hop used /does/ 
determine the source used (if appropriate).

In both cases though, the step to resolve next-hop to interface 
involves looking at local addresses (the interface follows from 
that). I'd have to go delve further into sources to see for sure, but 
I don't see how you can get from next-hop to interface without taking 
local addresses into account. (be it expressed in terms of 
connected-subnet routes, or by looking through a list of local 
addresses).

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

And you wouldn't, only those involved in diverging paths to the 
relevant border routers. If the border routers share link(s), then 
only the border routers need know.

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

Indeed.

But, ultimately, flooding required source-routing knowledge seems 
easier. Tunnel through unaware parts of your network seems a hack 
till you get your routers upgraded.

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

IGPs typically are link-local, yet manage to synchronise routing 
state within an AS. ;) You simply flood the required knowledge onward 
to other links.

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

Fair enough ;)

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

That's a fair consideration, yes.

Note that I don't wish to preclude the more complex host-side probing 
of all addresses. I simply would not want to see that encouraged as 
the norm.

Further, this ISP ingress problem affects more than just shim6. It 
affects all IPv6 communication from such a multihomed site to 
external hosts. Hence why I strongly suspect any IPv6 infrastructure 
that is intended to cope with IPv6 multihoming will ultimately 
acquire 'ISP steering' for routing and RAs regardless of shim6.

Indeed, routers and common Unix OSes have this capability /today/. 
Though, not a protocol to distribute this information to automate 
propogation of such routing information - that'd be nice to have I 
think.

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

I think it's complete overkill, but sure, yes. I don't think it 
should be precluded.

However, the site topology you argue should not need to be upgraded 
to work with shim6 likely /already/ has source routing in place to 
allow their v4 and v6 to work /today/. So you're tackling a problem 
which the local site administrator likely has already solved.

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

Ok.

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

Ok, yes: I agree with you.

I'll tell you what my fear is: it's sort of the converse of yours.

Where you fear I want to require IGPs, etc.. to be upgraded for Shim6 
to work - my fear is that shim6 will end up specifying that 
source-address probing will be a specified as a MUST regardless of 
what other (and possibly better) means has a site has to indicate 
prefix availability and steer packets to the right ISP.

> You seem to argue that shim6 should not be allowed to have the 
> capability to explore all n^2 address pairs,

Apologies, I've intended to argue that n^2 should not be /mandated/, 
however that implementations /may/ do so, if needs be.

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

Personally, I think n^2 would be a short-term hack until routing 
catches up (if indeed routing gets there /before/ shim6 - the ISP 
ingress problem will become apparent to /any/ PA-multihomed site, 
regardless of shim6, and you don't need n^2 probing to solve it - 
even today with IPv4).

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

Sure, but to take this "the hosts can find working paths better than 
internet routing" view to its most extreme you could also mandate 
source-routing to try probe different /remote/ paths in the internet. 
But that's not how we do routing in IP networks - we've always left 
it to the next-hop to know their neighbours and appropriate paths 
better than "we" do. If there's a problem in routing, fix it. :)

So no, I don't accept hosts must be prepared to do this, no more than 
they must today. I don't accept it's required as anything other than 
a hack for networks which are broken anyway.

However, I don't think it should be /precluded/ from shim6, no. I 
just have a fear that it will be specified as a default behaviour.

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

I gave the URL to the script ;) - that was run on the relevant 
'routers'. Other than configuring the hosts with addresses (which has 
to be done anyway), nothing.

It's probably worth mentioning that that site eventually moved to BGP 
and PI ;). However the PA addresses and source-routing remained in 
place, and continued to be published in DNS for a while.

regards,
--
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
"A computer is a state machine.
 Threads are for people who can't program state machines."

	- Alan Cox