Subject: [netlmm] [NEMO, NetLMM] for comments : The Problem Statements for NEMO in NetLMM domains

From: "Joo-Chul Kevin Lee" <[email-masked]>
Date: Mon, 5 Mar 2007 12:43:52 +0900

Dear folks.

I submitted a new internet-draft "The Problem Statements for NEMO in NetLMM
domains".

I think if the home network of a mobile router belongs to the NetLMM domain
and the mobile router moves in the NetLMM domain the MAG can't handle
packets
sent by nodes attached to the mobile network.

because the MAG may not know how to handle the packets based on
the mobile network prefix allocated to the mobile network. (the MAG
knows how to handle packets based on the prefix allocated to the
mobile router)

Comments are welcomed for this draft.
http://www.ietf.org/internet-drafts/draft-lee-netlmm-nemo-ps-00.txt

Abstract:
   The NetLMM protocol provides local mobility to the mobile node
   without requiring any modification of mobile node.  The NetLMM domain
   provides this service by maintaining forwarding state for the mobile
   node's prefix.  In case that the mobile node is a mobile router in
   the NetLMM home network the NetLMM domain may not have the forwarding
state
   for the mobile network prefix, so it can't forward packets from nodes
   within the mobile network, that is to say, existing NetLMM protocols
   do not consider mobile routers enough.

Best regards,
J. Lee

---------- Forwarded message ----------
From: [email-masked] <[email-masked]>
Date: Mar 1, 2007 5:50 AM
Subject: I-D ACTION:draft-lee-netlmm-nemo-ps-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : The Problem Statements for NEMO in NetLMM domains
        Author(s)       : D. Kaspar, J. Lee
        Filename        : draft-lee-netlmm-nemo-ps-00.txt
        Pages           : 13
        Date            : 2007-2-28

   The NetLMM protocol provides local mobility to the mobile node
   without requiring any modification of mobile node.  The NetLMM domain
   provides this service by maintaining forwarding state for the mobile
   node's prefix.  In case that the mobile node is a mobile router in
   the home network the NetLMM domain may not have the forwarding state
   for the mobile network prefix, so it can't forward packets from nodes
   within the mobile network, that is to say, existing NetLMM protocols
   do not consider mobile routers enough.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lee-netlmm-nemo-ps-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-lee-netlmm-nemo-ps-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-lee-netlmm-nemo-ps-00.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

-- 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
Joo-Chul Kevin Lee (ETRI)
Electronics and Telecommunications Research Institute.
161 Kajong-dong, Yusong-Gu, TAEJON, 305-350, KOREA
E-mail : [email-masked]/[email-masked] Tel : +82-042-860-1021
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Mar 2007 11:46:56 +0100

Joo-Chul, here are preliminary comments.  I think the Problem Statement 
NEMO for NETLMM is definitely worth the effort.

Joo-Chul Kevin Lee wrote:
> Dear folks.
> 
> I submitted a new internet-draft "The Problem Statements for NEMO in
>  NetLMM domains".
> 
> I think if the home network of a mobile router belongs to the NetLMM
> domain and the mobile router moves in the NetLMM domain the MAG can't
> handle packets sent by nodes attached to the mobile network.
> 
> because the MAG may not know how to handle the packets based on the
> mobile network prefix allocated to the mobile network. (the MAG knows
> how to handle packets based on the prefix allocated to the mobile
> router)

I think that is right.  If the PMA (HA) and MAG (AR) use Proxy Mobile 
IPv6, as in draft-sgundave, then I think there are issues about how the 
CN-to-LFN packets are encapsulated.

Normally, a MIPv6 HA would encapsulate a packet once towards MR.  With 
Proxy MIP6 there would be a need for double encapsulation, once towards 
AR and once towards MR.

