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

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 2 Dec 2007 09:36:28 -0800

Hi Vijay,

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Wednesday, November 28, 2007 2:26 PM
> To: Sri Gundavelli
> Cc: 'Giaretta, Gerardo'; [email-masked]
> Subject: Re: [netlmm] Review of draft-ietf-netlmm-proxymip6-07
> 

> > [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.
> 
> 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...
> 
> >> - 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?
> >>
> > 
> > [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. 
> 
> 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.
> 

I agree.

> >> - 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?
> >>
> > 
> > [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.
> 
> 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.
> 

Ok. We can change this. George had the same comment. Since, 
I dont have a good usecase to show when we would need this,
we can put a MUST there.

Sri

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

---

From: Bedekar Anand-ABEDEKA1 <[email-masked]>
Date: Sun, 02 Dec 2007 23:31:37 -0600

Sri/Vijay,

Please see below.

-Anand

On 12/2/2007 11:36 AM, Sri Gundavelli wrote:

<Snipping other parts from thread>

> I dont have a good usecase to show when we would need this,

I agree that MUST is appropriate there. Similarly, "MUST" in 
the corresponding list for the LMA on page 22, section 5.3, 
first two bullets just below Figure 6.

But I do have a question about Figure 8 in the "Signaling 
Considerations" section for MAG:
(p.43, just above the bullets that Gerardo referred to):

"               IPv6 header (src=Proxy-CoA, dst=LMAA)
                     Mobility header
                         -BU /*P & A flags are set*/
... "

The source address of the PBU need not always be the same as 
the Proxy CoA. I think it should be legitimate for the MAG 
to use one address (say IP1) for all the signaling PBU 
messages, and one or more other addresses (IP2, IP3,...) as 
the Proxy CoAs. For example, the MAG may want to use 
multiple CoAs to load-balance across interfaces, but for the 
sake of maintaining just one IPSec association with a given 
LMA, it may use just one IP address for all PBUs. So when 
constructing the IPv6 hdr for the PBU, src address MUST be 
AN address of the MAG, but that may or may not be the same 
as the Proxy-CoA. Clearly, whatever address the MAG uses as 
src address in the PBU must match the SPD at the LMA for 
IPSec, etc. So I think the wording of the first bullet right 
after Fig. 8 should be :

"The Source Address field in the IPv6 header of the message 
MUST be set to an address of the mobile access gateway"

(using "an address" instead of "the address", and MUST 
instead of SHOULD as per Gerardo's comment)

and the first line in Fig. 8 should be:
                IPv6 header (src=MAG-addr,dst=LMAA)

One question here : if the MAG sends a PBU using a src addr 
different from the Proxy CoA in the PBU, must it use the 
Alternate-CoA field in the PBU?

Another related point: in Fig. 6 in section 5.3:

"               IPv6 header (src=LMAA, dst=Proxy-CoA)
                     Mobility header
                 ..."

The dst address of the PBAck message I think needs to be the 
same as the src address that was used in the corresponding 
PBU. The second bullet below this figure is correct (modulo 
the SHOULD/MUST question), but Fig. 6 doesn't reflect that.

One more point relating to this:
On p. 21, second bullet in "Binding De-Registration:"

"    If the received Proxy Binding Update request with the 
lifetime
       value of zero, has a Source Address in the IPv6 
header different
       from what is present in the Proxy-CoA address field 
in the Binding
       Cache entry existing for that mobile node, the local 
mobility
       anchor MUST ignore the request."

Again, the src addr in the PBU IPv6 hdr need not be the same 
as the Proxy-CoA. But I'm not sure what the correct wording 
should be here, because I don't quite understand what error 
situation this constraint is guarding against - Perhaps the 
possibility that an old MAG tries to de-register the MN 
after some other MAG has already sent a PBU for that MN?

Thanks,
Anand

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 2 Dec 2007 22:08:42 -0800

Hi Anand,

Please see inline .. 

Sri

> Alternate-CoA field in the PBU?

Alt-CoA option can be used. If the option is present, the
3775 rules apply and the CoA field in the BCE and the tunnel end
point will point to the address specified in the Alt-CoA option.
But, the above rules will not change. The transport end points
in the signaling plane will remain the same. So, I agree with
your above comment that the Src address field can be different
that the CoA when the Alt-CoA option is present.

> as the Proxy-CoA. But I'm not sure what the correct wording 

I think, we can broadly state that when Alt-CoA option is
present, the CoA address in the BCE will be that of the value
present in the option. But, this is really implicit and is
all as per 3775. If others have no concerns adding this, I'm
personally ok adding one explicit line with out touching the
above normal usage example.

> after some other MAG has already sent a PBU for that MN?

This is for the scenario where the PBU message from the nMAG
updates the BCE first and the dereg PBU message from the pMAG 
arrives later, the CoA wont match as the BCE is already updated.
Guidance on what to do with that dereg PBU.

Thanks for your comments.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 06 Dec 2007 17:24:21 -0800

Bedekar Anand-ABEDEKA1 wrote:

> The source address of the PBU need not always be the same as the Proxy 
> CoA. I think it should be legitimate for the MAG to use one address (say 
> IP1) for all the signaling PBU messages, and one or more other addresses 
> (IP2, IP3,...) as the Proxy CoAs. For example, the MAG may want to use 
> multiple CoAs to load-balance across interfaces, but for the sake of 
> maintaining just one IPSec association with a given LMA, it may use just 
> one IP address for all PBUs. So when constructing the IPv6 hdr for the 
> PBU, src address MUST be AN address of the MAG, but that may or may not 
> be the same as the Proxy-CoA. Clearly, whatever address the MAG uses as 
> src address in the PBU must match the SPD at the LMA for IPSec, etc. So 
> I think the wording of the first bullet right after Fig. 8 should be :
> 
> "The Source Address field in the IPv6 header of the message MUST be set 
> to an address of the mobile access gateway"

I agree with this. It can be any address on the MAG.

Sri, I am not sure the Alt CoA option has anything to do here.
Lets assume a MAG has two IP addresses, it could use one with
one particular LMA and the other with another LMA. It would
just use addresses as the proxy CoAs without the Alt CoA option
being present in the proxy BU.

Vijay

> 
> (using "an address" instead of "the address", and MUST instead of SHOULD 
> as per Gerardo's comment)
> 
> One question here : if the MAG sends a PBU using a src addr different 
> from the Proxy CoA in the PBU, must it use the Alternate-CoA field in 
> the PBU?
> 
> The dst address of the PBAck message I think needs to be the same as the 
> src address that was used in the corresponding PBU. The second bullet 
> below this figure is correct (modulo the SHOULD/MUST question), but Fig. 
> 6 doesn't reflect that.
> 
> "    If the received Proxy Binding Update request with the lifetime
>       value of zero, has a Source Address in the IPv6 header different
>       from what is present in the Proxy-CoA address field in the Binding
>       Cache entry existing for that mobile node, the local mobility
> Again, the src addr in the PBU IPv6 hdr need not be the same as the 
> Proxy-CoA. But I'm not sure what the correct wording should be here, 
> because I don't quite understand what error situation this constraint is 
> guarding against - Perhaps the possibility that an old MAG tries to 
> de-register the MN after some other MAG has already sent a PBU for that MN?
> 
> Thanks,
> Anand
>

---

From: Bedekar Anand-ABEDEKA1 <[email-masked]>
Date: Thu, 06 Dec 2007 22:34:18 -0600

Hi Vijay,
Please see below.
-Anand

On 12/6/2007 7:24 PM, Vijay Devarapalli wrote:
>> CoA. I think it should be legitimate for the MAG to use one address 
>> (say IP1) for all the signaling PBU messages, and one or more other 
>> addresses (IP2, IP3,...) as the Proxy CoAs. For example, the MAG may 
>> want to use multiple CoAs to load-balance across interfaces, but for 
>> the sake of maintaining just one IPSec association with a given LMA, 
>> it may use just one IP address for all PBUs. So when constructing the 
>> IPv6 hdr for the PBU, src address MUST be AN address of the MAG, but 
>> that may or may not be the same as the Proxy-CoA. Clearly, whatever 
>> address the MAG uses as src address in the PBU must match the SPD at 
>> the LMA for IPSec, etc. So I think the wording of the first bullet 
>> right after Fig. 8 should be :
>>
>> "The Source Address field in the IPv6 header of the message MUST be 
>> set to an address of the mobile access gateway"
> 

[Anand] Yes, Alt-CoA is not required if the src address that 
the MAG uses for a particular LMA is the same as the CoA 
that the MAG wants to use for that LMA. Only if the MAG 
wants to use one of its addresses as the source IPv6 address 
of the BU but wants to use a *different* one of its 
addresses as the CoA, then Alt-CoA makes sense. As Sri 
mentioned, use of Alt-CoA in that case would simply be an 
application of the 3775 rules.

> 
>>
>> (using "an address" instead of "the address", and MUST instead of 
>> SHOULD as per Gerardo's comment)
>>
>> The dst address of the PBAck message I think needs to be the same as 
>> the src address that was used in the corresponding PBU. The second 
>> bullet below this figure is correct (modulo the SHOULD/MUST question), 
>> but Fig. 6 doesn't reflect that.
>>
>> because I don't quite understand what error situation this constraint 
>> is guarding against - Perhaps the possibility that an old MAG tries to

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 11 Dec 2007 19:41:34 -0800

Hi Gerardo,

Please see inline ... 
 
Regards
Sri

> > > 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,
> > >
> > > 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.
> > >
> > 
> > [Sri] I've provided responses to your detailed comments below.
> > 
> > 
> > > 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.
> > >
> > 
> > [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.
> > 
> 
> 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]
Network is responsible for the IP mobility management. It is controlling
that aspect. What you have provided here, is breakdown on the definition
of the mobility function and with missing other pieces. If the word
"control" is the issue. we can remove that. We can make the following
change removing that entire sentense, just to keep you happy. Even though,
I dont agree with your interpretation. As per 3344 or 3775, what is provided
is IP mobility, nothing more, nothing less. Below is the text:
  
   "Network-based mobility management enables IP mobility for a host
   without requiring its participation in any mobility related
   signaling.  The Network is responsible for managing IP mobility on
   behalf of the host.  The mobility entities in the network are
   responsible for tracking the movements of the host and initiating the
   required mobility signaling on its behalf.  This specification
   describes a network-based mobility management protocol and is referred
   to as Proxy Mobile IPv6."

> > 
> > > - 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.
> > >
> > 
> > [Sri] Ok. Dont agree, but will change it.
> > 
> 
> Good.
> 

[Sri] Will change it as agreed upon above.

[Closed]

> > 
> > > - 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.
> > >
> > 
> > 
> > [Sri] Ok. mobility to IP mobility, home agent to home agent with
> >     modifications.
> > 
> > 
> 
> OK.
> 

[Sri] Will change "mobility" to "IP mobility".

[Closed]

> > 
> > > - 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.
> > >
> > 
> > [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.
> > 
> 
> 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.
> 

[Sri] See the comment from Vijay as well on this. No change.

> 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.
> 
> > 
> > > - 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.
> > >
> > 
> > [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.
> > 
> 
> 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.
> 

[Sri] Remove these bullets ? I dont care. If others have no problem,
Raj/Vijay ?

   o  Addresses a deployment need.

   o  May be better suited on certain types of resource-constrained
      links or because of service provider specific policies.

> > 
> > > - 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.
> > >
> > 
> > 
> > [Sri] Ok
> > 
> > 

[Sri] Will change the text as agreed upon above.

[Closed]

> > 
> > > - 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.
> > >
> > 
> > [Sri] Ok. What is the change ? "mobility" vs "IP mobility" ? Is that
> not
> > implicit ?
> > 
> 
> 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".
> 

[Sri] Your view ... fine. Will change it to IP mobility in all places.

[Closed]

> > 
> > > - 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.
> > >
> > 
> > 
> > [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.
> > 
> 
> 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.
> 
> 

[Sri] The mobile node is always on the home link. That link is 
where it obtained its address configuration. From the client
perspective, we need to be able to state the mobile is always
on the home link. No change.

> > 
> > > - 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.
> > >
> > 
> > [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.
> > 
> 
> Sorry being picky on this aspect. I think it is important to 
> always use
> the correct terminology in order to avoid misunderstanding. 
> 

[Sri] No problem, if this makes you more happy. Will change it to "IP
mobility".

[Closed]

> > 
> > > - 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
> > >
> > 
> > [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.
> > 
> 
> 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. 
> 

[Sri] Consistent with the RA options in 4861. It could be flags
Managed or Unmaged ..related parameters. No change.

> 
> > 
> > > - 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.
> > 
> > 
> > [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.
> > 
> 
> What are the other mechanisms? Are they defined somewhere? 
> This was not
> discussed in the mailing list I think. 
> 

[Sri] This is upto the SDO architectures that implement this protocol
to define that trigger. This is out of scope for this document. No change.

> > 
> > >
> > > - 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"
> > >
> > 
> > [Sri] Ok.
> > 

[Sri] Will adopt the above text.

[Closed]

> > 
> > > - 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:
> > >
> > 
> > [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.
> > 
> 
> 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.
> 

[Sri] As we discussed in the IETF WG meeting, we will add a policy
profile definition in the terminology section as below:

"
Policy Profile:

Policy Profile is an abstract term for referring to a set of 
configuration parameters that are configured for a given mobile
node. The mobility entities in the Proxy Mobile IPv6 domain require
access to these paramaters for providing the mobility management to
a given mobile node. The specific details on how the network entities
obtain this policy profile is outside the scope of this document.
"

> > 
> > >    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
> > >
> > 
> > [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.
> > 
> 
> Fine. 
> 

[Sri] No change.

[Closed]

> > 
> > > - 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?
> > >
> > 
> > [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.
> > 
> 
> I agree that HNP is a unique key. So why do you mention (MN-ID,
> Proxy-CoA)? How would this work?
> 

[Sri] That combination is unique too. For dereg from the MAG that
created the session, it is sufficient. No change.

> > 
> > > - 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
> > >
> > 
> > [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.
> > 
> 
> 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.
> 

[Sri] We can make the following change.

   "This specification supports Per-MN-Prefix model and does not support
   Shared-Prefix model.  As per the Per-MN-Prefix model, there will be
   an unique home network prefix assigned to each mobile node and no other
   node shares an address from that prefix. The assigned prefix is unique
   to a mobile node and also unique to a given interface of the mobile node.
   If the mobile node is attached to a Proxy Mobile IPv6 domain through
   multiple interfaces and simultaneously, there will be an unique prefix
   that will be allocated to each of the connected interfaces."

> > 
> > > - 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.)
> > >
> > 
> > [Sri] We thought about this. But, there is a order here and we felt
> > this is probably better when structured this way.
> > 
> 
> I disagree, but I can live with this.
> 

[Sri] No change.

[Closed]

> > 
> > > - 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.
> > >
> > 
> > [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.
> > 
> 
> Yes, thanks. Sorry for the confusion.
> 
>

[Sri] Will adopt the above text. 

[Closed]

> > 
> > > - 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.
> > >
> > 
> > [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.
> > 
> 
> 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? 
> 

[Sri] For the LMA to accept the binding, it needs to identify and
authorize the mobile node. This probably again goes back to your
concern on the profile thing. We are not talking about how the
LMA authorizes a mobile. If the MN-ID list is local or in a AAA
database is not specified here, that is for your or some one's
bootstrapping document. No change.

> > 
> > > - 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
> > >
> > 
> > [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.
> > 
> 
> As mentioned, that would be better, as always. 
> 

[Sri] Will make the following change in Section

5.3: Constructing the Proxy Binding Acknowledgement Message:

"The identifier in the Mobile Node Identifier option [RFC-4283] MUST be
copied from the received Proxy Binding Update request. If the Status
field value is set to MISSING_MN_IDENTIFIER_OPTION, the identifier in
the Mobile Node Identifier Option MUST be set to a zero length
identifier."

> > 
> > > - 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.
> > >
> > 
> > [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.
> > 
> 
> 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. 
> 

[Sri] There are others who think, this break down is good. We need to
get input from others before we merge the sections. This gives
better readability, as some people thing. Lets gets more input on
this. 

> > 
> > 
> > > - 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.
> > >
> > 
> > [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.
> > 
> 
> 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. 
> 

[Sri] No change.

[Closed]

> > 
> > 
> > > - Section 5.4, Processing De-Registration Message: why is this
> > > multihoming specific? I don't see anything about 
> multihoming in this
> > > paragraph
> > >
> > 
> > [Sri] Agreed. Will fix this by moving this to 5.3.
> > 

[Sri] Will move it to Section 5.3.

[Closed]

> > 
> > > - 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.
> > >
> > 
> > [Sri] Ok. Its not needed. But, we can define a configurable 
> parameter.
> > Let me know, if you need the text on this before.
> > 
> 
> Up to you :)
> 

[Sri] Will make the following change.

"However, if there is no de-registration message that is received
within MinDelayBeforeNewPrefixAssign amount of time, the local mobility
anchor upon accepting the request MUST assign a new home network prefix
and create a new Binding Cache entry."

Protocol Variable:

MinDelayBeforeNewPrefixAssign = 500 Millisecs.

> > 
> > 
> > > - 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.
> > >
> > 
> > 
> > [Sri] Ok. Same comment from others. Will fix it.
> > 

[Sri] Will make the above change.

[Closed]

> > 
> > 
> > 
> > > - 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
> > >
> > 
> > 
> > [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.
> > 
> 
> OK.

[Sri] No change.

[Closed]

> 
> > 
> > > - 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:
> > >
> > 
> > [Sri] Please see my comments on Policy Store below (comment on Sec
> 6.2)
> > 
> 
> Please see my reply.
> 

[Sri] We agreed in the WG meeting to have a definition on the Policy
Profile. Text provided above. 

[Closed]

> > 
> > >    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.
> > >
> > 
> > 
> > [Sri] Ok. I see the point. Will rephrase this. Let me know if
> > you need the text before.
> > 
> 
> As in any WGLC. 

[Sri] We can make the following change.

      "Implementations MAY use a software timer for managing the
      tunnel lifetime and a counter for keeping a count of all the
      mobile nodes that are sharing the tunnel.  The timer value MUST be
      set to the accepted binding lifetime and MUST be updated after
      each periodic re-registration for extending the lifetime.  If the
      tunnel is shared for multiple mobile nodes, the tunnel lifetime
      MUST be set to the highest binding lifetime that is granted to any
      one of those mobile nodes sharing that tunnel."

> 
> > 
> > > - 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
> > >
> > 
> > [Sri] Please refer to my comments on Policy store below.
> > 

[Sri] We agreed in the WG meeting to have a definition on the Policy
Profile. Text provided above. 

[Closed]

> > 
> > >    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
> > >
> > 
> > [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.
> > 
> 
> Don't we have a tunneling both for uplink and downlink packets?
> 

[Sri] The section is about Return Routability and that we are not
supporting it here and thats all we are stating. No change.

> > 
> > 
> > > - 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.
> > >
> > 
> > [Sri] Ok
> > 

[Sri] Will adopt the above text.

[Closed]

> > 
> > > - 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.
> > >
> > 
> > 
> that problem
> ?
> 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.
> 

[Sri] We already discussed about multiple LMA's offline and I assume
we can close this. No change.

> 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
> 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.
> 

[Sri] This goes back to the policy definition. We are not talking
about discovery here. We just state the MAG is aware of this information
from the policy profile. How it gets the policy profile or generates
the policy profile is out of scope. No change.

> >  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. 
> 
> 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

[Sri] We agreed in the WG meeting to have a definition on the Policy
Profile. Text provided above. 

[Closed]

> > 
> > > - 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.
> > >
> > >
> > 
> > [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.
> > 
> 
> Who are we? Remember that this is a WG document, not your document :)
> 

Its not my document or your document. "We" implies the "authors". If one
person in the WG suggests some thing, it does not mean we just need to
accept the text. We as the authors need to ensure the text reflects the
WG consensus. If we dont agree to some text that some one suggests, they
can very well open it for discussion and get the WG consensus to add that
in. The word here is "being reasonable". 

> 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?

[Sri] Not every line must have a normative language. Some times you
explain the operation and provide the background. Normative language
is used in the right places, where ever required. No change.

> 
> > 
> > > - 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)
> > >
> > 
> > 
> > [Sri] No. Please see my prev. response on the use of policy 
> store for
> > 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.

[Sri] We agreed in the WG meeting to have a definition on the Policy
Profile. Text provided above. No change.

[Closed]

> 
> > 
> > > - 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.
> > >
> > 
> > [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.
> > 
> 
> 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?
> 

[Sri] This issues was discussed before in the ML and was listed in
the issue tracker. The issue was resolved after discussions in the ML.
The summary of the consensus:

- LMA is responsible for authorizing the prefix allocation. It manages
the addressing. However, MAG can always provide a prefix hint and the
LMA may or may not decide to accept that request. Its useful in many
cases.

The text reflects the WG consensus. No change.

> > 
> > > - Section 6.9.1, second list, bullet 10. It is not clear what
> > > happens in
> > > 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.
> 
> OK, right. 
> 

[Sri] No change.

[Closed]

> > > created when the MN sends the BU. Why the text in this bullet
> suggests
> > if the BCE is accepted, for differentiating the cases of a). LMA
> accepted
> Exactly, this is more or less what we have in RFC 3775
> 

[Sri] Will make the change that the MAG must create the BUL entry right
upon sending the PBU.

[Closed]

> > 
> > > - Section 6.9.1, fourth list, bullet 2. I think we must 
> specify what
> > > "after a certain timeout" means
> > >
> > 
> > [Sri] Ok. Will define a config parameter. Let me know, if you need
> > the text before.
> > 
> 

[Sri] Will make the following change.

      Either upon receipt of a Proxy Binding Acknowledgement message
      from the local mobility anchor or after MinPBURetryTime amount
      of time waiting for the reply, the mobile access gateway MUST
      remove the Binding Cache entry for that mobile node from its
      Binding Update List and withdraw the mobile node's home network
      prefix as the hosted on-link prefix on that access link.

Protocol Variable:

MinPBURetryTime = 2 secs.

> 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.
> 
> I think it should be a MUST. See also Vijay's comment.
> 

[Sri] Agreed. Will change it to MUST.

[Closed]

>  
> > 
> > > 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.
> > >
> > 
> > [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.
> >
> 
> Fine
>  

[Sri] No change.

[Closed]

> > 
> > > - Section 6.10.3, second paragraph. I think multiple LMAs 
> are out of
> > > 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.
> > 
> 
> 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.
> 

[Sri] We discussed about the LMA discovery above. No change. 

> > 
> > > - 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

[Sri] The DHCP Relay function MUST be enabled on the link
for supporting DHCP based addressing. Its not required, if
DHCP addressing is not enabled on the link. This is specified
in that section. No change.

> > > 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.
> > >
> 
> What about the issue above?
> 

[Sri] See above.

> > > - Section 6.14. I think this section should be removed. The
> > > interactions
> > > 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.
> > 
> 
> 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.
> 

[Sri] This is very limited text. We cant remove any thing further. No
change.

> > 
> > > - 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
> > >
> > 
> > [Sri] Agreed.
> > 

[Sri] Will add the missing parameters.

[Closed]

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

[Sri] With pleasure :)

> Gerardo

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 11 Dec 2007 22:17:17 -0600

> better readability, as some people thing. Lets gets more input on

[Ahmad]
YES. I agree with Sri. Keep it as is. 
Many Thanks!

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 13 Dec 2007 13:56:02 -0800

Hi Sri,

Thanks again for your responses. Please see inline.

~ snip ~

>    to as Proxy Mobile IPv6."

The text is fine to me.

~ snip ~

> [Sri] See the comment from Vijay as well on this. No change.

I still think the text is not accurate but I can live with it.

[Closed]

>       links or because of service provider specific policies.

This would be fine to me.

> on the home link. No change.

Yes, I agree with your statement above and the goal. Currently the
definition states:

      "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." 

The term "_initial_ layer-3 address configuration" seems misleading to
me. As you mentioned, when the UE moves to a different link in the same
PMIPv6 domain, it may get different configuration parameters (e.g.
address of the default router changes). So the initial configuration
parameters may change even though the HNP remains the same. This may
imply that the MN is no more in the home link, which is not true. 

Up to you if you want to change the definition. 

> Managed or Unmaged ..related parameters. No change.

I cannot understand this point. Does the RA includes the address? I
don't think so. It contains the home network prefix. 

> to define that trigger. This is out of scope for this document. No
change.

Can we state in the document that it is out of scope how this
information is conveyed to the MAG? 

> obtain this policy profile is outside the scope of this document.

Fine, thanks.

[closed]

> created the session, it is sufficient. No change.

I agree it is unique. But why adding this too? Should we just require to
always use the HNP as the unique key?

>    that will be allocated to each of the connected interfaces."

Text looks good. Just a nit in the last sentence:

    If the mobile node is attached to a Proxy Mobile IPv6 domain through
    multiple interfaces and simultaneously, different prefixes
    will be allocated to each of the connected interfaces."

> bootstrapping document. No change.

OK, got it. Thanks for the explanation. Can we then rephrase as follows?

o  If the local mobility anchor cannot authorize the mobile node based
the Mobile Node Identifier option [RFC-4283] present in the request, it
MUST reject the Proxy Binding Update

> the Mobile Node Identifier Option MUST be set to a zero length

Good, thanks.

[closed]

> better readability, as some people thing. Lets gets more input on

OK, I would suggest sending a separate email on the list for this issue
so we can get other opinions.

Let me know if you want me to do that.

> MinDelayBeforeNewPrefixAssign = 500 Millisecs.

OK, good

[closed]

>       one of those mobile nodes sharing that tunnel."

This sounds much better. Thanks

[closed]

> > > >    as defined in Mobile IPv6 cannot be used in Proxy Mobile
IPv6.
> supporting it here and thats all we are stating. No change.

I don't understand your view, but this is minor. I can live with this.

[closed]

> we can close this. No change.

We need to state that the LMA discovery/assignment is out of scope of
the document. This was the agreement offline. 
> the policy profile is out of scope. No change.

The current definition of policy profile does not list the parameters. I
think it is important to list in the policy profile definition the
parameters which are in the policy profile, including the LMA address.

This will be very useful to other documents such as the Diameter PMIPv6
application and the context transfer document, when they will be done. 

> in. The word here is "being reasonable".

I agree with everything you said, just replace authors with WG. But this
is fine and we have just discussed this in Vancouver

[closed]

> is used in the right places, where ever required. No change.

I still think the draft sometimes has too much informative text. But I'm
fine. I will leave the final decision to the IESG review.

[closed]

> The text reflects the WG consensus. No change.

Thanks for the explanation. 

[closed]

> MinPBURetryTime = 2 secs.

OK

[closed]

> in that section. No change.

Can we state that if DHCPv6 based addressing is supported, the MAG must
act as DHCP Relay?

> [Sri] This is very limited text. We cant remove any thing further. No

Fine. I'll let IESG decide if this is OK.

[closed]

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

Thanks again ;)

Gerardo

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 13 Dec 2007 15:41:17 -0800

Hi Gerardo,

Thanks. Please see inline for clarifications.

Regards
Sri

> Sent: Thursday, December 13, 2007 1:56 PM
> To: Sri Gundavelli
> Cc: [email-masked]
> Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-07
> 
> Hi Sri,
> 
> > > the IP routing. This implies that the network is 
> responsible of the
> IP

[Sri] Ok. Will adopt the above text.

[Closed]

> > > > > I think this paragraph must be completely removed. It 
> addresses
> a
> > > big
> > > > > which is not solved even in the interactions draft. 
> Besides, it
> is
> > > not
[Sri] 

[Closed]

[Sri]

[Closed]

> > > > >       manages the mobile node's binding state.  It is 
> important
> to

[Sri] Ok. We can remove the word "initial". W.r.t the address configuration,
the goal of this protocol is for ensuring the mobile retains the
address configuration as moves in the domain. Sure, there may be very minor
changes, but, it should not imply to the mobile, that the link has changed.
W.r.t the DR address, it is possible all the routers in the domain may be
using a common link-local address. L3 Address configuration generally
implies
the address and prefix info configured on the interface. If others see this
as an ambiguity, will reword it.

> don't think so. It contains the home network prefix. 

[Sri] Sorry. But, this is not suggesting that the mobile node can obtain
the address from the RA. Text below ...Let me know where you see the
problem.

   "If the network determines that the network-based mobility management
   service needs to be offered to that mobile node, the network will
   ensure that the mobile node using any of the address configuration
   mechanisms permitted by the network will be able to obtain the
   address configuration on the connected interface and move anywhere in
   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."

> > > > > I think it is not clear how the network knows that 
> the MN wants
> to

[Sri] Ok. Will add the below text.

"The specific details on how the mobile access gateway is able
to determine if the mobile node's current attachment is due to a
handoff of an existing mobility session or if it is as a result
of an attachment over a different interface is outside the scope
of this document."

Some thing to this affect ... slight rewording will be there..

> > > > > is a system level concept which does not clarify the 
> operations
> of
> > > the
> > > > such as in 3775 and in DSMIP for the IPv4 support doc. 
> So, we had
> to

[Sri] If we use HNP and ignore the PCOA, will endup deleting a
valid binding after handoff.

> >    to a mobile node and also unique to a given interface of 
> the mobile
> > node.

[Sri] Ok. Will adopt the text.

[Closed]

> > > > suggests what to do. If there is MN-Id say, 
> bob.ietf.org and that
> id
> > > is

[Sri] Ok. Will adopt the text.

[Closed]

> > > > [Sri] No. Its a logical grouping, it provides better 
> readability.
> In
> > > all as the rules in section 5.3 are not complete because 
> the checks
> in

[Sri] Ok. I will open this for input.

> >       mobile nodes that are sharing the tunnel.  The timer 
> value MUST
> be
> > > > >    In Proxy Mobile IPv6, the mobile node is not 
> involved in any
> IP
> > > > > mobility
[Sri]

[closed]

> the document. This was the agreement offline. 

[Sri] There seems to be different views here. My view is that, this
document is not defining any discovery mechanim. Vijay's view is that
there is no need for any discovery mechanism and what is defined is
adequate. I'm not commenting on the second part. All I prefer saying
is that, "the specific details on how the MAG obtains the policy
profile or generates the policy profile is outside the scope of this
document." LMA address is  a parameter in that profile. This clearly 
gives you what you want. The doc does not use the word discovery or
any DNS SRV records etc ... so you are fine.

> follow this

[Sri] It does list the parameters. Please refer to Section 6.2.

[Closed]

> Can we state that if DHCPv6 based addressing is supported, 

[Sri] It is stated. Will check and add clarification, if that is
not clear.

[Closed]

> > > > > received HNP completes the DHCPv6 exchange including 
> the prefix
> in
> > > the

Thanks !

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 13 Dec 2007 16:29:39 -0800

Hi Sri,

Thanks again for your good work on the comments.
Please find inline some more comments on the few remaining issues.

> as an ambiguity, will reword it.

I agree with you. I think this ambiguity exists. I am fine if I am the
only one seeing it.

> > > > > > Isn't just the home network prefix which is obtained? Only
if
> > DHCP

The point is that if stateless autoconfiguration is used then the
obtained address configuration does not include the address from the
HNP, but only the HNP. The text is slightly misleading.

Good.

[closed]

> > > > > [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

Yes, I'm fine.

[closed]

> [Sri] It does list the parameters. Please refer to Section 6.2.

You are right. However, based on the previous closed issue, the LMAA can
be only in the policy profile as the document does not specify how to
discover it. This implies that must be a mandatory field of the policy
profile for this specification. Other documents may define mechanisms to
populate dynamically this entry of the policy profile.

I would suggest moving the LMAA as mandatory field of the policy
profile.

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

Thanks

Gerardo

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 13 Dec 2007 17:57:42 -0800 (PST)

Hi Gerardo,

Please see inline ...

> I agree with you. I think this ambiguity exists. I am fine if I am the

[Sri] If no comments from others, will close this.

> HNP, but only the HNP. The text is slightly misleading.

[Sri] If SLAAC is used, identifier of EUI-64 format or of 3041
privacy based identifier, the mobile "will be be able to obtain
or generate an address from its HNP". I dont see where it misleading,
but, we can reword it, if others see this. I think, this is fine.

> I would suggest moving the LMAA as mandatory field of the policy

[Sri] It was a mandatory field till -05 version of the draft.
Suresh or some one wanted this to be in optional section,
so as to allow other modes of discovery. But, I agree with
what you stated, we probably should not have moved this.
To restate, not to make the error again.

The profile is required for the protocol to work. The LMAA
is a mandatory field in the profile. The entire profile can
be generated dynamically, can be statically configured or can
be handed off to the serving MAG as part of CT. Given this,
if we move the LMAA to the mandatory section, this will be
still be correct, as it is the mandary field in the profile.
I agree, we should move it back. If there are no objections
from others, will do so.

Thanks again.

Regards
Sri

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 13 Dec 2007 22:31:50 -0800

Hi Sri,

I think the LMAA must be a mandatory field of the policy profile.
Different mechanisms can be used to populate this policy profile at the
MAG. These are out of scope of the specification.

I think all issues can be closed, with the exception of the editorial
issue on the multihoming section. 

Thanks again for your hard work

Gerardo

> From: Sri Gundavelli [mailto:[email-masked]]
> Sent: Thursday, December 13, 2007 5:58 PM
> To: Giaretta, Gerardo
> Cc: [email-masked]
> >>>       Layer-3 address configuration for one of its interfaces
after
> >>> The term "_initial_ layer-3 address configuration" seems
misleading
> >> address configuration as moves in the domain. Sure, there may be
very
> >> minor
> >> W.r.t the DR address, it is possible all the routers in the domain
may
> >> the address and prefix info configured on the interface. If others
see
> >>    address configuration on the connected interface and move
anywhere
configuration
default-
> >>>> to define that trigger. This is out of scope for this document.
No

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 14 Dec 2007 11:23:22 -0800

>       links or because of service provider specific policies.

Removing these two is fine with me.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 14 Dec 2007 11:38:09 -0800

Sri, Gerardo and others,

I don't think LMA discovery can be out of scope for this document.
I also think we should not assume that the LMA IP address stored
in the policy profile is the only mechanism.

My understanding so far has been that we re-use the MIPv6
integrated and split scenario bootstrapping mechanisms for PMIPv6.

When the mobile node attaches to the MAG, it performs access
authentication. As part of access authentication, the MAG obtains
the IP address of the LMA that it needs to use for the particular
mobile node. This would be the integrated scenario.

The MAG can also do a DNS lookup for the LMA [RFC 5026]. How the
MAG obtains the FQDN for the DNS lookup could be out of scope. The
MAG could construct it from the realm part of the NAI provided by
the mobile node during access authentication. This would be the
split scenario.

So we have three mechanisms that we need to describe

1. LMA configuration on the MAG - The LMA to use is already
    configured on the MAG for a particular PMIPv6 domain or for a
    particular mobile node.

2. DNS lookup [RFC 5026]

3. LMA information delivered to the MAG during mobile node access
    authentication. [draft-ietf-mip6-bootstrapping-integrated-dhc]

If we agree with the above, I can quickly provide some text that
can be added to the PMIPv6 specification. We already have some
text, just needs to be cleaned up a bit. Please comment.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 14 Dec 2007 14:05:42 -0600

I agree with Vijay about the possibility of obtaining (or discovering) the
LMA address via multiple means. Makes sense in reusing some of the
techniques that have been developed already for discovering the HA address
in the bootstrapping solution I-Ds.

-Basavaraj

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 14 Dec 2007 14:07:07 -0600

> Removing these two is fine with me.

Fine by me as well. I think we no longer need the justifications for PMIP6
and hence it is sufficient to refer to the PS-doc.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 14 Dec 2007 12:16:00 -0800 (PST)

Hi Vijay,

>    configured on the MAG for a particular PMIPv6 domain or for a

We are stating the MAG *knows* the LMAA associated with a given
mobile node. This can be a local configuration or it may have
been obtained dynamically. So, what you stated above is true.
Why do we need to point to some draft in MIP6 WG or discuss about
DNS SRV records ? That's out of scope. May be there is no need
to define a new mechanism, or there is a need, why state that
here. For the system to work, we need this address and how thats
obtained is out of scope, thats always been the assumption.

Sri

>>  document." LMA address is  a parameter in that profile. This clearly gives
>>  you what you want. The doc does not use the word discovery or

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 14 Dec 2007 13:18:45 -0800

Hi Vijay, 

I think this goes beyond the scope of the base specification. Based on
definition of the policy profile that Sri has provided, it contains the
LMA address as a mandatory field. 

The base spec does not mention how the policy profile is populated, i.e.
how the MAG obtains the LMA address. You can define several mechanisms
for this, including the ones you have listed below. However some of
these have architectural impacts (e.g. the integrated scenario) and were
never discussed in the WG. Other issues are present for the DNS
discovery for example, e.g. which FQDN is used by the MAG to query the
DNS and how different MAGs can discover the same LMA address using DNS.

I am afraid the introduction of these procedures would delay the
publication of the PMIPv6 specification.

As I mentioned in Vancouver, I think the mechanisms below must be part
of the new charter as they are critical for PMIPv6 deployment. They
should not part of the base spec, though.

Gerardo

> Sent: Friday, December 14, 2007 11:38 AM
> To: Sri Gundavelli; Giaretta, Gerardo; [email-masked]
> Subject: LMA Discovery (was Re: [netlmm] Review of draft-ietf-netlmm-
> proxymip6-07)
> 
> Sri, Gerardo and others,
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 14 Dec 2007 13:20:19 -0800

> Sent: Friday, December 14, 2007 12:16 PM
> To: Vijay Devarapalli
> Cc: Giaretta, Gerardo; [email-masked]
> Subject: Re: LMA Discovery (was Re: [netlmm] Review of
draft-ietf-netlmm-
> obtained is out of scope, thats always been the assumption.

I fully agree with Sri. How the policy profile is obtained by the MAG is
out of scope of the base specification. This has always been the
assumption. 

Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 14 Dec 2007 14:17:38 -0800

Sri Gundavelli wrote:
> Why do we need to point to some draft in MIP6 WG 

Because we already have MIPv6 bootstrapping mechanisms that
can be used for PMIPv6 with little or no modifications.

or discuss about
> DNS SRV records ? 

DNS SRV records are probably not useful here. We mainly
added that to enable the mobile node to figure out if there
is "mobility service" (MIPv6 HA) in the network the mobile
node attaches to.

That's out of scope. May be there is no need
> obtained is out of scope, thats always been the assumption.

I had always assumed that we will be re-using MIPv6
bootstrapping mechanisms. There is really nothing new to
specify.

Vijay

>>> > > > > > > > > > > > > >  [Sri] You seem to be concerned about this. 
>>> Quite a few comments
>>> >  are
>>> > > >  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.
>>> gives

---

From: Frank Xia <[email-masked]>
Date: Fri, 14 Dec 2007 16:32:53 -0600

Hi Vijay and Sri

I think that  LMA Discovery,  DNS update, and such kind of
bootstrapping mechanism  is out of the scope of the basic PMIP protocol.

So we prepared Radius Proxy Mobile IPv6 draft
http://tools.ietf.org/wg/netlmm/draft-xia-netlmm-radius-01.txt.

By the way, we can't simply reuse MIPv6 bootstrapping mechanisms,
becuase there are some  differences which are highlighted in our draft.

BR
Frank

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 14 Dec 2007 15:10:33 -0800

Hi Gerardo,

> LMA address as a mandatory field. 

I am fine with the text that says the LMA address is stored in the
mobile node's policy profile. I am talking about how the LMA address
got there. IMO, we should mention that in the base specification
with references to the MIPv6 bootstrapping mechanisms.

> these have architectural impacts (e.g. the integrated scenario) 

?? What architectural impacts? The integrated scenario assumes the
following architecture.

                                       |
                   ASP(/MSP)           |   ASA/MSA(/MSP)
                                       |
                                       |
                   +-------+           |        +-------+
                   |       |           |        |       |
                   |AAAV   |-----------|--------|AAAH   |
                   |       |           |        |       |
                   |       |           |        |       |
                   +-------+           |        +-------+
                       |               |
                       |               |
                       |               |
                       |               |
                       |               |
                       |               |
                       |               |
                   +-----+    +------+ |
       +----+      |     |    |DHCP  | |
       | MN |------| NAS/|----|Server| |
       +----+      |Relay|    |      | |
                   +-----+    +------+ |
                                       |
                                       |
                   +--------+          |      +--------+
                   | HA     |          |      | HA     |
                   | in ASP |          |      |in MSP  |
                   +--------+          |      +--------+

In the above architecture, the MAG would be NAS/Relay. Everything
else would be the same, right?

and were
> DNS 

The construction of the FQDN can be based on the NAI provided by the
mobile node during access authentication. This could be out of scope.
The FQDN could be configured on the MAG, obtained from AAA (or some
other entity) or constructed dynamically by the MAG.

> and how different MAGs can discover the same LMA address using DNS.

This is where the policy profile helps. Once obtained, the LMA
address would be stored in the MN's policy profile.

> publication of the PMIPv6 specification.

Why do you say that? We are re-using MIPv6 procedures here. I don't
see any need for modifying the procedures.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 14 Dec 2007 15:24:49 -0800

Frank Xia wrote:
> Hi Vijay and Sri
> 
> I think that  LMA Discovery,  

We are only discussing LMA discovery.

> DNS update, and such kind of

None of this "such kind of" stuff. :)

> http://tools.ietf.org/wg/netlmm/draft-xia-netlmm-radius-01.txt.

I briefly looked at the document. I agree with section 4 onwards..
This is the back end RADIUS extensions between the MAG and the AAA
and the LMA and the AAA. So it definitely needs to be standardized.
But in section 3, I don't see anything new. The text is very similar
to what we have the MIPv6 bootstrapping documents. Ideally we should
be referring to those documents, not write new documents on the same
concepts.

Vijay

---

From: Frank Xia <[email-masked]>
Date: Fri, 14 Dec 2007 18:02:04 -0600

Hi Vijay

Thank you for your comments about our draft.

Please see my inline comments.

BR
Frank

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "Sri Gundavelli" <[email-masked]>; <[email-masked]>
Sent: Friday, December 14, 2007 5:24 PM
Subject: Re: LMA Discovery (was Re: [netlmm] Review ofdraft-ietf-netlmm-proxymip6-07)

> be referring to those documents, not write new documents on the same
Frank=>I would like to  highlight some differences
1)DNS update.
  Due to point-to-point link, it is possible that LMA don't know the exact IPv6
  address , so MAG is responsible for initiatiting dynamic DNS update
2)Dynamic LMA discovery.
   The mechnism is trasparent to the MN while MN is involved in MIPv6 case.
3)SA establishment.
  It is different from MIPv6 because many MN shared secured tunnel between
  LMA and MAG.  It  affacts the operation in LMA and MAG.

---

From: <[email-masked]>
Date: Sat, 15 Dec 2007 01:02:46 +0100

Hi folks, 

> Sent: 14. joulukuuta 2007 23:19
> 
> Hi Vijay, 
> 
> I think this goes beyond the scope of the base specification. 
> Based on definition of the policy profile that Sri has 
> provided, it contains the LMA address as a mandatory field. 
> 
> how the MAG obtains the LMA address. You can define several 
> mechanisms for this, including the ones you have listed 
> below. However some of these have architectural impacts (e.g. 
> the integrated scenario) and were never discussed in the WG. 
> Other issues are present for the DNS discovery for example, 
> e.g. which FQDN is used by the MAG to query the DNS and how 
> different MAGs can discover the same LMA address using DNS.

I am a bit puzzled about this thread. We have well defined
procedures from MIP6 bootstrapping that should be reuasable
within PMIP6 scope as well. And without too much magic in
there. If something is needed for clarifying things, it could
be minimal text additions with references to existing work.

IMHO Vijay captured the main points already in his mails.

> I am afraid the introduction of these procedures would delay 
> the publication of the PMIPv6 specification.
> 
> As I mentioned in Vancouver, I think the mechanisms below 
> must be part of the new charter as they are critical for 
> PMIPv6 deployment. They should not part of the base spec, though.

New work to define what? To state that for larger deployments
one most probably needs AAA backend that also serves as a place
to interface with the policy profile?

There are some grey areas like the one mentioned related to DNS.
If the MAG always insists to carry out a DNS query to discover the
LMA (e.g. in a lack of AAA backend or no remote shared policy 
profile) then it is IMHO system specific issue and up to an
operator not to deploy such network that cannot handle this
situation. 

Jouni

> > I also think we should not assume that the LMA IP address stored in 
> > the policy profile is the only mechanism.
> > 
> integrated 
> > and split scenario bootstrapping mechanisms for PMIPv6.
> > 
> > authentication. As part of access authentication, the MAG 
> obtains the 
> > IP address of the LMA that it needs to use for the 
> particular mobile 
> > node. This would be the integrated scenario.
> > 
> > The MAG can also do a DNS lookup for the LMA [RFC 5026]. 
> How the MAG 
> > obtains the FQDN for the DNS lookup could be out of scope. The MAG 
> > could construct it from the realm part of the NAI provided by the 
> > mobile node during access authentication. This would be the split 
> > scenario.
> > 
> > If we agree with the above, I can quickly provide some text 
> that can 
> > be added to the PMIPv6 specification. We already have some 
> text, just 
> > needs to be cleaned up a bit. Please comment.
> > 
> > Vijay
> > 
> > 
> > Sri Gundavelli wrote:
> > 
> > >>>>>> - 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
> > >>>>>> parameters at 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
> > >> We need to state that the LMA discovery/assignment is 
> out of scope
> of

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 14 Dec 2007 16:10:49 -0800

>   address , so MAG is responsible for initiatiting dynamic DNS update

We are not talking about DNS update. Just LMA discovery in this thread.

>    The mechnism is trasparent to the MN while MN is involved in MIPv6 case.

So? Isn't this obvious? In MIPv6 case, the MN does the DNS lookup
In PMIPv6 case, the MAG does the DNS lookup. Come on...

>   LMA and MAG.  It  affacts the operation in LMA and MAG.

IPsec SA establishment between the MAG and the LMA is already covered
in the base PMIPv6 specification.

Vijay

---

From: "Frank Xia" <[email-masked]>
Date: Fri, 14 Dec 2007 21:21:24 -0600

Hi Vijay

Please see my reply.. 

BR
Frank

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "Sri Gundavelli" <[email-masked]>; <[email-masked]>
Sent: Friday, December 14, 2007 6:10 PM
Subject: Re: LMA Discovery (was Re: [netlmm] Review ofdraft-ietf-netlmm-proxymip6-07)

> In PMIPv6 case, the MAG does the DNS lookup. Come on...
Frank=>It is not obvious.
You can have a theoretical deduction.  The fact is that MN is
host, while MAG is router.  DNS lookup is a natural function for a host, but
it is hard to say that a router should support.
IMHO, I wonder if there are any commercial ARs  with DNS lookup function.

> in the base PMIPv6 specification.
Frank=>The basic protocol describes what the SA looks like and how to use
the SA.  There is not detail desciptions about how to build the SA. 
SA establishment is within bootstraping scope.

---

From: Julien Laganier <[email-masked]>
Date: Mon, 17 Dec 2007 14:04:07 +0100

On Friday 14 December 2007, Giaretta, Gerardo wrote:
> > > I don't think LMA discovery can be out of scope for this
> > > document. I also think we should not assume that the LMA IP
> > > address stored in the policy profile is the only mechanism.
> > >
> > > MAG obtains the FQDN for the DNS lookup could be out of scope.
> > > The MAG could construct it from the realm part of the NAI
> > > provided by the mobile node during access authentication. This
> > > would be the split scenario.
> > >
> I fully agree with Sri. How the policy profile is obtained by the MAG
> is out of scope of the base specification. This has always been the
> assumption.

FWIW, I agree as well.

As for an analogy, MIPv6 bootstrapping mechanisms are not defined in the 
MIPv6 specification. Why shall it be different for PMIPv6?

Apart from that, the question of how PMIPv6 bootstrapping is done, i.e. 
whether via reuse of existing MIPv6 bootstrapping mechanisms or via 
specification of new ones, is an entirely different problem that 
doesn't belong to PMIPv6 base specification.

We can discuss that once the WG agree to address the problem of PMIPv6 
bootstrapping as part rechartering.

--julien

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 17 Dec 2007 13:31:16 +0000

inline...

> MIPv6 specification. Why shall it be different for PMIPv6?

GT> This is not strictly true. MIPv6 defines basic bootstrapping via
DHAAD.This works well if the MN connects at a link and wants to look
for an HA locally. What is not defined is discovery of HAs when the MN
is in a foreign link and does not know the HNP.

Regards
George

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Dec 2007 11:58:14 -0800

> MIPv6 specification. Why shall it be different for PMIPv6?

Bad analogy. :) We did provide some minimal form of HA discovery
in RFC 3775. The HA IP address need not be configured on the MN.

Anyway, the situation is different. We have some MIPv6 bootstrapping
mechanisms that can be re-used with no modifications. I don't think
we need a separate document on LMA discovery. Does not make sense,
unless PMIPv6 requires a new mechanism for LMA discovery.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Dec 2007 10:03:33 +0100

Hi George,

On Monday 17 December 2007, George Tsirtsis wrote:
> > > I fully agree with Sri. How the policy profile is obtained by the
> > > MAG is out of scope of the base specification. This has always
> > > been the assumption.
> >
> > FWIW, I agree as well.
> >
> > As for an analogy, MIPv6 bootstrapping mechanisms are not defined
> > in the MIPv6 specification. Why shall it be different for PMIPv6?
>
> This is not strictly true. MIPv6 defines basic bootstrapping via
> for an HA locally. What is not defined is discovery of HAs when the
> MN is in a foreign link and does not know the HNP.

You are right, I wasn't accurate. Should have say "*Some* MIPv6 
bootstrapping mechanisms are defined outside of the MIPv6 protocol 
specification."

--julien