Subject: Re: [netext] Milestone update for NetExt WG

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Jul 2012 16:15:46 +0200

Raj,

I have a comment about the proposed milestones:

Le 25/04/2012 22:36, [email-masked] a écrit :
[...]
> Jul 2012 	Submit Prefix Delegation for Proxy Mobile IPv6 to IESG for
> publication as a proposed standard

I wonder whether it is not too early for this submission to IESG.

I am saying so because we have an individual proposal which is
implemented and uses DHCPv6-Prefix Delegation, together with PBU/PBAck,
which realizes network mobility:
http://www.ietf.org/id/draft-petrescu-netext-pmip-nemo-01.txt

The -00 of this was submitted early March 2012, and some comments were
issued on the email list at that time.

We now have an implementation of it.

However, the draft that is proposed to be submitted to the IESG (I
suppose draft-ietf-netext-pd-pmip-02) seems to me to have the same goal
which is to support network mobility in a PMIPv6 domain.

There are important differences between the two drafts.  Not the least
important is that this WG item does not use DHCPv6-PD whereas our
individual proposal does, or that maybe we do not know the
implementation status of it, or the IPR status, etc.

For these reasons, I believe it may be too early to submit to IESG.  I
think further discussion should be performed before submitting to IESG.

What do you think?

Yours,

Alex

> Nov 2012	Submit IPv4 Traffic Offload Selector Option for Proxy Mobile
> IPv6 to IESG for publication as a proposed standard Feb 2013	Submit
> Proxy Mobile IPv6 Extensions to Support Flow Mobility to IESG for
> publication as a proposed standard Mar 2013	Submit Service Selection
> for MIP6 and PMIP6 to the IESG for publication as a proposed
> standard Apr 2013	Submit Logical Interface Support for multi-mode IP
> Hosts for publication as an Informational document May 2013	Submit
> EAP Attributes for WiFi - EPC Integration to IESG for publication as
> a proposed standard
>
>
>
> _______________________________________________ netext mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/netext
>

---

From: <[email-masked]>
Date: Wed, 11 Jul 2012 14:48:33 +0000

Hi Alex,

>I wonder whether it is not too early for this submission to IESG.

The PD I-D that has been discussed is complete and ready to be sent to the
IESG.
I see no reason to delay it further.

>which is to support network mobility in a PMIPv6 domain.

The PD I-D is a simple solution for delegating prefixes downstream and is
not a solution for NEMO in a PMIP6 domain.

>implementation status of it, or the IPR status, etc.

I hope the authors can clarify.

>think further discussion should be performed before submitting to IESG.

The WG can discuss it on the ML. With my chair hat on, I do believe that
the WG PD I-D is ready to be forwarded to the IESG as it is solving a very
specific problem. 

-Raj

>[email-masked]
>https://www.ietf.org/mailman/listinfo/netext

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Jul 2012 17:02:24 +0200

Le 11/07/2012 16:48, [email-masked] a écrit :
>> Le 25/04/2012 22:36, [email-masked] a écrit : [...]
>>> Jul 2012 	Submit Prefix Delegation for Proxy Mobile IPv6 to IESG
>>> for publication as a proposed standard
>>
> The PD I-D that has been discussed is complete and ready to be sent
> to the IESG. I see no reason to delay it further.
>
>>
>> implemented and uses DHCPv6-Prefix Delegation, together with
>> PBU/PBAck, which realizes network mobility:
>> The -00 of this was submitted early March 2012, and some comments
>> were issued on the email list at that time.
>>
>>  suppose draft-ietf-netext-pd-pmip-02) seems to me to have the
>> same goal which is to support network mobility in a PMIPv6 domain.
>
> The PD I-D is a simple solution for delegating prefixes downstream
> and is not a solution for NEMO in a PMIP6 domain.

Raj - I agree with the first part, the WG item draft delegates prefixes
by using PMIP extension - yes.

But I disagree with the second part.  You say it is not a solution for
NEMO in a PMIP6 domain.  But it says 'Mobile Router' several times.

If it is not a solution for NEMO in a PMIP6 domain, then it is a
solution to what?

>> There are important differences between the two drafts.  Not the
>> least important is that this WG item does not use DHCPv6-PD
>> whereas our individual proposal does, or that maybe we do not know
>> the implementation status of it, or the IPR status, etc.
>
>> For these reasons, I believe it may be too early to submit to
>> IESG. I think further discussion should be performed before
>> submitting to IESG.
>>
>> What do you think?
>
> The WG can discuss it on the ML. With my chair hat on, I do believe
> that the WG PD I-D is ready to be forwarded to the IESG as it is
> solving a very specific problem.

I am trying to understand what problem?

WG item draft's first phrase is:
> This specification extends PMIPv6 to assign a mobile network prefix
> to a mobile router for supporting network mobility.

Isn't this NEMO?

Yours,

Alex

>
> -Raj
>
>>
>> Yours,
>>
>> Alex
>>
>>
>>> Nov 2012	Submit IPv4 Traffic Offload Selector Option for Proxy
>>> Mobile IPv6 to IESG for publication as a proposed standard Feb
>>> 2013	Submit Proxy Mobile IPv6 Extensions to Support Flow
>>> Mobility to IESG for publication as a proposed standard Mar 2013
>>> Submit Service Selection for MIP6 and PMIP6 to the IESG for
>>> publication as a proposed standard Apr 2013	Submit Logical
>>> Interface Support for multi-mode IP Hosts for publication as an
>>> Informational document May 2013	Submit EAP Attributes for WiFi -
>>> EPC Integration to IESG for publication as a proposed standard
>>>
>>>
>>>
>>> _______________________________________________ netext mailing
>>> list [email-masked]

---

From: BOC Michael <[email-masked]>
Date: Wed, 11 Jul 2012 20:54:44 +0000

Hello,

I am co-author of this draft PMIP-NEMO-01 with Alex.
We have implemented PMIPv6 from scratch, our extension as well as other extensions proposed by netext contributors. 

During the implementation of the PMIP-NEMO extension, we faced a lot of technical problems but also design ones that were not solved by PD I-D -00 and still not with -02. We want to share with you about these problems and the solutions that we selected in our draft.  

Hence, beside the very specific support of prefix delegation in PMIPv6 the PD I-D proposes, we do consider that important related design choices and functionalities must be discussed before going forward. 

