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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 28 Sep 2005 14:27:25 +0200

Hi Henrik:

Thanks a lot for this detailed review. This is a very detailed work.
Many comments were just accepted as is and you'll find the result in the
pre 05 version, but I cut them from this mail, and left only the
discussions.
All is available at:
http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod
els-issues.html

Please note that the RFC editors do a great job in helping us
international writers finalize the text with all the appropriate
language. 

They might not get all the thanks they deserve, so this is an occasions
:)

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henrik Levkowetz
>Sent: Monday, September 26, 2005 11:29 PM
>To: [email-masked]
>Subject: [nemo] Review 2 of draft-ietf-nemo-home-network-models-04.txt
>
>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.
>
[<PT>] Thanks Henrik :)

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

>
>
>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. ]
[<PT>] Help anyone native in English? Seems that the last * is the one
covering what is meant here. The trouble with configuration is that in
our domain, it is often used as the configuration of a device, as
opposed to the arrangement of things is a larger system.

>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.
>
>
[<PT>] What about: 
	When the forms its Home Address out of one of its Mobile Network
Prefixes,
	since the Home Network prefix is an aggregation that encompasses
all
	the MNPs, the Home Address actually matches both prefixes. As a
result,
	the MR must expect a shorter prefix than that of the Mobile
Network from
	which the Home Address was formed.
 
>
>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?
>
[<PT>] We can not be routing. We are either proxying or bridging.
Depends if the interfaces are compatible for bridging... From Jari's
comment on that same part, I guess we will focus on proxying with a ref
to Dave's draft.

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

>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?
>
[<PT>] Yes. There is a comment by Jari around the same aspect.
Maybe we need to add a last sentence in 5.5 to say that we do not
recommend 
it for that reasons? I made that issue 8.
http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod
els-issue8.txt
[<PT>] 
>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?
>
[<PT>] I moved it; comments anyone?

>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.
>
[<PT>] Not necessarily a Home address. Just plug any Host on that link.
	We meant something like this: 
	A node on the Home Link receiving a Router Advertisement that
includes the
	Aggregated Home Network prefix might use that prefix for Address
Autoconfiguration.
	Such a node may also install a connected route to the Aggregated
	Home Network over the Home Link.

	As a result, unless the node has a better (longest match) route
to a given
      Mobile Network Prefix, it will lookup all MNNs on that MNP using
Neighbor Discovery
	over its interface to the Home Link.
>
>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/ ??
>
[<PT>] In fact, when you configure the address on the interface, you
also configure the MNP by providing the prefix length. I think the text
is OK?
>
>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?

[<PT>] Same from Jari... I removed the first sentence
>
>
>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.
>
[<PT>] Trying to say that the hierarchy is a configuration thing.
Nothing to do with the way things will be interconnected. What about : 
  Note that this is a hierarchy in terms of configuration, which may not
  be reflected in the actual connection between nodes.
>
>
>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?)
>
[<PT>] Nested Nemo causes nesting of tunnels (with NEMO BS). If the MRs
belong to a same HA, then the HA terminates recursively a number of
nested tunnels. Once the inner packet is obtained, SFO will pass it to
CASA over its own MRHA tunnel. 

Some deployments failed to use that 'trick' causing extensive use of sat
links.

This is also an advantage of shared proxies in the global HAHA case.
>
>
>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.
[<PT>] 
[<PT>] We got pretty much the same from Jari. Comments anyone? I guess
that this is part of issue 7.

Again, thanks a lot.

Pascal

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 28 Sep 2005 23:06:59 +0200

Hi Pascal,

> pre 05 version, but I cut them from this mail, and left only the

Makes sense.

> All is available at:
> http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models-issues.html
> 
> 
>>>    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
>>>    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.
>> 	distinction clear to me.  Are the Home Network prefixes a subset of
>> 	the Home Link prefixes?  A superset?  Or something else?  I'm more

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.
   How the two concepts relate in a given deployment depend on the
   organization of the Home Network, as described below.

