Re: I-D ACTION:draft-bagnulo-shim6-addr-selection-00.txt

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 4-okt-2005, at 9:57, marcelo bagnulo braun wrote:

> > http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-addr- 
> > selection-00.txt

   We do not assume that the DNS is dynamic:
   there will be situations in which both A:X and B:X are published,
   while in fact only one is reachable.

Such an assumption would be impossible, because even if the DNS could  
be updated in time (ie no caching) it's possible that Y can reach  
both A:X and B:X while for Z only A:X is reachable and B:X is  
unreachable.


Small nits:

- on page 3 the reference topology has ( A ) and ( B ) but then (C).  
The dashes also don't align to objects in a consistent manner.

- on page 3 it says "Host X has to global IPv6 addresses" but you  
probably mean "two"

- also, isn't using A and B for hosts and X and Y for ISPs more  
common (or is that just me?)

- it says "wit" somewhere

- "The first option is to simply let the upper layers to handle" the  
"to" is superfluous here

The big stuff:

- please don't start new headings with a new "page", it wastes time  
when reading on the screen and paper when the document is printed.

Basically you say that because applications are supposed to try all  
available destination addresses, there is no problem when a  
destination address doesn't work, but since applications don't try  
different source addresses a broken source address is problematic.

I agree that applications should try all addresses, and it looks like  
we have to extend this to trying all source/dest combinations. That  
can be painful. However, many applications DO NOT try all addresses.  
I think it would be good if the shim would be able to pick up the  
slack in these cases rather than depend on correct application behavior.

One of my main concerns is the time all this trying of alternative  
addresses in ULPs is going to take. In many cases, the shim will know  
that something isn't going to work much faster than even an expedited  
ULP timeout. For instance, AFAIK hosts are supposed to ignore ICMP  
errors during (TCP) session creation, but the shim can probably react  
to these without too much trouble. Also, when for the last N seconds  
there haven't been successful interactions using a certain address,  
the shim may reach the conclusion that this address is no longer  
reachable and not waste time with it for initial packets. The shim  
could transfer this knowledge to the RFC 3484 mechanisms.

5.1.  Proactive mechanisms

   In this case, two mechanisms are needed: first, a mechanism to  
detect
   the outage and then a mechanisms to inform the host about which
   prefixes should be used in the source address for the different
   destinations.

I don't really understand what you're talking about. If K has a  
broken address, does this mean that K knows this or that L knows this???

   There are several mechanisms that can be used to detect the outage.
   For instance, if any routing protocol is used between the ISP and  
the
   multihomed site, such protocol can be used to detect the outage.  In
   any case, it is possible to use a periodic ICMP echo request for
   detecting the outage on direct links.

There are better ways than pings for this.

   We propose to use the "preferred" lifetime to indicate whether
   addresses derived from the prefix can be used as source address in
   multihomed networks.  When a prefix is temporarily not available
   routers MUST advertise a null preferred lifetime for that prefix.

Agree. However, I would use "zero" rather than "null" here to avoid  
confusion.

   This solution is sufficient when the site is composed of a single
   link; for more complex sites with multiple subnets, we need a
   mechanism with a broader scope than Router Advertisement.  There are
   two available candidates that provide the required fucntionality:  
the
   Router Renumbering protocol [3] and the prefix delegation option
   defined for DHCP [8].

Both not used today, although prefix delegation may be taken up in  
the future.

Why not come up with something new for this? Such as a site scoped  
multicast message?

   In this scenario a mechanism like NAROS [6] can be used.  In this
   mechanism, a server acquires the reachability information available
   in the inter-domain routing system using BGP.

This is mostly useless due to aggregation in BGP.

   the retransmission service provided by the IP layer

:-)

You are trying to build shim functionality outside the shim...  
Doesn't make much sense to me.

Apologies for not reviewing this draft sooner.

Iljitsch