The design choices and some of the important functionalities are discussed in our draft PMIP-NEMO-02 (and yes the solutions described in our draft are different than PD I-D). For early discussions we can cite: 
- Delegating router location
- Multiple IA_PD request management
- MNP lifetime management in MAG/LMA
- Interferences with (non) Temporary Addresses
- Matching between DHCPv6's DUID and PMIPv6's MNID
- Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA
- ...

We are open to discuss about them with the PD I-D authors at IETF84 and on the ML with all interested participants.

PS: I don't want to come back on the discussion about NEMO support or not. I agree that the MR does not participate actively in any IP mobility signaling on the interface towards the mobile operator network.  

Best Regards,

Michael

________________________________________
De : [email-masked] [[email-masked]] de la part de Alexandru Petrescu [[email-masked]]
Date d'envoi : mercredi 11 juillet 2012 17:02
À : [email-masked]
Cc : [email-masked]
Objet : Re: [netext] Milestone update for NetExt WG

Isn't this NEMO?

Yours,

Alex

>> [email-masked] https://www.ietf.org/mailman/listinfo/netext

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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 12 Jul 2012 00:18:59 +0000

Alex:

As discussed in the past, some of the assumptions you are making are incorrect., IMHO I tried hard to understand the approach that you have in mind. Some comments below.

- In PMIPv6, the home network prefix (HNP) that the LMA assigns is a hosted on-link prefix on the MN-AR link. This is not a delegated prefix as in case of MR.
- The MAG is hosting the prefix on the link, MR can only "generate" addresses from that prefix. Its 64-bit length prefix allowing SLAAC support on the link
- MR performs all ND operations on the link for avoiding address conflict, generating address configuration and for defending the generated addresses

Given the above properties of the Home Network Prefix, I'm struggling to understand why you believe the MR can take the prefix that it receives in a RA message, splits up the address space and assigns it to the network behind it. What is your assumption here ?
MR can generate an address, two addresses or a dozen addresses and use them on the link after performing the ND operations. Now, splitting the 64-bits of MAG hosted prefix, does it mean the MR generates 2 pow 64 addresses and assigns them to LFNS on the ingress sides ? 

   For a HNP with prefix length 64, two or more MNPs are generated, each
   having a prefix length longer than 64.  For brevity and without
   losing generality, we present a detailed division example for a
   fictitious addressing system whose "IP" addresses are of a maximum
   length of 5 bits (instead of 128 bits of IPv6).

Alex: What is this fuzzy logic ? For hosted prefix on a link, we need 64-bits. Can the MR send an RA on its ingress link with /96 prefix length ? How will the LFN generate an EUI-64 identifier and generate a 128-bit address from a 96-bit prefix ?
Can you explain how SLAAC works on the ingress link ?

   This may be achieved either
   with DHCPv6 (MR or a DHCPv6 Server send these addresses) or with
   stateless address auto-configuration (MR or a Router send Router
   Advertisements containing MNP1 and/or MNP2).

>From a 64-bit prefix received in the RA on the egress link, a MR can generate a list of prefixes and send RA's for those prefixes on the ingress link ? Why do we need PD then ?

>   On the contrary, in the case of shared links, it is necessary to perform an operation of Neighbor Discovery proxying on the Mobile Router.  When MAG receives a packet from CN addressed to LFN, it would solicit the MAC address of LFN on the MAG-MR link (even though LFN is not present on that link).  For this reason, the MR must pretend it owns the IP address of LFN and respond to that solicitation with its own MAC address.
Lets assume we have enabled SEND on the link ?  What happens to that scenario ? Can the MR be able to defend the IPv6 address owned by an LFN ? Can the MR assert the ownership and use its Link-layer id for that address ?
Can you explain how SEND works in your proposal ?

>   For this reason, the MR must pretend it owns the IP address of LFN and respond to that solicitation with its own MAC address.

Sure. To summarize your draft  (from what I understood), a node on an IPv6 link can take a set of addresses from the prefix that it receives on the egress link and use them on its ingress link. It can cleverly proxy for those addresses and make the uplink router believe that it owns those addresses. So, remove mobility from this equation. Can a fixed node do this  ?

Can the MR take just one address and perform NAT66 operation and still support a network behind it ? 

The PD draft that the WG is working on about properly delegating prefixes to the MR, so the MR can use them on its ingress link. These are assigned in a legal manner, with out requiring any hacking requirements on the MR. The work is am extension to what MEXT WG did for PD support; its an approach for network-based mobility.

Regards
Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 12 Jul 2012 00:41:08 +0000

Hi Michael,

Thanks for sharing the details about your project. Nice to know, you have an implementation.

Its the LMA. That is the session anchor and for supporting mobility, that needs to be in path and is the only option

This is per RFC 3693, standard RR operation, no change

Its tied to the PMIP session lifetime. This is identical to session lifetime when using DHCPv4 per 5844

Please clarify what is the issue

Those are two different identifiers uses in different protocol planes.
MN Id is the mobile node's identifier. This is tied to the access authentication.
DHCP DUID is the identifier used by the RR.

- …

MAG uses the DHCPv6 solicit as a trigger for MNP state creation on the LMA, so it will have proper correlation and route when subsequent allocation over DHCP PD is complete

Please explain which part of the call flow, you have implementation challenge

   +-------------+    +--------------+          +-------------------+
   |Mobile Router|    |      MAG     |          |      LMA          |
   |(Req. Router)|    |(DHCPv6 Relay)|          |(Delegating Router)|
   +-------------+    +--------------+          +-------------------+
          |                  |                          |
          |                  |o========================o|
   1)     |                  |      PMIPv6 tunnel       |
          |                  |o========================o|
   2)     |-- Solicit ------>|                          |
          |                  |                          |
   3)     |                  |----------PBU------------>|
          |                  |                          |
   4)     |                  |<---------PBA-------------|
          |                  |                          |
   5)     |                  |--- Solicit ------------->|
          -                  -                -         - <-+
   6)     |                  |<-- Advertise ------------|   |
          |                  |                          |   |
   7)     |<- Advertise -----|                          |  Opt
          |                  |                          |  ion
   8)     |-- Request ------>|                          |  al.
          |                  |                          |   |
   9)     |                  |--- Request ------------->|   |
          -                  -                -         - <-+
   10)    |                  |<-- Reply-----------------|
          |                  |                          |
   11)    |<-- Reply --------|                          |
          |                  |                          |

    Figure 1: Prefix Delegation in PMIPv6 during the initial attachment
                           to the PMIPv6 Domain

