Subject: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 26 Sep 2005 23:28:41 +0200

I was asked to review this draft.

As you'll see, there are some places where my comments overlap with
Jari's - I did this review before reading through his - but there are
also a number of separate issues.

Overall comments:
	
 	This draft is quite clear and informative, with some exceptions
 	where language blemishes makes understanding less easy than it
 	could be.
 
 	The major comment I have that I miss a clear explanation of the
 	benefits of Extended vs. Aggregated Home Networks.  For the
 	Virtual Home Network and the Mobile Home (which I really
 	would have called Nested Mobile Networks...) the merits and
 	drawbacks are discussed adequately.
 
 	A second overall comment is that the Appendix doesn't belong in
 	this document.  The rest of the document is, as is said in the
 	Abstract, a documentation of usage and issues, while the
 	Appendix is a proposal for protocol enhancement.  It should be
 	removed and if desired proposed in a separate document.
 
Detailed Review:

Section 1., para. 2:

>    In order to read this document properly, the distinction between the
>    concepts of Home Link and of Home Network must be very clear.  A Home
>    Link is a physical or a virtual Link, attached to a Home Agent.  A
>    Home Network is an aggregation that can be further subnetted.  As a
>    result, the Home Network is not necessarily contained on a Home Link.
>    In fact, the Mobile Network Prefixes are subnets of the Home Network.
>    How the two concepts relate in a given deployment depend on the
>    organization of the Home Network, as described below.

	Unfortunately, the above description does not at all make the
 	distinction clear to me.  Are the Home Network prefixes a subset of
 	the Home Link prefixes?  A superset?  Or something else?  I'm more
 	confused after reading the above than before...

Section 1., para. 5:

>    NEMO Extended Home Network: In this disposition, the Home Network is
>       only one subnet of a larger aggregation that encompasses the
>       Mobile Networks, called extended Home Network.  When at Home, a
>       Mobile Router performs normal routing between the Home Link and
>       the Mobile Networks.  More in Section 5.

	Disposition?  Maybe say layout or configuration instead?
 	[Disposition:
 	  * your usual mood; "he has a happy disposition"
 	  * disposal: the act or means of getting rid of something
 	  * inclination: an attitude of mind especially one that favors one
 	    alternative over others; "he had an inclination to give up too
 	    easily"; "a tendency to be too strict"
 	  * a natural or acquired habit or characteristic tendency in a person
 	    or thing; "a swelling with a disposition to rupture"
 	  * Determination of the final arrangement or settlement of a case
 	    following judgment. ]

Section 1., para. 9:

>    In all cases, the Home Agents collectively advertise only the
>    aggregation of the Mobile Networks.  The dichotomy is kept within the
>    Home Agents and the Mobile Routers, as opposed to advertised by means
>    of routing protocols to other parties.

	Umm - not sure I see a dichotomy here?  Maybe use some other word?
 	[Dichotomy:  A dichotomy is a division into two non-overlapping or
 	mutually exclusive and jointly exhaustive parts. They are often
 	contrasting and spoken of as "opposites". The term comes from
 	dichotomos (divided): dich- ([in] two) temnein (to cut).]

Section 4., para. 1:

>    With Mobile IPv6 (MIP6) specification [7] Mobile Nodes are at Home
>    when they are connected to their Home Link, where they recognize
>    their Home Prefix in Router Advertisement messages.  Also, a binding
>    is checked using of Duplicate Address Detection on the Home Link, and
>    Home Agents discover each other by means of Neighbor Discovery
>    extensions over that link.

	s/With Mobile IPv6/In the Mobile IPv6/
 	s/using of/using/

Section 4., para. 2:

>      The Home Prefix, that is advertised on the Home Link, is a final
>    prefix, as opposed to an aggregation, and it may be used by hosts on
>    the Home Link for autoconfiguration purposes.

	s/The Home Prefix,/The Home Prefix/
 	s/Home Link,/Home Link/

