Re: administrivia (on avoiding injury)

[Jim Bound <seamus@bit-net.com>]

this is not hard to do and does not wack the stack that bad at all on a
host.  also it can be done without touching the APIs at all.  So just
state the req and what is to be done and what the outcome will be.  Us
implementors will make it happen.  Is my input.  

I think we all would rather do it right than hack up another translation
into the Internet IMO.

I could make it transparent to users who have ported to IPv6 too.

/jim

On Tue, 10 Apr 2001, Greg Maxwell wrote:

> On Tue, 10 Apr 2001, Ben Black wrote:
> 
> > On Tue, Apr 10, 2001 at 07:35:47PM -0400, Greg Maxwell wrote:
> > > 
> > > For point are we talking about RFC 2460 for the entire host or API level
> > > up?  Requiring no changes to the entire host for re-establishment may
> > > require contortions from transport level proposals, is this functionality
> > > actually required.
> > 
> > That is the question open to debate :)
> 
> Personally, I think it's reasonable to require a host change to switch to
> another prefix when there is link failure. However, others here have a lot
> more knoweldge then I about what the production channel looks like,
> obviously the solution can't be allowed to fail because it requires too
> much of vendors.
> 
> If others think that no-mod full host 2460 fail-over support is required,
> what do you think of regarding it as legacy and allowing proposals to
> solve it with ugly things like NAT-on-link-failure <shivers>.
> 
> I think it would be wise to trade a bit of end-to-end transparency in the
> short term (NAT for link failure on plain 2460 hosts) for additional
> end-to-end transparency in the future. 
> 
> > > I have another requirement:
> > > 
> > > Any proposed system must not intrinsically exclude bi-directional traffic
> > > engineering. 
> > > 
> > 
> > This is already covered in the draft, with examples of why people shift
> > their traffic around (performance, cost, etc).
> 
> Duh. Sorry. I read it, I'm being stupid.
> 
>