Re: administrivia (on avoiding injury)

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

> I was assuming that all of the prefixes would be mutually known before
> link failure, and that one pair must survive to keep the connection up. I
> don't think this is unreasonable at all.

So your proposing sending dst addrs to the transport or IP layer (we can
figure taht out later) and if one fails use the other.?

If so that is doable it can be done out of band via many of our APIs too.
If we want to do this it would fit well wit the IPv6 Advanced API rfc2292
which is sysctl on steroids but well defined.

But I don't think changes in the DNS will converge as fast as our network
reporting link failures as mini routing update to end nodes.  Also dns
even with dynamic updates will probably not happen instaneously as we
would like.

Does this mean we have DNS statement to make?  I think so.  But it don't
change anything in DNS and it will give you all your stuff and weight
it for you today.
  
> > > The SCTP RFC covers a complete protocol implimentation that can do this.
> > 
> > But as I stated in my mail to Sean SCTP has no mechanism to 'create' a new
> > endpoint except from another node telling it to in an association update.
> 
> Right. There should be some way for each sites router to push a new prefix
> onto each end node, and there is already a draft for a SCTP extension to
> add associations.
> 
> > Using the ND message extension I proposed it can be generated to the
> > association.  I think the SCTP folks could absorb this and would if we
> > presented it to them.  
> > 
> > With IPv6 it could just be a prefix update possible within SCTP.
> 
> > But this gets to other problem.  The nodes are not sending to the routers
> > ISPx but to the node on the other side.  So other than an intermediate
> > endpoint address via IPv6 Source route option it won't help much (but
> > could be done and converge fast).
> 
> Well, I think a clean implimentation would use source based routing on the
> border routers such that traffic with a source prefix of A only flows out
> via ISPA. 

Yep  
> [snip]
> > But doing dns pairwise resending is just a complete retransmit and maybe a
> > good default but I think we can do better here.
> 
> Eeek no! 

You cleared this up above.
 
> DNS should be used at initation and initation only. DNS should be cached
> (i.e. you should expect to have your link fail then suddenly learn via DNS
> that the host on the other end has renumbered, at least not over a
> reasonable time span). 

Yep my concern as some have proposed stuff like this for other problems
just checking.
 
> There is a proposed SCTP extension to add IP addresses to a live link.
> This should be a basic functionality for any transport level multihoming
> implimentation. See my assumption at the top.

Yep its getting pretty baked actually and I think some have prototypes
too?  I forgot about this tonight.
 
> 'You have a new prefix' would be generated by the site router when:
> 1) It's upstream says to it 'you have a new prefix' (if the site allows this)
> 2) When the site's admin adds another link.

OK.

> A future enhancement might add a 'think link is dead jim' message, so that
> hosts can not waste their time retransmitting into /dev/null. Other
> optimizations are possible, such as using information from other links to
> figure out a path is dead, so retransmission is not needed on connections
> that were idle when the link died.
> 
> I think all of that can safely be left for later as there are
> complications, see the message I posted just prior to this one. 
> 
> > Plus if we start trying to go up to user space and then back to kernel
> > space thats a hack for sure.  
> 
> Run away! Run away!

OK I am game.

It just seems to me there is so much chewing gum on the Internet today a
little work with ND would be good but I will put it on the back burner
which may give me time to think more and maybe write a draft (no commit to
the chairs for now :-------------))

/jim