Subject: [netlmm] Review of draft-ietf-netlmm-proxymip6-07

From: "Giaretta, Gerardo" <[email-masked]>
Date: Mon, 19 Nov 2007 15:39:06 -0800

Hi all,

Here are my comments for the WGLC on this draft. 

General comments (details on these comments can be found below): 
================================================================

- The draft has a lot of descriptive text that, while helping the reader
to understand the procedures, may cause interoperability issues. As it
sometimes lacks of normative words, it is difficult to understand if
there is a requirement for an implementation or not. I will point out
below the txt I am referring to

- The protocol is underspecified in some procedures. Constant or
variables values need to be added and need to replace qualitative
sentences. DHCPv6 usage is also unspecified in my opinion. See below for
details.

- One point where the protocol is underspecified is the "policy
profile". I think this concept is not clear in the document and does not
help implementers to understand what is actually needed. I suggest to
remove any occurrence of "policy profile" in the draft. I would prefer
to have a list of information required for MAG PMIPv6 procedures and
leave out of scope how this information are obtained. Pointing to an
abstract policy profile seems to solve the problem, but actually it does
not.

- Partially related to this policy profile: the LMA discovery is
definitely underspecified in the draft. I think this is OK since, as
mentioned in the current charter, the support of multiple LMAs and
related dynamic discovery is not in the scope of the base specification.
However this is not clearly stated in the draft. I suggest to remove the
text related to LMA discovery (e.g. presence of LMAA in the policy
profile) and to state clearly in the document that the LMA discovery
procedure is out of the scope of the document.

- The multihoming support is not correctly specified. I don't want to
reopen any discussion here, but I think some more details are needed in
the text. Moreover, it is not clear why the multihoming issue deserves a
different section: I think the same section should cover all LMA
procedures as the multihoming-related options are always included in the
PBUs. 

Detailed comments
==================

- In the abstract:

   behalf of the host.  The design principle in the case of a network-
   based mobility management protocol relies on the network being in
   control of the mobility management.  The mobility entities in the

I think this sentence must be removed from the abstract. First of all it
is a partial repetition of the previous sentence. Besides, it is not
clear what "in control of mobility management" means. It is clear that
it is always the MN which performs the initial attach request and the
actual movements, even though the IP mobility management signalling
originates from the network. 

- In section 1, paragraph 1:

   Mobility as specified in [RFC-3775] is host centric as it requires
   the IP host to manage its own mobility by signaling the Home Agent,
   which is located in the network.

What does host centric mean? I suggest rewording as follows:

   Mobility as specified in [RFC-3775] requires the IP host to send IP 
   mobility management signalling messages to the Home Agent, which is 
   located in the network.

- In section 1, paragraph 2: 

   challenge.  It is possible to support mobility for IPv6 nodes without
   host involvement by extending Mobile IPv6 [RFC-3775] signaling
   messages and reusing the home agent.  This approach to supporting
   mobility does not require the mobile node to be involved in the
   exchange of signaling messages between itself and the Home Agent.  A
   proxy mobility agent in the network performs the signaling with the
   home agent and does the mobility management on behalf of the mobile
   node attached to the network.  

The Home Agent needs some modifications and it is important to state it
in the introduction. Moreover it is important to clarify that the MN is
not involved in the IP mobility management signalling and not in generic
"mobility management signalling". This second comment applies to the
whole draft, I hope to have identified all the occurrences in this
review.
Here is a suggested rewording:

   challenge.  It is possible to support mobility for IPv6 nodes without
   host involvement by extending Mobile IPv6 [RFC-3775] signaling
   messages and reusing the home agent with some modifications.  This 
   approach to supporting mobility does not require the mobile node to
be 
   involved in the exchange of signaling messages between itself and the

   Home Agent.  A proxy mobility agent in the network performs the
signaling 
   with the home agent and does the IP mobility management on behalf of
the 
   mobile node attached to the network.  

- In section 1, paragraph 3: 

   Network deployments which are designed to support mobility would be
   agnostic to the capability in the IPv6 stack of the nodes which it
   serves.  IP mobility for nodes which have mobile IP client
   functionality in the IPv6 stack as well as those hosts which do not,
   would be supported by enabling Proxy Mobile IPv6 protocol
   functionality in the network.  

I think this paragraph must be completely removed. It addresses a big
issue of co-existence of MIPv6 capable hosts and non MIPv6 capable hosts
which is not solved even in the interactions draft. Besides, it is not
clear why PMIPv6 should be enabled for nodes which support MIPv6. 

- In section 1, paragraph 3. The list mixes advantages of a PMIPv6
protocol with advantages of a generic NETLMM solution. I think the third
and fourth bullets must be removed as they are not clear and anyway not
related to the PMIPv6 protocol choice. 

- In section 2.2, LMA definition:

      Local Mobility Anchor is the home agent for the mobile node in the
      Proxy Mobile IPv6 domain.  It is the topological anchor point for
      the mobile node's home network prefix and is the entity that
      manages the mobile node's binding state.  It is important to
      understand that the local mobility anchor has the functional
      capabilities of a home agent as defined in Mobile IPv6 base
      specification [RFC-3775] with the additional capabilities required
      for supporting Proxy Mobile IPv6 protocol as defined in this
      specification.

Suggested slight modification:

      Local Mobility Anchor is the home agent for the mobile node in the
      Proxy Mobile IPv6 domain.  It is the topological anchor point for
      the mobile node's home network prefix and is the entity that
      manages the mobile node's binding state.  The local mobility
