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:[email protected]]
Gesendet: Freitag, 10. September 2010 16:14
An: Bonneß, Olaf
Cc: [email protected]; [email protected];
[email protected]; [email protected]; [email protected]
Betreff: Re: New version available
On 10 September 2010 12:52, <[email protected]> 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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
