Re: administrivia (on avoiding injury) (fwd)

[Greg Maxwell <gmaxwell@martin.fl.us>]

---------- Forwarded message ----------
Date: Tue, 10 Apr 2001 22:23:30 -0400
 From: Daniel Senie <dts@senie.com>
To: Greg Maxwell <gmaxwell@martin.fl.us>
Subject: Re: administrivia (on avoiding injury)

Greg Maxwell wrote:
> 
> On Tue, 10 Apr 2001, Daniel Senie wrote:
> 
> > Greg, could you reread your last post, reparse the sentences and see if
> > you can phrase it in a way that parses? It's REALLY unclear what you're
> > trying to say.
> 
> I'm very sorry. I've been working too many 16 hour days, doing too
> many concurrent tasks, and being constantly interrupted. :(
> 
> Thank you for politely pointing this out to me.

:-)

I know how it gets...

> 
> The discussed language is the requirement that any proposal be compatible
> with 2460 hosts achieving 'degraded multihoming' (DM means: no requirement
> that TCP sessions survive a link failure, but the connection can be
> reestablished right away).

I've expressed the opinion that we're there already today...
applications wind up having to be able to do this, though it's VERY
painful at times (like when the connection was an interactive terminal
session, and you're in the middle of typing something).

> 
> As far as I can tell, that sort of 'degraded multihoming' is acceptable to
> the more vocal here for compatiblity with existing applications. That's my
> opinion as well, but I'm not so sure that we need to leave the entire end
> node unaltered and still achieve degraded multihoming on that end node.

I think it is generally acceptable IF there's some way to get
reconnected to the same end node. Seems to me this still requires we
have some way to talk about end nodes other than by use of IP addresses
(v4 or v6).

> 
> Alternately,
> 
> Would requiring the OS be modifyed be acceptable to provide degraded
> multihoming, as long the changes were not substantial and caused no
> visable API change and non-modifyed systems would be stuck single homed
> without proxys/NATs?)

No.

> 
> I think the point is worth of consideration as end-to-end multihoming
> might require provisions for NAT in routers if no host changes can be
> required for degraded multihoming (and thus require discussions about the
> accepeptibility of such methods, if they are not acceptable it might
> fully exclude end-to-end multihoming).

There's a MAJOR problem here... When you introduce the requirement for a
NAT in the stack, you're expressing a willingness to limit protocol
choices to a very few, limit the ability to offer services, and thus
severely limit what applications can work. As a transition strategy, NAT
can be acceptable. As a permanent feature, we have to consider that VERY
carefully. Many are trying to get people onto IPv6 to get them AWAY from
NAT. If it's to be a permanent fixture, application protocol design will
be severely affected.

> 
> If you feel that I sufficently clarified the post in question, and that
> this clarification would be useful to others, you have my consent to
> forward this onto the list.

I think it did. You may, at your discretion, also forward my comments if
desired.

-- 
-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.                    http://www.amaranth.com