Section 5.2, para. 4:

>    In implicit mode, the Home Agent has the necessary information to
>    continue routing to the MNPs in the absence of registration, and the
>    participation of the Mobile Router to the Home IGP is not required.

	IGP is not defined - please do so.

Section 5.2, para. 6:

>    Alternate procedures for ensuring the connectivity of the Mobile
>    Networks when at home are described in Section 7.

	s/Alternate/Alternative/

Section 5.3, para. 2:

>    In that case, the Home Address does not match the Home Link Prefix,
>    and there is a need to configure the Home Agent in a specific mode
>    with the support for the extended Home Network and the range of the
>    Mobile Network Prefixes.  Based on that new configuration, the Home
>    Agent can accept a Home Address that is not from the Home Link, and
>    it will know that it should not perform any DAD.

	Consistency: s/extended Home Network/Extended Home Network/
 	- above and in the rest of the document

Section 5.3, para. 5:

>    For all these reasons, this submode of extended is no more a trivial
>    extension to the MIPv6 Home Model, and it might not be compatible
>    with all implementations.

	s/submode of extended/submode of an Extended Home Network/
 	s/is no more a/is not a/

Section 5.4.1, para. 1:

>    In explicit mode, the routing to the MNP via the Mobile Router must
>    be restored when the Mobile Router is at Home.  This is normally
>    performed by the Mobile Router by means of the existing IGP.  In that
>    case, a specific support is required on the Mobile Router to control
>    the routing protocol operation, enabling the participation to the IGP
>    if and only if the Mobile Router is at home.  This support might not
>    be present in all implementations.

	s/participation to the IGP/participation in the IGP/

Section 5.5, para. 1:

>    The extended Home Network keeps the MIP6 concept of a Home Network
>    for both Mobile Nodes and Mobile Routers to take their Home Address
>    from.  Since there is no overlap between the prefixes that are
>    affected to MNPs and prefix(es) that are dedicated to the Home Link,
>    it is possible for MNs and Mobile Routers to coexist with that model.

	s/affected to/associated with/ - or possibly
 	s/affected to/assigned to/

Section 6., para. 0:

>    Also, when the Home Address is derived from the prefix on the Home
>    Link, the Home Agent behavior on the link trivially extends that of
>    MIP and the support should for that configuration should be available
>    with all implementations.

	s/the support should for that/support for that/

Section 6.1, para. 7:

>    Note that in that case, it makes sense for a Mobile Router to
>    register using a Home Address from one of its own MNPs.  Taking the
>    Home Address from its own range guarantees the uniqueness of the
>    suffix.  That uniqueness can be checked by the Mobile Router on its
>    ingress network using DAD.

	Maybe add a reference to RFC 3753 for the first use of ingress and
 	egress interface / network?

Section 6.2, para. 3:

>    Note that it must expect a shorter prefix than that of its Mobile
>    Networks, even if its Home Address is formed out of one of its MNPs,
>    but that the Home Address still matches the Home Network Prefix.

	This paragraph needs a bit of re-write.  Maybe something like:
 	-
 	Note that it must expect a shorter prefix than that of its Mobile
 	Network(s).  Even if its Home Address is formed out of one of its MNPs,
 	the Home Address must still match the Home Network Prefix.

Section 6.2.1, para. 0:

 6.2.1  Returning Home by egress

	Maybe better 'Returning Home with the Egress Interface' ?

Section 6.2.1, para. 3:

>    Alternatively, the Mobile Router might perform ND proxying for all
>    addresses in its MNPs, between the egress and the related ingress
>    interface.  Since the prefixes on the egress and ingress interfaces
>    are overlapping, routing is disallowed.

	This paragraph is not too clear to me.  So, here we aren't
 	bridging, and we aren't routing, so how can traffic flow?

Section 6.2.1, para. 6:

>                Figure 3: Bridging between egress and ingress

	I don't see the difference between Figure 2 and Figure 3.
 	Should I?