anchor 
      has the functional capabilities of a home agent as defined in
Mobile 
      IPv6 base specification [RFC-3775] with the additional
capabilities 
      Required for supporting Proxy Mobile IPv6 protocol as defined in
this
      specification.

- In section 2.2, MN definition:

      Throughout this document, the term mobile node is used to refer to
      an IP host whose mobility is managed by the network.  The mobile
      node may be operating in IPv6 mode, IPv4 mode or in IPv4/IPv6 dual
      mode.  The mobile node is not required to participate in any
      mobility related signaling for achieving mobility for an IP
      address that is obtained in that Proxy Mobile IPv6 domain.  

Suggested rewording

      Throughout this document, the term mobile node is used to refer to
      an IP host whose mobility is managed by the network.  The mobile
      node may be operating in IPv6 mode, IPv4 mode or in IPv4/IPv6 dual
      mode.  The mobile node is not required to participate in any IP
      mobility related signaling for achieving mobility for an IP
      address that is obtained in that Proxy Mobile IPv6 domain.  

- In section 2.2, Mobile Node's Home link. I think the definition is
partially misleading. The home link in PMIPv6 is always a virtual home
link and therefore the following text does not make sense to me:

      This is the link on which the mobile node obtained its initial
      Layer-3 address configuration for one of its interfaces after it
      moved into that Proxy Mobile IPv6 domain.

I think just removing the above sentence and keep the rest of the
definition should be fine.

- Section 3, second paragraph:

   Proxy Mobile IPv6 protocol is intended for providing network-based
   mobility management support to a mobile node, without requiring the
   participation of the mobile node in any mobility related signaling.
   The mobility entities in the network will track the mobile node's
   movements and will initiate the mobility signaling and setup the
   required routing state.

Suggested rewording:

   Proxy Mobile IPv6 protocol is intended for providing network-based IP
   mobility management support to a mobile node, without requiring the
   participation of the mobile node in any IP mobility related
signaling.
   The mobility entities in the network will track the mobile node's
   movements and will initiate the mobility signaling and setup the
   required routing state.

- Section 3, fifth paragraph:

   that Proxy Mobile IPv6 domain.  The obtained address configuration
   includes the address(es) from its home network prefix, the default-
   router address on the link and other related configuration
   parameters.  From the perspective of the mobile node, the entire

Isn't just the home network prefix which is obtained? Only if DHCP is
used the addresses are obtained. I suggest to reword in order to mention
only the home network prefix

- Section 3, paragraph before figure 2

   If the mobile node connects to the Proxy Mobile IPv6 domain, through
   multiple interfaces and over multiple access networks, the network
   will allocate an unique home network prefix for each of the connected
   interfaces and the mobile node will be able to configure an
   address(es) on those interfaces from the respective home network
   prefixes.  If the mobile node performs a handover from one interface
   to another in the same Proxy Mobile IPv6 domain, then the local
   mobility anchor will assign the same prefix to the new interface.

I think it is not clear how the network knows that the MN wants to
perform an inter technology handover. Since this is a descriptive
paragraph I suggest rewording as follows:

   If the mobile node connects to the Proxy Mobile IPv6 domain, through
   multiple interfaces and over multiple access networks, the network
   will allocate an unique home network prefix for each of the connected
   interfaces and the mobile node will be able to configure an
   address(es) on those interfaces from the respective home network
   prefixes.  If the mobile node performs a handover from one interface
   to another in the same Proxy Mobile IPv6 domain and provides
indication 
   to the network that an inter-technology handover occurs, then the
local
   mobility anchor may assign the same prefix to the new interface.

- Section 4, second paragraph. I suggest adding the following sentence
at the end of the paragraph: "The specification of the other security
mechanisms are beyond the scope of this document"

- Section 5.1, fifth bullet

   o  The IPv6 home network prefix of the registered mobile node.  The
      home network prefix of the mobile node may have been statically
      configured in the mobile node's policy profile, or, it may have
      been dynamically allocated by the local mobility anchor.  The IPv6
      home network prefix also includes the corresponding prefix length.

Remove the sentence mentioning to the mobile node's police profile. It
is a system level concept which does not clarify the operations of the
protocol. Suggested rewording:

   o  The IPv6 home network prefix of the registered mobile node.  The
      home network prefix of the mobile node may have been statically
      configured, or, it may have been dynamically allocated by the
local 
      mobility anchor.  The IPv6 home network prefix also includes the 
      corresponding prefix length.

- Section 5.1, end of the list. I think it would be useful to list all
the fields define in RFC3775 which are not used in case the BCE is a
proxy one. Basically Home Address and Sequence Number fields

- Section 5.1, third paragraph. I think only one possibility should be
indicated (MN-ID + MN_int_ID). Besides, how the (MN-ID, Proxy-CoA) would
identify the BCE in a handover?

- Section 5.2, first paragraph. Should we define somewhere in the
document the Per-MN-Prefix model and the Shared-Prefix model? I think
some introduction would be useful

- Section 5.3. I suggest having different sub sections for each
procedure (5.3.1 Processing Binding Registration, 5.3.2 Initial Binding
Registration, etc.)

- Section 5.3, first paragraph:

   Upon receiving a Proxy Binding Update request (a Binding Update
   Request with the 'P' flag set) from a mobile access gateway on behalf
   of a mobile node, the local mobility anchor MUST process the request
   as defined in Section 10.3 [RFC-3775];addtionally the following
   considerations must be applied.

