Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

[Mark Smith <[e-mail]>]

On Thu, 17 Mar 2011 12:47:04 -0700
Fred Baker <[e-mail]> wrote:

> 
> On Mar 17, 2011, at 11:51 AM, james woodyatt wrote:
> 
> > On Mar 17, 2011, at 11:12 AM, Fred Baker wrote:
> >> 
> >> I really don't think this conversation is going anywhere.
> > 
> > I'm sure I've made my position clear, and I seem to have persuaded no one that, if a routing protocol is to be recommended by this draft, then it MUST be a zero-configuration routing protocol.  I will now quit my campaign, and leave the discussion of this draft to proceed without further contribution from me.
> 
> Ack, and in residential networks in which (to pick one example) RIPng is in use and there is exactly one LAN, that shouldn't be a problem. What it means is:
> 
>  - deriving the LAN Subnet prefix from the RFC 3633 IA_PD
>  - using the timing specifications (30 second inter-update interval, 180 second dead interval) from RFC 2080
>  - periodically announcing a default route (2000::/3, which would be my thought, or ::/0).
> 
> In a network in which multiple LANs are present, and therefore multiple subnets, there must be a means to assign subnets from the IA_PD. One obvious approach is manual configuration; another requires a DHCP implementation that asks the ISP-facing router for a /64 for each of the other subnets. There are probably other approaches as well. The recommendation of an approach would be the province of another working group; we can ask either 6man or rtgwg for help with that.
> 
> 
> <aside>
> 
> I find myself reading through several sections of RFC 2080, and having some thoughts. The requirement, for example, is that each prefix that is going to be advertised be advertised every <inter-update interval>; the requirement is not that they all be announced in a burst. I have had the joy of maintaining RIP code that operated literally as specified ("Every 30 seconds, the RIPng process is awakened to send an unsolicited Response message, containing the complete routing table (see section 2.6 on Split Horizon), to every neighboring router."). In a network with a large number of routes, that's actually a profoundly bad idea. What you want to do is emit individual unsolicited Response messages roughly evenly spread in time (if I am putting 70 RTEs in an announcement and have a network with 2100 routes, I might emit a single unsolicited response message containing 70 prefixes every second). You want to emit a triggered update when you yourself lose an interface (poison all r
 ou
>  tes you had using the interface, and yes, do that in a burst) and when you receive an update that changes your own route table. When an interface comes up, you want to emit an all-routers multicast request for routes, and you emit a burst response to the unicast address when you receive such a request.
> 
> I also don't really recommend poison reverse as the default way to implement split horizon. You want to do a poison reverse on a triggered update when a route is lost, and repeat that during announcements in the hold-down period, but after that it's a waste of bandwidth and CPU cycles. In normal operation, send the live routes.
> 
> But then, what do I know?

I know that a single area OSPF configuration is simple,
zero-configuration with a basic initial and non-situation
specific configuration, handles the above scenario better, isn't CPU or
memory intensive anymore due to the effects of Moore's law unless it is
handling 1000s (if not 10s of 1000s) of routes, even for residential
CPE. I'd much prefer to see OSPF replace RIP as the chosen low-end
routing protocol in this day and age, in the least for it's much lower
convergence times.

I think the definition of zero-configuration for a routing protocol
is that it can determine or select necessary initial valid parameters
automatically (e.g. router-id, interface metrics), will discover
neighbors automatically and then trade routing information with them
without operator intervention, with a non-situation specific initial
bootstrap configuration. So pretty much all IGPs qualify, where as BGP
doesn't because it doesn't do automated neighbor discovery for good
reasons.

Regards,
Mark.