Subject: [netlmm] high-level technical comments to draft-sgundave

From: "Genadi Velev" <[email-masked]>
Date: Tue, 13 Mar 2007 16:31:03 +0100

Hi Sri,

thank you for the updated version of the I-D. IMO the readability of the
I-D has been improved. After going through the new version of the I-D, a
few high-level technical comments came to my mind.

A. During discussions on the DT solution (~6 months ago), the topic was
raised, if the LMA should be able to receive data packets over a tunnel
from a previous MAG after a new MAG has sent an update.  This may happen
because the previous MAG may still send packets (e.g. because of
buffering) after the MN moved to the new MAG.  DT solution supported
such an option.  Do you think it is feasible to allow this behaviour for
the LMA in PMIPv6?

B. If the MN is DNA-capable, after link-layer link-up notification the
MN sends Landmark Option (LO) in the RS message with the landmark prefix
to a new MAG.  I think we can assume that the MN's landmark prefix is
the MN-HNP, which it has received by previous MAG.  Normally, the
landmark prefix in the RS shall be the same as the MN-HNP, which the MAG
has obtained during the AAA procedure (meaning before the MN sent the
RS).  I don't know if a situation may happen, in which the MN-HNP
available at the MAG is different than the landmark prefix in RS. Maybe
we need to document this.

C. A comment related to DNA again, but this time to DNA-capable access
router.  I think we can include a statement in section 6 that if the MAG
is implemented on DNA-capable AR, the AR shall never send a complete RA,
i.e. having "Complete" flag set in the RA header, to a MN configured for
PMIP service.  Or in more general, some description about the behaviour
of a DNA-capable MAG may be needed.

D. In section 6.11. it is mentioned that the MAG can depend on
"Notification event from the local mobility anchor" for detecting the
presence of the MN on the connected link.  Do you think that this
"notification event" needs to be a part of the PMIPv6 protocol?  

regards,
Genadi

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 13 Mar 2007 12:58:11 -0700

Hi Genadi,

Thanks for the review. These are good comments and appreciate
for this constructive feedback. Please see inline.

Regards
Sri

-----Original Message-----
From: Genadi Velev [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2007 8:31 AM
To: Sri Gundavelli
Cc: [email-masked]
Subject: high-level technical comments to draft-sgundave

Hi Sri,

> such an option.  Do you think it is feasible to allow this behaviour for

Yes. It is feasible. But, this is an implementation optimization and may
not be required to be specified in the spec. We have done this in our
Mobile IPv4 implementation. We can certainly have some suggestive text on
keeping the old tunnel for 30-50ms and accepting packets from that tunnel
for that mobile. In any case, we can have some text around this for
implementation guidance.

> we need to document this.

The network/MAG will ensure the on-link prefix that it advertises
to the mobile node is always the MN-HNP. Now, if the mobile moves from
a link where there was no network-based mobility support, then the landmark
prefix in the RS will be different. But, the prefix in the advertised
RA should override that. In this scenario, DNAv6 should rightfully detect
a link change. We can have some text around this. Will talk to you more
once we have some text on this.

We had few threads with Julien on the issues around DNAv6, we will discuss
this as well.

> of a DNA-capable MAG may be needed.

Ok. We did not talk much about DNA-capable AR running MAG on the link.
We will look in to this.

> "notification event" needs to be a part of the PMIPv6 protocol?  

IPv6 NUD and other access technology specific methods are there for this
detection. IMO, we should depend on the local events about an event
that occurred locally, that is more predictable and fast, as supposed to
depending on an event from the LMA. Ryuji and Julien seem to think we
should cover this in the base. This can be solved in many ways, trying to
avoid one more extension for this. We will discuss about this.

Regards
Sri

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 14 Mar 2007 17:54:49 +0900

Dear Genadi

Kindly find my in-line comments.

> RS).

In case of Initial attachment (when the MN moves into the PMIPv6
domain for the first time), landmark prefix would not be MN-HNP. Maybe
at this point, the MN may not even have a MN-HNP.

In case of Inter-LMD mobility (where the MN moves inside PMIPv6
domain), the landmark prefix would be MN-HNP or one of MN-HNPs (if
there exists multiple MN-HNPs).

> PMIP service.

