Subject: [netlmm] comments on draft-sgundave-mip6-proxymip6-01.txt

From: "Genadi Velev" <[email-masked]>
Date: Thu, 18 Jan 2007 12:12:14 +0100

Hi Sri,

the updated version of the I-D has evolved a lot. Below you can find
some issues, which raised to my mind during the revision.

1) on shared prefix model 
In section 6.10. (on page 25) it is written:
   If the mobile is configured for Per-MN-Address model, the proxy
   mobile agent must set the Home Network Prefix Option to the DHCP
   assigned address for that mobile.  It is possible, the mobile is
   DNAv6 capable and after attaching to a new link, it never initiates a
   DHCP request.  In that situation, the proxy mobile agent must send
   the Binding Update with out the Home Network Prefix option and the
   home agent will send the mobile's home address in Binding
   Acknowledgement message, if there is a Binding Cache entry for that
   mobile, else it will reject the Binding Update and the proxy mobile
   agent must wait till the mobile triggers the DHCP for address
   configuration.

So, if the MN is DNAv6 capable, it wouldn't send DHCP request/confirm
after attaching to a the PMA: one unclear point here is how the PMA
decides when to send the PBU to the HA?  Further in this case, when the
MN is coming from the home network, the HA doesn't have BCE entry for
this MN (HA doesn't know the HoA). Then the HA will reject the PBU from
PMA. This results in unreachability of the MN.  I'd suggest to optimize
this procedure.  For instance, after receiving the PBU and if the HA
doesn't have BCE for that MN, it might ask the AAA/DHCP server about the
HoA and MN's profile.  Then the HA can announce the HoA to the PMA via
BAck. 

2) Default Router update at handover
In section 7.3 you describe the problem with updating the Default Router
entry in the MN at handover.  This topic was already discussed around
the San Diego meeting on this ML.  The outcome was documented in section
5.2.7.4 of the I-D draft-ietf-dna-protocol-03.txt.  I would suggest to
mention a reference to this solution, since it's on the way to become a
standard.  Of course, we can mention other possible solutions (as you
have already done) in the PMIPv6 draft. 

One general observation: it is not stated in the I-D whether the PMA
may/shall support the DNAv6 capability of an AR. The I-D talks about
cases where MN is DNAv6 capable, but not about DNAv6 capable PMA. 

3) HA-AAA server exchange
It is not clear to me, whether the HA contacts the AAA server each time
after reception of PBU?  It'd be reasonable to perform this only when
the first PBU from a given PMA arrives at the HA.  For all subsequent
PBUs from the same PMA, HA doesn't need to ask the AAA server. OK, in
this case the HA needs to keep track which PMA is already authorized for
sending PBU.  Further, HA may retrieve different information from the
AAA server depending on the existence or not of Binding Cache entry
(BCE) for the MN. E.g., the MN's profile needs to be retrieved only once
when BCE is established.  Does this needs to be specified in the I-D? It
could be good to differentiate between initial registration at HA and
subsequent registration updates.

My 2 pence,
Genadi

P.S. One side-issue: the reference [1] occurs twice in the I-D, however,
it is not clear which documet is meant by this.

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

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 18 Jan 2007 09:23:01 -0800 (PST)

Hi Genadi,

Please see inline ...

> HoA and MN's profile.  Then the HA can announce the HoA to the PMA via

Good question.

The reason for the above text is assuming the allocated DHCP address
for the mobile is not known to the home agent. If the allocated
address comes from a policy store, then all the entities are in sync
and the home agent can certainly send it back in the reply and there
is no need for the PMA to wait for the mobile to do the DHCP procedure.
Also, if the mobile's are configured with per-mn-prefix model, then
the proxy mobile agent can instantly send a PBU after the mobile's
access authentication and so no issue there as well.

If we support a scenario where the mobile's address comes from DHCP
and the home agent is not aware of that allocation, then it must depend
on the proxy to provide that information and for it to create a BCE.

In PMIP there is no physical home as such, where the mobile gets an
address with out the home agent having a BCE state. So the address that
is allocated to the mobile is always known to the home agent and the
same is ack'd in PBA. For what ever reason, if there is no BCE on the
home agent, address is not allocated from a policy store, mobile is
DNAv6 node and does have a DHCP address, in this special case, the
proxy must wait till the mobile sends a DHCP request, because all the
entities, home agent, proxy mobile agent, policy store do not have this
address state. Special case, indeed.

> cases where MN is DNAv6 capable, but not about DNAv6 capable PMA.

Ok. Definetly. If this was addressed in draft-ietf-dna-protocol-03.txt,
we will certainly leverage some of the ideas from there and provide a
reference to that I-D.

We did not see the impact of PMA's capability of DNAv6 on this protocol
and so did not cover that aspect. PMA is a fixed node and the link and
the prefix are stable and so I dont see that capability impacting the
PMA's operation.

> subsequent registration updates.

Typically the mobile's profile is stored in a Policy Store, such as "AAA"
or in its local store. Either way, the home agent should have the ability
to access that information and if the profile is downloaded and associated
with the BCE or it does it every time after it receives a PBU, is upto
implementations. I agree and I'd expect implementations to optimize this
logic and so we think, this should not be addressed in the document. We
will attempt to provide proper guidance, however.

> it is not clear which documet is meant by this.

Ok. We will fix this. Thanks for finding the nit. Good comments !

Regards
Sri

---

From: "Genadi Velev" <[email-masked]>
Date: Fri, 19 Jan 2007 17:17:53 +0100

Hi Sri,

thanks for your replies.

I have some thoughts on one point....

> address state. Special case, indeed.

If we say that the MN is never at "physical home", that means the HA
must never be on a physical shared link, to which a potential MN may
connect. Is this correct?  OTOH, if we assume a scenario, where the MN
boots up on a shared link, to which the HA is physically connected, then
the MN configures its IP address using stateless or stateful (DHCP)
autoconf., but this IP address is not registered at the HA.  Now, if the
MN moves away to another link (shared or point-to-point), where NetLMM
is supported, the PMA will send PBU to the HA (which however doesn't
have BCE for the MN).  So, I think we need to specify in the I-D,
whether in PMIP the HA may be on a physical link (a kind of home link),
to which the MN may connect. With other words: whether the MN has a
physical home link. 
I understand that having a physical home link would lead to a more
complicated PMIP protocol.

Regards,
Genadi

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 19 Jan 2007 08:44:33 -0800 (PST)

Hi Genadi,

> connect. Is this correct?  OTOH, if we assume a scenario, where the MN

Typically, the home prefix of the mobile is configured to be on
a virtual interface of the home agent. This is a very common
practise and from MIP4 deployment experience, all operators configure
it this way. Now, if we have Per-MN-Prefix model, a physical home
interface for every mobile is not realistic.

> to which the MN may connect. With other words: whether the MN has a

There should be a proxy mobile agent on any link where a mobile boots
up. The mobile's home prefix is always on a virtual interface.
I thought we did document this. We will probably add a section in the
next rev.

> complicated PMIP protocol.

Physical home link for this does not make sense. That too with
inclination for Per-MN-Prefix model, its has little value.

Regards
Sri