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

Sorry for not responding earlier; I was waiting for others' comments, 
and the ball got dropped.  Inline..

On Wed, 3 Nov 2004, Geoff Huston wrote:
> 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.

However, to be frank, I've had problems when reading the document. 
I've done it three times along the process, with different amount of 
concetration, and always I've thought, "so, what *were* the 
architectural issues?".  What I want to say is that the document 
structure, subsection titling or some other details are probably 
interfering with the readability of the document.

>> 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.

Then maybe some other reorganization would be possible, or a change of 
focus.  I'd just like to keep the sections concise, dealing with one 
particular issue only, so that it's easier to see the big picture 
without having to "combine the puzzle" in your head :-)

>> 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.

As above, then maybe some generic properties of e.g. locator selection 
should be discussed in a separate section, appropriately titled 
subsections or the like.

>> 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.

Yes, some of these issues could be pushed through hosts and locator 
selection to the hosts, maybe using some tools by the network 
management.  But if it's visioned this could be a significant part of 
the current solution set, then it should by all rights be expanded in 
the document to consider the different problems etc.

>> 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 document was just reorganized, while the topics are still the 
same, they should probably be classified here the same way as in the 
think-about.

>>   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