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. This is definitely not true in enterprise networks. We have other ways of doing this in a more general fashion such as RFC4191 "Default Router Preferences and More-Specific Routes". 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. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