Suggested text:

   Upon receiving a Proxy Binding Update request (a Binding Update
   Request with the 'P' flag set) from a mobile access gateway on behalf
   of a mobile node, the local mobility anchor MUST process the request
   as defined in Section 10.3 [RFC-3775], with one exception that this
   request is a Proxy Binding Update request and hence the following
   additional considerations must be applied.

- Section 5.3, Processing Binding Registrations, third bullet

   o  If the local mobility anchor cannot identify the mobile node, from
      the Mobile Node Identifier option [RFC-4283] present in the
      request, it MUST reject the Proxy Binding Update request and send
      a Proxy Binding Acknowledgement message with Status field set to
      133 (Not home agent for this mobile node).

What does this exactly mean? Bad formatted NAI? At initial registration
the LMA does not now the MN-ID and therefore cannot identify the MN. I
cannot understand this point.

- Section 5.3, Constructing the PBA. The MN-ID is not mandatory as it is
not included in case the Status field is set to
MISSING_MN_IDENTIFER_OPTION

- Section 5.4, overall. I understand that it was easier for the editor
to add a separate section for the multihoming support and related LMA
operations. However I think this is not the correct approach to describe
the protocol operations. The reason is that in the PBU the Access
Technology type option is mandatory and therefore the section 5.3 does
not described the exact procedure followed by LMA when receiving a PBU.
I think we should merge section 5.3 and 5.4 in order to clearly indicate
the procedures followed by the LMA when it receives a PBU. 

- Section 5.4, third paragraph

   The local mobility anchor MUST allow for an handover between two
   different interfaces of the mobile node.  In such a case, the home
   network prefix that is associated with a specific interface
   identifier of a mobile node will be updated with the new interface
   identifier.

Suggested rewording:

   The local mobility anchor MUST allow for an handover between two
   different interfaces of the mobile node. However this may require an 
   explicit indication from the mobile node and the mobile access
gateway. 
   In such a case, the home network prefix that is associated with a 
   specific interface identifier of a mobile node will be updated with
the 
   new interface identifier.

- Section 5.4, Processing De-Registration Message: why is this
multihoming specific? I don't see anything about multihoming in this
paragraph

- Section 5.4, MN Interface ID option not present in the request, bullet
5. We must define what "within a given amount of time" means.

- Section 5.4, MN Interface ID option not present in the request, bullet
5.

   o  Either upon creating a new Binding Cache entry or from matching an
      existing Binding Cache entry, after applying the above
      considerations, the interface identifier field in the Binding
      Cache entry MUST be set to the value present in the received
      Mobile Node Interface Identifier Option and the access technology
      type MUST be copied from the Access Technology type option present
      in the received Proxy Binding Update message.  If the Mobile Node
      Interface Identifier Option is not present, the interface
      identifier field in the Binding Cache entry MUST be set to
      ALL_ZERO.

Remove the last sentence as we are already in the case where the MN
Interface ID is not present. 

- Section 5.4, Interface ID option present in the request. What about
when HI=3? There is no corresponding text for this case

- Section 5.4, Interface ID option present in the request. Bullets 4 and
5 seem to be under the same condition. I guess we need only one bullet.

- Section 5.4, Interface ID option present in the request, bullets 6:
same comment as above on the meaning of "within a given time"

- Section 5.4, Interface ID option present in the request, bullets 7:

   o  Either upon creating a new Binding Cache entry or from matching an
      existing Binding Cache entry, after applying the above
      considerations, the interface identifier field in the Binding
      Cache entry MUST be set to the value present in the received
      Mobile Node Interface Identifier Option and the access technology
      type MUST be copied from the Access Technology type option present
      in the received Proxy Binding Update message.  If the Mobile Node
      Interface Identifier Option is not present, the interface
      identifier field in the Binding Cache entry MUST be set to
      ALL_ZERO.

I suggest removing the last sentence as it is already covered in the
previous subsection

- Section 5.5, fifth paragraph:

   This may be achieved by using context transfer schemes or by
   maintaining the sequence number in a policy store.  However, the
   specific details on how the mobile node's sequence number is
   synchronized between different mobile access gateways is outside the
   scope of this document.

I suggest removing the text about the policy store which is a non
entity, nowhere defined. Suggest rewording:

   This may be achieved by using context transfer schemes.  However, the
   specific details on how the mobile node's sequence number is
   synchronized between different mobile access gateways is outside the
   scope of this document.

- Section 5.6.1, fourth bullet. The text does not seem normative at all.
This is one of the parts of the draft which it is not clear if
implementers should care of. I suggest to remove this bullet.

- Section 5.7, last paragraph.

   In Proxy Mobile IPv6, the address of the local mobility anchor
   configured to serve a mobile node can be discovered by the mobility
   entities in other ways.  This may be a configured entry in the mobile
   node's policy profile, or it may be obtained through mechanisms
   outside the scope of this document.

The role of the policy profile is not clear. Again, I'm not comfortable
with the text which seems to solve everything by the existence of a
"policy profile". Suggest rewording

   In Proxy Mobile IPv6, the address of the local mobility anchor
   configured to serve a mobile node can be discovered by the mobility
   entities in other ways.  However how it is obtained is beyond the
scope 
   of this document.

- Section 5.9, second paragraph

   In Proxy Mobile IPv6, the mobile node is not involved in any mobility
   related signaling.  The mobile node uses only its home address for
   all its communication and the Care-of address (Proxy-CoA) is not
   visible to the mobile node.  Hence, the Return Routability procedure
   as defined in Mobile IPv6 cannot be used in Proxy Mobile IPv6.