this NEMO NETLMM ps draft says:
>    [netlmm-goals] describes the goals (or requirements) for NetLMM.
>    Section 3.7 "Support for Unmodified Mobile Nodes (Goal #7)" of
>    [netlmm-goals] says that the NetLMM solution should be able to
>    support any mobile node without requiring localized mobility
>    management software on the mobile node.  In this context, the mobile
>    node can be an ordinary host or a node that has some kind of global
>    mobility protocol.

Can we say that the mobile node can be a Mobile Router that runs NEMOv6?

this NEMO NETLMM ps draft says:
>   The NetLMM protocol has two principal functional entities, which are
>    called MAG (Mobile Access Gateway) and LMA (Local Mobility Anchor).
>    The LMA maintains a collection of routes for individual mobile nodes
>    and it will be used while the mobile node moves around in the NetLMM
>    domain.  The route information that the LMA keeps is, however, only
>    for the packets based on the subnet prefix allocated to the mobile
>    node itself.  Thus, if a mobile router joins the NetLMM domain as a
>    home network and moves around among MAGs that belong to the NetLMM
>    domain a MAG may not know how to handle the packets from nodes
>    attached to the mobile router because there is no way to inform the
>    MAG and LMA of the mobile network prefix.

Can we refine the problem.  And try to illustrate a packet from CN to 
LFN and what are the needed encapsulations.

Can we talk about ingress filtering.  What happens if a MR forwards a 
packet from its LFN towards CN through the AR?  The src address of that 
packet is LFN's address.  Is that packet ingress-filtered by AR?  Is 
there a risk for that?

Alex

> <http://www.ietf.org/internet-drafts/draft-lee-netlmm-nemo-ps-00.txt>
> 
> 
> 
> Abstract: The NetLMM protocol provides local mobility to the mobile
> node without requiring any modification of mobile node.  The NetLMM
> domain provides this service by maintaining forwarding state for the
> mobile node's prefix.  In case that the mobile node is a mobile
> router in the NetLMM home network the NetLMM domain may not have the
> forwarding state for the mobile network prefix, so it can't forward
> packets from nodes within the mobile network, that is to say,
> existing NetLMM protocols do not consider mobile routers enough.
> 
> Best regards, J. Lee
> 
> ---------- Forwarded message ---------- From:
> [email-masked] <mailto:[email-masked]>* 
> <[email-masked] <mailto:[email-masked]>> Date:
> Mar 1, 2007 5:50 AM Subject: I-D ACTION:
> draft-lee-netlmm-nemo-ps-00.txt To: [email-masked]
> <mailto:[email-masked]>
> 
> Author(s)       : D. Kaspar, J. Lee Filename        :
> draft-lee-netlmm-nemo-ps-00.txt Pages           : 13 Date
> : 2007-2-28
> 
> <http://www.ietf.org/internet-drafts/draft-lee-netlmm-nemo-ps-00.txt>
> 
> 
> [email-masked] <mailto:[email-masked]>
>  with the word unsubscribe in the body of the message. You can also
> visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change
> your subscription settings.
> 
> logging in, type "cd internet-drafts" and then "get
> draft-lee-netlmm-nemo-ps-00.txt".
> 
> http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Send a message to: [email-masked] <mailto:[email-masked]>. In
> the body type: "FILE
> /internet-drafts/draft-lee-netlmm-nemo-ps-00.txt".
> 
> NOTE:   The mail server at ietf.org <http://ietf.org> can return the
>  document in MIME-encoded form by using the "mpack" utility.  To use
> this feature, insert the command "ENCODING mime" before the "FILE" 
> command.  To decode the response(s), you will need "munpack" or a
> MIME-compliant mail reader.  Different MIME-compliant mail readers 
> exhibit different behavior, especially when dealing with "multipart"
> MIME messages (i.e. documents which have been split up into multiple
> messages), so check your local documentation on how to manipulate
> these messages.
> 
> _______________________________________________ I-D-Announce mailing
> list [email-masked] <mailto:[email-masked]> 
> Joo-Chul Kevin Lee (ETRI) Electronics and Telecommunications Research
> Institute. 161 Kajong-dong, Yusong-Gu, TAEJON, 305-350, KOREA E-mail
> : [email-masked]/[email-masked] 
> <http://[email-masked]/[email-masked]> Tel : +82-042-860-1021 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ netlmm mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Joo-Chul Kevin Lee" <[email-masked]>
Date: Thu, 15 Mar 2007 15:47:00 +0900

