Subject: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-def-01.txt

From: Brian Dickson <[email-masked]>
Date: Mon, 5 Mar 2012 19:31:23 -0500

Greetings, SIDR folks.

Here is the first of three IDs, concerning the definitions of "route leak".

Comments and feedback are encouraged.

Two sibling documents are also up (requirements and solutions), look for
similar messages in a minute.

Brian Dickson

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Mar 5, 2012 at 1:09 PM
Subject: New Version Notification for
draft-dickson-sidr-route-leak-def-01.txt
To: [email-masked]

A new version of I-D, draft-dickson-sidr-route-leak-def-01.txt has been
successfully submitted by Brian Dickson and posted to the IETF repository.

Filename:        draft-dickson-sidr-route-leak-def
Revision:        01
Title:           Route Leaks -- Definitions
Creation date:   2012-03-05
WG ID:           Individual Submission
Number of pages: 9

Abstract:
  The Border Gateway Protocol, version 4, (BGP4) provides the means to
  advertise reachability for IP prefixes.  This reachability
  information is propagated in a peer-to-peer topology.  Sometimes
  routes are announced to peers for which the local peering policy does
  not permit.  And sometimes routes are propagated indiscriminantly,
  once they have been accepted.

  This document considers the situations that can lead to routes being
  leaked, and tries to find acceptable definitions for describing these
  scenarios.

  The purpose of these definitions is to facilitate analysis of what a
  route leak is, and what the scope of the problem space for route
  leaks is.

  This, in turn, is intended to inform a requirements document for
  detection of (and prevention of) route leaks.  And finally, the
  definitions and requirements are intended to allow proposed solutions
  which meet these criteria, and to facilitate evaluation of proposed
  solutions.

  The fundamental objective is to &quot;solve the route leaks problem&quot;.

The IETF Secretariat

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 11 Mar 2012 17:36:44 -0400

Brian,

> Here is the first of three IDs, concerning the definitions of "route leak".

: 1.1. Rationale
: 
: 
:    A route-leak occurs when a prefix is originated by one party,
:    propagated by other parties, and received by the observer, where the
:    path used was not intentional end-to-end.  It is a leak if the
:    receiver did not want the route, from a generic policy perspective.

If the receiver didn't want the route?  While that's perhaps true in many
cases, the impacted party is usually someone whose route was distributed
outside the scope where they intended it to be distributed.

-- Jeff

---

From: Brian Dickson <[email-masked]>
Date: Sun, 11 Mar 2012 21:15:00 -0400

> outside the scope where they intended it to be distributed.

Yes, you are correct. We can expand the language however folks would prefer.

(But it is different from saying, "It is a leak _only_ if"... that was
definitely not the intention of the description.)

It should also be noted that, based on the definition(s), it would appear
to be a leak, to every recipient after it became a leak.

And, in most instances, it would also meet other leak-like criteria,
including intended scope.

The important thing is to reduce it to the smallest set of consistently
present conditions -- a basis, if you will -- to make it possible to build
rules into the protocol to stop leaks.

Brian