Subject: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Apr 2011 12:18:39 -0700

We had a last call on this prior to the Prague meeting, and there was work done off list, but no responses on-list.   If you support this work, please indicate that you support it.   If you oppose the work, please provide suggestions, comments, or reasons why it's entirely a bad idea.

Assuming that we get some comments between now and next Friday, we will determine consensus next Friday (May 29).

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Apr 2011 09:34:42 +0200

> Assuming that we get some comments between now and next Friday, we will determine consensus next Friday (May 29).

I'm obviously in support, but as a co-author that shouldn't count for much. ;-)

to summarize what this draft does:
in a typical DHCP-PD based ISP deployment, the ISP edge device (BNG) has two routes in the RIB per customer.
one /64 route for the link-net between BNG and RG and one /48-/56 for the customers delegated prefix.

the exclude option lets the ISP delegate a prefix - 1, resulting in a single aggregate route in the RIB per customer.
this is vital for 3GPP deployments, that has a (who knows why) limit of a single prefix per customer.

cheers,
Ole

---

From: Jyrki Soini <[email-masked]>
Date: Thu, 21 Apr 2011 10:22:23 +0300

> Assuming that we get some comments between now and next Friday, we will determine consensus next Friday (May 29).

I'm in favor of this draft. It solves the problem on 3GPP network specs
and is backwards compatible.
--
Jyrki Soini

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Apr 2011 17:44:28 -0700

> I'm obviously in support, but as a co-author that shouldn't count for much. ;-)

Of course it counts.   BTW, FTR, I'm in favor of the draft as well.

---

From: jouni korhonen <[email-masked]>
Date: Sun, 24 Apr 2011 02:07:35 +0300

Obviously I am in favor of this ;) And we do have a real need for the solution, whether we like it or not (in 3GPP deployments). The good thing is that the solution is backwards compatible, e.g. if waste of prefixes is fine for the operator it can use RFC3633 as-is. If some day in the future things get better on the architectures where the pd-exclude is needed (like imagine 3GPP getting unnumbered bearers or being fine with non-aggregated prefixes), the pd-exclude can just be turned off.

- Jouni

On Apr 19, 2011, at 10:18 PM, Ted Lemon wrote:

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

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 25 Apr 2011 12:00:10 -0400

Hi Ted,

> Of course it counts.   BTW, FTR, I'm in favor of the draft as well.

I support this draft going forward (I am a co-author as well).

Thanks
Suresh

---

From: Jiangsheng <[email-masked]>
Date: Tue, 26 Apr 2011 01:06:34 +0000

Feeling this work is useful. Support it from non-authorship. :P

Regards,

Sheng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Suresh Krishnan
> Sent: Tuesday, April 26, 2011 12:00 AM
> To: Ted Lemon
> Cc: [email-masked] WG
> Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01
> 
> Hi Ted,
>

---

From: GangChen <[email-masked]>
Date: Tue, 26 Apr 2011 10:15:50 +0800

I support this work. 3GPP network could benefit from new defined PD option.

Gang

---

From: Glen Zorn <[email-masked]>
Date: Tue, 26 Apr 2011 09:28:37 +0700

>> Feeling this work is useful. Support it from non-authorship. :P

Just out of curiosity, is this option known or believed to be useful to
anyone _except_ 3GPP?

...

---

From: jouni korhonen <[email-masked]>
Date: Tue, 26 Apr 2011 07:57:24 +0300

See for example http://www.ietf.org/mail-archive/web/dhcwg/current/msg11100.html

- jouni

On Apr 26, 2011, at 5:28 AM, Glen Zorn wrote:

> <gwz.vcf>_______________________________________________
> dhcwg mailing list
> [email-masked]

---

From: Glen Zorn <[email-masked]>
Date: Tue, 26 Apr 2011 12:28:41 +0700

> See for example http://www.ietf.org/mail-archive/web/dhcwg/current/msg11100.html

OK, in that message Jyrki Soini wrote in the last sentence (which I'm
guessing is the relevant one, right?) "The issue is not just [a] 3G
network peculiarity but it might also make life simpler on
xDSL/metro-Ethernet network implementations where [the] VLAN per
customer model is used."