Section 6.2.2, para. 0:

 6.2.2  Returning Home by ingress

	Maybe better 'Returning Home with the Ingress Interface' ?

Section 6.2.2, para. 4:

>    This fits the connected route model, since the Aggregated Home is
>    truly located on that network.  Note that in that case, it makes
>    sense for a Mobile Router to register using a Home Address from one
>    of its own MNPs. .

	Spurious full stop (".")
 	Additionally, the above paragraph seems to say that it does _not_
 	make sense for the Mobile Router to register using a Home Address
 	from one of its own MNPs as described in Section 5.3 ...
 	Could the document be more clear - maybe clearly recommend that
 	the Section 5.3 mode not be used?

Section 6.3, para. 1:

>    With this model, there is no specific space for independent nodes as
>    any address in the aggregation belongs to a MNP, and thus to a Mobile
>    Router.  This configuration excludes the cohabitation with MIP6 MNs
>    on the Home Link.

	s/independent nodes as/independent nodes, as/

Section 6.3, para. 2:

>    A Mobile Router that is at Home must own an address from the
>    aggregation on its egress interface and an address from its MNP -a
>    subnet of that aggregation- on its ingress interface.  A pure router
>    will reject that configuration, and the Mobile Router needs to act as
>    a bridge to enable it.  In order to deploy the aggregated Home
>    Network model, one must check whether that support is available in
>    the Mobile Routers if returning Home is required.

	Isn't this a clear deployment caveat, belonging in the next
 	section?

Section 6.4.1, para. 1:

>    A node on the Home Link discovers that the Aggregated Home Network is
>    actually a subnet on the Home Link and may use the prefix on the Home
>    Link to autoconfigure a Home Address.  Such a node may also install a
>    connected route to the Aggregated Home Network over the Home Link.

	I'm having a bit of trouble with the formulation here.  Do you mean
 	to say:
 	"If a node were to discovers that the Aggregated Home Network is
 	actually a subnet on the Home Link it might use the prefix on the
 	Home Link to autoconfigure a Home Address. ..." ?
 	- if so, maybe say that :-)  and also adjust the rest of the text
 	and the next paragraph accordingly.

Section 6.4.2, para. 2:

>    Also, note that NEMO authorizes multiple registrations for a same MNP
>    by different Mobile Routers.  This is a case of multihoming, and it
>    normally means that the Mobile Routers are interconnected by the
>    ingress network that bears the common MNP.  But there is no provision
>    in NEMO basic support to test that this condition is met at binding
>    time and maintained overtime.

	s/overtime/over time/

Section 6.4.2, para. 3:

>    It is thus possible for 2 different Mobile Routers to register a same
>    prefix with different Home Addresses, and this will cause an
>    undetected problem if the corresponding ingress links are not
>    connected.

	s/register a same/register the same/

Section 7., para. 0:

>    When the Home Address of a Mobile Router is derived from its MNP,
>    there is thus an additional risk of an undetected misconfiguration if
>    the Home Address is autoconfigured from the ingress link as opposed
>    to statically assigned with the MNP itself.

	s/assigned with the MNP itself/assigned to the MR/ ??

Section 7.1, para. 1:

>    The Home Link can be configured on the Home Agent on a virtual link,
>    in which case there's no physical Home Link for Mobile Routers to
>    return Home or for Home Agents to discover each others and perform
>    the ND level interactions as described in Mobile IPv6. [7]

	s/return Home or/return Home to, or/
 	s/interactions as/interactions on, as/

Section 7.1, para. 2:

> 		      /48                       eg: A:B:C::/48
>                     HA
>                     | /64                         A:C:C:E::/64
>          --+-----+--+- . -+- . -+--
>            |     |        |     |
>            MR1   MR2      MRi   MRN
>            /64   /64      /64   /64            A:B:C:i::/64  0 < i <= N

	s/eg/e.g./

Section 7.1, para. 15:

