Re: administrivia (on avoiding injury)

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

Just brain storming none of this is baked and SCTP is in good shape but
passing endpoints around at the API is still TBD for implementation. No
way ready to deploy except maybe for SIP, MEGACO, et al.  But could be!!! 

But...........

> Before you implement, please answer these three questions:
> 
> | > Personally, I think it's reasonable to require a host change to switch to
> | > another prefix when there is link failure. 
> 
>                 World----ISPZ
>                   |       |
>                 ISPA     ISPB
>                     \   /
>                     site
>                       |
>                     host
> 
> How does host detect a link failure between ISPB and ISPZ?

We have no way today.  But this plays into other mail I just sent.
ISPB would send Neighbor Discovery (ND) link-broken-ISPZ to site and site 
would send via ND host.  This would trigger at IP layer (quickest fix)
that all packets to ISPZ would now go to ISPA.

The ND from ISPB to host could be designed similar to the way router
renumbering works.

The host could do this at IP with the Homeless IP work and build a e2e
cache so packets would be forwarded correctly.  Or generate new endpoint
address for sctp which would be ISPA for that sctp 'association'.  

All the ND could be secured with IPsec as the key mgmt even with IKE would
not be hard (certificate authority would be at site and ISPA and ISPB.
 
> How does host detect a link failure between ISPZ and World?

Same as above it works with any link failure in this picture.

> When host detects either of these failures, how does it adapt
> such that there is no lost connectivity to what can still be 
> reached through site's _still operating_ connection to ISPB?

For TCP the host would treat it as need to retransmit the packet and
implementors would have to make this happen by emulating a forced
retransmit.

Likewise for SCTP but it would be retransmitted on different endpoint of
the association.

For UDP we got the same old problem.  The app needs to know to retransmit.
We could say thats life for UDP.  But that is cheesey IMO and I have a few
ideas here but will not spew them out right now but retransmit is possible
with UDP too.

The there is timeout period clearly (e.g. RTT, App Timer)?  

But the packet would get retransmitted to the right place from the end
node.

But I also think we cannot mandate all do this it can be cheaper for small
devices to just get link failure and start new connection to the ND prefix
or whatever is sent to it.  But the benefit is still seen to the routing
infrastructure the node just chooses to restart that should be permissable
too.  

Hmmm in fact the default can be for nodes that don't support the mutli6
e2e if it happens is they restart.  

my 2cents,
/jim