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

From: Pekka Savola <[email-masked]>
Date: Wed, 3 Nov 2004 07:39:55 +0200 (EET)

On Thu, 21 Oct 2004, Brian E Carpenter wrote:
> It is proposed to forward
>    draft-ietf-multi6-architecture-01.txt
> to the IESG for approval as an Informational RFC
>
> Any final comments must be sent to the WG list at [email-masked]
> within two weeks, i.e. at the latest on November 3, 2004.

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

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.

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.

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

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?

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

    the network.  IN the latter case there is also the consideration of

==> s/IN/In/

    IPSEC is necessary in this case, in order to avoid making changes to

==> s/IPSEC/IPsec/

    changes to the end-to-end interaction, as both endS of the

==> s/endS/ends/

   reasonable to assume that the identity assignation is not necessarily

==> s/assignation/assignment/ ?

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 ?

    [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').

10  Informative References

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

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Geoff Huston <[email-masked]>
Date: Wed, 03 Nov 2004 18:20:13 +1100

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.

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

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

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

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

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

yep :-)

>   IPSEC is necessary in this case, in order to avoid making changes to

thanks

>   changes to the end-to-end interaction, as both endS of the

thanks

>==> s/assignation/assignment/ ?

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

>==> could there be an empty line between the questions, so it would be more

yes - this appears to be a xml2rfc thing

>==> there's some crap here ('draft-ietf-multi6-things-to-think-abou').

yep - will fix

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Nov 2004 03:02:09 +0200 (EET)

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

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

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

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

>    an outage in the path associated with the currently used address.

OK