Suggest Rewording:

   In Proxy Mobile IPv6, the mobile node is not involved in any IP
mobility
   related signaling.  The mobile node uses only its home address for
   all its communication and the Care-of address (Proxy-CoA) is not
   visible to the mobile node.  Hence, the Return Routability procedure
   as defined in Mobile IPv6 cannot be used in Proxy Mobile IPv6. This 
   implies that the traffic is always routed through a bidirectional 
   tunneling

- Section 6.1, second bullet:

   o  The interface identifier of the mobile node's connected interface.
      This address can be acquired from the received Router Solicitation
      messages from the mobile node or during the mobile node's
      attachment to the access network.  This is typically a L2
      identifier conveyed by the mobile node.

We need to state clearly that it is out of the scope how this is
conveyed. Suggest rewording:

   o  The interface identifier of the mobile node's connected interface.
      This identifier can be acquired from the received Router
Solicitation
      messages from the mobile node or during the mobile node's
      attachment to the access network.  This is typically a L2
      identifier conveyed by the mobile node; however, how it is
conveyed is 
      out of the scope of this document.

- Section 6.2. I think this is a system level description which does not
need to be included in the draft. As stated earlier, I would be in favor
of removing any reference to the policy profile in the draft. We may
want to rephrase this section as follows:

   This specification relies on the knowledge of some parameters at the
MAG. 
   These parameters are the LMAA and the MN-ID. It is out of scope of
this 
   procedure how these parameters are obtained by the MAG.

- Section 6.4. I think this section should be re-written in order to
provide more normative text or removed. It is again one of the sections
which do not provide indications of what must be implemented. It's not
clear for example if the MAG needs to act as DHCP Relay. I'm fine
leaving outside the scope of the document these considerations as I
think they are part of the system design and not of the protocol design.

- Section 6.6, bullet 1. 

   o  The identifier of the mobile node that the mobile access gateway
      obtains typically as part of the access authentication or from the
      notified network attachment event, can be a temporary identifier
      and this identifier may also change at each re-authentication.
      However, the mobile access gateway MUST be able to use this
      identifier and obtain the mobile node's MN-Identifier from the
      policy store, such as from the RADIUS attribute, Chargeable-User-
      Identifier [RFC-4372].

Again the reference to the policy store is misleading and does not
provide any useful information to the specification. I suggest the
following text:

   o  The identifier of the mobile node that the mobile access gateway
      obtains typically as part of the access authentication or from the
      notified network attachment event, can be a temporary identifier
      and this identifier may also change at each re-authentication.
      However, the mobile access gateway MUST be able to link this 
      identifier to a long term identifier. How the matching between the
two 
      identifiers is performed is beyond the scope of this document

- Section 6.6, bullet 2. I suggest removing this bullet for the reasons
stated above (about the policy store)

- Section 6.7, third paragraph

   Typically, the mobile access gateway learns the mobile node's home
   network prefix information from the received Proxy Binding
   Acknowledgement message or it may be obtained from the mobile node's
   policy profile.  However, the mobile access gateway SHOULD send the
   Router Advertisements advertising the mobile node's home network
   prefix only after successfully completing the binding registration
   with the mobile node's local mobility anchor.

The document specified only one method to obtain the network prefix
which is the PBA. Therefore I suggest changing the text as follows:

   The mobile access gateway learns the mobile node's home
   network prefix information from the received Proxy Binding
   Acknowledgement message. However, the mobile access gateway MUST send

   the Router Advertisements advertising the mobile node's home network
   prefix only after successfully completing the binding registration
   with the mobile node's local mobility anchor.

- Section 6.9.1, bullet 10 of the first list

   o  If the mobile access gateway learns the mobile node's home network
      prefix either from its policy store or from other means, the
      mobile access gateway MAY choose to specify the same in the Home
      Network Prefix option for requesting the local mobility anchor to
      allocate that prefix.  If the specified value is 0::/0, then the
      local mobility anchor will consider this as a request for prefix
      allocation.

I suggest removing this bullet. There are no means specified in any
document to learn the home network prefix other than the PBA. 

- Section 6.9.1, second list, bullets 5 and 8 are the same conditions
and should be merged together

- Section 6.9.1, second list, bullet 10. It is not clear what happens in
case DHCPv6 is used to configure the IP address. 

- Section 6.9.1, second list, bullet 11. In RFC3775 the BUL entry is
created when the MN sends the BU. Why the text in this bullet suggests
that it is created when the PBA is received?

- Section 6.9.1, fourth list, bullet 2. I think we must specify what
"after a certain timeout" means

- Section 6.9.1, fifth list, bullets 2 and 3. Why is there a SHOULD for
source and destination addresses? Shouldn't it be a MUST?

- Section 6.9.2, first bullet. 

   o  The mobile access gateway on receiving the Router Solicitation
      message SHOULD send a Router Advertisement containing the mobile
      node's home network prefix as the on-link prefix.  However, before
      sending the Router Advertisement message containing the mobile
      node's home network prefix, it SHOULD complete the binding
      registration process with the mobile node's local mobility anchor.

In the last sentence I think a MUST is more appropriate than a SHOULD.
There is no way for the MAG to know the home network prefix before
receiving the PBA.

- Section 6.10.2. I suggest removing the second paragraph. It does not
provide any indication to implementers and does not contain any
normative text. It is one of the places in the draft where we can
actually simplify it. 

- Section 6.10.3, second paragraph. I think multiple LMAs are out of
scope of the base specification.