>    Some solutions can be proposed in order to perform an equivalent of
>    returning Home on a virtual Home Network.  One such approach is
>    sketched in appendix as an illustration.

	s/appendix/Appendix A/

Section 7.2, para. 1:

>    At some point in the future, NEMO basic support may be extended to
>    operate fully at L3 for instance if the HAHA protocol [11] gets
>    standardized and deployed.  Until then, NEMO operations still inherit
>    from mobile IPv6 [7] for the Home Agent to Home Agent communication,
>    which is basically based on Neighbor Discovery extensions over the
>    Home Link.  Making that link virtual bars the deployment of multiple
>    Home Agents, which may be desirable for reasons of load balancing.
>    Please refer to the NEMO multihoming issues [12] draft for more on
>    this.

	s/from mobile IPv6 [7] for the Home Agent to Home Agent communication,
 	 /the Home Agent to Home Agent communication from Mobile IPv6 [7]./
 	s/which is basically/This is basically/
 	-
 	Although I'm not sure if this paragraph should be kept in the
 	published document - it's speculative and may not make sense
 	to have there in 2 or 20 years?

Section 8.1, para. 1:

>    In this disposition, there is a bitwise hierarchy of Home Networks.
>    A global Home Network is advertised to the infrastructure by a head
>    Home Agent(s) and further subnetted into Mobile Networks.  As a
>    result, only the Home Agent(s) responsible for the most global
>    (shortest prefix) aggregation receive all the packets for all the
>    MNPs, which are leaves in the hierarchy tree.

	s/disposition/set-up/ (or something else -- not disposition)

Section 8.1, para. 3:

>    An example of that is the Cab Co configuration.  When a Taxi Company
>    owns a /32 prefix, this prefix is advertised at a fixed point in the
>    Head Quarters.  Regional offices are deployed around the world.  Even
>    though these regional offices are relatively stable in terms of
>    location and prefix requirement -say this changes every few years-
>    making them mobile allows a simpler management when a move has to
>    take place, or should the ISP service change.

	s/example of that/example of this/

Section 8.1, para. 6:

>                   Figure 6:  CAB Company HQ configuration

	Really cute addresses.  Really.

Section 8.1, para. 11:

>                Figure 7:  CAB Company regional configuration

	"Home addrSsync" ??

Section 8.1, para. 12:

>    Note that the hierarchy occurs at a configuration level and may not
>    be reflected in the actual connection between nodes.  For instance in
>    the Cab Co case, cabs are roaming within the city, each one attaching
>    to a different hot spot, while the regional office is connected to
>    the infrastructure using some ISP connection.

	Sorry, I don't understand what you want to say with the first
 	sentence of this paragraph.

Section 8.1, para. 13:

>    But it is also possible to reflect the organizational hierarchy in a
>    moving cloud of Mobile Router.  If a Mobile Home Agent acts as
>    root-MR for a nested configuration of its own Mobile Routers, then
>    the communication between Mobile Routers is confined within the
>    nested structure.

	s/cloud of Mobile Router/cloud of Mobile Routers/

Section 8.1, para. 15:

>    If SFO is also the root-MR of a nested structure of cabs, the
>    communication between cabs is relayed by SFO and does not require the
>    satellite link.  SFO recursively terminates the nested tunnels to the
>      cabs and re-encapsulates all the packets between the nested cloud and
>    correspondents in the infrastructure in a single tunnel to CA5A, this
>    providing for nested NEMO Route Optimization.

	The difference between the two cases discussed here isn't too
 	clear to me.  Does it consist only of where the tunnels are
 	terminated, or is there also a difference with respect to the
 	routing geometry (which nodes the traffic from the leaf nodes
 	pass through?)

Section 8.2, para. 1:

>    This complex topology applies to large distributed fleet, mostly if
>    there is a single interchange point with the internet (e.g. a NAT or

	s/large distributed fleet/a large distributed fleet/

Section 12., para. 0:

>    Issue 6: Pass idnits.  Thanks Henrik for this great tool :)

	You're welcome :-)

