Hi, here are a few comments about section 3.1 in the draft:
Other than the missing comma in the list of routers/ASes, near the end there is talk about a route leak. However, I don't think what's stated here as a route leak is what's commonly understood to be a route leak. I think a route leak is commonly understood to be when a route is announced to a neighbor in violation of the (intended) routing policy, i.e. a route leak can be the result of an erroneously implemented intended routing policy. I can't see how that's the case here, because no routing policy has been expressed for "I". This probably means that "I" re-advertises all routes it receives, from any edge on any other edge, and therefore by definition can't have a "route leak". It's another matter that the traffic pattern from B to J in the stated scenario involves a change to a path which traverses I. If we instead of "thinking BGP" in the drawing in 3.1, suppose we think "RIP with max metric 64" instead. Of course when you adjust metrics on any interface in the topology, traffic flows will shift around. I can't quite understand when we do the similar thing in BGP it's such a big problem? Admittedly, by prepending outgoing route announcements towards a given peer, you only affect "one end of the link", and there's a fair chance that asymmetric traffic patterns will result if that's the only thing which is done. But... Is that a problem? I think the problem desribed in section 3.1 could do with a bit clearer description of why this is problematical. Regards, - Håvard _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