Hi~ Alex.

Thanks for your comment!

Please see inline.

> CN-to-LFN packets are encapsulated.

Yes, right.

> Proxy MIP6 there would be a need for double encapsulation, once towards

Yes,  this would happen after MR moves to visited network (which is NetLMM
domain).

> Can we say that the mobile node can be a Mobile Router that runs NEMOv6?

As <netlmm-goals> said, the mobile node can be a node that has some kind
of global mobility protocol. The NEMO is a global mobility protocol, so I
think
the Mobile Router can be a mobile node.

> LFN and what are the needed encapsulations.

If the Mobile Router uses NetLMM domain as its home network, the Mobile
Router
could send two kinds of packet; the first is packet from itself (which has
MR's prefix),
the second is packet from LFN(or LMN) (which has MNP).

So, If the MAG can maintain forwarding information for MNP, it can re-use
tunnel between MAG and LMA.

> packet is LFN's address.  Is that packet ingress-filtered by AR?  Is

hmm.. I have not thought about this issue yet, but if the MAG
doesn't have some information for packets which have MNP,
this could be an issue.

In the next revision, I'll consider this issue also :-).

- jclee.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Mar 2007 13:56:56 +0100

Hi Joo-Chul,

[...]
>> Normally, a MIPv6 HA would encapsulate a packet once towards MR.
>> With Proxy MIP6 there would be a need for double encapsulation,
>> once towards AR and once towards MR.
> 
> 
> Yes,  this would happen after MR moves to visited network (which is 
> NetLMM domain).

I see what you mean, MR has a problem when coming from outside to inside
a NetLMM domain.

But I think, IMHO, there may be another problem, even if MR stays 
_within_ the NetLMM domain.  Let me explain.

By current draft-sgundave, the MAG (Access Router) learns the home
prefix of the MR from some 'user-profile' data.  Or, that
is only the prefix of the Home Address of the MR.  That is not the
Mobile Network Prefix.  MNP and Home Prefix of HoA are different.

So, for MAG to be able to forward packets to LFN, MAG would need to know
the Mobile Network Prefix (prefix deployed within the mobile network, 
which gives the address of LFN).

The only possibility to fix this without touching draft-sgundave is to
have the MR to use its Mobile NEtwork PRefix as part of its Home Prefix
(the prefix of its HoA).  But this way of working is not the main way of
NEMO working, a Cisco draft ("Home Network Models") explains why.

Hence, the problem here, IMHO, is in MAG knowing only the prefix of MR's
HoA, and not knowing Mobile Network Prefix.

I don't propose any solution, just to say that draft-sgundave may have a
big issue in the way it relies on the Home Prefix of Mobile Nodes.

>>> The NetLMM protocol has two principal functional entities, which
>>> are called MAG (Mobile Access Gateway) and LMA (Local Mobility 
>>> Anchor). The LMA maintains a collection of routes for individual
>>> mobile nodes and it will be used while the mobile node moves
>>> around in the NetLMM domain.  The route information that the LMA
>>> keeps is, however, only for the packets based on the subnet
>>> prefix allocated to the mobile node itself.  Thus, if a mobile
>>> router joins the NetLMM domain as a home network and moves around
>>> among MAGs that belong to the NetLMM domain a MAG may not know
>>> how to handle the packets from nodes attached to the mobile
>>> router because there is no way to inform the MAG and LMA of the
>>> mobile network prefix.
>> 
>> Can we refine the problem.  And try to illustrate a packet from CN
>> to LFN and what are the needed encapsulations.
> 
> 
> If the Mobile Router uses NetLMM domain as its home network, the
> Mobile Router could send two kinds of packet; the first is packet
> from itself (which has MR's prefix), the second is packet from LFN(or
> LMN) (which has MNP).
> 
> So, If the MAG can maintain forwarding information for MNP, it can
> re-use tunnel between MAG and LMA.

Remark, the forwarding information the draft-sgundave PMIP6 MAG 
maintains is not for MNP, it's the Home Prefix of the Home Address of 
the Mobile Router.  MNP is different than the Home Prefix of the Home 
Address of the Mobile Router.  MAG currently has no means to know the 
MNP (by my IMHO reading of draft-sgundave).  And I'm not requesting to 
add it.

Nothing in NEMOv6 protocol requires the MNP to be any derivation of the
prefix that the Home Address uses, and I think it should stay that way,
if ever used in PMIPv6.

>> Can we talk about ingress filtering.  What happens if a MR forwards
>> a packet from its LFN towards CN through the AR?  The src address
>> of that packet is LFN's address.  Is that packet ingress-filtered
>> by AR?  Is there a risk for that?
> 
> 
> hmm.. I have not thought about this issue yet, but if the MAG doesn't
> have some information for packets which have MNP, this could be an
> issue.

I agree, it could.

> In the next revision, I'll consider this issue also :-).

Thanks, before next revision, can we identify what PMIPv6 needs to do in
order to leave place for a NEMOv6 extension of Mobile IPv6?

Alex

---

From: "Joo-Chul Kevin Lee" <[email-masked]>
Date: Sat, 17 Mar 2007 10:44:28 +0900

Hi~ Alex!

thanks for your comments, see inline please :-)

