Re: revision of architecture draft is now published

Hi Geoff,

El 30/06/2004, a las 4:22, Geoff Huston escribió:

> draft-huston-multi6-architectures-01.txt has been published by the 
> drafts editor. This version integrates comments made by working group 
> members on the -00 version and also includes material proposed in the 
> interim multi6 working group meeting earlier this month.
>
> I would like to propose to the chairs that the working group consider:
>
> - that this document be adopted as a working group document, and
>
> - that the appendix of this document be split off from the main text 
> of the document and separately developed as a working group document.
>
>
> thanks.
>

Some comments about the draft:

- About MIPv6: imho we have an important thing to learn from mipv6 (in 
its current form) which is that return routability type of mechanisms 
are not suitable to address the multihoming problem. this is a 
fundamental problem, because in mipv6 the identifier ownership is 
proven by periodical reachability tests. Considering that multihoming 
deals with outages, the reachability tests will fail when there is a 
failure. the periodicity of the tests is required to avoid attacks 
shifted in time

- About traffic engineering: imho is within the scope of a multihoming 
solution, since i think TE are included among the goals stated in RFC 
3582. In particular

3.1.2.  Load Sharing

    By multihoming, a site should be able to distribute both inbound and
    outbound traffic between multiple transit providers.  This goal is
    for concurrent use of the multiple transit providers, not just the
    usage of one provider over one interval of time and another provider
    over a different interval.

and also:

3.1.4.  Policy

    A customer may choose to multihome for a variety of policy reasons
    beyond technical scope (e.g., cost, acceptable use conditions, etc.)
    For example, customer C homed to ISP A may wish to shift traffic of a
    certain class or application, NNTP, for example, to ISP B as matter
    of policy.  A new IPv6 multihoming proposal should provide support
    for site-multihoming for external policy reasons.

So, i guess that a multihoming solution should try to provide these 
goals, and imho an analysis of the solution space should consider these 
items.

- About section 2.

imho this section has improved in this version and now provides a more 
general approach, since it explicitly addresses both the site 
visibility, the session resilience cases and also TE stuff. However, 
perhaps it would be interesting to also include the case when the 
internal hosts attempt to initiate a communication after a failure?
I mean, when a failure occurs, there are three situations to be 
considered, imho. first, session resilience, second that an external 
host is capable of establishing new communications with multihomed 
hosts, and third that a multihomed host is capable of establishing new 
communications with external hosts after the outage, i think that the 
last case is missing.

- about section 4.2

where it states that:

   "The implication here is that if
    the local host wishes to maintain a session across such events it
    needs to communicate to remote host R that it is possible to switch
    to using a destination address for the multi-homed host that is based
    on ISP B' address prefix."

i think that the implication here applies both to established 
communications and to new ones
Additionally i am not sure that it is required that the local host 
informs R about the available locators. As Brian said once (if i 
remeber correctly), the local host is the last one to find out that one 
of its own locators in no longer working. IMHO what is needed is that R 
  discovers which is the new locator to use
So, i would rephrase it into something like:

    The implication here is that in order to enable the communication
    between R and the local host across such events, the remote host R 
has to discover that
    it has to use a destination address for the multi-homed host that is 
based
    on ISP B' address prefix.

(but if you understand my concerns, you can rephrase it much better 
than this, i guess :-)

- about section 4.4

at the end of the first paragraph it is stated than:

    "This modification could be undertaken
    within the transport protocol stack element, or within the
    internetworking stack element.  The functional outcome from these
    modifications would be to create a mechanism to support the use of
    multiple locators within the context of a single endpoint-to-endpoint
    session."

i am not sure that session would be appropriate for the IP layer... 
perhaps replacing session with "communication"?