- Section 6.11: I think this section is underspecified. It does not
mandate that the MAG acts as DHCPv6 Relay, which I think is needed. I
think the procedure should be the following: the MN sends a DHCPv6
Request (o DHCPv6 Confirm after a handover), the MAG acting as Relay
intercepts it and performs the PBU/PBA exchange and based on the
received HNP completes the DHCPv6 exchange including the prefix in the
message to the DHCPv6 server. I think this is not specified in the
draft. Either we specify it, including the necessary DHCPv6 options, or
we leave it out of scope.

- Section 6.14. I think this section should be removed. The interactions
draft is partially dealing with it. 

- Section 7.3, first paragraph and overall section. As the document
enables inter-technology handovers (value 2 of HI) the impacts to the MN
are not null and must be described. For example it will probably be the
MN that signals to the MAG that an inter-tech handover is requested.
Therefore it is not fully true that the specification does not require
any change to mobile node's IP stack as indicated in the first
paragraph.

- section 8.2: Access Technology Type option is missing among the
possible Mobility Options
 
Thanks
Gerardo

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 27 Nov 2007 22:14:12 -0800

Hi Gerardo,

Please see inline..

Sri

> -----Original Message-----
> From: Giaretta, Gerardo [mailto:[email-masked]] 
> Sent: Monday, November 19, 2007 3:39 PM
> To: [email-masked]
> Subject: [netlmm] Review of draft-ietf-netlmm-proxymip6-07
> 
> Hi all,
> 

[Sri] I've provided responses to your detailed comments below. 

> Detailed comments

[Sri] The network is responsible for mobilty management and that's what
its saying. Host does not even know, the network is offering the mobility.
This is not about making a client look dumb, but reflects the basic
nature of the protocol.

>    mobility management signalling messages to the Home Agent, 

[Sri] Ok. Dont agree, but will change it.

>    mobile node attached to the network.  

[Sri] Ok. mobility to IP mobility, home agent to home agent with
    modifications.

> clear why PMIPv6 should be enabled for nodes which support MIPv6. 

[Sri] Why does a mere mention of the CMIP enabled node would imply
it addresses coexistence issue. Its stating a fact that the PMIP network
can support both types of nodes.

> related to the PMIPv6 protocol choice. 

[Sri] PMIP6 is a NETLMM solution and any listed advantage of a
network-based solution are common to all solutions and for PMIP6
as well. The stated advantages exist for PMIP6 as well and does not
go away, because its PMIP6.

>       Required for supporting Proxy Mobile IPv6 protocol as defined in

[Sri] Ok

>       address that is obtained in that Proxy Mobile IPv6 domain.  

[Sri] Ok. What is the change ? "mobility" vs "IP mobility" ? Is that not 
implicit ?

> definition should be fine.

[Sri] Per the definition, its the link on which the mobile gets the
initial address configuration in that Proxy Mobile IPv6 domain. Its
not a virtual link. It makes sense to us. We should keep this.

>    movements and will initiate the mobility signaling and setup the

[Sri] Lot of stress on "IP Mobility". Fine. But, I dont think if we dont
state that, it will imply L2 mobility. We are almost splitting hair here.

> only the home network prefix

[Sri] Well, how does the mobile know the default-router on the link ? Its
using the same RA's from the AR on the link.

>    mobility anchor may assign the same prefix to the new interface.

[Sri] No. Its not always required for the network to learn this from
the MN. It may learn through other mechanisms. We have an agreement on
multihoming and as per that, how the MN notifies the MAG about the
address release or about the handoff between interfaces, is out of scope.
Lets stick to what we agreed and posted in the ML.

> mechanisms are beyond the scope of this document"

[Sri] Ok.

> protocol. Suggested rewording:

[Sri] No. I'm not sure what the concern is with the use of the term policy
profile. Any protocol or a system requires some operational parameters
and in the case of Proxy Mobile IPv6, the network entities require access
to some parameters and those parameters are grouped and refered to as a
policy profile. Please refer to my response in Sec 6.2 as well.

> proxy one. Basically Home Address and Sequence Number fields

[Sri] We were asked to remove fields that were defined in other docs,
such as in 3775 and in DSMIP for the IPv4 support doc. So, we had to
keep only new parameters. No change.

> identify the BCE in a handover?

[Sri] HNP is a unique key, I can always identify the BCE using this
keys. This is not about the Binding Cache existence test, but how
constitutes a unique search key in the BCE table.

> some introduction would be useful

[Sri] Ok. Will make it explicit that the HNP is per interface of the
mobile. We missed it here. Let me know, if you wante the text to be
posted.

