Subject: Re: [netlmm] AD review of draft-ietf-netlmm-pmip6-ipv4-support (part 3)

From: Jari Arkko <[email-masked]>
Date: Wed, 08 Apr 2009 18:23:15 +0300

I am reading the newest version and checking it against issues I raised 
earlier in the AD review. Most of the issues have now been resolved, 
thanks for that! There are a few remaining ones -- you will need a small 
revision to fix them.

> The spec should also at least mention DNAv4 and explain how it works 
> with PMIP.

This is not in the spec. I think we agreed that there is no issue, but 
you should add a paragraph somewhere to explain this.

>> Thus, it is
>> recommended that the DHCP client on the mobile node, which
>> performs mobility session handoff across interfaces in a Proxy
>> Mobile IPv6 domain, is configured to use a stable client
>> identifier that does not change during the active life of its DHCP
>> session.
>
> Three issues with this:
>
> 1) Remember that the goal of the proxy mobility protocol is to avoid 
> host changes. Indeed, hosts do not have any special support for it 
> today, so if we start making requirements then this will cause 
> significant problems. E.g., laptops connected to 4G modems might not 
> work, etc.
>
> I would phrase the above differently.
>
> When the mobile node uses different interfaces, by default it gets 
> different addresses for them, even in a Proxy MIP domain. In some 
> configurations it can retain the same address (but see below).
>
> 2) What if the DHCP client uses two interfaces _simultaneously_ and 
> has the same client id? I hope this does not mean that the PMIP domain 
> silently disables the other interface... that would not be allowed. 
> PMIP can not break existing functionality.
>
> 3) How does all this relate to the complex handoff rules we have in 
> the base spec? Perhaps the handoff rules are the ones that should be 
> followed, not the client identifier, at least not if current DHCP 
> clients can use the same ID on multiple interfaces... 

No changes here either. We talked about this at length, and here's what 
i would suggest:

Its fine to indicate that the same identifier can be helpful for the 
DHCP server when it is running on its own (not integrated with the rest 
of the PMIP system). However, you should also indicate that the existing 
handoff rules still apply for the proxy mip operation even in ipv4.

>> o When the mobile access gateway receives a DHCPDISCOVER message
>> from a mobile node, it can check if there is already an assigned
>> IPv4 home address for the mobile node from the local mobility
>> anchor.
> This may need more detail on what is a "the mobile node". Identified 
> how, by the RFC 5213 means, through the hwaddr in DHCP, through 
> client-id in DHCP, or what? And what if these pieces of information 
> disagree?

No changes. I think you agreed to change something here, did I miss it 
or didn't it make to the new version?

>> o If the Proxy Binding Update message is rejected by the local
>> mobility anchor for any reason, the local mobility anchor will
>> discard the DHCPDISCOVER messages from the mobile node.
>>
> This text is from the relay case. Interestingly, in the co-located 
> server case you had said a different thing. Namely that IPv4 service 
> must not be provided. I now realize that the earlier text should have 
> been more explicit. Must not provide how? What messages are involved?
>
> Also, is it appropriate to not answer the messages? Would it be better 
> to respond with a NAK? Or does that depend on whether the MAG is 
> operating as a server or as a relay? 

No changes.

Thinking about this again, I'm fine with the text as is.

