Subject: about draft-arkko-multi6dt-failure-detection-00.txt

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2004 18:10:35 +0200

Some comments about draft-arkko-multi6dt-failure-detection-00.txt:
 - in the intro a missing < before xref target='transport'/>
 - in 3.1 link-local IPv6 addresses, private (RFC 1918) IPv4 addresses,
   etc, are excluded. IMHO this is a too strong constraint: only
   ambiguous zone limited addresses should be excluded (note that
   one (only) address cannot be ambiguous).
 - in 3.2 s/the relevant default router/a relevant default router/
   (links in a resilient multi-homed environment should be served
    by more than one default router :-)
 - in 3.2 "Theoretically, it is also
   possible for hosts to learn about routing failures for a particular
   selected source prefix, even if no protocol exists today to
   distribute this information in a convenient manner."
   I disagree about the last part: there is a well known and simple
   protocol to announce routing failures for a source prefix: deprecate
   it, i.e., send RAs with zero preferred lifetime in the prefix info.

Regards

[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Oct 2004 19:51:12 +0300

Hi Francis and thanks for your input! A few responses

>    one (only) address cannot be ambiguous).

I'm open to doing this either way. I guess the issue is
accidentally attempting to connect to someone else's
10.0.0.1 address. I've heard that protocols in the
multimedia space already can run into this, however,
so this may not be a new problem.

How do others feel?

>     by more than one default router :-)

Ok.

>    it, i.e., send RAs with zero preferred lifetime in the prefix info.

Ah, yes. Thanks.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2004 19:09:04 +0200

In your previous mail you wrote:

   
   
=> IMHO there are three issues with zoned addresses:
 - zone IDs are local (so I can't designate a zone to a peer)
 - an unclothed zoned address is likely ambiguous (API issue)
 - is the peer zoned address in the same zone? (perhaps your concern).
I tried to solve these issues in my address management for IKEv2,
and in fact IMHO the only reasonnable scenario is to use only at most
one zoned address and from the beginning.
This is not an unlikely scenario and don't forget than the RFC 3484
rule 8 on destination addresses is "Prefer smaller scope"...

Thanks

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Oct 2004 13:28:38 -0700

>    it, i.e., send RAs with zero preferred lifetime in the prefix info.

In doing so you would be overloading two very different semantics on the 
deprecated state:
  - this prefix will stop working in the future (sometime after the valid
    lifetime expires) so don't use addresses in this prefix for new
     communication; no effect on existing communication
  - this prefix is currently not working; immediately switch existing
    communication (as well as new communication) to use an address from a
    different prefix.

Those two semantics are in conflict.

So if we want the second semantics one would need to carry that 
semantics. Of course, it wouldn't be hard to define some extension to 
the router advertisements (and the router renumbering protocol if we 
don't want to manually configure the routers) to say this; a single bit 
in the prefix option might be sufficient.

    Erik

---

From: Francis Dupont <[email-masked]>
Date: Fri, 29 Oct 2004 11:08:44 +0200

=> I agree but this idea is very old (last meeting in Washington?) and
the wanted effect is the same.

=> I disagree about the second semantics: the effect of deprecatin a
prefix does not include "immediately switch existing communication".

=> I agree if we want to extend the standard effect we have to add
at least an extra condition.

=> IMHO we don't need a bit but simply to add a threshold condition, for
instance if the preferred time jumps from at least X hours to zero so
existing communications may be affected. And add an advice to use
smooth decreasing to zero in RAs for the standard semantics.

Thanks

PS: as far as I know this idea is not supported by IPv6 routers (nor Cisco
or Juniper at least). We developed locally a little tool (poll some
critical BGP routes by SNMP and reconfig routers) and it worked exactly
how we wanted: new connections used only source addresses in working
prefixes... I tried the extended semantics in my MIPv6 code many (6?)
years ago but without a good solution to the signaling protection issue.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 29 Oct 2004 10:21:03 -0700

> smooth decreasing to zero in RAs for the standard semantics.

IMHO adding a bit is a lot clearer than trying to overload the lifetimes.

In the case of overloading, what would happen when a host is unreachable 
for some time, during which the deprecated lifetime announced by the 
routers decreases in real time (due to some planned renumbering).
When the host becomes reachable it sees that
	the last RA had lifetime = X
	the new RA has lifetime Y which is a lot less than X
	the remaining lifetime in its prefix list is close to Y

Figuring out robust rules for how the host says that the above is not a 
signal of a failed prefix, but other cases are, would be non-trivial.

*If* we are going to pursue this, then just defining a bit would be 
trivial.

    Erik