[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: failure detection
On Mon, 15 Aug 2005, Iljitsch van Beijnum wrote:
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.
Uh, so shim6 on the receiving side is going to use details of TCP to
demux shim6 packets before passing them up the stack (to IP layer
again). I'm guesing the answer is "No" :).
I think we're likely agreed details of TCP, or whatever happens to be
flowing, should be invisble to the shim layer.
And again, if you don't try tie shim6 demux to the /specific/ locator
address, this all gets easier. Don't make shim6 stateful, things get
easier. Demux can just can be the IPv6 equivalent of SNAT.
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.
??
Well, tough luck, then that local 'locator' address should never have
been specified as valid for shim to use. Can you give a more concrete
example? Do you mean RPF filtering by ISPs? Yes, for the multi-PA
approach you'll need ISP visible source to match.
But you don't per-se need address selection in shim6 for this -
however, I'm unsure now of what is being proposed exactly for the
mechanism.
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.
Why exactly? Demux can look like (security aside):
- take source address (the locator source) and do a lookup in a
locator -> endpoint table
- replace address
Hey presto. All that needs to be done is populate the
locator->endpoint table during setup with all the possible locators
the other-side advertises.
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.
Forgive me, I don't seem to be aware of what shim6 actually /is/
proposing for its mechanism then.
If the source is not selected by the exit router/host, then what is
the source to be set to exactly? If the proposal is for packets on
exit to contain the multihomed-prefix, that's fine. No locator
selection needed at all (cause you're not rewritting the source).
(But see the RPF problem, right?).
If the talk about locator address selection and probing is to do with
shim setup? My point stands: Don't bother, just try reach one of the
remote locator addresses, as appropriate.
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...
Wrt specifics: sorry, if the rewrite is to be of destination on
/demux/ at ingress site, above doesn't apply.
In general, try not make shim6 state depend on any /specific/ locator
state, so as to allow shim6 to work with any /valid/ locator.
There is no getting around it, except for giving up before you reach n^2...
Yes there is. Just dont bother.
Nothing else in common usage tries to work around interner-cloud-path
failures in such a fashion, nor should shim6. This specific proposal
(from what I saw of the slides at IETF) is a *really poor*
reinvention of internet routing. Don't go there.
(You can of course move this problem to another layer.)
Tada.
- 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?
It doesn't. That's how internet routing works.
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. :-)
No, I havn't.
The charter (thankfully) says nothing about coping with /any/ path
failure. Just that shim6 be able to cope with changes at the
endpoints.
- 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?
I have no idea how you got that from the point above.
Multihomed or not is irrelevant to "internet cloud" path failures
that you can do nothing about. And you should know I'm *very* eager
to see IPv6 multihoming made possible ;).
- 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.
Did I say anything about *advertising* anything over BGP?
Getting read-only BGP feeds is quite useful if you have multiple
links, and is a far *far* more sane way to detect the right path than
the n*2 path-probing idea.
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.
Firstly I don't actually see the relevancy, further discussing
analogies is usually a waste of time. FWIW, yes, I've seen lots of
cockpits and they are designed to be as simple as they can be -
modern flight automation and glass cockpits make this even more
possible. Go compare a modern airliner cockpit to that of to an /old/
one.
But not at all relevant. ;)
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.
The most common cases for IPv6 "multihoming" will be one or more of:
a) Single homed, but want "PI" addresses for portability
- Think of this as multihoming but with spread over time ;)
b) Cheap multihoming (eg two cheap end-user/SOHO DSL links)
- ISP wont do dynamic routing (be it advertising a default
via RIP or somesuch, or BGP)
c) Enterprise multihoming
- ISP /will/ advertise availibility via routing
For a, no path-probing locator-selection is needed in shim6 at all.
For b, no path-probing locator-selection is needed in shim6 at all.
So the only reason to want path-selection (by doing path-probes with
different locators) is for case b. My argument would be it's not
worth adding lots of complexity to shim6 for this case, when you
could do just as good a job /outside/ of shim6, with eg:
- a simple daemon to monitor link-status (if available)
- some kind of independent path-probing software that adjusts
routing as required
(and some OSes already have this functionality)
To reiterate:
- We already have internet-cloud failures today, and we cope
(eg, cause we're singly-homed, or we get route availibity
information from our ISP, or with some other path-probing
software, or we just trust our ISPs to do what they're supposed to
and get our packets to where they want to go, and we live with the
X nines availability we get from them or we get a different ISP)
- Those /same/ mechanisms can be used to cope with
internet-cloud paths failures in a shim6 world
Ergo:
- Shim6 does not need this complexity, it would be redundant and
counter-productive (particularly for sites that got route
availability information from their ISP)
What "crap" are you referring to?
The n^2 probing. Don't make shim6 specify that, please.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Lonesome?
Like a change?
Like a new job?
Like excitement?
Like to meet new and interesting people?
JUST SCREW-UP ONE MORE TIME!!!!!!!