Subject: [Monami6] Review of draft-ietf-monami6-mipv6-analysis-01.txt

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 12 Feb 2007 16:56:19 +0100

Hi,

I've reviewed draft-ietf-monami6-mipv6-analysis-01.txt .  The details
of the review are available below, and also on the web, inlined in the
full document text and colour-coded:
http://tools.ietf.org/rfcmarkup?url=http://levkowetz.com/ietf/reviews/review-ietf-monami6-mipv6-analysis-01.txt&comments=HENRIK

  General: 
    The document gives a comprehensive analysis of multihoming
    in the context of MIPv6, and in this regard, it is fairly complete.
    There are however a lot of editorial work and corner cases which
    I believe need some cleaning up.

  Nits: 
  * I believe it would be easier to read the document if the
    references were either given by name and reference number, or by
    symbolic references: "... RFC 3753 [4] ..." or "... [RFC3753] ..."
  * The language is too often a bit too formal, as if it was part
    of a patent application or legal document.  Less indirect language
    and a less formal style would be good in many places.

  Details:  

INTRODUCTION, paragraph 13:

>    The use of multiple interfaces is foreseen to provide ubiquitous,
>    permanent and fault-tolerant access to the Internet, particularly on
>    mobile nodes which are more prone to failure or sudden lack of
>    connectivity.  However, Mobile IPv6 currently lacks support for such
>    multihomed nodes.  The purpose of this document is to detail all the
>    issues arising through the operation of Mobile IPv6 on multihomed
>    mobile nodes.  A taxonmy is used to describe the different situations
>    where a mobile node is multihomed.  Issues are explained for each
>    multihomed configuration (number of interfaces, number of Home
>    Addresses or number of Care-of Addresses), and classified into
>    general IPv6 issues, issues pertaining to the specification of Mobile
>    IPv6, and issues related to the implementation of Mobile IPv6.  It is
>    not the intention of this document to imply that all issues must be
>    solved in the short term.

  The abstract starts out very abrupt, assuming that the reader already
  knows the context (IP mobility).  It would be better if this was
  established explicitly at the outset.  On the other hand, there
  are too many details at the end of the abstract to easily grasp on
  a once-through read to see if the docment is of interest to one --
  it would be better to cut out some of these details.

  s/taxonmy/taxonomy/

Section 1., paragraph 1:

>    The use of multiple addresses (allocated to either a single interface
>    or multiple interfaces) is foreseen to provide ubiquitous, permanent
>    and fault-tolerant access to the Internet, particularly on mobile
>    nodes which are prone to failure or sudden lack of connectivity.
>    Mobile IPv6 [1],[2] is designed to allow a mobile node to maintain
>    its IPv6 communications while moving between IPv6 subnets.  However,
>    the current specification of Mobile IPv6 lacks support for mobile
>    nodes with multiple addresses used simultaneously, i.e. multihomed
>    mobile nodes.  These addresses would be assigned to a single
>    interface or to multiple interfaces, which poses a number of issues.

  Same initial issue as for the abstract -- there's an assumption
  here about IP mobility which would be better state explicitly.

Section 1., paragraph 2:

>    Individual solutions have been proposed to extend Mobile IPv6 for
>    multihomed mobile nodes, but all issues have not been addressed in a
>    single document.  The purpose of the present document is thus to fill
>    up this gap by listing such issues, raising the discussion at the
>    IETF, and placing some requirements in order to propose comprehensive
>    solutions in forthcoming standards.

  This document doesn't really *address* the issues, as much as
  discuss them.  So it would probably to do s/been addressed in/been
  discussed in/.  Also: s/fill up this gap/fill this gap/.  The part
  about raising discussion within the IETF was relevant at the outset,
  but isn't really as relevant when being published as an RFC, so maybe
  take that out.  Also, with the next paragraph specifying two goals,
  it would probably be better to remove the last part completely,
  from 'The purpose..."

Section 1., paragraph 3:

>    This document has two goals.  The first goal of this document is to
>    define the requirements from the point of view of multihomed mobile
>    nodes operating Mobile IPv6.  The second goal of this document is to
>    define the issues arising when we attempt to fulfill these
>    requirements.  The definition of the potentially needed solutions is
>    out of scope of the analysis document.  These should be defined in a
>    separate document once the IETF community agrees on which issues
>    should be solved.

  s/The first goal of this document/The first goal/ s/The second goal
  of this document/The second goal/ I assume this document *is* the
  analysis document; in that case simply s/the analysis document/this
  document/ .  s/once the IETF community agrees on which issues should
  be solved//

