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

Re: failure detection

On 15-aug-2005, at 18:08, Paul Jakma wrote:

I'd also like to potentially add source-address-selection (for the globally routable shim address) to this list. 

[...]

Again, SAS is simply *not* something shim6 should do, or something which it has remotely near enough information to do. Let normal IP routing and SAS handle this task.

The thing is that for TCP, the source address is only selected at the beginning of the session. After that, it can't be changed because the other side wouldn't recognize the session anymore, i.e., it's needed for demultiplexing.

The shim MUST be prepared to set the source address because there may be ingress filtering at some point, and the wrong source address will make communication impossible. If the shim is going to rewrite the source address at the destination, we're no longer limited by TCP demux, but of course the shim itself must also demux. It's possible to do this without considering the source address, or at least the first 64 bits of the source address, but it's not entirely non-trivial.

If you follow your line of thinking about the source address to its logical conclusion, then obviously the site exit router must select the source address. We've talked about this A LOT in multi6 and its various design teams, and (others jump in if you don't agree) the conclusion was that this is certainly a capability we would like to have, but since it has its own difficulties (routers must know which packets they can and can't touch) and it will take a long time before we can depend on routers to do this, we have to make the shim work without this capability.

I'd suggest it would be more fruitful to ensure state between two shim6 speakers /not/ depend on the 'outside' (ie globally routable) addresses, and let shim6 be able to handle messages between two endpoints arrive with any 'outside' source address. 

Not sure what you mean...

It also eliminates the need for hideous n^2 address-to-address probing which is being considered.

There is no getting around it, except for giving up before you reach n^2...

(You can of course move this problem to another layer.)

- A may load-balance outbound packets between the two ISPs

Not really. Suppose A sends packets to router R which connects to both ISPs. How is A going to influence to which ISP R sends any given packet?

However, I feel it is a *really* bad idea to even consider trying to solve the problem of "internet cloud" path failures, 

I'm afraid you've come to the wrong wg.  :-)

    - Existing protocols already live with this today, and
      generally we're happy

Are you saying there is no requirement to multihome, even for people who go out of business when their link to the net fails for a significant amount of time?

    - It can be solved/mostly-mitigated by running a routing
      protocol (ie BGP)

Not without an information explosion. If you have address dada::dead:beef, and I see in BGP that dada::/16 is up, I'm going to send the packet as per this route. If it then turns out that your link to this ISP is down the packet isn't going to make it. And sending out a route for dada::dead:0/112 over another ISP won't scale.

- If you don't need to specify complexity, don't -> KISS

Ever looked inside the cockpit of a modern airliner? Not simple. And these people care A LOT more about their "redundancy protocols" that we do.

Keeping it simple is good advice when the choice is gaining advantage X in a simple way or gaining advantage X in a complex way. If keeping it simple means you only get X/2 rather than X, then simplicity isn't necessarily the right choice.

    - In trying to specify such a thing in shim6 you'll have to
      consider interaction with underlying IP routing, yet
      another layering violation.


Layers may interact, no violation per se.

Please drop the locator-selection crap for now. 

What "crap" are you referring to?

Iljitsch