On Wed, 8 Sep 2010 11:45:34 -0400 Suresh Krishnan <suresh.krish...@ericsson.com> wrote:
> Hi Mark, > > On 10-09-08 05:50 AM, Mark Smith wrote: > > On Thu, 26 Aug 2010 09:20:45 -0400 > > Thomas Narten <nar...@us.ibm.com> wrote: > > > >> Suresh, > >> > >> Suresh Krishnan <suresh.krish...@ericsson.com> writes: > >> > >>> The nodes attached to different subscriber lines cannot directly send > >>> packets to each other. They need to talk through the edge router. > >> How is this enforced? If I happen to know the mac address of my > >> neighbor's router (or host), can't I just send stuff directly? > >> > >> If I happen to send bogus NAs to my neighbor, does the architecture > >> prevent this? > >> > >>> All traffic needs to go through the edge router. There is no direct > >>> host-to-host communication allowed between different subscriber > >>> lines. > >> Will edge routers send redirects when "neighbors" are sending traffic > >> to each other? Or will the Edge Router become a performance bottleneck > >> when lots of traffic going through it is sent right back out on its > >> incoming interface? > >> > > > > The only reason to hair pin traffic through the edge router is so that > > the edge router can act as a policy enforcement point or billing point. > > There are also requirements for lawful intercept on the operators that > preclude direct communication between subscriber lines. > I think it is very very likely that some ANs have the mechanisms to do capture traffic at the point of connection of the customer, with those mechanisms not constrained by the VLANs/PVCs that are configured. > > > > While a lot of SPs would want that, others may not - with one reason > > being that if the edge router is geographically remote (as is > > commonly the case here in .au), then backhaul bandwidth between the > > ANs and the Edge Router has to be provisioned for this inter-customer > > traffic. SPs may consider this traffic trivial enough that it only > > wants to bill for traffic entering or leaving the aggregation network > > via the edge router, ignoring traffic that stays within it. I think > > this scenario also creates a need for a prefix-redirect, where the > > edge-router, fully aware of the prefixes residing behind the customer's > > Residential Gateways, can send a prefix redirect directing one RG that > > it is a link layer peer of the RG that the prefix covering the > > destination it is trying to reach, and therefore it can send traffic > > directly to the RG. There'd be some security issues to address, however > > ANs are already performing a lot of "layer violation" traffic > > inspection and policy enforcement, so I think it's unlikely that these > > additional mechanisms would be much of a burden. > > In the specific deployment that this draft is targeted for, user > isolation is an absolute requirement (R-40 in the TR-101 document and > explained in RFC4562) and hence it is unclear if prefix redirects would > be useful. > Sure. This was more of a comment about slightly more general scenarios and a slightly more general mechanism. I'd really like to see the BBF / ADSL industry take more advantage of ethernet, not use it just to reduce costs. A lot of effort has and is going into making it point to multipoint in residential access scenarios (i.e. make it fit an ATM connectivity model), yet there would be tangible advantages in also having options to truly take advantage of it's multipoint capabilities, such as the scenario I suggested. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