Section 1., paragraph 4:

>    In order to reach the goals of this document, we define a taxonomy
>    which is used to describe the different situations where a mobile
>    node is multihomed.  For each case, we show the configuration a
>    multihomed node may have (number of Home Addresses or number of
>    Care-of Addresses).  We also illustrate each scenario.

  s/(number/(the number/ s/ or/, and the/ s/each scenario./each
  scenario with example diagrams./

Section 1., paragraph 5:

>    To understand the foundation of this document, the reader must read
>    our companion document [3] which outlines the motivations, the goals
>    and the benefits of multihoming for both fixed and mobile nodes (i.e.
>    generic IPv6 nodes).  Real-life scenarios as illustrated in that
>    document are the base motivations of the present study.  The reader
>    must also understand the operation of the Mobile IPv6 protocol ([1]).

  s/must read our/should read the/ s/must also/should also/

Section 1., paragraph 6:

>    The document is organized as follows: in Section 2, we introduce the
>    terminology related to multihoming and used in this document.  In
>    Section 3, we discuss what is required on the mobile nodes to fully
>    benefit from a multihomed configuration.  Then we propose in
>    Section 4 a taxonomy to classify the different cases where mobile
>    nodes are multihomed.  Thereafter the taxonomy is used in Section 5
>    to describe a number of multihomed configuration specific to Mobile
>    IPv6.  Finally we discuss in Section 6 and Section 6.3 all issues
>    related to a multihomed mobile node and we identify what is missing
>    to reach the goals outlined in [3].  These issues are classified into
>    IPv6 issues, Mobile IPv6-specific issues, and advices to
>    implementers.

  s/missing to/missing in order to/

Section 2., paragraph 14:

>       In [3], a node is said to be multihomed when it has multiple IPv6
>       addresses, either because multiple prefixes are advertised on the
>       link(s) the node is attached to, or because the node has multiple
>       interfaces (see the entire definition).  For a mobile node
>       operating MIPv6, this may translate into the following definition:

  s/operating/using/

Section 2., paragraph 15:

>       A MN (as defined above) is said multihomed when it has i) multiple
>       addresses which are used as source address (regardless of HoA/CoA)
>       or ii) multiple tunnels to transmit packets.  A MN may have
>       multiple HoAs/CoAs in the following cases:

  s/has i)/has either i)/ s/as source address/as source addresses/
  s/packets./packets, or both./ It is not obvious what is meant
  by "multiple addresses used as source addresses (regardless
  of HoA/CoA)".  The immediate thought is that ''..multiple source
  addresses would mean either multiple HoA or multiple CoA, so what is
  really meant here... Hmm...''.  Could this be written in a different
  and clearer way?  Or maybe just remove the "(regardless of HoA/CoA)"
  which could be more confusing than helpful?

Section 2., paragraph 21:

>       This indicates a scenario where the MN has the ability to use any
>       of the said multiple addresses at the same time.  This implies
>       that a packet with the destination field set to one of the said
>       multiple addresses will reach the MN, either directly from a CN to
>       the MN or through a tunnel with one of the MN's HAs.  This also
>       implies that any of the said multiple addresses can be used as
>       source address above the MIPv6 layer.

  This paragraph is maybe a bit too formal to be easily read
  and grasped.  Could you eliminate 'said' and re-write in a more
  direct manner?  Also, what do you mean by 'above the MIPv6 layer'?
  Inner tunnel address?  If so, I'm not sure whether this is correct
  in all cases...

Section 2., paragraph 23:

>       This indicates a scenario when there is at least one valid address
>       named for each of the said multiple interfaces, and that the MN is
>       able to simultaneously use these addresses.

  As above, loose the 'said' and re-write more straightforward.

Section 6., paragraph 4:

>    This can translate into the following enumeration of requirements:

  s/can translate/translates/ s/enumeration of
  requirements/requirements/ _or_ s/enumeration of requirements/list
  of potential requirements/

  It is somewhat disturbing that it isn't clear which of the goals
  are associated with the following requirements -- will fulfilment of
  these requirements result in achieving all of the goals?  Will none
  of the goals be fulfilled if a single one of the requirements are not
  fulfilled?  Or ... ??  It might be better to re-write this section as
  a list of capabilities which can be combined to achieve the goals,
  rather than expressing them as _requirements_.  Or alternatively,
  couple each requirement to one or more of the goals, explicitly.

Section 3., paragraph 0:

