Subject: [v6ops] draft-sarikaya-v6ops-prefix-delegation

From: Fred Baker <[email-masked]>
Date: Tue, 10 May 2011 10:18:27 -0700

The authors have asked me about 
http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation
  "DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks",
  Behcet Sarikaya, Frank Xia, 19-Apr-11

When we discussed this at IETF-79, a number of views were expressed, varying from "let's adopt this as a working group draft and immediately publish as a BCP" to "ignore and abandon this draft, if anything it belongs in some other SDO or NOG", and all points in between. Several folks indicated that they would post comments to the list, and the comments didn't materialize.

Question for the assembled hordes: what needs to happen in this draft to make it useful/interesting for mobile network operators? What needs to happen to make it interesting to other operators?

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 May 2011 09:25:44 +0200

_is_ this best current practice?

does this conflict when DHCPv6 PD is used between UE and AR?
I'm concerned about section 3.2, where the AR DHCPv6 relay should add an IA_PD option to the DHCPv6 client - server exchange.
has that new protocol behaviour been reviewed in the DHC WG? in other scenarios that functionality has been solved either with snooping or the proposed RAAN option.

cheers,
Ole

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 12 May 2011 09:37:11 -0700 (PDT)

Hi Ole,

> _is_ this best current practice?

Well, we would like it to be. The main message of the draft is that we should 
use DHCP PD to automate prefix management especially for the networks that have 
large number of UEs attaching to their networks because a unique prefix has to 
be assigned to each UE in some networks.

If it is not we can change it to Informational, whatever WG decides. 

> does this conflict when DHCPv6 PD is  used between UE and AR?

The draft deals with UE address configuration when UE initially attaches the 
network.

After the address is configured, does UE need to do DHCPv6 PD? 
Maybe yes, but it is out of scope with my draft.

> I'm concerned about section 3.2, where the AR DHCPv6  relay should add an IA_PD 
>option to the DHCPv6 client - server exchange.
> has  that new protocol behaviour been reviewed in the DHC WG? 

Good point!

An earlier version was presented in DHC WG.
I copied this mail to Ted, expect he is going to chip in.

> in other scenarios that  functionality has been solved either with snooping or 
>the proposed RAAN  option.
> 

In version -01 we used Option 82. After Suresh, who is copied, commented, I 
changed it to IA_PD. Maybe he had asked, I don't know.

Would Option 82 which is already defined, work better?

Regards,

Behcet

> >  When we discussed this at IETF-79, a number of views were expressed, varying  
>from "let's adopt this as a working group draft and immediately publish as a  
>BCP" to "ignore and abandon this draft, if anything it belongs in some other SDO  
>or NOG", and all points in between. Several folks indicated that they would post  
>comments to the list, and the comments didn't materialize.
> > 
> >  Question for the assembled hordes: what needs to happen in this draft to 
>make it  useful/interesting for mobile network operators? What needs to happen 
>to make it  interesting to other operators?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 May 2011 13:06:56 -0400

> I copied this mail to Ted, expect he is going to chip in.

Hm, I don't remember this.   I think it would probably be better to define a new option for the relay to use to indicate what prefix to delegate.   Otherwise you're needlessly overloading the meaning of that option.

> Would Option 82 which is already defined, work better?

Option 82 doesn't exist in DHCPv6, so it probably wouldn't work very well... :)

---

From: Fred Baker <[email-masked]>
Date: Thu, 12 May 2011 10:19:07 -0700

On May 12, 2011, at 9:37 AM, Behcet Sarikaya wrote:
> On May 11, 2011, at 12:25 AM, Ole Troan wrote:

I don't think that's the question Ole was asking. He's not asking about the status of the draft; he's asking whether what the draft recommends is in fact the practice most operators use and arguably should use.

How do operators do this today?

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 12 May 2011 11:28:14 -0700 (PDT)

> I don't think that's the question Ole was asking.  He's not asking about the 
>status of the draft; he's asking whether what the  draft recommends is in fact 
>the practice most operators use and arguably should  use.
> 