> To support the IPv4 Transport Support feature, the conceptual Binding
> Update List entry data structure maintained by the mobile access
> gateway [RFC-5213 <http://tools.ietf.org/html/rfc5213>] MUST be 
> extended with the following additional
> parameters.
>
> o The IPv4 address of the local mobility anchor. ...
>
> o The IPv4 address of the mobile access gateway. ...
> The first one is OK, but the second one may not be. Nodes can already be
> assumed to know their own addresses; I do not think we need to create
> MIP-specific data structures to hold information that already exists
> elsewhere in the IP layer. 

No changes. You stated that you will address this as a part of the 
general DSMIP related issue, but this has really nothing to do with 
DSMIP. Section 4.1.1 is fine as it is extending LMA data structure to 
hold the NAT translated address (which wouldn't normally be handled). 
Section 4.2.1 on the other hand simply requests the MAG to replicate 
information that the node already has in other data structures. If you 
want to make a requirement that you have to be able to access such 
information, fine. But do not replicate information unnecessarily.

>> o When sending a Proxy Binding message for extending the lifetime of
>> a currently existing mobility session or for de-registering the
>> mobility session, the Proxy Binding Update message MUST be
>> constructed as the initial request.
> Why does this have to be stated? Nothing earlier in Section 4.2.2 talked
> about the initial PBU either. Is there some new requirement here beyond
> RFC 5213 or dsmip? 

No changes. You stated in earlier correspondence that there is no new 
requirement. You need to rewrite this to indicate this or remove the 
item completely. Your spec is not intended to restate things from RFC 5213.

>> The status values MUST be assigned
>> from the same number space used for Binding Acknowledgement status
>> values, as defined in [RFC-3775].
>
> Just say "... values are assigned from the number space ..." 

No changes. In our earlier correspondence, you said OK to this. Note 
that my reaction is to the keyword usage here, not to the other parts of 
the sentence.

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 8 Apr 2009 09:11:31 -0700 (PDT)

Hi Jari,

Looks like I missed some of the comments. Please see inline.

On Wed, 8 Apr 2009, Jari Arkko wrote:

> earlier in the AD review. Most of the issues have now been resolved, thanks 
> for that! There are a few remaining ones -- you will need a small revision to 
> fix them.
>
>>  The spec should also at least mention DNAv4 and explain how it works with
>>  PMIP.
>
> This is not in the spec. I think we agreed that there is no issue, but you 
> should add a paragraph somewhere to explain this.
>

Can add along the lines ...

- After handoff, the mobile node would typically trigger the DNAv4
procedures for detecting link change. As part of this procedure, it
would send an ARP request for the default-router. The MAG would respond
to this request, with its link-layer address configured for the interface
on that MN-AR link. However, the link-layer address of the MAG on of
the links would always be same, per RFC-5213 and hence the mobile node
would see no link change. So, DNAv4 capable mobile node's would function
as expected in PMIP6 network.

>>  1) Remember that the goal of the proxy mobility protocol is to avoid host
>>  changes. Indeed, hosts do not have any special support for it today, so if
>>  we start making requirements then this will cause significant problems.
>>  E.g., laptops connected to 4G modems might not work, etc.
>>
>>  2) What if the DHCP client uses two interfaces _simultaneously_ and has
>>  the same client id? I hope this does not mean that the PMIP domain
>>  silently disables the other interface... that would not be allowed. PMIP
>>  can not break existing functionality.
>>
>>  3) How does all this relate to the complex handoff rules we have in the
>>  base spec? Perhaps the handoff rules are the ones that should be followed,
>>  not the client identifier, at least not if current DHCP clients can use
>>  the same ID on multiple interfaces... 
>
> No changes here either. We talked about this at length, and here's what i 
> would suggest:
>
> Its fine to indicate that the same identifier can be helpful for the DHCP 
> server when it is running on its own (not integrated with the rest of the 
> PMIP system). However, you should also indicate that the existing handoff 
> rules still apply for the proxy mip operation even in ipv4.
>

The PMIP handoff rules are still the key rules. Will clarify this 
properly. I will go over this carefully. This is the tough one.

>>  This may need more detail on what is a "the mobile node". Identified how,
>>  by the RFC 5213 means, through the hwaddr in DHCP, through client-id in
>>  DHCP, or what? And what if these pieces of information disagree?
>
> No changes. I think you agreed to change something here, did I miss it or 
> didn't it make to the new version?
>

MN-Id is the co-relator. It should have been specified. Will clarify
this. Thanks

