Hi Fred, On Wed, 25 Nov 2009 08:47:04 -0800 "Templin, Fred L" <[email protected]> wrote:
> Hi Bob, > > > -----Original Message----- > > From: Bob Hinden [mailto:[email protected]] > > Sent: Tuesday, November 24, 2009 2:52 PM > > To: Thomas Narten > > Cc: Bob Hinden; Templin, Fred L; [email protected] > > Subject: Re: New draft on "Stub Router Advertisements in IPv6 Neighbor > > Discovery" > > > > > > On Nov 24, 2009, at 11:37 AM, Thomas Narten wrote: > > > > > Fred, > > > > > > Can you summarize what problem this draft is aimed at solving? What > > > is the motivation for this draft? (I've read it, but I don't > > > understand what the benefit of this approach is or what problem it > > > solves.) > > > > > > > In the Introduction says: > > > > A stub router is any router that attaches stub networks to the link, > > but does not itself attach the link to a provider network. Here, a > > "stub network" could be as simple as a small collection of IPv6 > > links, or as large as a complex corporate enterprise network. Stub > > routers are said to be "non-authoritative" for the link, since they > > cannot themselves provide forwarding services for packets emanating > > from their stub networks without using another router on the link as > > a transit. > > > > I disagree with this and don't think that a router that is connected to an > > ISP is inherrently higher > > priority than other routers. > > I don't understand this comment. The entity I am calling > "stub router" is simply trying to find a way to forward > packets on to their final destination using the best > possible exit router. There is nothing said or implied > about "priority". > > > This is definitely not true in enterprise networks. > > This is actually all about enterprise networks; in some ways, > an ISP network can be seen as just a special case of an > Enterprise network. > > > We have other ways of doing this in a more general fashion such as RFC4191 > > "Default Router > > Preferences and More-Specific Routes". > > Exactly; this document very much expects that stub routers > will advertise RFC4191 more-specific routers. > > > I don't see any need to define "stub routers" and see a lot > > of harm doing so. For example, in an enterprise, routing may be setup to > > keep the traffic inside of > > the enterprise for a long as possible and not use the local ISP connection. > > The inter-enterprise > > links might be much faster. > > The way it works is that the stub router may have a default > route but may not have a more-specific route to the destination > inside the enterprise. It then sends the packet to a default > router which hairpins it back to a router within the enterprise > that aggregates the more-specific route, but also sends a > redirect back to the stub router that originated the packet. > The stub router then sends an RA to the enterprise router > that aggregates the more-specific route, then subsequent > packets flow through the more-specific route and eliminate > the dogleg. > > So yes; packets stay inside the enterprise and do not go out > the local ISP connection only to come back in again. > I've been thinking of something similar if not the same. With some ISP customer attachment models e.g. certain ADSL ones, it'd be possible to have 100s or 1000s of subscriber CPE in a common link segment using one or a couple of upstream provider routers. Without something like a prefix redirect, hair pinning would occur for traffic between the downstream subscriber CPE, which could be a significant amount of traffic if there is a lot of downstream CPE and the subscribers are using applications that tend towards traffic locality e.g. VoIP and Video between relatives in the same geographically area, game players, P2P architecture applications etc. There can be some cost advantages to ISPs to aggregate customers into multiple layer 2 geographic groups (e.g. a central office/telephone exchange), and then have routing performed at a more central off-site location. It'd be useful to have a mechanism to try to keep traffic within the same c.o./exchange, minimising the use of the more costly backhaul bandwidth and upstream "one-armed-router" interface bandwidth when possible. Latency would also be reduced. When I've brought this idea up before (I think in v6ops), one concern was how it would impact the ability of an ISP to perform lawful intercept. The concern was that as the provider router wouldn't see the downstream inter-CPE traffic, LI wouldn't be able to be performed. My answer is that LI seems to be best achieved when it is performed as close as possible to the lawfully intercepted subscriber as possible. In this shared segment multiple-subscriber CPE/upstream provider router model, LI would be best performed at the point of attachment for the individual CPE/subscriber e.g. the point where the individual CPE's ADSL service attaches to the service provider's network. To do that, the ISP would need administrative control at and over that point of attachment. If the ISP doesn't have control of that point of attachment, then this LI can't be achieved with this prefix redirected, shared-segment CPE model - meaning that a different connectivity model e.g. PPPoE for the subscribers, with the resulting drawback of hair pinning, needs to be used. In other words, this connectivity model is an alternative connectivity option, with possible traffic locality benefits, if an ISP owns or is in control of both the layer 2 and layer 3 infrastructure. I think it'd be useful if this draft or associated ones provided a mechanism applicable to this ISP scenario. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