As IPv6 UEs are are rare, they are using prefix pool approach, I think. 
Many UEs can not connect on IPv6 because of chip set issue which was discussed 
on this list before.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 12 May 2011 12:18:22 -0700 (PDT)

Hi Ted,
  It seems like Section 3.2 requires more work which we did not anticipate, 
because of this I am going to remove Section 3.2. It is not the main part in my 
draft.

Regards,

Behcet

> Hm,  I don't remember this.   I think it would probably be better to define a  
>new option for the relay to use to indicate what prefix to delegate.    
>Otherwise you're needlessly overloading the meaning of that option.
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 19 May 2011 03:30:04 -0700 (PDT)

I submitted a revision based on the online and some offline comments received so 
far,
The new draft draft-sarikaya-v6ops-prefix-delegation-04.txt should be accessible
soon.

Regards,

Behcet

> has  that new protocol behaviour been reviewed in the DHC WG? in other 
>scenarios that  functionality has been solved either with snooping or the 
>proposed RAAN  option.
> 
> cheers,
> Ole
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 19 May 2011 03:00:28 -0700 (PDT)

I submitted a revision based on the online and some offline comments received so far,
The new draft draft-sarikaya-v6ops-prefix-delegation-04.txt should be accessible
soon.

Regards,

Behcet

> I'm concerned about section 3.2, where the AR DHCPv6 relay should add an 
> IA_PD option to the DHCPv6 client - server exchange.
> has that new protocol behaviour been reviewed in the DHC WG? in other scenarios 
> that functionality has been solved either with snooping or the proposed RAAN 
> option.
> 
> cheers,
> Ole
> 
>>  When we discussed this at IETF-79, a number of views were expressed, 
> varying from "let's adopt this as a working group draft and immediately 
> publish as a BCP" to "ignore and abandon this draft, if anything it 
> belongs in some other SDO or NOG", and all points in between. Several folks 
> indicated that they would post comments to the list, and the comments didn't 
> materialize.
>> 
> make it useful/interesting for mobile network operators? What needs to happen to 
> make it interesting to other operators?

---

From: jouni korhonen <[email-masked]>
Date: Wed, 25 May 2011 21:18:37 +0300

Hello,

I read the draft and have few issues with it. The draft attempts to give generic guidance about prefix delegation in mobile networks. However, except for mentioning "WiMAX" once in the introduction and making a reference to 802.16 link model RFC, the draft is mostly about 3GPP GPRS or EPC (or some mixture of those). Clear distinction should be made when the text applies to some specific architecture and when it does not.. 

Regarding the shared vs. p2p link model and DAD text I do not understand why those even needs to be discussed here.

The text should make it clear when the delegated prefix is /64 and when something else. E.g. in 3GPP architecture a PGW acting as a requesting router would only be asking for /64s.

In Section 3.1 it is assumed that the GGSN/PGW implements a relay, which is used by the client also residing in the same GGSN/PGW. I assume the attempt is to circumvent the fact that the client cannot unicast a solicitation to the server but a relay can. This is purely an implementation/deployment option and I do not see a reason to assume such collocated functionality.

One could also argue whether steps 2-5 in Figure 2 do happen before step 6. In 3GPP networks they happen in a middle of current step 6 (which is referenced in this step).

The last paragraph in Section 3.1 is somehow misplaced. I would give it its own section. It also took me a while to figure out what was meant here.. The current text is rather confusing regarding which node has which role in each step. The text should be more explicit when the requesting router is the MN and when it is the AR, and also how these cases differ from the rest of the system point of view.

What mobile architecture Section 3.2 refers to? If it is a "generic" architecture, I am not sure why RFC2119 language is needed.

Section 3.4 talks about renumbering. It should be made clear whether the delegated prefix is used to number the MN itself or whether the MN was the requesting routing. In certain mobile architectures renumbering is not considered at all i.e. prefixes always have an infinite lifetime. If renumbering is needed that would mean tearing down the connection. Also in certain mobile architectures adding new prefixes is either possible or not depending which entity was the requesting router.