> big issue in the way it relies on the Home Prefix of Mobile Nodes.

Oh! this is the point that I have missed!

At first, I think that there is no problem in case that the visited network
is
NetLMM domain, because all packets from LFN would be tunneled
to the HA and the src address of those packets is the MR's CoA.

so, I think the MAG may be able to handle all packets from the MR.

I think this is an important comment.
I'll include this in next revision.

Thank you!

> MNP (by my IMHO reading of draft-sgundave).  And I'm not requesting to

Yes,  you are right, so I have used "IF" in my comment.
There was some ambiguity in my expression.
(English is not my mother tongue ;-) )
I would like to change my expression as follows;
=> "IF" the MAG "CAN GET" forwarding information for MNP.....

Except for this english expression, my thought is exactly same as yours,
MAG have no means to know how to handle MNP CURRENTLY. ;-)

> prefix that the Home Address uses, and I think it should stay that way,

yes, I agree.

> order to leave place for a NEMOv6 extension of Mobile IPv6?

Why not? we can discuss in ML.
Thanks for your good comment!

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 17 Mar 2007 15:18:31 +0100

Joo-Chul Kevin Lee wrote:
> At first, I think that there is no problem in case that the visited 
> network is NetLMM domain, because all packets from LFN would be
> tunneled to the HA and the src address of those packets is the MR's
> CoA.

Ok, I agree with you.

When MR is in a netlmm domain, logically only MAG encapsulates (not MR), 
because MR believes it is at home (so it doesn't tunnel).  MR believes 
it is at home because the prefix advertised by MAG to MR is the home 
network prefix.

> so, I think the MAG may be able to handle all packets from the MR.

If MAG receives a packet from LFN, that is forwarded by MR, then MAG 
doesn't know the prefix of the src address of that packet, because that 
is the MNP (MNP is not the home network prefix).  So MAG may ingress 
filter packets from LFN, which may be a problem.
[...]
> Yes,  you are right, so I have used "IF" in my comment. There was
> some ambiguity in my expression. (English is not my mother tongue ;-)
> ) I would like to change my expression as follows; => "IF" the MAG
> "CAN GET" forwarding information for MNP.....
> 
> Except for this english expression, my thought is exactly same as
> yours, MAG have no means to know how to handle MNP CURRENTLY. ;-)

I agree with that.

