Subject: [netlmm] Remaining Open Issues

From: Christian Vogt <[email-masked]>
Date: Thu, 06 Sep 2007 11:17:40 +0300

Sri,

thanks for revising the P-MIPv6 specification.  There are a few open issues left
in our tracker [1].  In order to help folks form an opinion on whether those
issues can be considered resolved now, may I ask you to send a brief statement,
per open issue, on how the issue got addressed by the revised specification?

I believe this would be helpful for everyone.

Thank you,
- Christian

[1]  http://www3.tools.ietf.org/wg/netlmm/trac/report/1/

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 6 Sep 2007 11:18:08 -0700

Thanks for raising this, Christian. 

Authors, thanks for the revised draft.  It would be very helpful for
reviewers to see a change log and the resolution to the open issues that
were addressed by this draft.  Please post that to the mailing list.   

Thanks,
Vidya

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Thursday, September 06, 2007 1:18 AM
> To: Sri Gundavelli
> Cc: NetLMM Mailing List
> Subject: [netlmm] Remaining Open Issues
> 
> Sri,
> 
> thanks for revising the P-MIPv6 specification.  There are a 
> few open issues left in our tracker [1].  In order to help 
> folks form an opinion on whether those issues can be 
> considered resolved now, may I ask you to send a brief 
> statement, per open issue, on how the issue got addressed by 
> the revised specification?
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 6 Sep 2007 12:58:06 -0700

Christian/Vidya,

Sure we will publish the log, on how we addressed each
of the issues.

Thanks
Sri 

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Thursday, September 06, 2007 11:18 AM
> To: Christian Vogt; Sri Gundavelli
> Cc: NetLMM Mailing List
> Subject: RE: [netlmm] Remaining Open Issues
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 9 Sep 2007 20:55:09 -0700

Change log between the -01 and 03 version of the docs.

Fixes the following issues:

- Removed assumptions on the acquiring MN-Id as part of Access
  Authentication (Vidya).

- Acquiring the MN identifier and related considerations. Based on
  the input from Jari.
 
- Added section on the Timestamp/seq number considerations (Issue 166)

- Changed the timestamp format. (Alex)

- Added lot more details on LMA processing of the PBU.

- Clearly seperated the message processing rules for initial PBU's,
  Reregistrations and Deregistrations (Jonne)

- Added lot more details on MAG sending the PBU and processing the PBA

- Added message formats for the tunneled packets.

- Removed duplicate text in the MN section and in other places. Fixed
  the editorial issues (Issue 157)

- Defined the order for sending the RA's only after completing the
  signaling (Issue 165 & Issue 155)

- Added the flow sequence in Section 3. But, will add some more text
  in the next rev. But, this issue can be closed (Issue 152).

- Defined the link-local address option. For fixing the link-local
  address collision issue (Julien).

Again, please review and comment on the draft. We want to go last
call in a week. We will update the draft in between.

Thanks
Sri

> Subject: Remaining Open Issues
> 
> Sri,
> 
> few open issues left

---

From: "Genadi Velev" <[email-masked]>
Date: Mon, 10 Sep 2007 15:54:18 +0200

Hi Sri,

going through the -03 version of the document I stumbled over some
editorial issues. 

1) Page 29, 2nd paragraph says:
  "One of the workarounds for this issue is to set the DNAv6
   configuration parameter, DNASameLinkDADFlag to TRUE and that will
   force the mobile node to redo DAD operation every time the interface
   comes up, even when DNAv6 does detect a link change."

The last part should be: "... to redo DAD operation every time the
interface identifies a handover, even when DNAv6 does not detect a link
change."

2) Several parts of the document specify that NAI option must be
included in the Proxy Binding Update and Proxy Binding Acknowledgement
messages. However, in section 8 "Message Formats" nothing is mentioned
about NAI option. Do you plan to include a descriptive text in the next
document version?