> procedure (5.3.1 Processing Binding Registration, 5.3.2 

[Sri] We thought about this. But, there is a order here and we felt
this is probably better when structured this way. 

>    additional considerations must be applied.

[Sri] ? Thats what we have. May be you reversed it. So, the
the change would be, ";addtionally the following considerations
must be applied". Ok, fine.

> cannot understand this point.

[Sri] If the option format is bad, the processing rules from 3775 will
take care of this. Not sure, why this confuses you. If the LMA cannot
identify the MN from the identifier present in the option, the text
suggests what to do. If there is MN-Id say, bob.ietf.org and that id is
not known to LMA, it rejects the PBU. If you still think this is not
clear, provide the text that you think is right.

> MISSING_MN_IDENTIFER_OPTION

[Sri] Ok. Will fix this by stating the NULL id should be present when
returning this status code. Let me know, if you want the text before.

> the procedures followed by the LMA when it receives a PBU. 

[Sri] No. Its a logical grouping, it provides better readability. In
fact some one specifically suggested to have smaller logical groups
as supposed to 5 page processing rules, which is hard to read. Section
5.3 clearly points to 5.4 and also to Timestamp processing rules. The
idea is not to allow implementations to skip multihoming rules, but
for better structuring. When we mandate multihoming, its clearly
mandated, keeping them in separate sections does not make it any
different or not make the section less important. Clearly, the rules
from these different sections are chained.

>    new interface identifier.

[Sri] No. We already stated that if the MAG definitively knows the
mobile node's current attachment is due to a handoff then it can
mark the HI hint, Otherwise it cannot. There is no need to further
state that MN should send that trigger and note that there is no
such mechanism today. Network may derive that trigger in multiple
ways. This is inline with the agreement we reached on the multihoming
issue, lets stick to that.

> multihoming specific? I don't see anything about multihoming in this

[Sri] Agreed. Will fix this by moving this to 5.3. 

> 5. We must define what "within a given amount of time" means.

[Sri] Ok. Its not needed. But, we can define a configurable parameter.
Let me know, if you need the text on this before.

> Interface ID is not present. 

[Sri] Ok. Same comment from others. Will fix it.

> when HI=3? There is no corresponding text for this case

[Sri] The first two points cover this case as well. IID is unique,
and the BCE would match in such case.

> 5 seem to be under the same condition. I guess we need only 

[Sri] HI values are different.

> I suggest removing the last sentence as it is already covered in the

[Sri] The flow is different, or we need to create a common section
just for this one processing rule. Might be better to keep this in
both places. But, we can change it, if others think the same way.

> entity, nowhere defined. Suggest rewording:

[Sri] Please see my comments on Policy Store below (comment on Sec 6.2)

> implementers should care of. I suggest to remove this bullet.

[Sri] Ok. I see the point. Will rephrase this. Let me know if
you need the text before.

> "policy profile". Suggest rewording

[Sri] Please refer to my comments on Policy store below.

>    implies that the traffic is always routed through a bidirectional 

[Sri] Ok. IP mobility part is fine. The Last line does not fit in
here. All its saying is RO is out of scope. Not sure, how we can
talk about bi-directional tunnel and so dont agree with this change.

>       out of the scope of this document.

[Sri] Ok

>    procedure how these parameters are obtained by the MAG.

[Sri] You seem to be concerned about this. Quite a few comments are
centered around this. Let me understand and try to explain from your
point of view. Not sure, if your concern is that this does not make
a case for a bootstrapping document or attempts to solve that problem ?
Please correct me, if my assumption is wrong.
I agree, any serious deployments would need a bootstrapping protocol
and interface to AAA. Such interface is typically covered in extension
documents. What we have is the basic mechanism for the system to work in
the absence of such an interface. But, that does not imply, we are solving
the bootstrapping problem.  If I'm an implementor and follow this document
for MAG and LMA implementation, I can provide a simple config file or a CLI
interface for provisioning user data and my system will work. The policy
profile is just a group of config parameters, required for the protocol
operation. By removing the term, facts do not change, we still need some
parameters and on a per user basis. What we call that, a policy profile or
by some other abstract name, will do no harm to other work or will not
solve the bootstrapping problem or AAA interface in a psudo fashion.

> think they are part of the system design and not of the 

[Sri] The MN-AR link is a dynamically created IPv6 link and guidance
must be provided on how to enable a given address configuration mode.
This is required. If you want this to rewritten, please provide the
text and we will review it.

> stated above (about the policy store)

[Sri] No. Please see my prev. response on the use of policy store for
configuration. Same response for both the above comments.

> document to learn the home network prefix other than the PBA. 

[Sri] No. This was discussed before. We clearly want the ability for the
MAG to suggest a prefix hint. The hint can be locally configured in
the MN's profile on that box. This response is valid for both the above
comments.

> and should be merged together

[Sri] No. The error codes are different in each of those cases.

> case DHCPv6 is used to configure the IP address. 

[Sri] The prefix availability on the link and the address configuration
modes are unrelated. The expiry of router, is valid in both cases and
the MAG behavior should be the same.

> that it is created when the PBA is received?

[Sri] Good point. Will check on this. We may need a flag to indicate
if the BCE is accepted, for differentiating the cases of a). LMA accepted
PBU b.) LMA yet to accept PBU. 

> "after a certain timeout" means

[Sri] Ok. Will define a config parameter. Let me know, if you need
the text before.

> source and destination addresses? Shouldn't it be a MUST?

[Sri] Wanted to leave some room for different network configurations.
As I said in response to George's comments, its better to leave it
with SHOULD and have some lee way for the implementations. Again, 
I'm not sure either when some one would use a different address other
than what is received. Even for Alt-Coa, the headers wont change. But,
better not to mandate this and I dont think this will cause any
interop issues.

>       registration process with the mobile node's local 

[Sri] There was a comment on this before to use "SHOULD" and not a "MUST"
as the MAG may not be able to send it for what ever reasons. Its a strong
language in any case that we are using here.

> normative text. It is one of the places in the draft where we can

[Sri] No. It provides guidance to implementors. You and me may know
the protocol in detail, for some on doing the implementation, these basics
are required. 

> scope of the base specification.

[Sri] No. This was discussed in the ML before. Please do no reopen this
discussion. There can be one ore more LMA's in a PMIP6 domain. This was
the assumption since -00 version of the draft. We dont have to apply
unwanted restrictions on PMIP6 and for no reason. This is useful for
PMIP6 deployments, these type of restrictions will kill the protocol and
its usage.

> draft is partially dealing with it. 