>> Thanks, before next revision, can we identify what PMIPv6 needs to do
>> in order to leave place for a NEMOv6 extension of Mobile IPv6?
> 
> Why not? we can discuss in ML. Thanks for your good comment!

I'm not sure authors of draft-sgundave ack this as a potential issue, 
and I'm not requesting adding text right now in any draft.

There are several ways in which this can be dealt with, that I don't know.

If we both identify a problem, it may be that PMIPv6 doesn't need the 
problem at all (for reasons out-of-this-WG) and ignore it.

All we (at least I) can do is to articulate the technical problem and 
then see what others think about the problem.

Thanks,

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 18 Mar 2007 02:24:38 -0700

Hi Joo-Chul,
 
NEMO support does not belong to the base draft and we did not cover it, but
a quick
comment on the discussion you guys are having. Again, this is a *general
discussion*
and does not mean the base draft is supporting all of this.
 
- Currently, we support PER-MN-Prefix model and so we create a prefix route
for the mobile
  node MN-HNP, over the tunnel.
 
- We allow the mobile node to obtain its address configuration in one more
ways. If the
  mobile node uses Stateless Auto Address Configuration using 3041 based
scheme,
  the mobile node can generate multiple addresses from its home network
prefix, using
  them as ephemeral addresses. I believe a popular OS stack, Vista by
default configures
  like 10 to 15 addresses from the same prefix block on its interface. So,
when supporting
  autoconf with this privacy support, the MAG may not predictably learn the
address that the
  mobile node is using. Off course, since it has the MAC address of the
mobile node and
  through other ways, the MAG can learn the address of the mobile node, but
the MAG can
  certainly forward the traffic to the mobile node's L2 address.
 
- The MAG may send the MNP options in the PBU, if it knows the networks that
are attached
  to the mobile node, either thru IGP or from static configuration. 
 
- The LMA can associate this MNP's to the mobile node's MN-HoA, if present
in the BCE
  or it can associate with a randomly chosen address from the MN-HNP. By
associating the
  MNP with any address from the mobile node's home prefix block, the route
can be established
  over the tunnel.
               
           - The Mobile Network Prefix (MNP) is reachable via MN-HoA or any
address from MN-HNP
           - MN-HoA is reachable via LMA-MAG tunnel.
 
So, any packet that is sent to a node in the MNP, the LMA will receive it
over the tunnel and 
after decap, it should forward the packet to the MN's MN-HoA or to the MAC
address of the 
mobile node.  So, when supporting NEMO and if the MAG cannot determine the
MN-HoA,
but, can use the L2 address of the mobile node for forwarding the traffic
after decap.

Sri

  _____  

From: Joo-Chul Kevin Lee [mailto:[email-masked]] 
Sent: Friday, March 16, 2007 6:44 PM
To: Alexandru Petrescu
Cc: [email-masked]
Subject: [netlmm] Re: The Problem Statements for NEMO in NetLMM domains

Hi~ Alex!

On 3/16/07, Alexandru Petrescu <[email-masked]
<mailto:[email-masked]> > wrote: 

Hi Joo-Chul,

Thank you! 

yes, I agree. 

I agree, it could.

Alex

E-mail : [email-masked]/[email-masked]

---

From: "Joo-Chul Kevin Lee" <[email-masked]>
Date: Sun, 18 Mar 2007 19:40:30 +0900

Hi Sri~ ;-)

I understand what you want to say. I don't insist that this issue should
be handled in current PMIP draft. I also agree that the most urgent job
of NetLMM WG is to finish NetLMM base protocol (i.e. maybe PMIP?)
ASAP.

But I wish that this issue should be handled as an extension of NetLMM
protocol. The comments that you replied are similar to the part of solution
that I have thought, so if NetLMM WG adopts this issues through re-chartering
we can contribute to this issue.

Thanks for your comments!

J.Lee.

On 3/18/07, Sri Gundavelli <[email-masked]> wrote:
>  ________________________________
> On 3/16/07, Alexandru Petrescu <[email-masked] > wrote:
> > Hi Joo-Chul,
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 18 Mar 2007 14:30:56 +0100

