Re: WGLC comments on draft-ietf-multi6-architecture-02.txt

[Geoff Huston <gih@apnic.net>]

John,

Thanks indeed for your careful review of this document. I've responded
inline to your questions, but in general I agree with the suggestions here

regards,

    Geoff


> Geoff,
>
> I support this draft going forward, I have a couple of issues, some questions
> but mostly nits.
>
> thanks,
> John
>
> Issues:
> ======
>
> 1) This document would benefit from a terminology section.  Perhaps a
> reference
>    to the Terminology section in RFC3582 as well.  Terminology to include
> would be
>    "session resilience"; add ULP, LLP and EIP; as well as others.

sounds like an excellent suggestion. I'll look into this



> 2) Section 5.3.1 - Triggering Locator Switches.  Inserting an information
> reference
>    to
> http://www.ietf.org/internet-drafts/draft-iab-link-indications-00.txt could
>    be useful. It seems to me that a crucial part of any multihoming
> solution will
>    be the triggering of a multihoming event.  I don't think we need to
> explicitly
>    list all of the potential triggers, but let the astute reader catch-up
> on some
>    related work.


Thanks for this. This has been a more recent contribution than the first
passes of the multi6 document, and I agree that a vcross reference here
would be useful


> Questions:
> =========
>
> 1) Section 4.3:
>
>    "The intent of multi-homing in the IPv6 domain is to achieve a
>    comparable functional outcome for multi-homed sites without an
>    associated additional load being imposed on the routing system."
>
>         This sentence seems incomplete, a comparable functional outcome
>         as compared to what?

I had implicitly added "to IPv4" in my head when I wrote that setence! :-)


> 2) 1st line, page 8:
>
>    "In addition to this objective of session resilience across network
>    reachability changes," ...
>
>         I had a hard time parsing this at first, perhaps the coffee  didn't
>         kick in.  Is it:
>
>    "In addition to this objective of session resilience across network
>    reachability changes," ...
>
>         or
>
>    "In addition to this objective of session resilience during network
>    reachability changes," ...
>
>         or
>
>    "In addition to this objective of session resilience in spite of network
>    reachability changes," ...


I think its the third. But it needs clarification in any case. What is
going through my head as I read your comments is the distinction between
session resilience DURING the period of routing instability while the
routing system reaches a new converged state as distinct to the objective
of session surviveability BEFORE and AFTER a routing change. I do not think
it is possible to undertake the former (DURING) given that there is no
reliable stable routing state during routing churn, so I did mean BEFORE
and AFTER.


> Nits:
> ====
>
> 1) Spacing problem, but this seems to be a Secretariat problem.

xml2rfc does have some quirky behaviours in lists.

> 2) Page 6:
>
>    "The environment of multi-homing is one that is intended to provide
>    sufficient support to local hosts so as to allow local hosts to
>    exchange IP packets with remote hosts, such that this exchange of
>    packets is to be seamlessly supported across dynamic changes in
>    connectivity."
>
>         Change 'seamlessly' to another term, perhaps
> 'transparently'?  Seamlessly
>         has a lot of mobility baggage, so it might be good to avoid that
> term.

agreed

and yes to the rest.


> 3) Expand first usage of ULP in section 4.2.
>
> 4) Section 4.3 (and others) "vs" should be "vs."
>
> 5) Section 5.3.1 - adding a new line before each bullet would increase
> readability.
>
> 6) "5.3.5  Dynamic Capability Negotiation
>
>
>    The common aspect of these approaches is that they all involve
>    changes to the end-to-end interaction, as both endS of the"
>
>         endS -> ends
>
> 7) Section 6 - insert a blank line between questions; otherwise it is
> somewhat
>    awkward to read.