Hi Bill, |> It started with comments on for example "LOCs are constantly in flux?" | |For strategy B they fluctuate as renumbering (instead of rerouting) |resolves nearby link failures. For strategy H changes are more |planned.
OK, this is B & H as separate strategies. For me, H is not acceptable. I work on solutions for ad hoc networking. Ad hoc not equals planning. |> And that renumbering "consistently failed in the past". |> On both, I cannot agree. | |On that we'll have to agree to disagree. I have too much operations |experience to consider renumbering as implemented now and in the past |as anything but an unmitigated failure. OK, I agree that *current* IPv6 is not able to fulfill needs for automatic renumbering. But who said that the required enhancement is not part of the approach? I say solutions MUST support ingress filtering, as ingress filtering SHOULD be there. So it is part of the approach. You could specify so, if you want. It is already in Autoconf PS (6.1 R11) and RFC5220 (2.1.2). And supported by BRDP Based Routing. By the way, I think the firewall criticism applies to strategy A as well. In split load scenarios, firewalls see part of the traffic and would block flows. See also http://www.ietf.org/proceedings/08nov/slides/behave-14.pdf slide 31 for a problem description. Maybe approach B performs the best, as (transport) connections would be symmetric. |At any rate, that's why the comment is in the criticisms section. |Whether you consider it valid or not, past operational experience with |host-level renumbering will form a major criticism for strategies |based on host-level renumbering. Proponents of those strategies should |expect to say, "This is why it didn't work out in the past and here's |what we've done about that in our new protocol." Fully agree. This is why I put some cycles in BRDP / BRDP Based Routing. Teco. _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
