Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-03.txt

[Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>]

Hi Brian,

On Sun, 10 Jan 2010 14:07:16 +1300
Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> On 2010-01-10 12:58, Mark Smith wrote:
> > Hi Brian,
> > 
> > On Sun, 10 Jan 2010 08:37:34 +1300
> > Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> > 
> >> On 2010-01-10 04:16, Mikael Abrahamsson 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). 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). 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.
> >> Especially since the amount of such local traffic seems likely to
> >> be tiny, and therefore not worth optimising. Does anyone have any
> >> actual data on this?
> >>
> > 
> > I don't - my motivation has been to look at it as a missed
> > opportunity for better traffic locality, if the mechanism to do it was
> > simple enough.
> > 
> > It seems to me that peer selection in peer-to-peer protocols could be
> > improved by measuring the latency between peers (e.g. by looking at
> > the SRTT values of the TCP connections to the peers), as lower
> > latency peers would also typically have more bandwidth between them. If
> > peer-to-peer as a content distribution method continues to increase, I
> > think there is or will be increasing value in having customer CPE being
> > more aware of more direct paths to local destinations.
> 
> That's true in theory. But since what we are aiming at with the current
> draft is the first round of CPE requirements based on well established
> specs, it seems out of scope. Probably a topic for discussion on
> draft-wbeebee-v6ops-ipv6-cpe-router-bis?
> 

Certainly the whole prefix-redirect idea is out of scope for this
draft. The only area where I thought there could be related issues was
if the CPE didn't issue RAs, then RAs wouldn't be able to be used for a 
a prefix-redirect capability announcement (if that is a good idea in
itself). Thinking about it a bit more, a Neighbor Announcement option
might be a better place to express such a capability, and wouldn't
require CPE to issue RAs towards the SP router.

On a related note, I think some of the data in section 3.1.  "Reduced
Cross-domain Traffic" of "Improving Peer Selection in Peer-to-peer
Applications: Myths vs. Reality" shows the value of localising traffic
for P2P architecture applications -

http://tools.ietf.org/id/draft-irtf-p2prg-mythbustering-00.txt


Regards,
Mark.