3) Sections 8.1 and 8.2 provide no description about the mobility
options in both Proxy Binding Update and Proxy Binding Acknowledgement
messages. I'd suggest to modify figures 11 and 12 and include some
descriptive text. 
An example for figure 11 can be as follows:

       0               1               2               3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |            Sequence #         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|H|L|K|M|R|P|  Reserved       |            Lifetime           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                        Mobility options                       .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Additional text in section 8.1 is necessary to describe the meaning of
"Mobility Options". For example:
 
 "Variable-length field of such length that the complete Proxy Binding
Update message is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The Proxy Binding
Update message may include zero or more of the following options:
  * NAI Option (???)
  * Home Network Prefix Option
  * Link-local Address Option
  * Timestamp Option "

A corresponding text shall be included also in section 8.2, where the
list with possible mobility option should be extended with "Status Value
Option".

regards,
Genadi

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Monday, September 10, 2007 5:55 AM
> To: 'Christian Vogt'
> Cc: 'NetLMM Mailing List'
> Subject: [netlmm] RE: Remaining Open Issues
> 
>  

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 10 Sep 2007 08:38:07 -0700

Hi Genadi,
 
Please see inline.

> From: Genadi Velev [mailto:[email-masked]] 
> Sent: Monday, September 10, 2007 6:54 AM
> To: Sri Gundavelli
> Cc: NetLMM Mailing List
> Subject: RE: [netlmm] RE: Remaining Open Issues
> 
> Hi Sri,
> 

Ok. We missed this.

> about NAI option. Do you plan to include a descriptive text 

Section 8.2 just identifies the PBU/PBA messages and the purpose.
It does not talk about the options that go into it.  There are IPv6
and IPv4 related options and all based on the signaling logic.
The options that go into the message are identified in the signaling
considerations. (Sections 5.3 and 6.9). It has the complete message
formats.

>                                       |            Sequence # 
>         |
>       |                                                       
>         |
>       .                        Mobility options               
>         .
>       |                                                       
>         |

This draft is leveraging the message/option formats from 3775. I'm not
sure, if we should define any of that here. I can add an explicit 
statement, since, you had this doubt.

> list with possible mobility option should be extended with 

If you see  3775, the message and options are clearly mentioned 
seperately. In the message format sections, we are only defining the
message and the option formats. In what combination they are used, that
is based on the signaling logic. 

Thanks
Sri

---

From: "Genadi Velev" <[email-masked]>
Date: Tue, 11 Sep 2007 10:56:09 +0200

Hi Sri,

please see my comments below 

> considerations. (Sections 5.3 and 6.9). It has the complete message

Ok, I missed the reference to RFC4283 regarding NAI option, which by the
way was given in section 5.1. in version -03. I noticed that you
captured this in version -04 and modified Sections 5.3 and 6.9. --
thanks.

> statement, since, you had this doubt.

My point was, that in figures 11 and 12 (respectively figures 13 and 14
in version -04) the last field of the PBU/PBA format were empty. Just
for the readability of the document, we can put "Mobility options" in
that field.

> is based on the signaling logic. 

I understand that RFC3775 gives a complete description of the mobiltiy
header. However since a few mobiltiy options from RFC3775 are used in
PMIP, IMO it can be beneficial to list the PMIP-relevant mobiltiy
options somewhere in section 8 (like a summary of what is specified
previously in section 5.3. and 6.9.).

Thanks,
Genadi

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 11 Sep 2007 21:10:09 -0700

Hi Genadi,
 
> previously in section 5.3. and 6.9.).

Thinking a bit further, I agree, we can list the options that can
go with it. Initial thought was that, we are only talking about the
container (BU/BA) format changes in that section. The options that
go in to that message and the complete message formats are in
signaling considerations.

I looked at how HMIP and NEMO specs, both extended the MIP6 BU/BA
formats. But, since PMIP is bit different and we cant allow all the
base spec options in this message, we can probably list them there
(atleast for the current spec).  IPv4 support doc can do the same as
well.
  
Thanks, we will make this change.

Regards
Sri