[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: failure detection



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