On Aug 17, 2010, at 9:14 AM, Mark Smith wrote:
> 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.
Actually, you are missing some major theory here due to code complexity.
Vendors have stats on defects per line of code, now take the following:
receive_packet_loop()
{
rx_pkt();
lookup_nh();
tx_pkt();
}
vs
router:
receive_packet_loop()
{
rx_pkt();
lookup_nh();
if (pkt.iif == pkt.oif) {
check_rate_limiters();
send_redirect();
}
pkt.ttl--;
tx_pkt();
}
host:
receive_packet_loop()
{
rx_pkt();
if (pkt.isredirect)
{
check_redirect_valid();
update_routing_table();
run_routing_table_aging();
}
}
You are introducing a lot of complexity to a system that honestly does not need
it.
>
> 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 can imagine cases where a transient network event would make
redirects useful, but if a user has HA requirements, their overall architecture
should incorporate these via some other process (eg: HSRP/VRRP/CARP).
> 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."
I certainly think it's better, but once again, we have experienced network
outages as a consequence of IPv6 redirects being silently enabled by default by
broken vendors implementations due to this further code complexity and load
placed upon the RE/RP.
Here's a sample (random, yeah right) router interface in our network facing a
host:
interface X
description BM: puck.nether.net - local wire
ip address 204.42.254.1 255.255.255.240
no ip redirects
no ip proxy-arp
ip pim bsr-border
ip pim sparse-mode
ip multicast boundary 62
ip route-cache same-interface
ip route-cache flow
logging event link-status
load-interval 30
no keepalive
speed 1000
duplex full
ipv6 address 2001:418:3F4::1/64
ipv6 enable
no ipv6 redirects
ipv6 nd suppress-ra
no mop enabled
hold-queue 3584 in
- Jared
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