Then you don't get into trouble by trying to capture the fine distinctions
which is explained in the rest of the document in just one or two sentences :-)

>>
>>Section 1., para. 5:
>>
>>>    NEMO Extended Home Network: In this disposition, the Home Network is
>> 	  * inclination: an attitude of mind especially one that favors one
>> 	    alternative over others; "he had an inclination to give up too
>> 	  * a natural or acquired habit or characteristic tendency in a person
>> 	  * Determination of the final arrangement or settlement of a case
>> 	    following judgment. ]
>>
>>

The last bullet is about court cases, and not directly applicable here.
We need a different word.  What about "arrangement"?

>>>    Networks, even if its Home Address is formed out of one of its MNPs,
>> 	Network(s).  Even if its Home Address is formed out of one of its MNPs,
> 	When the forms its Home Address out of one of its Mobile Network Prefixes,
> 	since the Home Network prefix is an aggregation that encompasses all
> 	the MNPs, the Home Address actually matches both prefixes. As a result,
> 	the MR must expect a shorter prefix than that of the Mobile Network from

Looks better.  s/When the/When the MR/ in the first line.  Changing the order
of the first sentence may be even better.  What about:

	Since the Home Network prefix is an aggregation that encompasses all
	the MNPs, a Home Address that an MR forms from one of its Mobile Network
	Prefixes, will actually match both the Home Network prefix and its
	Mobile Network prefix.  To properly identify the Home Network, the MR
	must expect a shorter prefix than that of the Mobile Network from
	which the Home Address was formed.

>>>    interface.  Since the prefixes on the egress and ingress interfaces

Ok. 

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

>>>    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
> Maybe we need to add a last sentence in 5.5 to say that we do not recommend 
> http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models-issue8.txt

Sounds appropriate.

[...]
> 
>>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
>>	I'm having a bit of trouble with the formulation here.  Do you mean
>> 	to say:
>> 	actually a subnet on the Home Link it might use the prefix on the
>> 	- if so, maybe say that :-)  and also adjust the rest of the text
>       includes the Aggregated Home Network prefix might use that prefix
>       for Address Autoconfiguration. Such a node may also install a
> 	As a result, unless the node has a better (longest match) route to
>       a given Mobile Network Prefix, it will lookup all MNNs on that MNP
>       using Neighbor Discovery over its interface to the Home Link.

Ok.  But you need to use 'might', 'would', 'could' etc. to distinguish
this possible but undesirable behaviour from something which should be
done.  Looking forward to seeing some adjusted text.

>>>    there is thus an additional risk of an undetected misconfiguration if
>>>    the Home Address is autoconfigured from the ingress link as opposed

No, the language as it stands doesn't really make sense.  A fix is needed.
Maybe
	s/assigned with the MNP itself/assigning an address and MNP/ ?

>>>    standardized and deployed.  Until then, NEMO operations still inherit
>>>    from mobile IPv6 [7] for the Home Agent to Home Agent communication,
>>>    Home Link.  Making that link virtual bars the deployment of multiple
>>	s/from mobile IPv6 [7] for the Home Agent to Home Agent communication,
>> 	 /the Home Agent to Home Agent communication from Mobile IPv6 [7]./

That could work, supposing you've also adjusted the start of the second
sentence.

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

Mmm.  Maybe.  But I'm still not sure I understand it.  Maybe two small
parallel examples are needed to illustrate the distinction.

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

Ok, so the distinction is one of where the tunnels are terminated, then?
Avoiding unnecessary traffic up and back down over the common link is
a by-product of terminating the tunnels at the common HA, no?

I think the text needs to be clearer here.

> that this is part of issue 7.

Right.

> Again, thanks a lot.

You're welcome.

Regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 28 Sep 2005 23:17:53 +0200

A small correction to one of my comments:

on 2005-09-28 23:06 Henrik Levkowetz said the following:
[...]
> a by-product of terminating the tunnels at the common HA, no?

That should be:
		  			   "... over the common link is
a side-effect of terminating the tunnels at the common HA, no?"

	Henrik