[sidr] Injecting idea of "freshness of repository data" into BGP

Jeffrey Haas <jhaas@pfrc.org> Wed, 28 March 2012 08:19 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8163A21F88EB for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 01:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.152
X-Spam-Status: No, score=-102.152 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ms+AZAGsXNOp for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 01:19:40 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org []) by ietfa.amsl.com (Postfix) with ESMTP id D991621F88E6 for <sidr@ietf.org>; Wed, 28 Mar 2012 01:19:39 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 8C9241703C8; Wed, 28 Mar 2012 04:19:39 -0400 (EDT)
Date: Wed, 28 Mar 2012 04:19:39 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: sidr@ietf.org
Message-ID: <20120328081939.GA19843@slice>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [sidr] Injecting idea of "freshness of repository data" into BGP
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2012 08:19:40 -0000

Per my mic comment at IETF 83:
During the San Diego interim session we had discussed potentially signaling
in BGP the idea that a given AS may have fresher data available in its

My original thought had been something along the lines of a new AFI/SAFI
that contains this data.  Matt L., in discussing this point at the mic with
me, suggested something that has resemblence to the serial number field in
DNS.  For example, this field could go into the "reserved" field that a
route originator puts into the signature.  If the serial number increases,
this could suggest that fresher information is present in that originator's

Discussion around this mechanism:
- If this is part of a given route's signature block, the issue is that a
  given origin may be seen with a number of serial numbers  depending on
  propagation of BGP routes.
- Such a serial number is important not only for the originator of a route,
  but also all parties participating in the signature.
  This particular details suggests to me that such signaling probably should
  be separate from the signatures.
- By being part of the signature, we get some level of freshness in things
  in a route-by-route basis and less likely that a completely separate
  "route" that is repository freshness is dropped.

-- Jeff