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.
Understood and agreed. Better be verbose than overly brief.
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.
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.
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?
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.
OK
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings