Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt

From: Thierry Ernst <[email-masked]>
Date: Thu, 1 Dec 2005 14:28:29 +0900

Hi,

> > > >    because Mobile IPv6 defines its own Route Optimization
> > > >    mechanism in its base protocol suite as a standard,
> > > >    collaboration with this and NEMO brings various complexity.
> > > > 
> > > > NEMO = NEMO Basic Support ?
> > > 
> > > I don't so.  I think the text's intent was to refer to NEMO RO
> > > (and possibly Basic as well).
> > 
> > So, you may write "NEMO RO" not just "NEMO".
> 
> I need the co-author who wrote this text to confirm, but if the
> intention was indeed to imply NEMO-RO and NEMO Basic, then I will keep
> NEMO.  If it was only one of them, of-course we would switch to that.

But this would still not tell the reader if you are speaking about the
"NEMO protocols" (taking all you may think about) or the NEMO concept,
or the NEMO configurations, or just as a standalone term to describe a
network that moves.  I mean, I don't know what NEMO stands for in this
sentence.

> > > > 4.5.  Detection of New Functionalities
> > > > 
> > > > Is this an issue ? Isn't there a better place ?
> > > 
> > > Like?
> > 
> > For me it looks more like a requirement than an issue.
> > 
> 
> I am unwillingly to write a "Requirements" section, for fear of being
> accused trying to sneak in requirements for RO in a problem statement
> draft.  I would have it remained in the "Issues" section.  If you feel
> that "Issue" has a more specific meaning, then I would change the
> title of this section to "General Considerations".

This is a comment on naming the section "Issues" vs something else, not
on section 4.5 specifically: OK with your comment, so another term could
be"design goals" which is a smoother work for"requirements". But this is
just an editorial suggestion,  you guys kwow how it's the best for you
to present things. I'm fine with both.

> > > > 4.7.  Mobility Transparency and Location Privacy
> > > > 
> > > >    One advantage of NEMO Basic Support is that the Correspondent
> > > >    Nodes and Mobile Network Nodes need not be aware of the
> > > >    actual location and mobility of the mobile network.  With
> > > >    Route Optimization, it might be necessary to reveal the point
> > > >    of attachment of the Mobile Router to other nodes, such as
> > > >    the Mobile Network Nodes or their Correspondent Nodes.  This
> > > >    may mean a tradeoff between location privacy [17] (and
> > > >    mobility transparency) and Route Optimization.
> > > > 
> > > > Agree with location privacy, but mobility may still be
> > > > transparent to MNNs. You shouldn't group these
> > > > issues/requirements togethers.
> > > > 
> > > 
> > > The previous sentence read "necessary to reveal ... such as the
> > > MNNs or their CNs".  For MNNs, its mobility transparency.  For
> > > CNs, its location privacy.  We could of-course break it into two
> > > parts, but they stamped from the same thing: requiring the MR
> > > reveal its location to some other nodes.
> > 
> > I don't buy that "location privacy" is defined the way you seem to
> > define it. Location Privacy is about not providing my location to my
> > peers, not about not knowing where I am !
> 
> I don't see the difference between your interpretation and mine.
> 
> "Location Privacy is about not providing my location to my peers" is
> equivalent to how I see it: "For CNs, its location privacy".
> 
> "about not knowing where I am" is equivalent to how I see it "For MNN,
> its mobility transparency".
>
> > I advocate an independent paragraph on "mobility transparency" with
> > text taken from 4.7 and 4.3.
> > 
> I could attempt a split and get back to you.  My feeling is that the
> text will be largely similar (which is why I made the editorial
> decision not to split).  Please note that we are NOT trying to say
> location privacy = mobility transparency.  They are clearly distinct
> considerations. It is just that I feel that the text describing the
> two has so much overlapping that I grouped them into one sub-section.
> In the text, we have clearly use the terms location privacy and
> mobility transparent distinctly so that it shouldn't create the
> impression that they are the same thing (which apparently, we failed,
> judging on your comments).

I guess your definition of "mobility transparency" and yours are
different. Mine is contained in draft-ietf-nemo-requiremnents 3.3.
Network Mobility Support Transparency. A MNN can be aware of its
location while "mobility transparency" is enforced. So, this is why I'm
saying "mobility transparency" and "location privacy" are orthogonal and
should be dealt with in distinct sections.