[Sri] No. This is not touching CMIP-PMIP interactions. Its just stating,
what the MAG can do when it denies network-based mobility service to a
mobile node. How graceful a system should behave in such scenario. 

> possible Mobility Options

[Sri] Agreed.
 
Thanks for the review. 

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 28 Nov 2007 14:25:57 -0800

Hi Gerardo, Sri,

A few comments below.

> can support both types of nodes.

Agree. It must be explicitly stated that mobile nodes that have
Mobile IPv6 stack running on them can still attach to the PMIPv6
network.

> using the same RA's from the AR on the link.

Right. There could be other information delivered in the router
advertisement.

> clear, provide the text that you think is right.

Gerardo, there could be any number of reasons why the LMA is
not able to identify the mobile node based on the MN-ID
provided by the mobile node. The LMA must send an binding ack
to the MAG with failure status in this case. Silently dropping
is not an option.

> issue, lets stick to that.

Gerardo, while the mobile node could provide an indication, thats
not the only solution possible. You could have systems where this
information is obtained from the AAA or from the previous MAG.
Anyway, mandating changes on the mobile node in the base PMIPv6
specification is going to conflict with the charter that says no
modifications to the host.

> solve the bootstrapping problem or AAA interface in a psudo fashion.

If anyone can come up with a better name, it would help a lot.
The policy store in real world, would be HSS/HLR/AAA/Database/etc...

> PBU b.) LMA yet to accept PBU. 

I think even here we should create the BUL entry as soon as the
proxy BU is sent. Having a flag in the BCE to indicate whether the
Proxy BAck was received or not is an implementation issue and
should not be specified in the draft.

> better not to mandate this and I dont think this will cause any

hmm... Sri, I agree with Gerardo here. I don't think it can be
any other addresses other than the MAG and the LMA's addresses.
So it should be a "MUST" here.

> PMIP6 deployments, these type of restrictions will kill the protocol and

Agreed. A particular MAG should be able to use two different
LMAs for two different mobile nodes. We shouldn't assume that a
particular MAG can only be connected to one LMA.

Vijay

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 30 Nov 2007 16:06:17 -0800

Hi Vijay,

Some more comments inline.

> to the MAG with failure status in this case. Silently dropping

I'm not proposing silently dropping on anything else. I'm just trying to
understand what "identify the mobile node" means as the first PBU will
have a "new" MN-ID. Is this about an authorization step at the LMA? If
so, I think it should be mentioned.

> modifications to the host.

Agree, but you wanted the inter-tech handovers and this will probably
mandate changes in most implementations :)

As I said to Sri, I'm fine to keep the old text here.

> > for MAG and LMA implementation, I can provide a simple config file
or a
> CLI
> > parameters and on a per user basis. What we call that, a policy
profile
> or

Can we just say that how the MAG knows this set of parameters is out of
the scope of the base specification and may be deployment specific?

The problem I have with the terminology in the draft is that it seems
that the policy profile solves the issue of providing the MAG with the
parameters but actually it does not.

> should not be specified in the draft.

Yes, Vijay may be right. Anyway I think the text must mention that the
BUL entry is created when the PBU is sent.

> So it should be a "MUST" here.

Yes.

Gerardo

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 30 Nov 2007 16:06:14 -0800

Hi Sri,

Thanks for addressing my comments. Please find some more comments
inline.

> This is not about making a client look dumb, but reflects the basic

My point is that the network is responsible to send PBU which updates
the IP routing. This implies that the network is responsible of the IP
mobility management. Saying that the network controls the overall
mobility management is wrong as the overall mobility management includes
several aspects.

Moreover, the fact that the MAG sends the PBU does not mean that the
network controls the mobility as the MN still performs several L2
procedures which trigger the network to send the PBU. 

Finally, also in MIPv6 the network controls the mobility as can refuse a
BU from the MN. 

I would be OK if we can rephrase as follow:

"The design principle in the case of a network-based IP mobility
management protocol relies on the network being responsible of sending
the signaling messages to update the routing after a movement of the MN"

> [Sri] Ok. Dont agree, but will change it.

Good.

> [Sri] Ok. mobility to IP mobility, home agent to home agent with

OK.

> can support both types of nodes.

As we have discussed in the context of
draft-giaretta-netlmm-mip-interactions there are many issues when a
MIPv6 capable node is in a PMIPv6 domain. It is not clear what means
that both types of nodes are supported: indeed a MIPv6 node never acts
as a MIPv6 node if PMIPv6 is always used. In my view this does not mean
that a MIPv6 node is supported.

Moreover, the first sentence may not be true in case of multihoming
support. The need for the network to know about HI and Interface Type
seems in contrast with the fact that the network is agnostic of the
capability of the IPv6 stack of the nodes.

> go away, because its PMIP6.

I agree. My comment was referred to the fact that the wording implies
that these are advantages specific of the PMIPv6 solution. 

The third and fourth advantages are not clear to me. Please remove them
and point to the problem statement RFC.

> >       mode.  The mobile node is not required to participate in any
IP
> [Sri] Ok. What is the change ? "mobility" vs "IP mobility" ? Is that
not

As mentioned in the beginning to me there is a big difference. Mobility
implies several aspects which may include network selection to IP
mobility. I am sure this is implicit for all authors and many people in
the WG but I think it is technically more correct to state "IP
mobility".

> not a virtual link. It makes sense to us. We should keep this.

