Hi Woj, thx for your comments. I nearly forgot that an ISP has to offer its customers a good service, thx for reminding me ;-). I'm just inserting as an answer a sentence, I found in an email posted by Tom Petch on this mailing list in another context: Tom Petch wrote on Fr 10.09.2010 18:06: ".... So the onus is on operators to turn their good business reasons into engineering problems, eg as a requirements RFC, that the IETF will then solve. " I know the problem and look for a solution. Hence it would be very helpful to discuss solutions (and I-D krishnan-rs-mark is at least an approach to that) and not just holding long tirades how bad the problem is. Just my 0.02 €. Olaf _____
Von: Wojciech Dec [mailto:wdec.i...@gmail.com] Gesendet: Freitag, 10. September 2010 16:14 An: Bonneß, Olaf Cc: roberta.magli...@telecomitalia.it; swm...@swm.pp.se; i...@69706e6720323030352d30312d31340a.nosense.org; ipv6@ietf.org; f...@cisco.com Betreff: Re: New version available On 10 September 2010 12:52, <olaf.bonn...@telekom.de> wrote: > > > PPP is not used here. There are numerous different > deployment models, PPP > > is an expensive one that should be avoided unless there is > serious use for > > it. > > While it is true that PPP is not used here, I won't say that > PPP should be avoided. > PPP is a valid and widely deployed model in DSL Broadband > environment; Broadband Forum has already published TR-187 > that explains how to deploy IPv6 with PPP. > > In addition in case of bridged Layer 2 RG model, PPP + SLAAC > with the /64 announced in the RA PIO is a valid solution. > > Best Regards, > Roberta Trying to bring the ball back into the game. If I have to run (as network operator) PPP or 1:1 VLAN based access networks and besides that also N:1 VLAN based network access parts than I would nevertheless like to have _one_ common method for provisioning of address/prefix information. And since SLAAC is one of the valid mechanisms for doing that (according to WT-187) I'm interested to learn if/how that can also work for N:1 VLANs. And I-D krishnan-6man-rs-mark is describing such an approach. Thats why I'm also interested in that I-D. Which of these would be preferable to have: 1. "One common method for provisioning" for all possible scenarios and access technologies, with no requirements on the end host or CPE, resulting in a fair number of users with no connectivity? (Note: the "one" method claim is rather dubious given some major differences inherent to access technologies you are assuming, eg PPP and IPoE, if not factors like DHCP PD and others) 2. Use the right tool set for each access scenario, each with a slightly different configuration but one that ensures iuser connectivity? 3. Set a bar on the minimum _CPE_ requirements that will be supported by the network (ensuring connectivity) within the given scenarios, along with potentially having a single configuration/provisioning method? An example of this would be requiring a routed CPE and/or DHCPv6 support on the CPE/host (which is what some operators have already done). It might be stating a truism, but the presence of such a CPE will still allow non-DHCPv6 capable v6 devices within a user's home to get connected... I may be not running a network, but the goal of optimizing the amount of provisioning done by the operator alongside supporting all possible user access scenarios, all coming at the cost of leaving a good number of such users with no (or broken) v6 connectivity sounds like a particularly unwise trade-off and one that should be avoided (which applies to the proposed approach). Regards, Woj. Ciao Olaf -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------