[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: administrivia (on avoiding injury)
- To: Daniel Senie <dts@senie.com>
- Subject: Re: administrivia (on avoiding injury)
- From: Margaret Wasserman <mrw@windriver.com>
- Date: Wed, 11 Apr 2001 15:35:07 -0400
- Cc: multi6@ops.ietf.org
- Delivery-date: Wed, 11 Apr 2001 12:33:45 -0700
- Envelope-to: multi6-data@psg.com
>How quickly these addresses will get updated in DNS, making it possible
>to serve out services in this model remains to be seen.
There was discussion on this list about fail-over between multiple
addresses returned by DNS. It indicated that all current BSD-based
apps (except LPR, I think) will try additional IP addresses returned
by DNS if the first one fails. So, I believe that the solution is
to include all of the hosts addresses in the DNS response. If the
services is not reachable at one address, the client should try
other addresses.
>Well, if there are multiple hosts on a local net who are using those
>addresses for communications among themselves, I have some real concerns
>about sending them messages to cease such communications. The routers
>may not be a party to all conversations, after all.
Deprecating an address does not cause an IPv6 host to discontinue
existing communications. It only causes an IPv6 host to prefer other
(non-deprecated) addresses for establishing new communications.
>How do we do it today? It's hard. We often DON'T know that connectivity
>is lost. We're often not talking about carrier detect dropping on a
>link. I think THIS is one of the underlying issues in need of a solution
>if any sort of host-based multihoming is to be considered.
I agree.
>The knowledge
>of link outage would have to be propagated QUICKLY to hosts, meaning
>we'd have to be able to detect that outage in a very timely fashion.
How quickly? From earlier discussion, it seems that the routing to
a multi-homed IPv4 network could take quite some time to converge
after an outage -- long enough that TCP connections will often
experience a retransmission timeout. I agree that it would be good
to do better, but is this a hard requirement? If so, how much better?
>Another thing needed is a definition of LINK OUTAGE. I propose a link is
>declared dead when it's not carrying traffic as intended. This may
>translate to a policy that states packet loss over 90% on a link leads
>to an assumption of death, rather than a traditional "T1 link is down,
>therefore reroute" type of decision.
How would routers detect this situation? And, if they did detect it,
how would the information be propagated back into the site (across
the Interdomain Routing to Site Routing boundary)?
Margaret