Regards
Sri

On Jul 11, 2012, at 1:54 PM, BOC Michael wrote:

Hello,

Best Regards,

Michael

________________________________________
De : [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] de la part de Alexandru Petrescu [[email-masked]<mailto:[email-masked]>]
Date d'envoi : mercredi 11 juillet 2012 17:02
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [netext] Milestone update for NetExt WG

Le 11/07/2012 16:48, [email-masked]<mailto:[email-masked]> a écrit :

Hi Alex,

On 7/11/12 9:15 AM, "ext Alexandru Petrescu"
<[email-masked]<mailto:[email-masked]>> wrote:

Raj,

Le 25/04/2012 22:36, [email-masked]<mailto:[email-masked]> a écrit : [...]
Jul 2012    Submit Prefix Delegation for Proxy Mobile IPv6 to IESG
for publication as a proposed standard

What do you think?

Isn't this NEMO?

Yours,

Alex

-Raj

Yours,

Alex

_______________________________________________ netext mailing
list [email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netext

_______________________________________________ netext mailing list
[email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/netext

_______________________________________________
netext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netext
_______________________________________________
netext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netext

---

From: BOC Michael <[email-masked]>
Date: Thu, 12 Jul 2012 09:56:55 +0000

Hi Sri,

The cited points were more « topics » than just technical misunderstanding.

Please have a look of my responses in line. I hope they will highlight the need for a slight delay in the Netext WG milestone plan.
Maybe we can change the subject of this mail.

Michael

De : Sri Gundavelli (sgundave) [mailto:[email-masked]]
Envoyé : jeudi 12 juillet 2012 02:41
À : BOC Michael
Cc : Alexandru Petrescu; [email-masked]; [email-masked]
Objet : Re: [netext] Milestone update for NetExt WG

Hi Michael,

As in RFC5844, the DHCP server or relay may be located on the MAG then the location of the Delegating router cannot be simply set on the LMA as "the only option".
We have deployment issues where the DHCPv6 server (and the delegating router also) will be located on another server than the MAG and LMA (and this is an option for us).
If the LMA is the session anchor, the delegating router can accommodate with specific configuration.

A bit off-topic, I can design a solution much more efficient by having delegating routers on MAGs.

You mean RFC3633 ? How does the MAG knows that the MR request specific MNPs (Section 7, about hints). How does those multiples prefixes are included in PBU/PBA?

RFC5844 says in Section 3.4.3 :

The DHCP lease length allocated to the mobile node's IPv4 home
      address may be different from the binding lifetime at the local
      mobility anchor for that mobile node's session.  It is not
      possible to keep these lifetimes synchronized, and so its not
      required that the configured lifetimes should be kept same in both
      DHCP and Proxy Mobile IPv6.

So there are no required synchronization between PMIP session lifetime and DHCPv6 lease length. In our implementation this cause high overhead in terms of treatments to evaluate if only one MNP is still valid or not.
When we consider tens of MNP per UE and thousands of UEs this is not possible.

You let the MR sends DHCPv6 SOLICIT. So you let any mobile node to send DHCPv6 SOLICIT. So you will have to treat IANA, IATA, IAPD, and so on.. How this is done is not presented in the PD I-D draft.
And I don't even talk about the signaling overhead caused by this.

PMIPv6 session lifetime is not synchronized with DHCPv6 lease length. Then if one control plane takes a decision, like PMIPv6's mobile node rejection, the delegating router database will remain desynchronized.
This can be solved through obscure mechanisms but I think it is important to clarify this point (and yes we assume that the delegating router may not be collocated with the LMA).

If the lease length is much more lower than the session lifetime you multiply the number of PBU/PBA and DHCPv6 SOLICIT/REQUEST/REPLY/... messages

- ...

          |                  |                          |

   1)     |                  |      PMIPv6 tunnel       |

          |                  |                          |

          |                  |                          |

          |                  |                          |

          -                  -                -         - <-+

          |                  |                          |   |

          |                  |                          |  ion

          |                  |                          |   |

          -                  -                -         - <-+

          |                  |                          |

          |                  |                          |

                           to the PMIPv6 Domain

In the draft PMIP-NEMO-02 we expose the solutions we found as we addressed the design, technical, and implementation challenges.
They may not solve all cited problems but we are committed to improve the quality of the prefix delegation support draft that will be submitted to the IESG.

Regards
Sri

Hello,

Best Regards,

Michael

Hi Alex,

Raj,

What do you think?

Isn't this NEMO?

Yours,

Alex

-Raj

Yours,

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 12 Jul 2012 10:29:37 +0000

Hi Michael.

Sure. We can discuss offline and work on any clarifications needed.

I've one comment with regards to your draft. As Raj said, what the WG draft is supporting is delegated prefix model and in alignment with the other approaches that were used in DSMIP based protocols after lots of debates and careful evaluation.  The approaches such as NAT-based, or MR doing some form of bridging with changing MAC addresses ..etc are approaches that are not about PD, but about some techniques. You are welcome to publish specs and get support from the WG to standardize, or publish them as informational specs (if the WG likes them). Please note that the charter is not disallowing such approaches, so the PD IESG timeline does not imply the gates are closed.

In any case, you want WG reviews on all the assumptions that your draft is making. The approach of an host learning a Prefix in RA and hosting a part of the prefix on its ingress side is some magic, IMO. This technique, if legal, valid and works for SLAAC, SEND, can be a generic technique useful for wireless and wireless. Nothing specific to mobility.

Regards
Sri

On Jul 12, 2012, at 2:56 AM, BOC Michael wrote:

Hi Sri,

Michael

De : Sri Gundavelli (sgundave) [mailto:[email-masked]]
Envoyé : jeudi 12 juillet 2012 02:41
À : BOC Michael
Cc : Alexandru Petrescu; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [netext] Milestone update for NetExt WG

Hi Michael,

As in RFC5844, the DHCP server or relay may be located on the MAG then the location of the Delegating router cannot be simply set on the LMA as “the only option”.
We have deployment issues where the DHCPv6 server (and the delegating router also) will be located on another server than the MAG and LMA (and this is an option for us).
If the LMA is the session anchor, the delegating router can accommodate with specific configuration.

You let the MR sends DHCPv6 SOLICIT. So you let any mobile node to send DHCPv6 SOLICIT. So you will have to treat IANA, IATA, IAPD, and so on.. How this is done is not presented in the PD I-D draft.
And I don’t even talk about the signaling overhead caused by this.

PMIPv6 session lifetime is not synchronized with DHCPv6 lease length. Then if one control plane takes a decision, like PMIPv6’s mobile node rejection, the delegating router database will remain desynchronized.
This can be solved through obscure mechanisms but I think it is important to clarify this point (and yes we assume that the delegating router may not be collocated with the LMA).

If the lease length is much more lower than the session lifetime you multiply the number of PBU/PBA and DHCPv6 SOLICIT/REQUEST/REPLY/… messages

- …

          |                  |                          |

   1)     |                  |      PMIPv6 tunnel       |

          |                  |                          |

          |                  |                          |

          |                  |                          |

          -                  -                -         - <-+

          |                  |                          |   |

          |                  |                          |  ion

          |                  |                          |   |

          -                  -                -         - <-+

          |                  |                          |

          |                  |                          |

                           to the PMIPv6 Domain