I can't see why. If the MAG (or DNA-capable AR) knows all the MN's
MN-HNPs, it can generate the Complete RA (of MN' home link) and send
it to the MN in unicast.

Thanks for your kind consideration.

Best Regards

JinHyeock

---

From: "Genadi Velev" <[email-masked]>
Date: Wed, 14 Mar 2007 15:33:49 +0100

Hi Sri,

thanks for the reply. I agree with your comments. Of course I'm open to
talk to you on the PMIP-DNA inter-action. BTW, I saw today that such a
topic is included in the updated agenda for Prague. 
There is just one clarification I'd like to make to your reply.

> avoid one more extension for this. We will discuss about this.

Yes, I agree that the detection of the MN's presence on the connected
link should rely on events coming from the local (i.e. MN-AR) interface.
However, in your I-D section 6.11. you have mentioned that one option is
a notification coming from the LMA. This is what I wanted to stress --
currently there is no other message going from LMA to MAG except the
P-BAck. So, if the LMA needs to initiate notification to the MAG (e.g.
to delete a state for a given MN), there might be a need for a new
message. If the consensus is not to define a new message, then we can
delete the option which allows the LMA to notify the MAG in section
6.11.

Regards,
Genadi

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Tuesday, March 13, 2007 8:58 PM
> To: 'Genadi Velev'
> Cc: [email-masked]
> Subject: RE: high-level technical comments to draft-sgundave
> 
> Hi Genadi,
>

---

From: "Genadi Velev" <[email-masked]>
Date: Wed, 14 Mar 2007 16:26:24 +0100

Hi JinHyeock,

please see my comments inline.

> there exists multiple MN-HNPs).

Yes, I agree with the scenarios you have described. With my initial
comment I wanted to give some food for thoughts. Now, we can assume a MN
coming into LMD domain and sending RS with landmark prefix
(corresponding to the previous LMD). If this prefix is not contained in
the AR's prefix list, than the AR should generate a Complete RA to the
MN (according draft-ietf-dna-protocol).  But this is not in-line with
the MAG specification, because MAG shall advertise only MN-HNP for a
given MN and not all prefixes it knows (please see also my next comment
below). Therefore some text is needed to describe the interaction
between PMIPv6-capable MAG and DNAv6-capable AR. I'm not sure, if such a
text should better go to MN-AR I-D or to PMIPv6 I-D.

