[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: draft-wbeebee-ipv6-cpe-router-04 comments
Hi Barbara,
On Mon, 30 Mar 2009 10:08:02 -0400
"Stark, Barbara" <bs7652@att.com> wrote:
(As a disclosure, I work for an SP with a reasonable sized ADSL
network with Ethernet backhaul, but I'm participating here in my own
time.)
> My remembrance of why SPs aren't keen to localize routing is quite
> different.
> Originally, cable operators had neighbors all on the same Ethernet
> network. Neighbors were able to discover each other's computers and
> printers (this was before routers were common), and sometimes sniff each
> other's traffic. This was considered a bad thing, from a customer
> security and privacy standpoint. Telco providers decided that they did
> not want to it this way, and effectively made Ethernet connections from
> customers "point-to-point" to an element in the access network.
>
It is useful to remember history, but it's not the situation today -
and we're talking about designs trying to suit today's and near
future situations and requirements.
I'm not sure about cable CPE, but all ADSL CPE these days is a router,
doing IPv4 NAT and firewalling, by default, although they can usually be
configured to act as a bridge. While the bridging capability for
existing CPE might be useful as a deployment option for IPv6, I think
eventually all IPv6 CPE will be routed. SPs will probably in effect
demand it, because it makes it easier to scale subscriber counts within
the same part of the network topology.
> Today, the access network elements are able to detect a lot of malware
> traffic (especially DDoS attacks), and disconnect customers that are
> infected with malware that presents a security / privacy /
> performance-impacting risk to others. Unfortunately, this is not an
> infrequent occurrence. If customer traffic were somehow able to bypass
> these network elements, it would open up neighbors to attacks by
> infected neighbors. That would be a very bad thing.
>
So, is their any reason why that functionality must be located in the
BNG?
Alan's company already make ADSL DSLAMs that perform an amount of IP
based traffic processing, despite them not participating in the IP
forwarding process. I'm guessing a lot of the DPI boxes don't
participate in IP forwarding either, so in the least, they don't show
up in traceroute output. It's all layer violations of course, but that
seems to be being more accepted for security / traffic policy
enforcement reasons today (e.g. RA guard, DHCP snooping/modificaton on
switches/ADSL DSLAMs etc.)
> Furthermore, in general, there just isn't that much neighbor-to-neighbor
> communication, that would make the savings outweigh the cost of
> implementation. The only neighbor my home trades a lot of traffic with
> (my kids and their kids, gaming) is on a separate network, since we use
> different service providers.
>
Peer-to-peer traffic e.g. bittorrent etc., is a strong candidate for
network locality. The only thing that doesn't seem to exist
is P2P applications that make network topology aware peer selection,
and I think the IETF are already working on that. Once they exist, I
think there will be considerably more local intra-SP traffic than there
is today.
> Lack of cost justification and security concerns are the reasons why SPs
> are unlikely to localize traffic within the access network, for general
> consumers.
Maybe this is what we're tripping up on. Different topologies and
network densities have different optimal forwarding paths. If the BNG
is colocated with the broadband layer 2 infrastructure in an exchange /
central office, then the overhead of traffic being forwarded via the
BNG, albeit increased, isn't all that significant. However, if the BNG
is located at some more central aggregation point, then having traffic
that can stay within the exchange/C.O. by e.g., going direct between
customer CPE at layer 2, saves both BNG resources and sometimes
significant backhaul bandwidth costs. That might not be a significant
cost today, but once P2P app become (layer 3) topology aware, I think
that'll increase significantly the amount of traffic that will be
being unnecessarily hair-pinned via an off-site device.
Regards,
Mark.
> Barbara
>
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> > Behalf Of Mark Smith
> > Sent: Monday, March 30, 2009 5:48 AM
> > To: Alan Kavanagh
> > Cc: Alastair Johnson; Mikael Abrahamsson; Olaf.Bonness@telekom.de;
> > v6ops@ops.ietf.org
> > Subject: Re: AW: draft-wbeebee-ipv6-cpe-router-04 comments
> >
> > Hi Alan,
> >
> > On Sun, 29 Mar 2009 21:09:37 -0400
> > "Alan Kavanagh" <alan.kavanagh@ericsson.com> wrote:
> >
> > > Correct, and this is why SP's are not too keen to have routing
> > localised
> > > in the aggregation network before the BNG.
> > >
> >
> > I'd have thought they should be keen to avoid that, unless all of
> their
> > customers are all under or likely to all under surveilence at the same
> > time!
> >
> > The technical requirement of LI is that traffic has pass the
> > interception point. As the majority of people are honest, it seems to
> > me that optimising the topology to pass the interception point, rather
> > than for best throughput and lower latency, is wasteful, and an unfair
> > performance and ultimately a network capex and opex cost burden on
> > those subscribers who aren't under surveilence, and may never be. Only
> > traffic that is to be lawfully intercepted should be forced past this
> > interception point, if it doesn't already naturally traverse it.
> >
> > Some topologies would inherently make the BNG the best traffic
> > interception point e.g. wholesale broadband aggregation via L2TP.
> > However, for other topologies (e.g. a single VLAN interconnecting
> > customers' ADSL routers, and an upstream default router for access to
> > the Internet/other services), traffic can travel direct between
> > subscribers / their CPE, as the CPEs have an on-link peer
> relationship.
> > Should lawful interception be required, either that on-link path could
> > be changed to traverse the interception point (e.g., by mechanisms
> > such as forced forwarding), or better yet, the interception point be
> > the
> > suspect subscriber's point of interconnection i.e. the specific ADSL
> > service that they're using - as all their traffic is naturally going
> to
> > traverse that point.
> >
> > If an SP wants to have a topology that has all traffic traversing the
> > BNG, or is forced to because of a legal requirement, that's fine.
> > My argument is that other SPs won't have this requirement so they
> > shouldn't also be forced to adopt this LI optimal topology - they
> > should have the freedom to implement a topology optimised for
> > throughput and low latency.
> >
> > So, getting back to the discussion point, I think there would be
> > value in having a mechanism where downstream CPE can be informed of
> > on-link peer-CPE's assigned prefixes, without the CPE themselves
> having
> > to trust each other's announcements. An idea I had a while back was a
> > "prefix redirect", similar to an ND host redirect, issued by, and only
> > accepted from, the upstream on-link default router. Not quite as
> > optimal as the CPE themselves announcing their prefixes via a routing
> > protocol, but it would be more scalable - the CPE would only be
> > maintaining topological knowledge for destinations they're currently
> > using, rather than for all the destinations they can reach via on-link
> > peer CPE.
> >
> > Regards,
> > Mark.
> >
> >
> > > -----Original Message-----
> > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> > > Behalf Of Alastair Johnson
> > > Sent: March 28, 2009 1:41 PM
> > > To: Mark Smith
> > > Cc: Mikael Abrahamsson; Olaf.Bonness@telekom.de; v6ops@ops.ietf.org
> > > Subject: Re: AW: draft-wbeebee-ipv6-cpe-router-04 comments
> > >
> > > Mark Smith wrote:
> > > > On Thu, 26 Mar 2009 17:53:05 +0100 (CET) Mikael Abrahamsson
> > > > <swmike@swm.pp.se> wrote:
> > > >
> > > >> On Thu, 26 Mar 2009, Olaf.Bonness@telekom.de wrote:
> > > >>
> > > >>> Normally the customers are separated from each other by split
> > > horizont mchanisms and MAC adress translation techniques.
> > > >> Yes, but that defeats the whole purpose of the proposal from Mark
> > > >> Smith if I correctly interpret the scenario he proposed.
> > > >>
> > > >
> > > > Yes it would defeat it. The only reason I can think of to require
> > hair
> > >
> > > > pinning of traffic between downstream on-link peer CPE is if your
> > > > default router is your traffic billing point, and you want to bill
> > > > (count) the traffic between those CPE. Otherwise you're probably
> > > > unnecessarily forcing a P2P model connectivity model (i.e.
> > > > an ATM ADSL backhaul model) onto a multi-access technology (an
> > > > Ethernet/ADSL backhaul model).
> > >
> > > Lawful Interception is another reason that a service provider may
> > want
> > > all traffic from a subscriber aggregated to the default router.
> > There
> > > may be no way around this, depending on the LI requirements that are
> > > placed on the service provider, and where the logical interception
> > point
> > > is (BNG vs. DSLAM).
> > >
> > > aj
> > >
> > >
>
>
> *****
>
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622
>
>