Then I am missing something here. The assumption is that the MN acts as
always in the same link, which is the home link, as it never changes the
IP address. However there is a specific link among all these links which
has a specific meaning just because it is the first link visited by the
MN in the PMIPV6 domain. Do we really need this definition? Is it needed
for any functionality of PMIPv6? It sounds a bit confusing to me.

> state that, it will imply L2 mobility. We are almost splitting hair
here.

Sorry being picky on this aspect. I think it is important to always use
the correct terminology in order to avoid misunderstanding. 

> using the same RA's from the AR on the link.

Yes, this is correct. I was referring to the sentence "includes the
address(es) from its home network prefix". Isn't just the prefix which
is obtained? Besides the default-router address, I mean. 

> Lets stick to what we agreed and posted in the ML.

What are the other mechanisms? Are they defined somewhere? This was not
discussed in the mailing list I think. 

> policy profile. Please refer to my response in Sec 6.2 as well.

The term policy profile mandates the usage of an external entity in
order to have a working solution but it does not specify any interaction
with this. To me this means that it is out of the scope of the document
and needs not to be mentioned. 

I think it is cleaner to say that the network entities require access to
some parameters and how this is performed is out of the scope of the
document. I think this would be more correct.

> keep only new parameters. No change.

Fine. 

> constitutes a unique search key in the BCE table.

I agree that HNP is a unique key. So why do you mention (MN-ID,
Proxy-CoA)? How would this work?

> mobile. We missed it here. Let me know, if you wante the text to be

I think that for a WGLC the issue should always be solved in the mailing
list. This is needed in order to be sure that a second WGLC is not
needed.

> this is probably better when structured this way.

I disagree, but I can live with this.

> must be applied". Ok, fine.

Yes, thanks. Sorry for the confusion.

> clear, provide the text that you think is right.

This is what it not clear to me: what does it mean that bob.ietf.org is
not known to LMA? Are you assuming that LMA have all possible MN-IDs? Or
is it that an authorization step is unsuccessful? 

> returning this status code. Let me know, if you want the text before.

As mentioned, that would be better, as always. 

> from these different sections are chained.

Yes but I think this is really confusing. It does not help the reader at
all as the rules in section 5.3 are not complete because the checks in
5.4 are needed too. Any single rule in 5.3 must be completed by the part
in 5.4; to me this is really confusing. 

> issue, lets stick to that.

I'm still missing how the network can derive that trigger. Even in case
of handover preparation as under definition in other SDO, there is not a
clear indication if the old connection needs always to be closed.

Anyway, I can live with the old text if this is unacceptable to you. 

> Let me know, if you need the text on this before.

Up to you :)

> both places. But, we can change it, if others think the same way.

OK.

> [Sri] Please see my comments on Policy Store below (comment on Sec
6.2)

Please see my reply.

> you need the text before.

As in any WGLC. 

> talk about bi-directional tunnel and so dont agree with this change.

Don't we have a tunneling both for uplink and downlink packets?

> Please correct me, if my assumption is wrong.

My concern is that the LMA discovery is underspecified in the document.
As there is a clear statement in the charter that this should not be
part of the base specification, I think we can just leave out of the
scope of the document.

> for MAG and LMA implementation, I can provide a simple config file or
a
> CLI
> interface for provisioning user data and my system will work.

We can then just say the LMA is statically configured at the MAG and
dynamic discovery or assignment are out of scope.

>  The policy
> parameters and on a per user basis. 

I fully agree. This is why I think it is cleaner to state that these
parameters are needed and how they are conveyed to the MAG is out of the
scope of the base specification and may be system/deployment specific. 

The policy profile seems to be a magic box which solves all the issues,
but this is clearly not the case.

> What we call that, a policy profile or

Who are we? Remember that this is a WG document, not your document :)

My point is that there is no MAY, SHOULD or MUST in this paragraph and
therefore it is not clear what should be implemented. Do you agree with
that?

> configuration. Same response for both the above comments.

Same replies as above. Please include this issue among the open issues
in the Vancouver slides as we should discuss this aspect during the
meeting.

> the MN's profile on that box. This response is valid for both the
above

In the MIPv6 bootstrapping it is always the HA which assigns the HoA.
Why do we need the MAG to provide the hint? Which are the deployment
requirements for this?

> the MAG behavior should be the same.

OK, right. 

> PBU b.) LMA yet to accept PBU.

Exactly, this is more or less what we have in RFC 3775

> [Sri] Ok. Will define a config parameter. Let me know, if you need

It's not if I want it or not. It's that you are supposed to reach the
agreement on the text and on the open issues after the WGLC. Either you
publish a new version and you provide the next text in separate emails
for each issue or you publish the text before submitting the draft, but
you have to reach agreement on the text after a WGLC.

> better not to mandate this and I dont think this will cause any

I think it should be a MUST. See also Vijay's comment.

> the protocol in detail, for some on doing the implementation, these
basics

Fine
 
> PMIP6 deployments, these type of restrictions will kill the protocol
and

Not sure if any restriction will kill the protocol as other SDOs are
already working on SDO-specific solutions for LMA discovery and other
issues.

Even though there can be multiple LMAs in a PMIPv6 domain, I think the
dynamic LMA discovery is currently out of scope. Again, this will not
have any impact on PMIPv6 deployments as interested SDOs are working on
SDO-specific solution.

> > we leave it out of scope.

What about the issue above?

> mobile node. How graceful a system should behave in such scenario.

I think this is not clear as it is written what the MAG should do but
not how it should do. This is fine as it is a system level issue but
then I think we should limit the amount of this informative text.

> > possible Mobility Options

Thank you for the time spent on replying to all comments.

Gerardo