>    3.  A MN should be able to share its traffic load among its
>        interfaces, when several interfaces are activated and configured
>        with valid addresses.

  s/, when/ when/

Section 6., paragraph 0:

>    6.  If multiple HAs are available, the MN should be able to use
>        multiple HAs simultaneously for a given Home Address.

  Hmm.  Are you talking redundant HAs on the same link here, with
  VRRP switchover or similar, or are you talking multiple HAs in
  separate networks which both announce (BGP) the same prefix, or
  something else?  This should be clearer -- it's hard to be certain
  of what you really mean by 6. currently...

Section 7., paragraph 1:

>    One has to consider whether these goals can be achieved with
>    transparency or without transparency.  Transparency is achieved when
>    switching between interfaces does not cause the disruption of on-
>    going sessions.  To be achieved with transparency, a necessary (may
>    or may not be sufficient) condition is for the end-point addresses at
>    the transport/application layer to remain unchanged.  This is in view
>    of the large amount of Internet traffic currently carried by TCP,
>    which unlike SCTP, cannot handle multiple end-point address pairs.

  Ooops - now it reads as if the requirements above are goals,
  not requirements -- not sure if you mean to refer to 1-6 at the
  beginning of the section, or 1-7 just above. (And it probably would
  be good to use 1-7 and a-g instead...)

  s/To be achieved with transparency/to achieve transparency/
  s/SCTP,/SCTP/

Section 7., paragraph 2:

>    In the future, when a Shim6 protocol [5] is designed and deployed,
>    upper layer transparency may be maintained even if end-point
>    addresses are changed.  However, as Shim6 is in its early design
>    phase as of the writing of this memo, we will continue to assume that
>    an end-point address change would cause a transport layer disruption
>    throughout this document.

  I guess this is correct, but note that from an upper layer
  viewpoint, this is maybe not a particularly enlightening way of
  looking at SHIM6.  From that viewpoint, SHIM6 provides a mobility
  protocol with different characteristics than MIPv6, and both can let
  the upper layers see stable endpoint identifiers even if underlying
  locators change; it's just that it's done with different mechanisms.

  I suggest you remove this paragraph.

Section 4., paragraph 1:

>    In order to examine the issues preventing a MIPv6 mobile node to meet
>    the requirements listed in Section 3 we use in the present document
>    the following taxonomy (x,y) where:

  Here we come to what has been my greatest reservation with this
  taxonomy: This is formally clear and succinct, but a single tuple
  is hard to understand and remember the implications of if you
  haven't recently read this document.  I'd prefer almost any kind
  of alternative notation which made it easier to grasp, without
  remembering the order, which indicator belonged to the HoAs and
  which belong to the CoAs.  Some possibilities:

  (Hx,Cy) - e.g., (H1,Cn), (H*,C1), (H1,C1) hx/cy h1/cN, h*/c1,
  h1/c1 HxCy H1Cn, H*C1, H1C1

  This would make it possible to see from the notation whether it
  was the first or second indicator which belonged to the HoA, etc.
  I don't care particularly exactly which notation is used, as long
  as it is clearly more self-explanatory than (n,1) or (1,*) etc.

Section 4., paragraph 10:

>    Figure 1: Illustration of the Taxonomy

  The exact meaning of the '::=' symbol isn't self-evident.  Maybe use
  words, or add an explanation?

Section 4., paragraph 13:

>    The configurations denoted by these parameters will have an impact on
>    the way multihoming is supported.  According to the number of HoAs
>    and CoAs, different policies will be needed, such as "which CoA has
>    to be mapped with which HoA", "must all the CoAs be mapped with all
>    the HoAs", etc.

  s/According to/Depending on/ s/mapped with/mapped to/g

Section 5.1., paragraph 2:

>    When the node in the same configuration has several interfaces, it
>    may lead to a special situation where a node is connected to both its
>    home link and a foreign link.  The MN is multihomed since it would be
>    able to use both interfaces.  The Home Address might be directly used
>    on the interface which is connected to the home link, and a Care-of
>    Address is configured on the other interface which is connected to a
>    foreign link.  There cannot be more than two interfaces, otherwise
>    the mobile node would either have (A) multiple interfaces on the home
>    link, or (B) multiple interfaces on foreign links.  For (A), there
>    would be multiple HoAs.  For (B) there would be multiple CoAs.  These
>    two cases would fall in another scenario, either (n,*) (see
>    Section 5.2, Section 5.4 and Section 5.5) or (*,n) (see Section 5.3
>    and Section 5.4).

  "There cannot be more than two interfaces, ..." -- This is not
  trivially true.  What is true is that there cannot be more than one
  interface used to connect to the home network, and one interface
  used to establish a CoA.  There can be any number of interfaces
  which are left inactive because of policy decision, user preference
  or MIP software limitations.

