On Oct 2, 2012, at 5:23 PM, Russ White <[email protected]> wrote: >>> >>> - Path information is lost. While this doesn't impact loop prevention, this >>> information is operationally useful. >> >> +1. Reachability data optimisation is highly desirable and may one day be >> necessary, but this is one of the wrong places to do it. > > Again, I'm a bit baffled. Can you explain how this draft actually > removes reachability optimization in the DFZ? It's carefully crafted NOT > to remove any reachability information that produces a shorter path. > > I know the chairs have already (short sightedly, IMHO), decided not to > accept this draft as a WG item, but I'd really like to understand what > specific situation you can draw up where the proposed mechanism > increases the stretch in any path.
Russ, The problem as I see it is many of those that operate in the BGP/DFZ don't know what they are doing. This makes solving these problems infinitely more complex compared to how they should be if everyone was sane. 58.64.162.0/24 2497 701 6453 45474 174 17444 is a great example for me and easily observed (even if just as a transitory announcement). I see this in my router, but the above leaked out... *>i58.64.160.0/19 x.x.x.x 120 0 17444 17444 17444 17444 17444 17444 17444 i Not only did the above route look disgusting for the as_path, but there should have been some better covering prefixes appear perhaps? Anyways, you can't make people route sanely and the ISPs have a hard time rejecting the money people want to pay for the extra flexibility. - Jared _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
