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

[Iljitsch van Beijnum <[e-mail]>]

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