Appendix A.:

	The language of the following appendix is less polished than the
 	language of the main body of the document, but I'm not reviewing
 	it in detail; instead I suggest that it belongs in a separate
 	document, as it's a proposal of a possible protocol enhancement
 	and not just a description of usage scenarios of the basic
 	protocol.

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 30 Sep 2005 11:06:05 +0200

>>>> [<PT>]
>>>> [<PT>] The Home Network is a whole network whereas the Home Link
just
>>>> has a subnet. The sentence that covers this is:
>>>>  " the Home Network is not necessarily contained on a Home Link".
>>>> We can add a few words there to make it more specific like
>>>>
>>>>  " the Home Network is not necessarily contained on a Home Link,
but can
>>>> be distributed between the Home Link and the Mobile Networks"
>>>>
>>>> Is that better?
>>>
>>>Slightly, but not enough, I think.  After trying out various
formulations,
>>>I actually think it would be better to reduce the paragraph to this:
>>>
>>>   In order to read this document properly, it is important to
realise
>>>   there is a distinction between the concepts of Home Link and Home
>>>   Network, and in a NEMO context these may not at all be equivalent.
>> [<PT>] What about:
>>     In order to read this document properly, it is important to
realize
>>     that in a NEMO context, the Home Network is not bounded by the
Home Link.
>>     How the two concepts relate in a given deployment depends on the
>No - remember, this is at the very beginning of the document.  Reading
this
>would still leave me wondering - what is meant here - bounded?
Physically?
>logically? prefix-wise?  what??
>
>My earlier suggestion still seems to me like a good one - would you
consider
>it again?

[<PT>] The problem that I tried to change was in the comparison of a
Link (usually a L2 term) and a Network (usually a L3 term). I wanted to
say that in MIP, the Network overlaps with - is congruent to, whatever -
the Link. But in NEMO, the network is much wider as it spans the Home
Link and all the Links that the MRs carry with them.  

Could you then reword a bit?

>>>> [<PT>] We want to show the difference between fig 3 and fig 4
actually.
>>>> These are about how things actually plug physically. Fig 2 is a
>>>> configuration thing, stressing where the prefixes are assigned and
it
>>>> compares to fig 1. I still think it's OK like that. Too many words
might
>>>> clouds things even more, and bore some readers.
>>>
>>>The problem is that now a reader (at least this reader) is wondering
why
>>>you don't just refer back to Fig. 2.  So why not just refer back to
Fig. 2? :-)
>>>
>> [<PT>]
>>
>> I see your point. 2 reasons, none great. First is that the picture is
>> collocated with the text so the reader does not have to search for
it.
>> Second is that even is some actual drawing is the common, one refers
to
>> configuration and the other to arrangement, per our agreed upon
terms.
>> I'm afraid of an additional confusion if a same picture is used to
>> reflect the 2.
>
>No, that would be OK - now there is confusion because this reader
doesn't
>understand what the difference is and why the need for another figure.

[<PT>] Or we can change the figures to reflect the fact that one is
config and the other arrangement?
[<PT>] 

>> Note that this is a hierarchy in terms of configuration, which may
not
>> be reflected in the actual arrangement of nodes at a given point of
time.
>> For instance in the Cab Co case, some Cabs might roam to a different
city,
>> or even attach to the Headquarters.
>> "
>
>Ahh!  *That* I can understand.
>
>Of course, I then wonder if that will actually work - what happens if a
Cab
>attaches to a HA in a different city which doesn't have a matching
prefix?

[<PT>] Attaching is building a CoA, not binding. The CoA is formed from
a prefix that is exposed by another city, and globally reachable, so it
works. In terms of tunnels, it is an interesting story :)
I have deployed the whole thing using my implementation to check the
configuration. It works, cabs can be attached to other cabs, etc... When
you add RRH to the picture, you can even have SFO attach to one of its
cabs :)

Thanks again :)

Pascal