Sri Gundavelli wrote:
> Hi Joo-Chul,
> 
> NEMO support does not belong to the base draft and we did not cover
> it, but a quick comment on the discussion you guys are having. Again,
> this is a *general discussion* and does not mean the base draft is
> supporting all of this.

I agree, general discussion, and thanks for replying.

> - Currently, we support PER-MN-Prefix model and so we create a prefix
>  route for the mobile node MN-HNP, over the tunnel.

Yes, it's the Home Network Prefix of the Mobile Node.

> - We allow the mobile node to obtain its address configuration in one
>  more ways. If the mobile node uses Stateless Auto Address
> Configuration using 3041 based scheme, the mobile node can generate
> multiple addresses from its home network prefix, using them as
> ephemeral addresses. I believe a popular OS stack, Vista by default
> configures like 10 to 15 addresses from the same prefix block on its
> interface. So, when supporting autoconf with this privacy support,
> the MAG may not predictably learn the address that the mobile node is
> using. Off course, since it has the MAC address of the mobile node
> and through other ways, the MAG can learn the address of the mobile
> node, but the MAG can certainly forward the traffic to the mobile
> node's L2 address.

Thus defeating the purpose of privacy?  MAG can track the nodes by their 
MAC address?  MAG inruses the privacy of MN?

> - The MAG may send the MNP options in the PBU, if it knows the
> networks that are attached to the mobile node, either thru IGP or
> from static configuration.

I don't think MAG could know the MNP (Mobile Network Prefix) of all MRs 
that may come under it.  It may be that some MRs have several such MNPs, 
not one.  The Home Address and Home Network Prefix is indeed one-per-MN, 
but the MNPs aren't one-per-MR, they can be several-per-MR.

The MRs (like phones) don't run IGP, so for these IGP is out of scope.

Static configuration - why.

> - The LMA can associate this MNP's to the mobile node's MN-HoA, if 
> present in the BCE or it can associate with a randomly chosen address
> from the MN-HNP. By associating the MNP with any address from the
> mobile node's home prefix block, the route can be established over
> the tunnel.

Yes, if MAG knows the Mobile Network Prefix, I agree.

However, I think that simpler ways to achieve this exist, provided that 
PMIPv6 assumptions are modified.

I think PMIPv6-sgundave assumption that the MAG knows the HNP (Home 
Network Prefix) has several inconvenients.  One of them is that it 
requires extension of PMIPv6 to support MR.

If you wish, we can discuss simpler ways to achieve MR with PMIPv6, w/o 
PMIPv6 extensions.

> address from MN-HNP - MN-HoA is reachable via LMA-MAG tunnel.

Yes, at HA.

> So, any packet that is sent to a node in the MNP, the LMA will
> receive it over the tunnel and after decap, it should forward the
> packet to the MN's MN-HoA or to the MAC address of the mobile node.

Half-yes... not sure what you mean by LMA forwards to MAC address of MR, 
because LMA and MR are never on same link.

> So, when supporting NEMO and if the MAG cannot determine the MN-HoA, 
> but, can use the L2 address of the mobile node for forwarding the 
> traffic after decap.

Not sure what you mean here, but sounds a bit weird to forward based on 
L2 address, but maybe you mean differently.

Alex

---

From: "Joo-Chul Kevin Lee" <[email-masked]>
Date: Mon, 19 Mar 2007 22:53:22 +0900

Hi, Sri and Alex~

see inline please.

> > node, but the MAG can certainly forward the traffic to the mobile

I'm not sure what you are trying to explain here.
which part of this paragraph is related to "NEMO in NetLMM" issue?

> Static configuration - why.

I agree with Alex.

> > packet to the MN's MN-HoA or to the MAC address of the mobile node.

I'm not sure why LMA (not MAG?) will receive packet over the tunnel
when we want to send packet to a node in the MNP.

> because LMA and MR are never on same link.

I agree with Alex.