Subject: [netlmm] Comments on draft-ietf-netlmm-pmip6-ipv4-support-07

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 30 Dec 2008 15:38:54 -0800

I read through the draft and it looks good overall.  I am preparing the shepherding writeup to send the document for AD review.  In the meantime, I enclose some comments I have in this email.  These and a few other pending comments from the mailing list can be addressed along with the AD review comments.  

* The document has a lot of forward references that make it somewhat of a difficult read.  If possible, minimizing such forward references would be helpful for the reader. 

* In section 3.3.1, is prefix length not needed?  

* Section 3.4 makes a recommendation for DHCP client operation on the mobile node.  Since we cannot quite force a particular behavior of an MN, it would be good to call out the issues with changing client ids and leave it at that.  

* Section 3.4.1 should call out the impact to handoff latency when the MAGs are configured with different DHCP server IP addresses.  There is a latency impact when a FORCERENEW or a timeout and re-negotiation of the full DHCP handshake has to occur for the MN to renew its IP address.  

* In section 3.4.2, as part of Figure 7, the document notes that steps 4 and 1-2 may occur in any order.  Is this really true?  While the MN may send the DHCPDISCOVER before step 1 happens, shouldn't the MAG send the DHCPDISCOVER to the LMA only after the tunnel is setup? 

* Section 5 is a bit confusing - I'm not sure why there is a need for the configuration parameters.  Could the encapsulation mode not be determined by the LMA, based on NAT detection?  Further, on each one of those parameters, there is no explanation on when it may be configured to be 0 or 1.  If these parameters must be present, some explanation to clarify when what value makes sense is needed. 

* s/security associated/security association

Thanks,
Vidya
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 31 Dec 2008 14:27:12 -0500

Hi Vidya,

There is one major issue that I have raised twice so far. It has not
been addressed yet. The document should not be sent to the IESG before
that issue is addressed. The most recent email on this is at
http://www.ietf.org/mail-archive/web/netlmm/current/msg05737.html

Vijay 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Narayanan, Vidya
> Sent: Tuesday, December 30, 2008 3:39 PM
> To: [email-masked]
> Subject: [netlmm] Comments on draft-ietf-netlmm-pmip6-ipv4-support-07
> 
> I read through the draft and it looks good overall.  I am 
> preparing the shepherding writeup to send the document for AD 
> review.  In the meantime, I enclose some comments I have in 
> this email.  These and a few other pending comments from the 
> mailing list can be addressed along with the AD review comments.  
> 
> * The document has a lot of forward references that make it 
> somewhat of a difficult read.  If possible, minimizing such 
> forward references would be helpful for the reader. 
> 
> * Section 3.4 makes a recommendation for DHCP client 
> operation on the mobile node.  Since we cannot quite force a 
> particular behavior of an MN, it would be good to call out 
> the issues with changing client ids and leave it at that.  
> 
> * Section 3.4.1 should call out the impact to handoff latency 
> when the MAGs are configured with different DHCP server IP 
> addresses.  There is a latency impact when a FORCERENEW or a 
> timeout and re-negotiation of the full DHCP handshake has to 
> occur for the MN to renew its IP address.  
> 
> * In section 3.4.2, as part of Figure 7, the document notes 
> that steps 4 and 1-2 may occur in any order.  Is this really 
> true?  While the MN may send the DHCPDISCOVER before step 1 
> happens, shouldn't the MAG send the DHCPDISCOVER to the LMA 
> only after the tunnel is setup? 
> 
> * Section 5 is a bit confusing - I'm not sure why there is a 
> need for the configuration parameters.  Could the 
> encapsulation mode not be determined by the LMA, based on NAT 
> detection?  Further, on each one of those parameters, there 
> is no explanation on when it may be configured to be 0 or 1.  
> If these parameters must be present, some explanation to 
> clarify when what value makes sense is needed. 
>