Hi All, On Wed, Jun 08, 2016 at 08:48:11AM -0400, Joe Provo wrote:
On Wed, Jun 08, 2016 at 11:48:36AM +0000, Sriram, Kotikalapudi (Fed) wrote:
Thanks for the inputs about the inter-AS messaging and route-leak prevention techniques between neighboring ASes. Certainly helpful information and also useful for the draft (draft-ietf-idr-route-leak-detection-mitigation).
However, my question was focused on "intra-AS" messaging. About conveying from ingress to egress router (within your AS), the info regarding the type of peer from which the route was received at ingress. This info is used at the egress router to avoid leaking a route.
Question: Is the "common practice" described in the original message http://mailman.nanog.org/pipermail/nanog/2016-June/086242.html (see the stuff in quotes) sufficient or are there other ways in common use in which network operators convey the said information from ingress to egress router?
But in my experience, community tagging is by far the widest deployment due to the broad support and extent of information which can be carried.
I second this. One of NTT's design principles is to be very strict in what we accept (e.g. "postel was wrong") at the ingress point. At the ingress point the route announcement is weighted, judged, categorized & tagged. This decides 99% of what happens next: the egress points are merely executing what was "decided" at ingress (but exceptions are possible).
It is useful to note that AS_PATH if often also involved on egress decisions.
You say 'often', but I don't recognise that design pattern from my own experience. A weakness with the egress point (in context of route leak prevention) is that if you are filtering there, its already too late. If you are trying to prevent route leaks on egress, you have already accepted the leaked routes somewhere, and those leaked routes are best path somewhere in your network, which means you've lost. Having said that: as a conscious effort to mitigate (known) fragility in one's 'ingress policy deployment' an egress AS_PATH filter might be a good second layer of defense. It doesn't protect your own network but it helps block further spreading of garbage. Kind regards, Job