Section 5.1., paragraph 3:

>    Achievable goals (when the node has multiple interfaces): Ubiquitous
>    Access, Reliability, Load Sharing, Load Balancing, Aggregated
>    Bandwidth, Preference Settings.

  It's not obvious to me that this statement is correct; I'd for
  instance say that you can't achieve Ubiquitous Access, and only
  limite Reliability.

  Also, in para. 2 above, you have explained how you only cna have
  two interfaces used by the MN simultaneously, and only one at a time
  as HoA and one at a time as CoA.  However, you still say "multiple
  interfaces" here and below.  Either there is something fundamental
  I don't understand here, or you should change this to something else
  (1 HoA, 1 CoA) or qualify "multiple interfaces" in some other manner.

Section 5.1., paragraph 8:

>       Reliability can be achieved through bicasting since the MN has two
>       addresses and should be able to request any CN to duplicate
>       traffic to both of them.  However, MIPv6 does not allow the MN to
>       request bicasting on the CN (see Section 6.2.2).

  s/Reliability can/Reliability could/

Section 5.2., paragraph 1:

>    The MN is multihomed, since it has several HoAs.  This case may
>    happen when a node is getting access to the Internet through
>    different HAs (possibly distinct operators) and each offers a Mobile
>    IPv6 service to the node.  That way, the node will have a HoA per HA.
>    Alternatively, a single home network may be multihomed to the
>    Internet, leading to having multiple prefixes on the home link.  Thus
>    the MN would have multiple HoAs for a single home link.  Either case,
>    the node would need to configure a single CoA on the visited IPv6
>    subnet, and bind that single CoA to all the HoAs it owns.  If the MN
>    has multiple interfaces, only one interface is connected to a foreign
>    network.  The other interfaces are connected to their home links.

  s/ Either case/ In either case/ s/their home links./their home links,
  or are inactive./

Section 5.2., paragraph 2:

>    Achievable goals: Ubiquitous Access, Reliability, Load Sharing, Load
>    Balancing and Aggregated Bandwidth (if the MN has more than one
>    interface) and Preference Settings.

  I'd not say Ubiquietous Access, and I'd say Limited Reliability,
  Limited Load Sharing, Limited Aggregated bandwidth.  There are
  restrictions on each of these, so just saying that they are
  achievable in this configuration is misleading.

Section 5.2., paragraph 10:

>       In Bidirectional Tunnel (BT) mode, preference settings and load
>       sharing only affect the path between the CN and the HA(s), and not
>       the path between the MN and the HA(s), as long as the CoA does not
>       change.  In RO mode, the path between the MN and the CN does not
>       change if the CoA does not change.  As an entry in the binding
>       cache is identified by a HoA, the MN can register the same CoA
>       with all HoAs, on any distant node.  A mechanism would then be
>       needed for the MN to select which HoA should be used when a new
>       communication flow is initiated.  A similar mechanism is needed on
>       the CN side if it knows that multiple HoAs are assigned to the
>       same MN.  With such mechanisms, it would be possible to use
>       multiple HoAs at the same time, and load sharing could be
>       performed.  See in Section 6.1.1 where such path selection issues
>       are discussed.  It is also possible that the MN register one HoA
>       as a CoA for another HoA (see discussions in Section 6.3.1).

  Since it is likely in many (most?) scenarios of practical interest
  that it is the first hop from CoA towards HA which is most bandwidth
  constrained, this load sharing may be of limited value or interest.
  You probably should mention something about this.

Section 5.2., paragraph 11:

>    o  Load Balancing and Aggregated Bandwidth
>       Load balancing and aggregated bandwidth are achievable when the MN
>       has several interfaces.  In this case, the MN is attached to one
>       foreign link via one of its interfaces, and it is attached to home
>       link(s) with its other interface(s).  In this case, the MN can
>       spread flows over its interfaces.  Note that if a CN initiates a
>       communication, the interface that it will use on the MN would
>       depend on the information it has about this MN.

  As above, this load balancing and bandwidth aggregation may be of
  limited value or interest, and you probably should mention something
  about this, too.

Section 5.3., paragraph 1:

