Re: Requirements [was Re: Transport level multihoming]

[Brian E Carpenter <brian@hursley.ibm.com>]

Joe,

If the BGP update fails to propagate before the TCP timeout pops,
the application has to restart. Even if this is very rare,
reliable apps must allow for it. (This means any app with
transactional integrity requirements - these simply can't assume
a reliable transport layer, whatever the TCP spec promises.)

That's why my requirement isn't for survivable TCP; it's
a much weaker requirement, that IP connectivity survives.
Note: I did not say IP connectivity with the same address pair.
This in no way implies that "CIDR-style" is the only solution.

   Brian

Joe Abley wrote:
> 
> On Wed, Apr 04, 2001 at 12:27:40PM -0400, Daniel Senie wrote:
> > > My answer is no, it would be a very serious mistake to require (b)
> > > in this case. It would result in an undeployable solution.
> >
> > Agree with Brian. Applications will have to deal with restarting
> > connections if they die. This is fairly common already, since the
> > IPv4/BGP multihoming world works this way.
> 
> Could you explain this further?
> 
> My impression is that IPv4/BGP multihoming that happens today provides
> session stability, and applications do not need to deal with restarting
> connections in the event of a re-homing event.
> 
> If the intention is to provide a multi-homing architecture in v6 that
> provides all the functionality of the v4 one, then I think we need to
> put more thought into why session stability is not required before we
> discard it. Otherwise there is a danger that pressure will exist to
> do CIDR-style multi-homing in v6 since it remains the only solution
> that meets this particular requirement.
> 
> Joe