Re: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt

[Geoff Huston <gih@apnic.net>]

Pekka,

Thanks for your careful review of the document.

I've threaded responses to your questions and comments


regards,

  Geoff


At 04:39 PM 3/11/2004, Pekka Savola wrote:
> I've two bigger concerns here.  While they aren't changes which must be adopted, I think
> doing so would improve the document's readability a lot and help in clarifying its scope, so it
> might be worth the effort..

>1)
>
>The document is rather long and conversational in tone.


Yes. There is a fair amount of ground to cover and quite frankly in my case brevity would lead to a document that would quickly become cryptic. I chose this style as a) its a style I'm comfortable write in and b) I believe that it is suited to this form of architectural discussion, where the intent is not to be prescriptive in advocating one approach or another, but to look at the overall space and look at the manner in which various approaches choose to operate within this space.



> That's probably not a big problem, but I found it difficult to read, because there was not a clear structure in the document.  In particular, section 4.3 "Multi-homing: Identity Considerations" (which was discussing generic issues for further subsections) seemed ill placed to section 4.  More appropriate place for quite a bit of this discussion would be under section 5, possible under 5.3.2 in particular.


I'm afaid that I do not agree with this. The purpose of this section is to motivate the following 2 section (4.3 and 4.5) by looking at the common aspects of identity in the context of multi-homed environments without assuming a particular implementation class.

Section 5 is a more general discussion about identities, and section 4.3 would be out of place if moved there.


>I'd like to reduce the amount of generic discussion in section 4, just
>making it lay out the different approarches in sufficient detail, and
>refer to the following sections for lengthier (and more structured)
>discussion of the details.

This section (4) looks at generic styles of approach, rather than particular approaches, and looks at the potential advantages and possible limitations of multi-homing within the context of each style, and discusses them. The following section (5) is a more focussed examination of the behaviour and properties of identifiers.


>There are also some rather long sections or long paragraphs, which could be split into more digestible pieces.  E.g., section 5.1 could possibly be split into subsections based on the approach.  That could give more structure and make the document easier to consume.

I have used section headers as delimiters for particular topics which are then expounded in a single text block. Putting in a third level of heading would be somewhat disruptive to the flow of the argument I would contend.


>2)
>
>I've griped before about this document not having enough 'truth in advertising', i.e., it says it describes the architectural approaches to multihoming in IPv6, but does not go in sufficient detail to e.g., traffic engineering possibilities (the mention of this has been sprinkled along the draft though).  Still, I think this is a bit of misleading and we should try to avoid this.  I'd just make it clearer that this document focuses on connection survivability and not the whole multihoming problem space.

The document attempts to steer a neutral line between what some folk see as possibilities, and others see as unrealistic. For example, some would see host-based locator selection as a tool to push traffic along particular network paths which in turn could provide particular traffic engineering outcomes. while others would say that traffic engineering as an outcome of host-based locator selection is a case of fanciful thinking, as there is clearly insufficient network-based path state information provided to hosts to allow them to make an informed decision about a locator selection that would yield particular path characteristics and network load profiles.

>How to go about this (just an idea):
> - a note at the end of section 3 (or after the list quoted from 3582) that
>the focus is on ensuring connection survivability
> - rename section 4, Approaches to Multi-Homing, to include a note about
>connection survivability and the like
> - note in section 4.1 that this also provides more than just conn. surv.
> - maybe some minor tweaks in the abstract, introduction and the title

I' afraid that I don't agree with this approach - the document is intended to take an architectural view of multi-homing, and do so without particular limitation of perspective in terms of its architectural analysis.

>mostly editorial
>----------------
>
>   In addition, [2] documents further considerations for IPv6
>   multi-homing.  Again, the reader is referred to this document for the
>   detailed enumeration of these considerations.  The general topic
>   areas considered in this study include:
>   o  interaction with routing systems,
>   o  aspects of a split between end-point-identifier and forwarding
>      locator,
>   o  changes to packets on the wire, and
>   o  the interaction between names, endpoints and the DNS.
>
>==> does this call for minor edits to update to the latest think-about-...
>organization?

I do not believe so - what did you have in mind?



>   All transit providers for the site accept a prefix advertisement from
>   the multi-homed site, and advertise this prefix globally in the
>   inter-domain routing table.
>
>==> s/accept/need to accept/ (a slightly different nuance)?


The text here is describing a scenario, and the sense of the verb is
intended to be descriptive rather than prescriptive. In this case the
descriptive form "accept" is intended.



>   The possible application of the MIPv6 protocol to the multihoming
>   problem would be to use BU messages to convey information about
>   alternative addresses to be used after the outage.
>
>==> clarify: s/convey/convey prior to the outage/ ?

An alternative wording is:

    The possible application of the MIPv6 protocol to the multihoming
    problem would be to use BU messages to convey information in
    advance about alternative addresses that could be used following
    an outage in the path associated with the currently used address.




>   the network.  IN the latter case there is also the consideration of
>
>==> s/IN/In/

yep :-)


>   IPSEC is necessary in this case, in order to avoid making changes to
>
>==> s/IPSEC/IPsec/


thanks



>   changes to the end-to-end interaction, as both endS of the
>
>==> s/endS/ends/

thanks


>  reasonable to assume that the identity assignation is not necessarily
>
>==> s/assignation/assignment/ ?

I checked this - I believe I do mean assignation, in the sense of 'something assigned'



>6.1  Establishing Session State
>
>
>      What form of token is passed to the transport layer from the upper
>      level protocol element as an identification of the local protocol
>      stack?
>      What form of token is passed to the transport layer from the upper
>      level protocol element as an identification of the remote session
>      target?
>
>==> could there be an empty line between the questions, so it would be more
>readable ?

yes - this appears to be a xml2rfc thing



>   [4]  Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E.
>        Nordmark, "Mobile IP version 6 Route Optimization Security
>        Design Background", Work in progress: Internet Drafts
>        draft-ietf-mip6-ro-sec-01.txthttp://bgp.potaroo.net/ietf/idref/
>        draft-ietf-multi6-things-to-think-abou, July 2004,
>        <http://bgp.potaroo.net/ietf/idref/draft-ietf-mip6-ro-sec/>.
>
>==> there's some crap here ('draft-ietf-multi6-things-to-think-abou').

yep - will fix

>10  Informative References
>
>==> shouldn't some of these really be normative references ?

I do not believe so - this is not a specification document and hence
there are no base documents upon which this document relies.
That was my reasoning for using informative references in any case.

Again, thanks for your careful review of the document.

  regards,

   Geoff