Hi, Robert, The problem being solved is, that the current methodology places the entire onus on not allowing route leaks, on the immediate upstream provider - who may be small and inexperienced.
What is being solved, in particular, is the ability to identify and block route-leaks when one is _more_ than one AS-hop away from the leak, in a guaranteed fashion. Blocking, or even noticing, route leaks via one's peers, can be difficult (or nearly impossible) today. Best practices are good, but consider the level of adoption of BCP-38. Clearly, best practices are not good enough, or we wouldn't have any interest in the "route leak" problem. Reducing the best practice to a "pick one of these four settings (and don't use #4 unless you REALLY know what you are doing)", is a deliberate choice. Make it easy. And, for the most part, the party benefiting significantly, is the person _using_ that setting. Route leaks _hurt_ the leaker/leakee probably as much or more than anyone else. If route filters are seat-belts, then this is an air-bag. Either is good, both is best. Especially when used. Brian On Mon, Mar 19, 2012 at 6:42 PM, Robert Raszuk <rob...@raszuk.net> wrote: > Hi Brian, > > > The desired outcome is that sender/receiver _negotiate_ what is or is not >> to be sent, >> and the protocol merely enforces what has been agreed upon. The automatic >> enforcement >> of this high-level policy, is what stops route leaks from being initiated >> or propagated. >> The policy is still determined by the operators at both ends of a peering >> session. >> Just like the IP addresses and ASNs, the policies have to match for BGP >> session establishment. >> Unilateral misconfiguration (whether by accident or deliberate act), >> which could have introduced >> or propagated route leaks, are prevented. >> > > I have read your drafts reg route leaks however I would like to clarify > one very basic question. > > When any provider creates a BGP peering relation to his customer it is a > common best practice among most if not all ISPs that there is a strict BGP > policy applied over the session to make sure only legitimate customer > blocks are advertised. > > If such policy would be required to be share one could use prefix ORF. > > With this in mind I am really not clear what practical vs theoretical > problems you are attempting to solve ? > > Best regards, > R. > >
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
