[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Jari,


On Thu, 5 Feb 2009, Jari Arkko wrote:


Sri,


 No. We are applying the rules only once. Any of the keys can be used
 for the BCE lookup. The lookup rules in 3.1.2.7 are when using IPv4
 HoA. Will make it bit more explicit.
Ok. So if you look up based on HNP1 from the BU that has (HNP1, HNP2, V4ADDR1) and the BCE has (HNP1, HNP2, V4ADDR2) there's going to be an error back to the sender? This seems right. 



Yes. We try to match all the entries in the binding, both IPv6 and
IPv4 entries. Will check through all combinations, to see we are not
missing any case here.
But I still do not understand what your text in the document attempted to say. Do you mean that while PMIP ensures that the address is in sync between the profile, LMA, and MAG, the actual address assignment to the mobile node happens via DHCP? 




This is w.r.t multi-homing support. If the terminal is a multi-homed
terminal, the static address specified in the policy profile needs
to be associated with a given interface of a mobile node and especially
when that relation changes after a inter-interface handoff, but the
policy profile still needs to track that association. We tried to say
how that is done is out of scope just as in 5213.

  "The IPv4 home address assigned to the mobile node's attached
   interface.  The specific details on how the network maintains the
   association between the address and the attached interface is
   outside the scope of this document.  This address field also
   includes the corresponding subnet mask."





 Ok. Initial thought was to keep it just way, through out and not
 have this selective addition or deletion. However, to support the
 3GPP's requirement of deferred address support, we had to add this.
 Will clarify this in the initial sections.
OK. But please do not break the old model from RFC 5213 where the HNP set had to stay unchanged. I do not think we should change the principles based on which address family we are dealing with. 



Within the address family, we are keeping the address set a fixed set
as in 5213. We just allowed the addition/deletion of a given address
family as a whole during re-registrations. So, the base rule that we
followed earlier is still intact.



 5213 already required the link-layer address of the MAG to be
 a fixed address on all links, to avoid all the issues as we
 discussed during the IESG reviews. So, the IPv4 doc is bound
 to that requirement and hence hardware address of the DR as seen by
 the MN should remain fixed.


Ok. Can you add explicit note about this to the v4 document?



Sure. We will add this.


Thanks
Sri