[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: administrivia (on avoiding injury)




> > 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.
> [snip]
> 
> Well, it's not quite that simple:

Sure it is.  The next level of indirection just has to be more cognizant.
 
> 
>    [.......world.............]
>         /1   |2    |3     \4 
>     [ISPA] [ISPB] [ISPC]  [ISPD]
>        \5  /6  \7  /8 \9     /10
>        [SITEA] [SITEB] [SITEC]
> 
> Would you like failue of link 2 to make SiteA<->SiteB go across the world
> rather then ISPB.

With my proposal SiteA and SiteB could also be extension #2 to ND. The
traffic would be using link 6+7 anyway and in fact if ND is set up right
that will work in IPv6 as optimum path today.

Assuming global addresses are being used of course between sites which is 
not a problem with IPv6.
  
> Should a failure of 7 make SITEA not try to reach SITEC via
ISPB? > 

Loss of 7 would not be reported to SITEA unless it was using it.

> The simplest, but lest efficent, method is for the hosts to attempt
> retransmission across alternative pairs.
> 
> I think that should suffice for our purposes here.

It could be our first solution yes.  But should not be our only one.
And I would only agree if it is a complete retransmission.

> 
> In the future I think that negitive ND type messages will accelerate and
> make such things more efficent. Also, packet loss will more likey be a
> sign of failure (or really really bad congestion) if ECN is widely used,
> so more agressive path change could be triggered by it.

I agree.
 
> Unless someone has a theory as to what transport level multihoming is dead
> without 'push' notification of link failure, or why it would have to be
> implimented architecturally rather then as an improvement, we should
> probably leave it alone.

I think we need the push to make it useful for sure. Whether we pursue it
depends on how aggressive we want to be as a working group.

I will work on all solutions.

But I think we do the Internet a great service if we can help alleviate
some of the routing infrastructure pain by a little bit of enhancements to
ND and negative push as you elegantly reference it.  And for what its
worth I have believed this for a long time for IPv6.

And I think we can do it without breaking installed based or blowing away
the stacks we built even for hardware emerging implementations as they
should be treating ND options as opaque and loadable to the Interface
Processor CPUs for both ingress and egress data movement.

regards,
/jim