Jared: On 10/2/12 6:44 PM, "Jared Mauch" <[email protected]> wrote:
> >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. I agree. Which is why our proposal is optional; if you want to do it, you can enable itŠas you can manually filter blocks of routes today or make all the exceptions you want (or are paid for). For the example above, we do need to better articulate the "rules" around checking the AS_PATH before making a decision. Thanks! Alvaro. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
