Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here

[Mark Smith <[e-mail]>]

On Mon, 31 Jan 2011 16:30:16 -0600
Jack Bates <[e-mail]> wrote:

> 
> 
> On 1/31/2011 4:14 PM, Michael Newbery wrote:
> > +1. While a fully managed service is something that a customer may
> > wish to purchase, that's a whole different service to the normal ISP
> > case, and keeping a clean demarcation only enhances even a fully
> > managed service offering.
> 
> You've also broken a good portion of my customers if they left 
> everything plugged in as is and could upgrade their routers to IPv6 (or 
> I'll be issuing 2-8 /48's for a single customer, as it's not uncommon 
> for multiple routers to be connected into the ISP bridging modem, or 
> even a switch connected to the modem with a string of routers connected 
> to it)
> 
> We're not talking about changing the demarcation. We're talking about 
> the ability separate allocation to customer from delegation to a router. 
> More specifically, multiple routers, in an automated fashion. There's no 
> additional tracking concerns.
> 
> 1) Customer has 1 router and it has 1 or more delegations inside of an 
> allocation which can all be summaries as an aggregate.
> 
> 2) Customer has multiple routers and it has multiple delegations inside 
> of an allocation which can be summaries as a group of aggregates if you 
> need specific router information or as the entire allocation if you only 
> care about the specific customer.
> 

The issue with this second model is that a multihomed CPE or multiple
CPE  scenario isn't in scope for the simple CPE draft, and trying to
address it in the simple CPE draft at this time would only further
delay its publication. In the longer term, dynamic multihoming would be
useful, and may become far more popular. However, I think it is
important to soon have an RFC that describes the IPv6 equivalent of the
most commonly deployed IPv4 scenario today, which is the single CPE,
single homed scenario.

> I'm not saying that everyone will agree with the model. Yet, to not even 
> support the model? Is there another model you have for supporting this 
> without issuing longer prefixes which can lower the depth of the 
> customer network?
> 
> Jack
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops