[GROW] , feedback, draft-evens-grow-bmp-adj-rib-out-01, draft-evens-grow-bmp-local-rib-00
<Thomas.Graf@swisscom.com> Wed, 16 August 2017 18:21 UTC
Return-Path: <Thomas.Graf@swisscom.com>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C43C1326A9 for <grow@ietfa.amsl.com>; Wed, 16 Aug 2017 11:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 jdoZScLFZAc6 for <grow@ietfa.amsl.com>; Wed, 16 Aug 2017 11:21:55 -0700 (PDT)
Received: from mail.swisscom.com (outmail110.swisscom.com [193.222.81.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B69113239A for <grow@ietf.org>; Wed, 16 Aug 2017 11:21:55 -0700 (PDT)
Received: by mail.swisscom.com; Wed, 16 Aug 2017 20:21:53 +0200
Date: Wed, 16 Aug 2017 18:21:50 +0000
From: Thomas.Graf@swisscom.com
To: grow@ietf.org
Message-ID: <808856199.7808618.1502907712964@ss002889.tauri.ch>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="----=_Part_7808616_2135661683.1502907712964"
X-Mailer: Totemo_TrustMail_(Notification)
Thread-Topic: [GROW], feedback, draft-evens-grow-bmp-adj-rib-out-01, draft-evens-grow-bmp-local-rib-00
Thread-Index: AdMWu3mQmJurc/uoR1uXpC/A/D2h9g==
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.57.23.41]
X-CFilter-Loop: Reflected
X-Trustmail: processed
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/Fgg3p05_W4QtHpRGY2tveCOJKQs>
Subject: [GROW] , feedback, draft-evens-grow-bmp-adj-rib-out-01, draft-evens-grow-bmp-local-rib-00
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 16 Aug 2017 18:21:58 -0000
Hi,
I would like to congratulate on these two drafts, share my opinions and our intention to use BMP local RIB and Adj RIB Out support as soon as it is available and look forward to test it.
We have BMP V3 and BGP VPNv4/VPNv6 eBGP peerings to MPLS PE routers from our collectors. We are using the Adj RIB out metrics, gathered by BGP VPNv4/VPNv6 eBGP peering, to correlate/aggregate with Netflow/IPFIX. The Adj RIB In metrics collected by BMP V3 are used for BGP control-plane visualization and troubleshooting purposes.
To correlate BGP VPNv4/6 with IPFIX IPv4/IPv6 VRF name (IPFIX element id 236, VRFname) we are currently using SNMP OID mplsL3VpnVrfRD(1.3.6.1.2.1.10.166.11.1.2.2.1.4).
To simplify the current collection setup we like to reduce from two peerings (BMP + BGP VPNv4/6) to BMP only and improve Netflow/IPFIX correlation by using BMP local RIB instead of Adj RIB out.
We are pleased to see that the collection of BGP route-distinguishers have been covered in section 5.1 and the VRF name in section 6.1.1. We expect that with this, we are able to correlate to the VRF name contained in the IPFIX template (IPFIX element id 236, VRFname). That would further simplify our current setup since we would not need SNMP anymore. Correct?
The only question raised when reading through the IETF grow-bmp-local-rib draft was, if it would make sense to include an additional information, such as if a route was filtered through a table-map/distribute-list/admin distance when imported from BGP local RIB to the RIB. This could be seen similar as a peer route-policy in the Adj RIB in/out.
This could be a useful additional information since one of the application is to correlate IPFIX with the RIB and the only differences between the BGP local RIB and RIB could be due table-map/distribute-list/admin distance filtering.
I hope this makes sense. Please correct me if I misunderstood something. Feedback very welcome.
kind regards
Thomas Graf
___________________________________________________________________________
Network Engineer
Cloud Connectivity Management
Phone +41 58 223 84 01
Mobile +41 79 728 80 12
thomas.graf@swisscom.com<mailto:thomas.graf@swisscom.com>
___________________________________________________________________________
Swisscom (Schweiz) AG
Binzring 17
CH-8045 Zürich
Switzerland
www.swisscom.ch<http://www.swisscom.ch>