>>  This text is from the relay case. Interestingly, in the co-located server
>>  case you had said a different thing. Namely that IPv4 service must not be
>>  provided. I now realize that the earlier text should have been more
>>  explicit. Must not provide how? What messages are involved?
>>
>>  Also, is it appropriate to not answer the messages? Would it be better to
>>  respond with a NAK? Or does that depend on whether the MAG is operating as
>>  a server or as a relay? 
>
> No changes.
>

Ok.

>>  gateway [RFC-5213 <http://tools.ietf.org/html/rfc5213>] MUST be extended
>>  with the following additional
>>  parameters.
>>
> No changes. You stated that you will address this as a part of the general 
> DSMIP related issue, but this has really nothing to do with DSMIP. Section 
> 4.1.1 is fine as it is extending LMA data structure to hold the NAT 
> translated address (which wouldn't normally be handled). Section 4.2.1 on the 
> other hand simply requests the MAG to replicate information that the node 
> already has in other data structures. If you want to make a requirement that 
> you have to be able to access such information, fine. But do not replicate 
> information unnecessarily.
>

I agree. Will take this out. Its there in terminology.

> requirement. You need to rewrite this to indicate this or remove the item 
> completely. Your spec is not intended to restate things from RFC 5213.
>

Ok.
Will state, as per be the base spec or DSMIP spec. Will clarify its not a
new requirement.

> No changes. In our earlier correspondence, you said OK to this. Note that my 
> reaction is to the keyword usage here, not to the other parts of the 
> sentence.
>

I assumed its about a sentence rewrite. Looks like I missed the point. So,
the error is with the use of the key words, such as "MUST". Got it.

    "This document also defines new status values, used in Proxy Binding
    Acknowledgement message, as described in Section 3.3.2.  These values
    MUST be assigned from the same number space as allocated for other
    Status codes [RFC-3775].  Each of these allocated values MUST be
    greater than 128."

Thanks Jari.

Regards
Sri

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 08 Apr 2009 19:33:45 +0300

Sri,

> as expected in PMIP6 network.

This is fine, though you could probably make it even shorter. You don't 
have to explain how DNAv4 works; just note that DNAv4 works because of 
the link-layer address being the same.

>>> host
>> No changes here either. We talked about this at length, and here's 
>> what i would suggest:
>>
>> DHCP server when it is running on its own (not integrated with the 
>> rest of the PMIP system). However, you should also indicate that the 
>> existing handoff rules still apply for the proxy mip operation even 
>> in ipv4.
>>
>

OK. I think the issue is that the MAG/LMA will make one determination 
(based on the rules), and the DHCP server will make another one.

>>> how,
>> No changes. I think you agreed to change something here, did I miss 
>> it or didn't it make to the new version?
>>
>

OK

>>> server
>> information that the node already has in other data structures. If 
>> you want to make a requirement that you have to be able to access 
>> such information, fine. But do not replicate information unnecessarily.
>>
>

OK

> Will state, as per be the base spec or DSMIP spec. Will clarify its not a

OK

>> that my reaction is to the keyword usage here, not to the other parts 
>> of the sentence.
>>
>

Ack.

> Thanks Jari.

Thank you for quick response.

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 8 Apr 2009 09:43:18 -0700 (PDT)

Hi Jari,

On Wed, 8 Apr 2009, Jari Arkko wrote:

> This is fine, though you could probably make it even shorter. You don't have 
> to explain how DNAv4 works; just note that DNAv4 works because of the 
> link-layer address being the same.
>

Sure, that sounds much better. I will resolve it that way.
Will post the draft tonight my time.

Regards
Sri

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 8 Apr 2009 18:14:01 -0400

Hi Sri,

Thanks for answering it promptly.

ryuji

On 2009/04/08, at 12:43, Sri Gundavelli wrote:

>> This is fine, though you could probably make it even shorter. You  
>> don't have to explain how DNAv4 works; just note that DNAv4 works  
>> because of the link-layer address being the same.
>>
>