Re: [Idr] [GROW] I-D Action:draft-ietf-grow-bmp-05.txt

Robert Raszuk <raszuk@cisco.com> Wed, 15 December 2010 23:24 UTC

Return-Path: <raszuk@cisco.com>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DADE128C0EB; Wed, 15 Dec 2010 15:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES226sR4mO1f; Wed, 15 Dec 2010 15:24:37 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 87FFE28C0EF; Wed, 15 Dec 2010 15:24:37 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArIFAN/cCE1AZnwM/2dsb2JhbACWBI4tc6cSgk4OAZh7hUoEinuDFg
X-IronPort-AV: E=Sophos;i="4.59,351,1288569600"; d="scan'208";a="193601851"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Dec 2010 23:26:18 +0000
Received: from [192.168.1.61] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oBFNQHDg014328; Wed, 15 Dec 2010 23:26:18 GMT
Message-ID: <4D094EA3.9040407@cisco.com>
Date: Thu, 16 Dec 2010 00:26:27 +0100
From: Robert Raszuk <raszuk@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: grow@ietf.org
References: <20101215221502.31105.54307.idtracker@localhost>
In-Reply-To: <20101215221502.31105.54307.idtracker@localhost>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>
Subject: Re: [Idr] [GROW] I-D Action:draft-ietf-grow-bmp-05.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@cisco.com
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Dec 2010 23:24:48 -0000

John at all,

> 	Title           : BGP Monitoring Protocol
> 	Author(s)       : J. Scudder, et al.
> 	Filename        : draft-ietf-grow-bmp-05.txt
> 	Pages           : 16
> 	Date            : 2010-12-15

If I remember correctly the fundamental reason for bmp was to provide a 
very simple mechanism for replaying content of received updates from the 
peers as well as provide some form of signaling reg their state 
transition. That goal was great.

Unfortunately version -01 and above moved away from this and simplified 
the requirement to reply/send content of Adj_RIB_In instead of those 
coming updates from the peers.

So we are effectively loosing the most crucial part of the original 
proposal as we no longer be able to pass to some observatory linux 
station those prefixes which were dropped on inbound or worse any 
potential malformed updates or attributes if they were not stored in the 
RIB_In.

I think it defeats a lot of use cases. Perhaps this subtle difference 
should be discussed more before we proceed any further with this document.

Many thx,
R.