On Aug 27, 2012, at 10:43 AM, Noel Chiappa wrote: >> From: Nick Hilliard <[email protected]> > >>> Overall, then, it is desirable to remove overlapping routes from the >>> global routing table where possible. > >> People inject prefixes into the DFZ for specific reasons. If they are >> pruned by some upstream providers but not others, then the traffic >> engineering model is broken because you can no longer depend on >> more-specifics having visibility around the dfz. > > Doing traffic engineering by injecting more-specifics into the global > destination-vector routing is a top pick on my list of 'optimal illustration > for hammer-nail syndrome'. So if we break that approach, that's not a bug, > that's a feature.
Sez you -- but there are a large number of folk that are currently doing this, and doing this for a reason, and will no doubt be very surprised when it suddenly stops working… Removing their ability to use this "feature" because it violates your (and to honest, my) views of elegance seems, um, impolite at best. > > Of course, doing traffic engineering 'right' would involve getting rid of > this archaic, creaky destination-vector routing architecture, and that is > going to be a huge project. > Yup. > But in the meantime, there are approaches that are create slightly less > overhead for everyone in the entire system: e.g. using the identity/location > binding layer - there are several choices available at the moment. Deployed ones? That I can actually use, now? > They're > just as ugly (architecturally), but at least fewer entities have to bear the > overhead costs (which are less in toto, too). W > > Noel > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > -- What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?" -- (Terry Pratchett, Pyramids) _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
