end user assignment best practice

[Wade Roberts]

On 2013-03-19, at 21:33, Ron Vachiyer <proutfoo at outlook.com> wrote:

>> I'm aware of 4 options. 
>> 
>> 1. Provide a separate /64 from a pool local to the PE router. A /48  
>> allocated for this caters for ~64k endpoints per PE router. Keeping  
>> this local to the PE router prevents route disaggregation within your  
>> core, but must be considered dynamic by the CE. 
>> 
> 
> this is already the plan.  a /48 on the PE is set aside to number all the ptp interfaces between the PE and the customer sites.  What do you mean by "must be considered dynamic by the CE"? 

By 'must be considered dynamic by the CE' I mean if the CE terminates to another PE, the WAN prefix will change.
> 
>> 2. Provide an extra customer specific /64. Only viable method today if  
>> you require static publicly routable addressing on the WAN side of the  
>> CE. Adds an extra routing entry and update if CE can't be guaranteed to  
>> terminate on a specific PE router. 
>> 
> 
> don't you need to provide a extra specific /64 for #1?  Since the CE is not under customer control, the only way to provide him with a means to subdivide the /48 as he sees fit is to route it all the way to his edge router, which in my scenario is one hop past the CE.  This means I have to number as follows:
> 
> PE </64> CE </64> CUST </48>
> 
> as opposed to v4 which currently typically is
> 
> PE </30> CE </29> CUST

Options 1 and 2 are effectively identical, the differentiation is administrative. Some providers have always provided static v4 addressing on the WAN link and have a strong preference to maintain 'parity' when deploying v6, thus option 2.

All of the options I outlined are assumed to be configured thus:

PE </64> CE </48> CUST

The /48 is delegated via the PE to the CE using DHCPv6-PD, the /64 is implementation specific.

I've obviously overlooked the complication of the CE sitting in the middle at layer 3. To keep the topology as it is, you'll need the 2 /64s as you've specified, it'll be ugly until this is addressed.

> 
>> 4. Leave the WAN link to only use Link-Local. Messy and not at all  
>> ideal, but works in some situations. 
>> 
> 
> yuck, messy indeed.
> 
>> I'm familiar with active deployments which are using options 1 and 4. 
>> 
> 
> Perhaps what is annoying me is not the extra utilization of address space but the fact historically there is no dynamic routing between the CE and PE, for lack of a need for it.  If I have to maintain an additional route to every CE it may be necessary to add dynamic routing.
> 

How do you plan to implement this? 4 scenarios come to mind.

1. Configure all addressing manually.

2. Configure the PE </64> CE independently, manually configure the CE for the CUST device to perform DHCPv6 + -PD against to obtain its /64 and /48.

3. Configure the PE </64> CE independently, configure the CE to behave as a DHCPv6 relay which the CUST device passes through to query the PE directly.

4. Have the CE be configured auto. PE </64> CE plus 2x -PD prefixes from the PE (the CE </64> CUST and the CUST </48>). The CE <> CUST configuration is performed as per regular DHCPv6 + -PD.

I'd go with 4 personally, as long as the CE is flexible enough to perform all the juggling, otherwise look at 2.

> 
>> As for reading material, TR-187 is worth being familiar with,  
>> especially for v6 over PPP: 
>> http://www.broadband-forum.org/technical/download/TR-187.pdf 
> 
> thanks, will have a look at it.
> 
> Ron.