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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 29 Sep 2005 18:36:34 +0200

[<PT>] second round, same rules :)

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

[<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
    organization of the Home Network, as described below.

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

>>>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.
>
>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.
>
[<PT>] Well, it is normal for a Node to autoconf, and the result is
undesirable in that case:

	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 would 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 would lookup all MNNs on that MNP using
Neighbor Discovery
	over its interface to the Home Link, and fail.
[<PT>] 

>
>>>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.
>
>Mmm.  Maybe.  But I'm still not sure I understand it.  Maybe two small
>parallel examples are needed to illustrate the distinction.
[<PT>] What about:
"
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.
"

>
>
>>>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.
>
>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.
>
[<PT>] What about:

If SFO is also the root-MR of a nested structure of its own cabs, the
communication
between cabs is relayed by SFO and does not require the satellite link.
As of
traffic to the outside of the nested NEMO, SFO
recursively terminates the nested tunnels from its cabs and
reencapsulates all
the packets between the nested cloud and correspondents in the
infrastructure
in a single tunnel to CA5A. As a result, the unwanted effect of nesting
of tunnels
is avoided over the Internet part of the packet path.

Thanks again :)

Pascal

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 29 Sep 2005 21:24:19 +0200

Hi Pascal,

on 2005-09-29 18:36 Pascal Thubert (pthubert) said the following:
>>>>>    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.
>>>> 	distinction clear to me.  Are the Home Network prefixes a subset of
>>>> 	the Home Link prefixes?  A superset?  Or something else?  I'm more
>>>  " the Home Network is not necessarily contained on a Home Link, but can
>>Slightly, but not enough, I think.  After trying out various formulations,
>     that in a NEMO context, the Home Network is not bounded by the Home Link.

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>] We want to show the difference between fig 3 and fig 4 actually.
>>> compares to fig 1. I still think it's OK like that. Too many words might
>>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>] 
> 

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.

>>>>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:
>>>> 	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
>>> [<PT>] Not necessarily a Home address. Just plug any Host on that link.
>>>       includes the Aggregated Home Network prefix might use that prefix
>>>       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
> 	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 would also install a connected route to the Aggregated
> 	As a result, unless the node has a better (longest match) route to a given
>       Mobile Network Prefix, it would lookup all MNNs on that MNP using Neighbor Discovery

Looks good to me.

>>
>>>>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
>>> Nothing to do with the way things will be interconnected. What about :
> 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,

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?

>>>>>    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
>>> [<PT>] Nested Nemo causes nesting of tunnels (with NEMO BS). If the MRs
>>> nested tunnels. Once the inner packet is obtained, SFO will pass it to
>>> Some deployments failed to use that 'trick' causing extensive use of sat
>>> links.
>>>
>>Ok, so the distinction is one of where the tunnels are terminated, then?
> communication between cabs is relayed by SFO and does not require the
> satellite link. As of traffic to the outside of the nested NEMO, SFO
> recursively terminates the nested tunnels from its cabs and reencapsulates
> all the packets between the nested cloud and correspondents in the
> infrastructure in a single tunnel to CA5A. As a result, the unwanted
> effect of nesting of tunnels is avoided over the Internet part of the
> packet path.

Clearly better.  In the second sentence, s/As of/As for/.  Otherwise good.

> Thanks again :)

You're welcome!

	Henrik