Regards
Sri

Hello,

Best Regards,

Michael

Hi Alex,

Raj,

What do you think?

Isn't this NEMO?

Yours,

Alex

-Raj

Yours,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Jul 2012 13:22:16 +0200

> Sure. We can discuss offline and work on any clarifications needed.

Offline?

> I've one comment with regards to your draft. As Raj said, what the WG
> draft is supporting is delegated prefix model

I tend to agree with a model where the prefix is delegated.

> and in alignment with the other approaches that were used in DSMIP
> based protocols after lots of debates and careful evaluation.

What does this mean in particular?  I don't understand what do you refer
to by this alignment?  There doesn't seem to be v4/v6 in this PMIP-NEMO
discussion, so why mentioning DSMIP?

> The approaches such as NAT-based, or MR doing some form of bridging
> with changing MAC addresses ..etc are approaches that are not about
> PD, but about some techniques.

Well, we do not consider neither NAT, nor changing MAC addresses aka ND
proxy, other than maybe tangential - these are not core to our PMIP-NEMO
proposals

The manner we propose by which a HNP can be subdivided into several MNPs
is none of these.

> You are welcome to publish specs and get support from the WG to
> standardize, or publish them as informational specs (if the WG likes
> them). Please note that the charter is not disallowing such
> approaches, so the PD IESG timeline does not imply the gates are
> closed.

No no Sri, please read our comments.  Please clarify.

For example, both you and Raj seem to insist that 
draft-ietf-netext-pd-pmip-02 is not about network mobility.  But the 
draft says
"This document specifies an extension to Proxy Mobile IPv6 protocol for 
supporting network mobility using DHCPv6-based Prefix Delegation."

So again - is this draft about network mobility or not?

