On 13 September 2010 08:49, <olaf.bonn...@telekom.de> wrote: > 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. >
Quite the contrary. My earlier mail gave a number of valid options. The approach espoused by the current rs-mark, which you appear to support, requires a modification of the existing ICMPv6 spec as well as host implementations. Is this the type of solution you are after? How does that factor into your business reasons? Thanks, Woj. Thanks, Woj. > > 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 --------------------------------------------------------------------