>    The MN is multihomed since it has several CoAs.  This case may for
>    instance occur when the interface of the node is connected to a link
>    where multiple IPv6 prefixes are available.  One possible reason for
>    this is that the visited network is multihomed and because of that,
>    multiple prefixes are available in it, one per provider.  Note that
>    one of the interfaces of the MN may be connected to its home link.

  I'm surprised that you mention the (at least to me) less interesting
  scenario of multiple CoAs on the same link, and don't mention the
  more interesting scenario of multiple independent interfaces who
  are not on the same link.  Fix?

Section 5.3., paragraph 2:

>    Achievable goals: Reliability, Load Sharing, Preference Settings,
>    Load Balancing and Aggregated Bandwidth (if the MN is equipped with
>    several interfaces)

  I'd split this in one CoA interface vs. multiple CoA interfaces.
  The extent to which the goals can be achieved differ between these
  cases.  In particular, in the case where you don't have any interface
  connected to the home network, the conclusion for all of the goals
  differ between the one-interface and the multi-interface case.

Section 5.3., paragraph 4:

>    o  Ubiquitous Access, Reliabiility

  s/Reliabiility/Reliability/

Section 5.5., paragraph 4:

>    Current situation with MIPv6

  The discussion here feels strange to me - I don't see how this case
  differs from any other non-mobility multihoming case, as long as
  you're in n HoA, 0 CoA situation.  I'd prefer to simply say so,
  OR if there is any point on which this situation differs from that
  case, specifically point out such points, rather than keep to the
  format of the previous 5.x sections...

Section 6.1.1., paragraph 7:

>       This choice would be made at the time of a new communication flow
>       set up.  Usual IPv6 mechanisms for source and destination address
>       selection, such as "Default Address Selection for IPv6" [7] could
>       be used.

  Possibly you should also mention the use of DNS SRV records, and
  which address(es) to announce for the DNS A / AAAA records.

Section 6.1.1., paragraph 10:

>       When multiple CoAs are available, the MN and its communicating
>       peers (HA and CNs) must be able to select the appropriate CoA to
>       be used for a particular packet or flow.  The MN may use its
>       internal policies to (i) distribute its flow, and (ii) distribute
>       policies on distant nodes to allow them to select the preferred
>       CoA.  Solutions like flow binding [6] may be used.

  Humm.  How/when would *ever* a CN *choose* a CoA (as opposed to
  a HoA, which might result in RO to a CoA chosen by the MN) to
  communicate with?  If this statement is correct, some more text,
  maybe an example, would be good.

Section 6.1.1., paragraph 11:

>    Another related aspect of path selection is the concern of ingress
>    filtering.  This is detailed in Section 6.1.2.

  s/detailed/covered below/

Section 2, paragraph 0:

>    Currently, IPv6 has not clearly defined mechanism for failure
>    detection.  A failure in the path between two nodes can be located at
>    many different places: the media of one of the node is broken (i.e.,
>    loss of connectivity), the path between the MN and the HA is broken,
>    the home link is disconnected from the Internet, etc.  By now, MIPv6
>    only relies on the ability or the inability to receive Router
>    Advertisements within a stipulated period to detect the availibility
>    or loss of media (local failure).  Current effort [11] in the DNA
>    Working Group aims to address this, such as through the use of layer
>    2 triggers [12].  Movement detection might be extended to include
>    other triggers such as the loss of connectivity on one interface.
>    Further mechanisms would be needed to detect a failure in the path
>    between a MN and its CN(s), as well as between the MN and its HA(s),
>    between the MN and CN(s), or between the HA and CN(s).

  s/availibility/availability/

Section 6.2.1., paragraph 3:

>    To counter this issue, solutions like [13] may be used.

  This would be more readable if you would give the title, draft name,
  or other indication of what you're referring to...

Section 6.2.2., paragraph 1:

>    Rule 4 of RFC3484 specifies that a HoA will always be preferred to a
>    CoA.  While this rule allows to choose which address to use, it does
>    not allow MN to benefit from being multihomed in some cases.  When a
>    MN is multihomed, it may have one of its interfaces directly
>    connected to a home link.  This may have an impact on the way
>    multihoming is managed, since addresses from other interfaces cannot
>    be registered as CoAs for the HoA associated to the home link the
>    mobile node is connected on.

  s/allows to choose/allows the host to choose/ s/allow MN to
  benefit/allow the MN to benefit/

Section 6.3.1., paragraph 5:

>    In order to benefit from any multihoming configuration, a MN must be
>    able to register whatever address it owns with any of its HoA, as
>    long as the above statement is verified.

  s/verified/observed/

Section 6.3.2., paragraph 2:

>    With no such mechanism, the MN may be confused and may bind this CoA
>    to a possibly wrong HoA.  The result might be to bind the CoA to the
>    same HoA the previous CoA was bound to or to another one, depending
>    on the implementation.  It would indeed be better to specify the
>    behavior so that all implementations are compliant.

  It's not obvious to me how an HA can be 'wrong' in this respect.
  Surely, it would be possible, when aquiring a new CoA, to bind it
  to all of the HAs, (except possibly HAs on the same link as the CoA)?

Section 6.3.4., paragraph 1:

>    Internet connectivity is guaranteed for a MN as long as at least one
>    path is maintained between the MN and its CN.  When an alternative
>    path must be found to substitute for another one, the loss of one
>    path to the Internet may result in broken sessions.  In this case,
>    new transport sessions would have to be established over the
>    alternate path if no mechanism is provided to redirect flow
>    transparently at layers above layer 3.  The need for flow redirection
>    is given in Appendix A.

  Unclear language: "when an alternative path must be found to
  substitute for another one, ..."

  I'm not sure what you mean to say here.

Section 6.3.4., paragraph 3:

>    The second category is when the HoA changes: if one of the MN's HoA
>    needs to be changed, it influences the path between the CN and the
>    HoA.  In (n,*) cases, the MN has multiple HoAs.  If one fails,
>    established sessions on the failed HoA would break if no support
>    mechanism is used to redirect flows from a failed HoA to another,
>    unless the transport session has multihoming capabilities, such as
>    SCTP, to allow dynamic changing of addresses used.

  Again, it is not easy to understand what is meant here.  I think
  one of the problem is when you say 'needs to be changed', without
  qualifying with _where_ or _in which respect_ the need for change
  exists.

Section 7., paragraph 3:

>    Mention about relation with Shim6.

  This could be important, yes.

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 20 Feb 2007 16:48:45 +0100

Hi Henrik and all,

First, I would like to thank you very much for this deep review.
I tried to address all your comments. Please check the new version here:

http://www.rennes.enst-bretagne.fr/~montavont/ietf/draft-ietf-monami6- 
mipv6-analysis-02.txt

and the diff from 01 here :

http://www.rennes.enst-bretagne.fr/~montavont/ietf/diff-02-from-01.html

Anyone is welcome to discuss how I addressed Henrik's comments.  
Please do not hesitate to provide any feedback.

I would also like to draw your attention on section 3, which section  
I changed from Requirements to Nodes capabilties.

I just have few comments on which I have questions / comments. Please  
find them inline.

On Feb 12, 2007, at 4:56 PM, Henrik Levkowetz wrote:

[SKIP]

>   instance say that you can't achieve Ubiquitous Access, and only
	
NICOLAS: The achievable goals are not mobile IP dependant: it is
	dependant of the topology of the configuration. Normally, when
	you have multiple interfaces, you should be able to achieve
	these goals. See introduction of section 5.
	I have added: Achievable goals (when the MN has a
	single interface).

>   (1 HoA, 1 CoA) or qualify "multiple interfaces" in some other  
[SKIP]
>   achievable in this configuration is misleading.

NICOLAS: same comment as before: does the introduction of section 5 is
	clear enough? => these goals are only achievable if mechanisms
	are provided in addition to MIPv6.

>   You probably should mention something about this.

NICOLAS: agree. I have updated the text.
>   limited value or interest, and you probably should mention something

NICOLAS: I don't think it is a limited interest: the MN has the choice
	to use any of its interfaces, and the first hop at the MN may
	be the bottleneck

>   differ between the one-interface and the multi-interface case.

NICOLAS: but this paragraph describes the achievable goals, and not
	how to achieve these. I don't think there is a difference in
	the achievable goals (exept for the aggregated bandwidth,
	which is specified)

[SKIP]

>   format of the previous 5.x sections...

NICOLAS: Added the sentence : "This situation is quite similar to a
	non-mobile node which is multihomed." The based configuration
	is the same as a fixed node, exept that here the node IS
	mobile, this is why I would prefer to keep the same format for
	this section

>   maybe an example, would be good.

NICOLAS: Here we refer to a mechanism where the MN can advertise its
	multiple CoAs to HA/CN and possibly associated rules. Don't
	you think that the text already say that, and that the
	reference can be used to clarify such a mechanism?

[SKIP]

Nicolas