Alex
>
> In any case, you want WG reviews on all the assumptions that your
> draft is making. The approach of an host learning a Prefix in RA and
>  hosting a part of the prefix on its ingress side is some magic, IMO.
>  This technique, if legal, valid and works for SLAAC, SEND, can be a
>  generic technique useful for wireless and wireless. Nothing specific
>  to mobility.
>
> Regards Sri
>
>
>
>
>
>
>> Hi Sri, The cited points were more « topics » than just technical
>> misunderstanding. Please have a look of my responses in line. I
>> hope they will highlight the need for a slight delay in the Netext
>>  WG milestone plan. Maybe we can change the subject of this mail.
>> Michael *De :*Sri Gundavelli (sgundave)
>> [mailto:[email-masked]] *Envoyé :*jeudi 12 juillet 2012 02:41
>> *À :*BOC Michael *Cc :*Alexandru Petrescu;[email-masked]
>>  <mailto:[email-masked]>;[email-masked]
>> <mailto:[email-masked]> *Objet :*Re: [netext] Milestone update for
>> NetExt WG Hi Michael, Thanks for sharing the details about your
>> project. Nice to know, you have an implementation.
>>
>> Its the LMA. That is the session anchor and for supporting
>> mobility, that needs to be in path and is the only option As in
>> RFC5844, the DHCP server or relay may be located on the MAG then
>> the location of the Delegating router cannot be simply set on the
>> LMA as “the only option”. We have deployment issues where the
>> DHCPv6 server (and the delegating router also) will be located on
>> another server than the MAG and LMA (and this is an option for
>> us). If the LMA is the session anchor, the delegating router can
>> accommodate with specific configuration. A bit off-topic, I can
>> design a solution much more efficient by having delegating routers
>>  on MAGs.
>>
>>
>> - Multiple IA_PD request management This is per RFC 3693, standard
>>  RR operation, no change You mean RFC3633 ? How does the MAG knows
>>  that the MR request specific MNPs (Section 7, about hints). How
>> does those multiples prefixes are included in PBU/PBA?
>>
>>
>> - MNP lifetime management in MAG/LMA Its tied to the PMIP session
>> lifetime. This is identical to session lifetime when using DHCPv4
>> per 5844 RFC5844 says in Section 3.4.3 : The DHCP lease length
>> allocated to the mobile node's IPv4 home address may be different
>> from the binding lifetime at the local mobility anchor for that
>> mobile node's session.  It is not possible to keep these lifetimes
>>  synchronized, and so its not required that the configured
>> lifetimes should be kept same in both DHCP and Proxy Mobile IPv6.
>> So there are no required synchronization between PMIP session
>> lifetime and DHCPv6 lease length. In our implementation this cause
>> high overhead in terms of treatments to evaluate if only one MNP
>> is still valid or not. When we consider tens of MNP per UE and
>> thousands of UEs this is not possible.
>>
>>
>> - Interferences with (non) Temporary Addresses Please clarify what
>>  is the issue You let the MR sends DHCPv6 SOLICIT. So you let any
>> mobile node to send DHCPv6 SOLICIT. So you will have to treat IANA,
>> IATA, IAPD, and so on.. How this is done is not presented in the PD
>> I-D draft. And I don’t even talk about the signaling overhead
>> caused by this.
>>
>>
>> - Matching between DHCPv6's DUID and PMIPv6's MNID Those are two
>> different identifiers uses in different protocol planes. MN Id is
>> the mobile node's identifier. This is tied to the access
>> authentication. DHCP DUID is the identifier used by the RR. PMIPv6
>>  session lifetime is not synchronized with DHCPv6 lease length.
>> Then if one control plane takes a decision, like PMIPv6’s mobile
>> node rejection, the delegating router database will remain
>> desynchronized. This can be solved through obscure mechanisms but I
>> think it is important to clarify this point (and yes we assume that
>> the delegating router may not be collocated with the LMA). -
>> Increasing load of DHCPv6 solicit/reply and by extension PBU/PBA
>>
>> If the lease length is much more lower than the session lifetime
>> you multiply the number of PBU/PBA and DHCPv6
>> SOLICIT/REQUEST/REPLY/… messages - … MAG uses the DHCPv6 solicit as
>> a trigger for MNP state creation on the LMA, so it will have proper
>> correlation and route when subsequent allocation over DHCP PD is
>> complete Please explain which part of the call flow, you have
>> implementation challenge +-------------+    +--------------+
>> +-------------------+ |Mobile Router|    |      MAG     | | LMA
>> | |(Req. Router)|    |(DHCPv6 Relay)| |(Delegating Router)|
>> +-------------+    +--------------+ +-------------------+ |
>> | | | |o========================o| 1)     | |      PMIPv6 tunnel
>> | | |o========================o| 2)     |-- Solicit ------>| | | |
>> | 3)     | |----------PBU------------>| |                  | | 4)
>> | |<---------PBA-------------| | |                          | 5) |
>> |--- Solicit ------------->| - -                -         - <-+ 6)
>> |                  |<-- Advertise ------------|   | | |
>> |   | 7) |<- Advertise -----| |  Opt |                  | |  ion 8)
>> |-- Request ------>|                          |  al. | | |   | 9)
>> |                  |--- Request ------------->|   | - -
>> - - <-+ 10)    |                  |<-- Reply-----------------| | |
>> | 11)    |<-- Reply --------| | |                  |
>> |
>>
>> Figure 1: Prefix Delegation in PMIPv6 during the initial
>> attachment to the PMIPv6 Domain In the draft PMIP-NEMO-02 we expose
>> the solutions we found as we addressed the design, technical, and
>> implementation challenges. They may not solve all cited problems
>> but we are committed to improve the quality of the prefix
>> delegation support draft that will be submitted to the IESG.
>> Regards Sri On Jul 11, 2012, at 1:54 PM, BOC Michael wrote:
>>
>>
>> Hello,
>>
>> I am co-author of this draft PMIP-NEMO-01 with Alex. We have
>> implemented PMIPv6 from scratch, our extension as well as other
>> extensions proposed by netext contributors.
>>
>> During the implementation of the PMIP-NEMO extension, we faced a
>> lot of technical problems but also design ones that were not solved
>> by PD I-D -00 and still not with -02. We want to share with you
>> about these problems and the solutions that we selected in our
>> draft.
>>
>> Hence, beside the very specific support of prefix delegation in
>> PMIPv6 the PD I-D proposes, we do consider that important related
>> design choices and functionalities must be discussed before going
>> forward.
>>
>> The design choices and some of the important functionalities are
>> discussed in our draft PMIP-NEMO-02 (and yes the solutions
>> described in our draft are different than PD I-D). For early
>> discussions we can cite: - Delegating router location - Multiple
>> IA_PD request management - MNP lifetime management in MAG/LMA -
>> Interferences with (non) Temporary Addresses - Matching between
>> DHCPv6's DUID and PMIPv6's MNID - Increasing load of DHCPv6
>> solicit/reply and by extension PBU/PBA - ...
>>
>> We are open to discuss about them with the PD I-D authors at IETF84
>> and on the ML with all interested participants.
>>
>>
>> PS: I don't want to come back on the discussion about NEMO support
>>  or not. I agree that the MR does not participate actively in any
>> IP mobility signaling on the interface towards the mobile operator
>>  network.
>>
>>
>> Best Regards,
>>
>>
>> Michael
>>
>>
>> ________________________________________ De
>> :[email-masked]
>> <mailto:[email-masked]>[[email-masked]
>> <mailto:[email-masked]>] de la part de Alexandru Petrescu
>>  [[email-masked]
>> <mailto:[email-masked]>] Date d'envoi : mercredi 11
>> juillet 2012 17:02 À :[email-masked]
>> <mailto:[email-masked]> Cc :[email-masked]
>> <mailto:[email-masked]> Objet : Re: [netext] Milestone update for
>>  NetExt WG
>>
>> Le 11/07/2012 16:48,[email-masked]
>> <mailto:[email-masked]>a écrit :
>>
>> Hi Alex,
>>
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Raj,
>>
>> Le 25/04/2012 22:36,[email-masked]
>> <mailto:[email-masked]>a écrit : [...]
>>
>> Raj - I agree with the first part, the WG item draft delegates
>> prefixes by using PMIP extension - yes.
>>
>> But I disagree with the second part.  You say it is not a solution
>>  for NEMO in a PMIP6 domain.  But it says 'Mobile Router' several
>> times.
>>
>> [email-masked] <mailto:[email-masked]>
>>
>> list
>> <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/netext
>>
>>
>>
>>
>>
>>
>>
>>
>> netext mailing list [email-masked] <mailto:[email-masked]>
>> list [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Jul 2012 13:48:23 +0200

> hosting a part of the prefix on its ingress side is some magic, IMO.

Sri, sorry for intervening on this aspect.  I wanted to mention:

This HNP Division approach is nothing magic, there are a number of other
proposals doing similar prefix division in order to deliver further in a
network.

The other comment is that our method of achieving network mobility with
PMIP and DHCP Prefix Delegation works without the above HNP prefix
division.  The two methods are alternative - do HNP Division and no need
of Prefix Delegation, do Prefix Delegation and no need of HNP Division.

> generic technique useful for wireless and wireless. Nothing specific

Well we do it for network mobility and not for generic technique.  I am
afraid that if you submit now a draft doing network mobility in PMIP any
other subsequent network mobility PMIP submission will have to face the
question of why we do it again.

Or, the question now is why is PMIP-Prefix Delegation claiming to do
network mobility and not do network mobility at the same time?  My
supposition is that authors claim to the WG that authors do not do
network mobility and authors claim to elsewhere that authors _do_
network mobility.

This is obvious to me that it is illogic.

Yours,

Alex
>> Michael *De :*Sri Gundavelli (sgundave) [mailto:[email-masked]]
>> *Envoyé :*jeudi 12 juillet 2012 02:41 *À :*BOC Michael *Cc
>> :*Alexandru Petrescu;[email-masked]
>> <mailto:[email-masked]> *Objet :*Re: [netext] Milestone update
>> for NetExt WG Hi Michael, Thanks for sharing the details about
>> your project. Nice to know, you have an implementation.
>>
>> another server than the MAG and LMA (and this is an option for us).
>> If the LMA is the session anchor, the delegating router can
>> high overhead in terms of treatments to evaluate if only one MNP is
>> still valid or not. When we consider tens of MNP per UE and
>> mobile node to send DHCPv6 SOLICIT. So you will have to treat
>> IANA, IATA, IAPD, and so on.. How this is done is not presented in
>> the PD I-D draft. And I don’t even talk about the signaling
>> overhead caused by this.
>>
>>
>> desynchronized. This can be solved through obscure mechanisms but
>> I think it is important to clarify this point (and yes we assume
>> that the delegating router may not be collocated with the LMA). -
>> SOLICIT/REQUEST/REPLY/… messages - … MAG uses the DHCPv6 solicit
>> as a trigger for MNP state creation on the LMA, so it will have
>> proper correlation and route when subsequent allocation over DHCP
>> PD is complete Please explain which part of the call flow, you
>> have implementation challenge +-------------+    +--------------+
>> +-------------------+ |Mobile Router|    |      MAG     | |
>> LMA          | |(Req. Router)|    |(DHCPv6 Relay)| |(Delegating
>> Router)| +-------------+    +--------------+ +-------------------+
>> |                  | | |
>> |o========================o| 1)     | |      PMIPv6 tunnel       |
>> | |o========================o| 2)     |-- Solicit ------>| | |
>> |                          | 3)     | |----------PBU------------>|
>> |                  | | 4)     |
>> |<---------PBA-------------| | |                          | 5)
>> |                  |--- Solicit ------------->| -
>> -                -         - <-+ 6)     |                  |<--
>> Advertise ------------|   | | |                          |   | 7)
>> |<- Advertise -----| |  Opt |                  |
>> |  ion 8) |-- Request ------>|                          |  al. | |
>> |   | 9)     |                  |--- Request ------------->|   | -
>> -                - - <-+ 10)    |                  |<--
>> Reply-----------------| | |                          | 11)    |<--
>> Reply --------| | |                  |                          |
>>
>> to the PMIPv6 Domain In the draft PMIP-NEMO-02 we expose the
>> solutions we found as we addressed the design, technical, and
>> lot of technical problems but also design ones that were not
>> solved by PD I-D -00 and still not with -02. We want to share with
>> you about these problems and the solutions that we selected in our
>> draft.
>>
>> We are open to discuss about them with the PD I-D authors at
>> IETF84 and on the ML with all interested participants.
>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 12 Jul 2012 13:27:00 +0000