> MN-HNPs, it can generate the Complete RA (of MN' home link) and send

I agree with you. In my statement with "Complete RA" I meant that the AR
sends _all_ prefixes it knows to the MN. And this shouldn't be done. So,
we need to align a MAG and DNA-capable AR. Maybe the DNA-capable AR
needs to keep a separate PrefixList for each MN it serves. These
PrefixLists should be configured in different manner, because some MNs
may obtain PMIP service, others may obtain MIP service by the AR. Does
such behaviour need to be documented?  Again, I don't know if the MN-AR
I-D is not a better place for such kind of details. 

Regards,
Genadi

---

From: "JinHyeock Choi" <[email-masked]>
Date: Thu, 15 Mar 2007 10:24:33 +0900

Dear Genadi

Please see my comments inline.

> text should better go to MN-AR I-D or to PMIPv6 I-D.

I agree that some text is needed for the interaction between PMIPv6
&DNAv6. Upon receiving an RS with a landmark prefix, DNAv6 &
PMIPv6-capable AR should reply MN-HNPs specific to the soliciting MN.
It should advertise different CompleteRAs to different MNs.

> needs to keep a separate PrefixList for each MN it serves.

agree.

> These
> such behaviour need to be documented?

I think so. PMIPv6-capable AR should manage separate prefix list for
separate MN. When the AR receives an RS, it should send different RA
according to the soliciting MN.

There may be a problem when the soliciting RS does not have any
information to identify the soliciting MN. For example, if the RS has
either unspecified source address or link local address without
link-layer address option, the AR would have difficulty identifying
the MN.

Best Regards

JinHyeock

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 14 Mar 2007 23:48:09 -0700

Hi Genadi,

Sure, we can discuss all the DNA related issues in the
allocated time slot. So far, we have covered most of 
the DNA interactions, did not cover much on the MAG's
DNA capability and the implications. We can talk about
this and other things in Prague. 

Regards
Sri 

-----Original Message-----
From: Genadi Velev [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 7:34 AM
To: Sri Gundavelli
Cc: [email-masked]
Subject: RE: high-level technical comments to draft-sgundave

Hi Sri,

Regards,
Genadi

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 15 Mar 2007 00:44:38 -0700

Hi Jin,

-----Original Message-----
> From: JinHyeock Choi [mailto:[email-masked]] 
> Sent: Wednesday, March 14, 2007 6:25 PM
> To: Genadi Velev
> Cc: Sri Gundavelli; [email-masked]
> Subject: Re: [netlmm] high-level technical comments to draft-sgundave
>
>Dear Genadi
>

>It should advertise different CompleteRAs to different MNs.

But, this is not specific to DNAv6. On a shared-link, upon receiving
a RS (with or without the landmark prefix option), the MAG must send
the RA with MN-HNP, corresponding to the sending mobile node. This
is documented in the spec. On shared-link, the MAG has to keep the
RA's specific to the mobile and must keep a separation.

>> such behaviour need to be documented?

Yes. Please see Section 6.12

> according to the soliciting MN.

This was stated in the document.

>> link-layer address option, the AR would have difficulty identifying

It MUST depend on the L2 address for the node identification. The
relation between the MN-NAI, L2 address is preserved after the 
access authentication.

---

From: "JinHyeock Choi" <[email-masked]>
Date: Thu, 15 Mar 2007 18:59:51 +0900

Hi Sri

> RA's specific to the mobile and must keep a separation.

yes, you're right. I read the 'RA Unicast' part but didn't realize
that that implies 'An AR should manage Prefix List per MN'.

> This was stated in the document.

ok.

> relation between the MN-NAI, L2 address is preserved after the

So I understand that L2 address would be extracted from L2 header,
then L2 layer would deliver to IP layer the RS with the MN's L2
address.

Best Regards

JinHyeock

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 19 Mar 2007 12:23:02 -0400

Hi Folks,
   I have been trying to follow the discussion regarding DNA issues in 
netlmm.

<dna chair hat off>
I believe that the issues netlmm has with DNA hosts ARE THE SAME issues 
that netlmm has with a non-DNA host. i.e. they are not specific to DNA. 
Two issues to be handled on the MAG are

1) The MAG needs to maintain a prefix list per-MN, and when the MN sends 
an RS respond with only the prefixes in the MN-specific prefix list.
2) If the source address of the RS is unspecified, the MAG needs  figure 
out a way to identify the MN.

If these two issues are handled by the MAG, it would work fine with DNA 
hosts.
</dna chair hat off>

Cheers
Suresh

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 19 Mar 2007 11:39:54 -0700

Hi Suresh,

Thanks for your email. As discussed with Genadi and JinHyeock, we
have addressed the DNAv6 issues. We do cover the case of MAG
maintaining prefix list on a MN basis and the identification of
the MN is also covered.

Regards
Sri 

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Monday, March 19, 2007 9:23 AM
To: [email-masked]
Cc: Genadi Velev; Sri Gundavelli; JinHyeock Choi
Subject: DNA and netlmm (was Re: [netlmm] high-level technical comments to
draft-sgundave)

Hi Folks,

<dna chair hat off>

Cheers
Suresh

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Mar 2007 11:08:21 +0100

Suresh,

> 1) The MAG needs to maintain a prefix list per-MN, and when the MN
> sends an RS respond with only the prefixes in the MN-specific prefix
> list.
> 2) If the source address of the RS is unspecified, the MAG needs 
> figure out a way to identify the MN.
>
> If these two issues are handled by the MAG, it would work fine with
> DNA hosts.

Let me also state that it is legal for current IPv6 nodes to send
either an unspecified source RS or an RS with a source address.

It would be bad if the NETLMM working group defined
solutions that result in significant breakage when hosts
work according to current specifications.

Jari

---

From: Sathya Narayanan <[email-masked]>
Date: Tue, 20 Mar 2007 08:25:54 -0400

Jari,

The current DNA draft mandates the use of link-local address as the 
source for RS messages. "The router solicitation message is sent to the 
All_Routers_Multicast address and the source address MUST be the link 
local address of the host." So, with a DNA-MN it should be possible to 
identify the MN. If the MN is not a DNA-MN, the scenario becomes very 
different, there will probably be more problems then just being able to 
identify the MN, IMO.

Sathya