Why Section 3.5.1? If it needs to be there, a bit more text is needed to build to the context around FMIP6.

Section 3.5.2: s/IMNI/IMSI
Also I would not say MAC address corresponds to IMSI. IMEI could be a better choice.

Section 3.5.3: What is "broadcasting prefixes" ? For prefixes used for documentation purposes see RFC5156.

I have hard time to see the value of this document in its current form. The overall presentation should be far more focused and more specific on topics it covers. For the parts it documents existing systems those has to be as they are in respective SDO specs. For those parts that are generic recommendations, I would like to see more reasoning why given recommendations are considered good. Mixing existing architectures and generic architectures in the same context and figures make reading really hard.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 May 2011 09:34:40 -0700 (PDT)

Hi Jouni,
Thanks for the review. My comments inline.

> Hello,
> 
> I read the draft and have few issues with it. The draft attempts  to give 
>generic guidance about prefix delegation in mobile networks. However,  except 
>for mentioning "WiMAX" once in the introduction and making a reference to  
>802.16 link model RFC, the draft is mostly about 3GPP GPRS or EPC (or some  
>mixture of those). Clear distinction should be made when the text applies to  
>some specific architecture and when it does not.. 
>
> 

Agreed. We clarified this in the new version.

>those even needs to be  discussed here.

Agreed.

> The text should make it clear when the delegated prefix  is /64 and when 
>something else. E.g. in 3GPP architecture a PGW acting as a  requesting router 
>would only be asking for /64s.
> 

Agreed.

> In Section 3.1 it is  assumed that the GGSN/PGW implements a relay, which is 
>used by the client also  residing in the same GGSN/PGW. I assume the attempt is 
>to circumvent the fact  that the client cannot unicast a solicitation to the 
>server but a relay can.  This is purely an implementation/deployment option and 
>I do not see a reason to  assume such collocated functionality.
> 

Well you need a relay if the server is not on-link which could be a common case 
that's why we have it.
 
> One could also argue whether steps  2-5 in Figure 2 do happen before step 6. In 
>3GPP networks they happen in a  middle of current step 6 (which is referenced in 
>this step).
> 

Good point. Clarified this now.

> The last  paragraph in Section 3.1 is somehow misplaced. I would give it its 
>own section.  It also took me a while to figure out what was meant here.. The 
>current text is  rather confusing regarding which node has which role in each 
>step. The text  should be more explicit when the requesting router is the MN and 
>when it is the  AR, and also how these cases differ from the rest of the system 
>point of  view.
> 

Yes, we made it a new section.

> What mobile architecture Section 3.2 refers to? If it is a  "generic" 
>architecture, I am not sure why RFC2119 language is  needed.
> 

OK, corrected it.
> Section 3.4 talks about renumbering. It should be made clear  whether the 
>delegated prefix is used to number the MN itself or whether the MN  was the 
>requesting routing. In certain mobile architectures renumbering is not  
>considered at all i.e. prefixes always have an infinite lifetime. If renumbering  
>is needed that would mean tearing down the connection. Also in certain mobile  
>architectures adding new prefixes is either possible or not depending which  
>entity was the requesting router.
> 

Agreed. We removed this section.

> Also I would not say MAC address  corresponds to IMSI. IMEI could be a better 

Absolutely. This was a typo now corrected.

>documentation purposes see  RFC5156.

Here we talk about the routing protocols like IGP, OSPF not about the 
documentation prefix. Corrected the typo on IGP.

> 
> I have hard time to see the value of this document in its  current form. The 
>overall presentation should be far more focused and more  specific on topics it 
>covers. For the parts it documents existing systems those  has to be as they are 
>in respective SDO specs. For those parts that are generic  recommendations, I 
>would like to see more reasoning why given recommendations  are considered good. 
>Mixing existing architectures and generic architectures in  the same context and 
>figures make reading really hard.
> 

It is mainly on existing architectures and informational.

If you think we should have more text, feel free to propose some.

Regards,

Behcet