Re: [GROW] Benoit Claise's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)

Rob Shakir <rjs@rob.sh> Mon, 26 October 2015 00:49 UTC

Return-Path: <rjs@rob.sh>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1E91B342A; Sun, 25 Oct 2015 17:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.009
X-Spam-Level:
X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qu1-2JyrhWEV; Sun, 25 Oct 2015 17:49:35 -0700 (PDT)
Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E861B3427; Sun, 25 Oct 2015 17:49:34 -0700 (PDT)
Received: from [2601:681:201:5165:618b:914e:c6fc:2228] by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <rjs@rob.sh>) id 1ZqVyL-0004xO-9g; Mon, 26 Oct 2015 00:49:13 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail-EDA02C49-7B4C-44F2-904D-47797FFE955D"
Mime-Version: 1.0 (1.0)
From: Rob Shakir <rjs@rob.sh>
X-Mailer: iPhone Mail (13B143)
In-Reply-To: <1684AD66-D70F-4C9B-A82C-E5E898C451B3@gmail.com>
Date: Sun, 25 Oct 2015 18:49:27 -0600
Content-Transfer-Encoding: 7bit
Message-Id: <BF261938-D623-4553-A0DA-5EABBC0D00C6@rob.sh>
References: <20151015101026.11100.83526.idtracker@ietfa.amsl.com> <953F2D54-DD79-4B2F-B182-0D15E3E51F9C@juniper.net> <etPan.56240542.7b6a3110.f1d3@corretto.rob.sh> <20151019194855.GH15569@pfrc.org> <562A0C38.5010304@cisco.com> <20151023143543.GB26793@pfrc.org> <E9A13432-5CD2-46D5-BF37-2C3D36E27E2C@rob.sh> <1684AD66-D70F-4C9B-A82C-E5E898C451B3@gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/grow/2AcAiRGzWSXmLhzKj0LjT_Q9eV8>
Cc: draft-ietf-grow-bmp@ietf.org, grow-chairs@ietf.org, grow@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-idr-bgp-model@ietf.org
Subject: Re: [GROW] Benoit Claise's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2015 00:49:37 -0000


> On Oct 24, 2015, at 22:48, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> 
> 
>>> On Oct 23, 2015, at 7:41 AM, Rob Shakir <rjs@rob.sh> wrote:
>>> 
>>> To tie this all back together, BMP yang state can be correlated to BGP
>>> operational state.  Where it isn't, the message contents can be.
>> 
>> Agreed, given that BMP will simply transmit the PDU, the only requirement this raises for a YANG BGP RIB model (such that the two can be correlated) is to use the same encoding that is used in existing messages for attributes of a BGP message.
> 
> I had a slightly different question, and comes from my lack of complete understanding of BMP.
> 
> I understand that the operational model for monitoring BGP RIB data is not quite there in either the IDR or the openconfig YANG model. But if we agree that there could be a single YANG BGP RIB model, then is it possible that information carried by BMP could be transmitted say as part of a NETCONF/RESTCONF notification? Or is there something specific about the information that is being transmitted or how it is being transmitted that is BMP specific?

Yes and no. As Jeff indicated BMP is a lot more raw than having entirely parsed the contents of a message. 

Also, BMP is implemented and running today. We need to give operators tools that are useful now - and nailing down the BMP spec is one of the ways we do that. If it is replaced at a later date by some new streamed update relating to the RIB model is something that future implementors and users will decide. 

Cheers,
r. 

> 
> Mahesh Jethanandani
> mjethanandani@gmail.com
> 
> 
> 
> 
>