Alex:

> of Prefix Delegation, do Prefix Delegation and no need of HNP Division.

No. Prefix Delegation per RFC 3633, allows a node to request a prefix and host that prefix on its ingress links. The model support RR and DR functions; it is based on a standard model of prefix delegation. The change is to support mobile environment.

The approach of learning a prefix "hosted on a link", and claiming ownership of some art of the prefix as supposed to claiming ownership on an address is a new concept. FWIW, the router never delegated that prefix and it never allowed it to be any other link, other than that link. So, there is a world of difference. Analogy is ilke this. You rented a taxi, on the way you started offering taxi service :). Also, please explain:

a. how SLAAC works
b. how SEND is enabled 
c. how a host on a link operating in SLAAC mode, can learn a prefix in the RA, claim ownership on part of the prefix and in turn host that prefix on the ingress link
d. if SLAAC is disabled and DHCPv6 stageful mode is supported on the MAG-MN link, what happens to your proposal

> question of why we do it again.

The WG document went through a long review process and was adopted after an adoption call. You have a new idea now, but in all "fairness", we cannot hijack an IETF WG document, with the fear that some future work of ours will have some questions. That is not right. If your approach has merit, has support from the WG, you can always publish an alternative approach. Or, even deprecate a standard. You can request the chairs to Ask for reviews and WG adoption. If there is consensus, it will get approved. Again, Xingue's WG draft is not stopping you from achieving this.

> network mobility and authors claim to elsewhere that authors _do_

I do not know where to go if we start arguing about the definitions of MR, MH, IP Node …
We do adding prefix delegation to PMIP sessions. The ability to support PD support per DHCPv6 is what we are supporting.

> The manner we propose by which a HNP can be subdivided into several MNPs

You do.  Draft text:

"For this reason, the MR must pretend it owns the IP address of LFN and respond to that solicitation with its own MAC address."

> The manner we propose by which a HNP can be subdivided into several MNPs

I know this discussion won't end and you will thoroughly enjoy this discussions :). But, to make progress, 
Please explain how your draft works and get WG support. Note that Xingyue's draft is not your blocker.
My final comment, please ask the chairs to request WG adoption on your draft.

Regards
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Jul 2012 16:34:31 +0200

Sri,

Le 12/07/2012 15:27, Sri Gundavelli (sgundave) a écrit :
>> Le 12/07/2012 12:29, Sri Gundavelli (sgundave) a écrit : [...]
>>> draft is making. The approach of an host learning a Prefix in RA
>>> and hosting a part of the prefix on its ingress side is some
>>> magic, IMO.
>>
>> This HNP Division approach is nothing magic, there are a number of
>> other proposals doing similar prefix division in order to deliver
>> further in a network.
>>
>> The other comment is that our method of achieving network mobility
>> with PMIP and DHCP Prefix Delegation works without the above HNP
>> prefix division.  The two methods are alternative - do HNP
>> Division and no need of Prefix Delegation, do Prefix Delegation and
>> no need of HNP Division.
>>
>
> No. Prefix Delegation per RFC 3633, allows a node to request a
> prefix and host that prefix on its ingress links. The model support
> RR and DR functions; it is based on a standard model of prefix
> delegation. The change is to support mobile environment.

