[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-03.txt
Hi Mikael,
On Sat, 9 Jan 2010 16:16:10 +0100 (CET)
Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Sat, 9 Jan 2010, Mark Smith wrote:
>
> >> Why can't a CPE router send unicast RAs to other CPE
> >> routers as long as they are not malicious and do not
> >> in any way conflict with the RAs sent by SP routers?
> >
> > I think on some networks that could have multicast traffic volume
> > related scaling issues. It's quite possible to build single Ethernet
> > link layers using DSL that have 100s or 1000s of CPE attached. It also
> > seems a bit redundant to have the CPEs fully aware of all their
> > neighbours' downstream prefixes, yet be unlikely to use those routes
> > very often.
>
> I think no ISP will ever build a network that allows for local routing
> like that (at least not intentionally).
Up until the end of November I worked at one, and I would have like to
have built something like this.
In this ADSL scenario, geographic layer 2 customer aggregation points
weren't always layer 3 traffic aggregation points. It's a trade off
between a larger number of smaller layer 3 devices, one or two at each
layer 2 geographic site, or a more centralised and offsite layer 3
infrastructure, handling traffic for multiple layer 2 geographic sites.
How many layer 2 sites you aggregate together for layer 3 services is
determined by the geography of your customer base, how many and the
size of the layer 3 devices you want to operate and the costs of
backhaul bandwidth between the layer 2 sites and the chosen layer 3
aggregation site. In this scenario, backhauling all inter-customer
traffic to a more central locations where the layer 3 infrastructure
was located, even though customers were local layer 2 peers seems
redundant to me.
The fundamental difference here verses what's been built in the past
with IPv4 is that with the IPv6 addressing model of allocating
relatively large prefixes to SP customers, and IPv6's multicast
neighbour discovery (i.e. more scalable than IPv4's broadcast address
based resolution), there are scenarios where 100s if not 1000s of
routers may be link layer peers. The cost difference between layer 2
forwarding and layer 3 forwarding also encourages minimising the layer
3 resources.
In the IPv4+NAT world, while the CPE were routers, the prefixes behind
them weren't unique so it fundamentally wasn't possible to have the CPE
or the SP routers make local and more intelligent forwarding decisions.
Now that IPv6 will provide customer unique prefixes, the locations
behind the customer CPE are now externally visible and therefore could
be used for more optimal and less resource consuming traffic
forwarding. Optimal traffic paths provide better quality of service to
customers, and less resource consuming traffic forwarding provides
lower costs to service providers.
> So far ISPs do not want customers
> to talk L2 directly with each other, but instead want to do the routing
> between customers (mostly for security reasons).
"security reasons" is a nice generic term, but it doesn't really
explain anything. What specific "security reasons"? What if an ISP
doesn't want to provide "security", and would rather just be a dumb bit
pipe for their customers?
I also think it may not be that ISPs haven't wanted their customers to
talk L2 directly with each other, it think it's probably because they
haven't been able to. They've had legacy PPPoE infrastructures which
force hair pinning of traffic between layer 2 adjacent customer, or the
nature of the link layer technology, e.g. cable or ATM, hair pins the
traffic anyway and may not support simple link layer peer-to-peer
traffic exchange, without something like NHRP or setting up switched
virtual circuits.
> I therefore think it's a
> moot point to try to drive any standard that by a lot of security measures
> tries to solve this in the CPE. It just won't be deployed because of its
> complexity.
If a generic "complexity" argument is going to be used, then I'd argue
that a prefix-redirect mechanism is much much simpler than PPPoE, PPP or
DHCP. Single packet format, simple processing. It's not really any more
complex that host-redirects and they're not complicated.
Regards,
Mark.