Hi Thomas, On Tue, 01 Dec 2009 09:12:44 -0500 Thomas Narten <nar...@us.ibm.com> wrote:
> Mark Smith <i...@69706e6720323030352d30312d31340a.nosense.org> writes: > > > I think a "prefix redirect" mechanism is justified because it provides > > more optimal forwarding for inter-CPE traffic. I only brought up > > the LI issue and addressed it because that seemed to be the only > > objection there was to the idea when I suggested it before. I don't > > think it is a valid concern, and if the IETF has decided not to > > consider LI type requirements, then it is one less thing any drafts have > > to address and document. > > A prefix redirect is a minor performance optimization over the current > redirects we have. > > I remain skeptical that such a redirect is needed and provides > sufficient value. > > Note that this is not the first time such a redirect was suggested. > It's been discussed in the past, but there was never really enough > support for it to go forward. > > As always, what exactly is the problem that needs solving here? I'm > not talking about a generic "possible" performance benenfit in "some > cases". What specifically do we see happening in real (or planned) > deployments that justifies this sort of enhancement? > I'm still a bit confused about Fred's scenario, however here is the one I've been thinking about. Broadband Forum TR-101 describes using Ethernet instead of ATM for backhaul. This technology has been deployed here in Australia quite significantly over the last 5 years. The common deployment model for IPv4 over ADSL in these networks is PPPoE, resulting in hair pinning of traffic between subscribers when they're attached to the same ethernet segment. PPPoE makes broadband look like high speed dialup, which allowed ISPs to introduce broadband fairly rapidly without having to change their backend authentication/billing systems etc. The drawback is the overheads of potential authentication failures due to username/password errors, when the ISP already knows who the subscriber is (i.e. they know where they live), and the PPPoE 8 byte per packet cost which is to essentially convert the multi-access nature of Ethernet into a point-to-point service, resembling dialup. The number of subscribers attached to an exchange/central office can be small enough that installing redundant layer 3 infrastructure in each exchange/C.O. can be cost prohibitive. Instead, in each exchange/C.O., only ADSL/Ethernet infrastructure is deployed. The supporting layer 3 equipment is located at a more central location, providing layer 3 to multiple exchanges/C.O.s, over high speed backhaul. Depending on the size or number of the layer 3 equipment you wish to operate, your physical geography, and the cost of backhaul bandwidth, the number of subscribers attached to the same layer 2 segment may number in the many thousands. If IPv6 was deployed "natively" over the ADSL/Ethernet backhaul in this scenario (i.e. a multi-access segment, rather than an engineered point-to-point one a la. PPPoE), you then have 1 or more likely 2 service provider routers (with e.g. VRRP), and potentially a large number of downstream subscriber routers, a.k.a. CPE, with /48s or /56s behind them. The provider routers will have static routes pointing towards the subscriber CPE for the /48s / /56s, while the subscriber CPE will have a default route towards the provider routers. With the potential for 1000s of subscriber CPE being layer 2 neighbours, as well as traffic having to be hair-pinned offsite for inter-subscriber traffic, an optimisation would be to have the subscriber CPE aware of it's on-link neighbour CPE's downstream prefixes. This would reduce latency for that traffic, reduce required backhaul bandwidth, and eliminate the hair-pinned traffic from entering and leaving the provider routers, helping to increase the number of subscribers who could be attached to this domain. All the current methods I can think of that could be used to achieve this optimisation have scaling and/or trust limitations: - static routes in the subscriber CPE requires excessive operational overhead, and if subscribers own the CPE (which is the common situation here in .au), you're probably asking Mums (moms) and Dads to be (trusted) network operators, entering 100s or 1000s of static routes. - dynamic routing is unlikely to be able to cope with the number of neighbour adjacencies it has to maintain, and if subscribers own the CPE, again they probably need to be network operators. The number of prefixes being distributed via the dynamic routing protocol may also be beyond the capabilities of the typical IGPs and the CPE CPUs that it's running on. - possibly RAs with the route information option could be traded between the subscriber CPE and provider routers, however that would require inter-router RA support, and also would possibly encounter some of the trust and scaling issues that using traditional dynamic routing protocols would. It seems to me that something like a prefix redirect, sent from the provider routers to the subscriber CPE when traffic is to be hair-pinned, would be a better solution. It retains the topology authority that the provider routers have over the the segment, avoids subscribers having to become network operators, and because it is reactive to traffic flow, is, with appropriate controls e.g. per-CPE rate limits on generation, more scalable than the proactive dynamic methods like an IGP. I started working on a draft a few weeks ago to propose this. It seems that there might be overlap with Fred's draft, which is why I suggested that it could a scenario that could be addressed in his. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