So call me a moron, but what do VLANs have to do w/IPv6 prefixes?

...

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 26 Apr 2011 14:04:44 +0200

+1

Thanks to the authors, I am in favour of this draft.
(To solve the 3GPP way of Prefix Delegation)

Cheers,
Ales

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
> Lemon
> Sent: Tuesday, April 19, 2011 9:19 PM
> To: [email-masked] WG
> Subject: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01
> 
> We had a last call on this prior to the Prague meeting, and there was work done off
> list, but no responses on-list.   If you support this work, please indicate that you
> support it.   If you oppose the work, please provide suggestions, comments, or reasons
> why it's entirely a bad idea.
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Apr 2011 08:15:05 -0700 (PDT)

Hi Jouni,
  Can you please explain to me why we need PD Exclude option in 3GPP while 3GPP 
was not using stateful address configuration but instead using SLAAC? 

Also if ever recommended using what type of architecture? As you know DHCP PD 
could be used in many different ways.

Don't get me wrong, I am not against this draft, I saw mention of it in 23.401, 
congrats on the hard work.

Regards,

Behcet

> 
> See for example  
>http://www.ietf.org/mail-archive/web/dhcwg/current/msg11100.html
> 
> -  jouni
>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 26 Apr 2011 11:36:27 -0400

Hi Glen,

> So call me a moron, but what do VLANs have to do w/IPv6 prefixes?

The BBF has two different VLAN deployment models. The one where each 
subscriber line is connectev into the Edge Router using a different vlan 
tag is called the 1:1 VLAN (or the VLAN per customer) model. Each of 
these customer circuits is associated with two prefixes now. A /64 for 
performing SLAAC towards the subscriber and a shorter prefix (say /56) 
for delegating to the LAN(s) inside the subscriber's home. Due to 
limitations in RFC3633, these two prefixes are not aggregatable. Using 
the DHCP PD exclude option, these two prefixes can be aggregated.

Thanks
Suresh

---

From: Jouni <[email-masked]>
Date: Tue, 26 Apr 2011 23:02:32 +0300

Bechet,

> was not using stateful address configuration but instead using SLAAC? 

Prefix delegation does not need to be coupled with the DHCP-based address allocation. The real cause for all of this was the desire to a) have an efficient use of prefixes and b) be able to aggregate the delegated prefix and the /64 assigned to mobile device's uplink in a nice way (i.e. the /64 is part of the shorter delegated prefix mainly for policy control purposes).

> could be used in many different ways.

BBF has a similar 1:1 VLAN deployment model option, where this could be used. The presentation from Maastricht http://www.ietf.org/proceedings/78/slides/dhc-3.pdf summarizes nicely different PD deployment models.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Apr 2011 15:10:52 -0700 (PDT)

> Prefix delegation does  not need to be coupled with the DHCP-based address 
>allocation. The real cause  for all of this was the desire to a) have an 
>efficient use of prefixes and b) be  able to aggregate the delegated prefix and 
>the /64 assigned to mobile device's  uplink in a nice way (i.e. the /64 is part 
>of the shorter delegated prefix  mainly for policy control purposes).
> 
> BBF has a similar 1:1 VLAN deployment model option, where  this could be used. 
>The >presentation from Maastricht  
>http://www.ietf.org/proceedings/78/slides/dhc-3.pdf 
>
> summarizes nicely different  PD deployment models.

But the situation in BBF is different. BBF has well defined DHCP PD scenarios in 
various BBF documents like TR-177, TR-187, WT-146, etc. I don't see the same 
situation in 3GPP as of now. 

Let's hope that it changes and then this documents becomes applicable in 3GPP. 

Regards,

Behcet

---

From: Ole Troan <[email-masked]>
Date: Wed, 27 Apr 2011 14:07:00 +0200

Bechet,

> situation in 3GPP as of now. 

what makes you say that?

this document clearly indicates that RFC3633 based prefix delegation is part of Release-10:
http://tools.ietf.org/html/draft-ietf-v6ops-3gpp-eps-00#section-5.3

cheers,
Ole