I suppose you want to mean that a mobile environment is exclusively
PMIP?  This would be to claim more than necessary, no?  MIP is also
mobile, DHCP is also mobile.

> The approach of learning a prefix "hosted on a link", and claiming
> ownership of some art of the prefix as supposed to claiming
> ownership on an address is a new concept. FWIW, the router never
> delegated that prefix and it never allowed it to be any other link,
> other than that link. So, there is a world of difference. Analogy is
> ilke this. You rented a taxi, on the way you started offering taxi
> service :).

I tend to agree with your description, in the WiFi case.  Yes, a router
receiving an RA containing a prefix, and extracting a part of it for use
in its ingress interface would be more than what the semantics of a RFC
RA is.

In practice, e.g. on WiFi, a router receiving an RA even if it would be
able to use parts of it on its ingress interface, the access router
which provided that prefix does not have a routing table entry for it,
so the entities on the ingress would not work.

On another hand, still in practice, a cellular link "no-ARP" would not
suffer of this shortcoming.  The route for HNP on the access router is a
connected route and has no next-hop.  In this sense, it is very well
possible on cellular link (wireless, mobility) to use this HDNP
division; and without doing ND proxy.

It is also possible to try to specify extensions to RA such that this
prefix in it has additional semantics, like "Type 200" means "prefix to
be used further down the line" - a kind of prefix delegation with ND.
We work on it as well.

But even without this ND PD, the HNP Division can work well on cellular
links to offer network mobility.

> Also, please explain:

There may be an issue on how SLAAC works, on the ingress interface.  If
the HNP is /64 then HNP division would obviously offer an MNP at /65 or
longer.  And because Ethernet IIDs are 64 length and addresses are 128,
there is obviously an issue here.

But there are solutions to that.  For example, if one uses LFNs in the
moving network which are not Ethernet (IID of length shorter than 64),
then SLAAC works with a MNP /65.

Or otherwise don't use SLAAC on ingress, but use DHCP.

I don't see other issues.  Is this what you meant?

> b. how SEND is enabled

Should be checked.  I don't see it as impossible.

> c. how a host on a link operating in SLAAC mode, can learn a prefix
> in the RA, claim ownership on part of the prefix and in turn host
> that prefix on the ingress link

Works on cellular links.

> d. if SLAAC is disabled and DHCPv6 stageful mode is supported on the
> MAG-MN link, what happens to your proposal

If SLAAC is disabled and DHCPv6 is used on the MAG-MN link then DHCPv6 
Prefix Delegation should be used.  In this case, HNP Division has maybe 
less place here.

But the way in which you propose the use of Prefix Delegation has some 
problems: what do you set in the MNID of a PBU provoked by the DHCP 
Request?  (DHCP Request does not contain MNID).

Alex

>
>
>>> This technique, if legal, valid and works for SLAAC, SEND, can
>>> be a generic technique useful for wireless and wireless. Nothing
>>>  specific to mobility.
>>
>> Well we do it for network mobility and not for generic technique. I
>> am afraid that if you submit now a draft doing network mobility in
>> PMIP any other subsequent network mobility PMIP submission will
>> have to face the question of why we do it again.
>>
>
> The WG document went through a long review process and was adopted
> after an adoption call. You have a new idea now, but in all
> "fairness", we cannot hijack an IETF WG document, with the fear that
> some future work of ours will have some questions. That is not right.
> If your approach has merit, has support from the WG, you can always
> publish an alternative approach. Or, even deprecate a standard. You
> can request the chairs to Ask for reviews and WG adoption. If there
> is consensus, it will get approved. Again, Xingue's WG draft is not
> stopping you from achieving this.
>
>
>> Or, the question now is why is PMIP-Prefix Delegation claiming to
>> do network mobility and not do network mobility at the same time?
>> My supposition is that authors claim to the WG that authors do not
>> do network mobility and authors claim to elsewhere that authors
>> _do_ network mobility.
>>
>
> I do not know where to go if we start arguing about the definitions
> of MR, MH, IP Node … We do adding prefix delegation to PMIP
> sessions. The ability to support PD support per DHCPv6 is what we
> are supporting.
>
>
>
>> Well, we do not consider neither NAT, nor changing MAC addresses
>> aka ND proxy, other than maybe tangential - these are not core to
>> our PMIP-NEMO proposals
>>
>> The manner we propose by which a HNP can be subdivided into
>> several MNPs is none of these.
>
> You do.  Draft text:
>
> "For this reason, the MR must pretend it owns the IP address of LFN
> and respond to that solicitation with its own MAC address."
>
>
>
>> The manner we propose by which a HNP can be subdivided into
>> several MNPs is none of these.
>
>
>
> I know this discussion won't end and you will thoroughly enjoy this
> discussions :). But, to make progress, Please explain how your draft
> works and get WG support. Note that Xingyue's draft is not your
> blocker. My final comment, please ask the chairs to request WG
> adoption on your draft.
>
>
>
>
>
> Regards Sri
>
>
>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Jul 2012 16:56:38 +0200

Sri,

[...]
>> after an adoption call.

But any Last Call?

(the adoption call was July 2011; some of the comments at mic at that
time was about working on a problem statement - that happens now).

>> You have a new idea now, but in all "fairness", we cannot hijack an
>> IETF WG document, with the fear that some future work of ours will
>> have some questions. That is not right. If your approach has merit,
>> has support from the WG, you can always publish an alternative
>> approach. Or, even deprecate a standard. You can request the chairs
>> to Ask for reviews and WG adoption. If there is consensus, it will
>> get approved. Again, Xingue's WG draft is not stopping you from
>> achieving this.

Well, of course half empty is not half full and hijacking is not good.

But one would not submit a draft to IESG when:
- competitor exists
- LC is not there
- implementation and IPR are not mentioned.

Or?

Alex

