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

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

Hi Fred,

On Fri, 8 Jan 2010 08:58:51 -0800
"Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:

> Ole,
> 
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Ole Troan
> > Sent: Friday, January 08, 2010 4:29 AM
> > To: Mark Smith
> > Cc: IPv6 Operations
> > Subject: Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-03.txt
> > 
> > Mark,
> > 
> > > On Fri, 18 Dec 2009 09:09:21 -0800
> > > Fred Baker <fred@cisco.com> wrote:
> > >
> > >> I will open a WGLC on this after new years; My mind will be elsewhere
> > >> for the coming two weeks, I imagine yours will as well. However, if
> > >> you want to start reading/commenting now...
> > >>
> > >
> > > I hope I'm not going to look silly because I've missed it, however, do
> > > these CPE (as they are routers) issue RAs on their WAN interface? I'd
> > > think a statement relating to whether they do or don't, and if they do,
> > > what options MUST/MUST NOT etc. are permitted should be covered in the
> > > WAN interface section.
> > >
> > > (as a side note, a possible use for these CPE issuing RAs is to
> > > announce support of optional capabilities - I'm thinking about the idea
> > > of prefix-redirects for more optimal inter-CPE traffic flow, and a
> > > prefix-redirect capability announcement to the upstream provider
> > > routers in the CPE's WAN RAs would allow the provider routers to know
> > > not to send prefix-redirects to CPE that don't support that capability)
> > 
> > is not the following (reformatted) requirement not clear enough?
> > 
> > W-1:  When the router is attached to the WAN interface link it MUST
> >          act as an IPv6 host for the purposes of stateless or stateful
> >          interface address assignment ([RFC4862]/[RFC3315]).  The router
> >          MUST act as a requesting router for the purposes of DHCP prefix
> >          delegation ([RFC3633]).
> > 
> > "acting as a host" is the key here. feel free to suggest better text if you don't think that's clear
> > enough.
> > 
> > the WAN interface which is a host for some purposes and a router for others is stretching the
> > definitions in RFC4861 already. having an interface which can do both RS and RA at the same time
> > would be stretching it too far.
> 
> 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.

My thinking has been that a prefix-redirect option, with appropriate
rate-limits, issued by the SP router toward the originating CPE, would
be a more scalable and less resource consuming way to achieve optimal
CPE-to-CPE forwarding.

As a prefix-redirect option doesn't currently exist, it'd be both
redundant and resource consuming for the SP router to continue to send
prefix-redirects to CPE that wasn't paying attention to them. One
thought I'd had was if the CPE were issuing RAs, they announce a
prefix-redirect capability option. The SP router would then know it
could send prefix-redirects to the announcing CPE. This CPE router
state in the SP router could also be used to track per-CPE
prefix-redirect rate limits, rather than having a global
prefix-redirect rate limit.

Regards,
Mark.