> > > >    Using the Mobile Network Prefix would usually mean that the
> > > >    initiator is the Mobile Router, and has the benefit of
> > > >    binding numerous Mobile Network Nodes with one signaling. 
> > > >    However, it also means that if location privacy is
> > > >    compromised, the location privacy of an entire Mobile Network
> > > >    Prefix will be compromised.
> > > > 
> > > > s / will / would
> > > > 
> > > 
> > > That is subjective I think.  But no harm changing :)
> > 
> > Native English speakers will correct me if I'm wrong but I've learnt
> > that the future tense cannot be used after words like "if, when,
> > after,.." etc.
> > 
> 
> I am not a native english speaker, but I think I have heard
> expressions such as "if you XXX, I will kill you!" numerous times :). 
> I think your rule refers to the "XXX" part (e.g. there is no "If you
> will do ..."), not the "then" part.

Isn't it "if you XXXX, I kill you!" ? BTW, English being used by so many
non-native English speakers in the world, I wouldn't be surprised to see
the same mistake in loads of documents.

I guess no native English speaker reads this tread, otherwise we would
be fixed already  ;-)

> > > > 5.5.  How is Mobile Network Node's Address Bound to Location?

> > > >       This approach has the advantage of keeping the
> > > >       implementations of Correspondent Nodes unchanged. 
> > > >       However, it requires the root Mobile Router to act as a
> > > >       Neighbor Discovery proxy for all the Mobile Network Nodes
> > > >       that are directly or indirectly attached to it.  This
> > > >       increases the processing load of the root Mobile Router.
> > > >       In addition, a change in the point of attachment of the
> > > >       root Mobile Router will require every nested Mobile Router
> > > >       (and possibly Visiting Mobile Nodes) to change their
> > > >       care-of addresses. Not only will this cause a burst of
> > > >       Binding Updates where every Mobile Router and every
> > > >       Visiting Mobile Node start sending Binding Updates to
> > > >       their Correspondent Entities, it will also cause a burst
> > > >       of Duplicate Address Discovery messages to be exchanged
> > > >       between the mobile network and the access network. 
> > > >       Furthermore, route optimization for Local Fixed Nodes is
> > > >       not possible without new functionalities implemented on
> > > >       the Local Fixed Nodes.
> > > > 
> > > > At LFNs, these are functionalities not related to mobility
> > > > support. I think we need to draw a line between mobility-related
> > > > functionalities and other. The other ones could be referred to
> > > > as"requirements" to distinguish between the two.
> > > > 
> > > 
> > > What are functionalities required for mobility support then?
> > 
> > A mechanism to send a BU is a mobility support functionality.  A
> > DHCP functionality is not a mobility support functionality. DHCP is
> > useful for any node, fixed or mobile, in a fixed network or a mobile
> > network which needs a dynamic address.
> 
> Agree, but the text is about mechanism to send BU for LFN.  Sure , for
> ND-proxy, you can always used DHCP or similar to have the LFN change
> their addreses.  That is not mobility.  However, this defeats the
> purpose of NEMO.  The ideal of NEMO is so that MNNs can retain their
> original source address.  So, the LFN we have would need some mobility
> management functionality in order to enjoy the benefits of RO, which
> is precise what we meant by "Furthermore, route optimization for Local
> Fixed Nodes is not possible without new functionalities implemented on
> the Local Fixed Nodes".

The text doens't say nor assumes that LFNs send BUs,. The MR sends the
BU. So,  what kind of mobility management functionality would be
required at the LFN ?

By the way, the text above mentions "careof address". In such a case,
what would be the home address for the LFN ? 

> > It would be nice from solution draft authors cited in ROSA to
> > provide a better published reference rather than for ROSA authors to
> > seek for this by themselves.
> > 
> Yes, authors please do so.

Hope they do.

Thierry.

-- 
Thierry ERNST, PhD
WIDE, Jun Murai Lab., Keio University, Japan
Nautilus6 Chair: http://www.nautilus6.org
Web: http://www.sfc.wide.ad.jp/~ernst/
T:+81-44-580-1600 F:+81-44-580-1437
--

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 01 Dec 2005 17:57:53 +0800

> network that moves.  I mean, I don't know what NEMO stands for in this

Ok, will add the word "Procotols", "Basic", or "Route Optimization"
depending on context.

> should be dealt with in distinct sections.

Here is the text from ietf-nemo-requirements:

   MNNs behind the MR(s) do not change their own physical point of
   attachment as a result of the mobile network's displacement in the
   Internet topology.  Consequently, NEMO support is expected to be
   performed only be the MR(s).  Specific support functions on any other
   node than the MR(s) would better be avoided.

(BTW, there is a typo: "be" -> "by" in line 4).

Ok, I will make some changes to the text in ROSA.

> BU. So,  what kind of mobility management functionality would be

The text is on ND-Proxy, not MR-as-Proxy.  So obviously MR is not
sending BU on behalf of LFN.

Instead, MR (or root-MR) is performing ND-Proxy for an address that is
configured from the AR's prefix.  For LFN to use this address, it means
(a) LFN use this address as its source address; or (b) LFN implements
mobility management and use this address as its CoA.

For both (a) and (b), LFN needs functionality to understand that MR is
performing ND-Proxy.  For (b), LFN needs mobility management
functionality.

Thus, I see no need to change the text in 5.5.3.

> what would be the home address for the LFN ? 

When CoA is used, its has always been used with VMN or child-MR.  If LFN
is changed to use this as CoA, it is no longer a LFN but a LMN.

/rgds
/cwng

---

From: Thierry Ernst <[email-masked]>
Date: Sat, 3 Dec 2005 00:21:38 +0900

> > > I could attempt a split and get back to you.  My feeling is that
> > > the text will be largely similar (which is why I made the
> > > editorial decision not to split).  Please note that we are NOT
> > > trying to say location privacy = mobility transparency.  They are
> > > clearly distinct considerations. It is just that I feel that the
> > > text describing the two has so much overlapping that I grouped
> > > them into one sub-section. In the text, we have clearly use the
> > > terms location privacy and mobility transparent distinctly so that
> > > it shouldn't create the impression that they are the same thing
> > > (which apparently, we failed, judging on your comments).
> > 
> > location while "mobility transparency" is enforced. So, this is why
> > I'm saying "mobility transparency" and "location privacy" are
> > orthogonal and should be dealt with in distinct sections.
> > 
> 
>    performed only be the MR(s).  Specific support functions on any
>    other node than the MR(s) would better be avoided.
> 

Good spot ! 
Shall I comment more on your draft so that you can spot typos on mine ?
;-)

> > > > > >       However, it requires the root Mobile Router to act as
> > > > > >       a Neighbor Discovery proxy for all the Mobile Network
> > > > > >       Nodes that are directly or indirectly attached to it. 
> > > > > >       This increases the processing load of the root Mobile
> > > > > >       Router. In addition, a change in the point of
> > > > > >       attachment of the root Mobile Router will require
> > > > > >       every nested Mobile Router(and possibly Visiting
> > > > > >       Mobile Nodes) to change their care-of addresses. Not
> > > > > >       only will this cause a burst of Binding Updates where
> > > > > >       every Mobile Router and every Visiting Mobile Node
> > > > > >       start sending Binding Updates to their Correspondent
> > > > > >       Entities, it will also cause a burst of Duplicate
> > > > > >       Address Discovery messages to be exchanged between the
> > > > > >       mobile network and the access network. Furthermore,
> > > > > >       route optimization for Local Fixed Nodes is not
> > > > > >       possible without new functionalities implemented on
> > > > > >       the Local Fixed Nodes.
> > > > > > 
> > > > > > support. I think we need to draw a line between
> > > > > > mobility-related functionalities and other. The other ones
> > > > > > could be referred to as"requirements" to distinguish between
> > > > > > the two.
> > > > > > 
> > > > > 
> > > > DHCP functionality is not a mobility support functionality. DHCP
> > > > is useful for any node, fixed or mobile, in a fixed network or a
> > > > mobile network which needs a dynamic address.
> > > 
> > > Agree, but the text is about mechanism to send BU for LFN.  Sure ,
> > > for ND-proxy, you can always used DHCP or similar to have the LFN
> > > change their addreses.  That is not mobility.  However, this
> > > defeats the purpose of NEMO.  The ideal of NEMO is so that MNNs
> > > can retain their original source address.  So, the LFN we have
> > > would need some mobility management functionality in order to
> > > enjoy the benefits of RO, which is precise what we meant by
> > > "Furthermore, route optimization for Local Fixed Nodes is not
> > > possible without new functionalities implemented on the Local
> > > Fixed Nodes".
> > 
> > The text doens't say nor assumes that LFNs send BUs,. The MR sends
> > the BU. So,  what kind of mobility management functionality would be
> > required at the LFN ?
> 

I think I was not in the right context then.

> configured from the AR's prefix.  For LFN to use this address, it
> means(a) LFN use this address as its source address; or (b) LFN
> implements mobility management and use this address as its CoA.
> 
> performing ND-Proxy.  

OK, but it makes this functionality a "mobility support" functionality,
or something else ?

> For (b), LFN needs mobility management
> functionality.

Well, it's not a LFN anymore then ;-)
 
> > By the way, the text above mentions "careof address". In such a
> > case, what would be the home address for the LFN ? 
> > 
> 
> When CoA is used, its has always been used with VMN or child-MR.  If
> LFN is changed to use this as CoA, it is no longer a LFN but a LMN.

It's right that you have mentioned Care-Of address in the context of a
VMN, but I didn't notice this detail when I commented on this. So, fine.

Thierry