>>> Or, the question now is why is PMIP-Prefix Delegation claiming
>>> to do network mobility and not do network mobility at the same
>>> time? My supposition is that authors claim to the WG that authors
>>> do not do network mobility and authors claim to elsewhere that
>>> authors _do_ network mobility.
>>>
>>
>> I do not know where to go if we start arguing about the
>> definitions of MR, MH, IP Node … We do adding prefix delegation to
>> PMIP sessions. The ability to support PD support per DHCPv6 is what
>> we are supporting.
>>
>>
>>
>>> aka ND proxy, other than maybe tangential - these are not core
>>> to our PMIP-NEMO proposals
>>>
>> "For this reason, the MR must pretend it owns the IP address of
>> LFN and respond to that solicitation with its own MAC address."
>>
>>
>>
>> I know this discussion won't end and you will thoroughly enjoy
>> this discussions :). But, to make progress, Please explain how your
>> draft works and get WG support. Note that Xingyue's draft is not
>> your blocker. My final comment, please ask the chairs to request
>> WG adoption on your draft.
>>
>>
>>
>>
>>
>> Regards Sri
>>
>>
>>
>>
>>
>>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Jul 2012 17:05:11 +0200

[...]

>> The manner we propose by which a HNP can be subdivided into several
>> MNPs is none of these.
>
> You do.  Draft text:
>

Right, but that is only in the case of 'shared' links like WiFi.  In the
case of ptp wireless links like cellular links "it is not necessary to
add any additional behaviour for MR to work (LFN to be reachable from
CN). It is sufficient for MR to perform HNP division [...]"

>> The manner we propose by which a HNP can be subdivided into several
>> MNPs is none of these.
>
>
>
> discussions :).

:-) well I am trying to enjoy more... only if we could have agreed on
this logical interface draft.  But it's dropped :-(

> But, to make progress, Please explain how your draft works and get
> WG support.

I would like to get an opportunity to present at the face-to-face
meeting if possible.  Maybe 5 minutes presentation of PMIP-NEMO à la
petrescu-boc-janneteau may help clarify?

> Note that Xingyue's draft is not your blocker.

This is something we could try to identify.  I personally strongly
believe that if WG delivers to IESG now a draft doing network mobility
with PMIP then that's done - any future try is going to face this need
to answer _why_ network mobility with PMIP again, do it once and only
one way, etc.

This is something we could ask others oppinions: do you think that other
PMIP-NEMO solution drafts are possible if we submit now
draft-ietf-netext-pd-pmip-02 to IESG?

What do you think?

> My final comment, please ask the chairs to request WG adoption on

I would like to but I believe it may be too early?  It has never been
presented to a face-to-face WG session...

Alex

---

From: <[email-masked]>
Date: Thu, 12 Jul 2012 15:07:03 +0000

Alex,

The I-D is ready for WG LC and will be issued shortly.
I-D authors are expected to follow IETFs IPR policies and I would expect
the same for the WGs P-D I-D.

-Raj

On 7/12/12 9:56 AM, "ext Alexandru Petrescu"
<[email-masked]> wrote:

>>> definitions of MR, MH, IP Node Š We do adding prefix delegation to

---

From: <[email-masked]>
Date: Thu, 12 Jul 2012 15:09:05 +0000

Alex,

>petrescu-boc-janneteau may help clarify?

If you need an agenda slot to present your I-D and make the case to the
WG, please submit a request.
See: http://www.ietf.org/mail-archive/web/netext/current/msg02537.html

-Raj

---

From: <[email-masked]>
Date: Thu, 12 Jul 2012 15:20:04 +0000

Hi Alex,

>draft-ietf-netext-pd-pmip-02 to IESG?

The WG has worked on the P-D solution as specified in
draft-ietf-netext-pd-pmip for a while now.
Is the solution broken? I do not believe so.
If the WG members are in favor of the solution proposed in this I-D, then
the chairs will issue a WG LC and forward it to the IESG.
The WG is not limited to standardizing a single solution only for network
mobility. And hence if your ideas proposed in the I-D have traction, the
WG could take up that work as well. Your fears that the work would stop is
unfounded.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 12 Jul 2012 17:28:52 +0200

Le 12/07/2012 17:20, [email-masked] a écrit :
>> believe that if WG delivers to IESG now a draft doing network
>> mobility with PMIP then that's done - any future try is going to
>> face this need to answer _why_ network mobility with PMIP again, do
>> it once and only one way, etc.
>>
>> This is something we could ask others oppinions: do you think that
>> other PMIP-NEMO solution drafts are possible if we submit now
> draft-ietf-netext-pd-pmip for a while now. Is the solution broken? I
> do not believe so. If the WG members are in favor of the solution
> proposed in this I-D, then the chairs will issue a WG LC and forward
> it to the IESG. The WG is not limited to standardizing a single
> solution only for network mobility. And hence if your ideas proposed
> in the I-D have traction, the WG could take up that work as well.
> Your fears that the work would stop is unfounded.

Raj,

Half of the solution we propose is too close to the WG item: allocate a
prefix with DHCPv6-PD, and PMIP, such that to support network mobility.
(the other half - HNP division is more different).

In the details, we believe our implementation to be better and the
message sequence are different.  For example, our MAG would not
interoperate with WG item's LMA.  And we need a DHCPv6 Server whereas WG
item works _without_ a DHCPv6 Server.

These are all variants of a single solution.  If this WG item goes to
IESG then half of our draft is dead. (the other half - HNP Division -
may still live, trying to do network mobility without modifying DHCP,
nor PMIP).

In my experience, it is very hard to convince a WG to do new work again.
  The WG item's most prominent proponents will backfire very strongly
about any new proposal doing the same thing.

This is why I complain about the use of the term 'network mobility' in
the existing draft.  Were it to say that the existing WG item draft does
just 'prefix delegation' then maybe it could go.  But its current aim is
particularly clear, and it is not 'prefix delegation'.

Also, there is this work on the problem statement of network mobility
draft... it seems decoupled from the WG item solution.

Yours,

Alex

>> I would like to but I believe it may be too early?  It has never
>> been presented to a face-to-face WG session...
>>
>> Alex
>>
>>>
>>>
>>>
>>>
>>>
>>> Regards Sri
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

---

From: <[email-masked]>
Date: Thu, 12 Jul 2012 15:40:23 +0000

If the PD part of the I-Ds are the same, then you will need to justify the
advantages of your solution or identify issues with those specified in the
WG document.  
As you stated, "these are variants of a single solution".
The WG has decided to proceed with one approach and there is consensus on
that. 
What you are proposing is an alternative approach which needs to be
evaluated by the WG to determine what to do with it.

Since you have requested an agenda slot at IETF84, you will get an
opportunity to make the case to the WG.

-Raj