Hi Jared, On Mon, 16 Aug 2010 12:17:13 -0400 Jared Mauch <ja...@puck.nether.net> wrote:
> > On Aug 16, 2010, at 5:43 AM, Mark Smith wrote: > > > It seems to me that arguing against redirects is actually arguing for > > having a common case, rather than an transient one, of nodes that don't > > have full onlink prefix knowledge. I think having all nodes attached to > > the link (i.e. both hosts and routers) being fully aware of all onlink > > prefixes is a much better idea. > > Not really, it's about the role of a device in a network. > > If there are multiple subnets within a single broadcast domain that require > redirects to tell the hosts about what is on-link, it's much better to > actually configure your host correctly (or have it actively participate vs > passively via redirects) so they have knowledge of these additional subnets. > That's exactly what I was saying regarding having RAs announce all onlink prefixes, so that end-nodes are fully informed. > If you're for random slop on a link, then redirects may be helpful, but > that's not something that is architected well. I can't think of anyone that > actually would PLAN for that type of environment. Agree. I think of redirects as fixups during a transient situation, not a normal operational one. > Most cases I've seen it involve into a mess over time. Preventing a > mess and shifting the burden is what I'm speaking out about here. I suppose that comes down to whether networks should try to be tolerant to misconfiguration or not. I think the robustness principle suggests that networks should - "if there is a possibility it'll work, give it a try". > I've known many host guys who treat routers (and switches) as a "black box" > that gets their packets/frames there. Sending them messages about alternate > reachability of prefixes is useful in a trusted environment. Without > authenticating those messages (ie: speaking in an active IGP) it can quickly > become less useful noise and actually inhibit communication. > > All I've heard is that "someone might put two different subnets on the same > broadcast domain and want helper messages to make a better decision" vs > "redirects are REQUIRED to maintain reachability between end nodes". > > That is where I take issue with the tact being taken here. > I don't think that is the case. > Requiring that a router send and hosts listen to these messages introduces > complexities to the system. I can't get my vendors to produce stable router > software in 2010, let alone expect the diverse business-units within the > vendors to actually get this complexity right. However, how does lessening the requirements in RFCs cause vendors to increase the quality of their implementations? There aren't bugs in absent features. Bugs occur in features that haven't been implemented well. I think the best place to solve problems is where they're caused. Bad implementations usually aren't the fault of RFCs (unless the RFCs aren't good in the first place), they're the fault of the implementer, so at the implementer should be where they're fixed. If they don't want to do that, then they deserve appropriate consequences (loss of business, etc.) > Making something which I surely agree is a "nice to have" (due to > latency reduction and other various intrinsic benefits) a requirement > is shifting the burden and introducing complexity (to hosts and > routers) where it's not necessary. I think that's assuming that bandwidth in and out of a router's interface is high, such that the cost of constantly hair pinning traffic back onto the link it came from is cheaper than the cost of identifying when to send a redirect and sending one. That's usually the case on high speed LAN interfaces, but may not be in other environments. I agree that there are quite a number of cases where hair pinning is cheaper, however I don't think it is in all cases. I agree with the suggested text Brian Carpenter posted - "Redirect functionality SHOULD be supported. If the node is a router, Redirect functionality MUST be supported but MAY be disabled by default." Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
