Some comments below.
** Section 1, Introduction:
"On the other hand, the labeled
VPN routes are exchanged beween PE and PE, which could have been
monitored by BMP but are currently not implemented due to the massive
data exchange between the monitored devices and the BMP monitoring
station."
We support monitoring L3VPN and EVPN today in OpenBMP. For L3VPN, we normally
see similar loads (data exchanges) as monitoring full IPv4 tables. Can you
elaborate on how the L3VPN exchange is more than monitoring eBGP IPv4 transit
peering (full IPv4 RIB)? I normally measure the load by initial RIB dump and
then the incremental rate per NLRI. Currently, I see a typical IPv4 peer
(pre-policy) with an incremental load of 12 NLRI's per second on average.
** Section 2, Extension of BMP Peer Up Message:
"If the Information Type is VPN Label, allocated per interface per
label, the
Information field should include the VPN label (20 bits label and 4
bits zero
padding) and the corresponding interface address, with the total length
specified in the Information Length field. One label and one interface
address
is allowed for each Information TLV."
Which interface address?
"If the Information Type is VPN Label, allocated per route per label,
the
Information includes the VPN label (20 bits label and 4 bits zero
padding)
and the corresponding route prefix, with the total length specified in
the
Information Length field. The prefix should be in VPNv4 address format.
One label and one prefix is allowed for each Information TLV."
Isn't this forming a RIB now? Makes sense if it's peer or interface wide label
because that is at peer scope. Encoding prefixes becomes a RIB at this point.
Considering it's encoded in VPNv4 format, why not just encode this as a normal
update for that AFI/SAFI? My initial thoughts are to reuse the VPNv4 afi/safi
(or labeled unicast) BGP UPDATE message or create a new BMP type to encode VPN
label to prefix mappings.
If the Information Type is VPN Label, allocated per next hop per label, the
Information should include the VPN label (20 bits label and 4 bits zero
padding) and the corresponding next hop address, with the total length
specified in the Information Length field. One label and one next hop address
is allowed for each Information TLV.
This is also a RIB, but a rib of next-hops with associated labels, right?
IMHO, encoding this as labeled unicast or as a new BMP type might make more
sense.
** Section 3, Operation:
I believe this is also the same use-case used for egress peer
engineering/segment-routing. We do have a method to collect this today using
https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-15 and
https://tools.ietf.org/html/draft-gredler-idr-bgplu-epe-11 . Do you have some
other examples for the other types proposed?
In general, as I understand this draft, it is a method to convey single label
to X mappings (e.g label RIB). Where X is either peer, vrf, interface,
route/prefix, next-hop, etc. I'm leaning more towards a new BMP type instead
of trying to convey this in peer up informational TLV's. The original RFC7854
draft doesn't completely define how to handle PEER UP's in terms of when to
expect a new RIB dump or not. Currently, a new peer up can indicate that we
should set all previous NLRI's as withdrawn and to expect a new RIB dump.
Overloading the PEER UP to convey label mappings could complicate this.
The peer level labels might have overlap with egress peer engineering
(https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-15).
Thanks,
Tim
On 7/2/18, 7:00 PM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology
Research Dept. NW)" <[email protected] on behalf of [email protected]>
wrote:
Hi all,
We have uploaded two drafts on BMP extensions.
"draft-gu-grow-bmp-vpn-label" proposes the idea of using BMP to collect VPN
labels for applications such as traffic optimization.
"draft-zhuang-grow-monitoring-bgp-parameters" proposes to use BMP to
collect BGP parameters: capacity and default behavior. The capacity parameters
(both enabled and not enabled) are reported to the BMP server for better
network optimization. The default behavior parameters, such as vendor-specific
protocol preferences, are reported for multi-vendor interoperation.
Comments and suggestions are welcome!
Thanks!
Yunan
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: 2018年7月2日 16:05
To: Lizhenbin <[email protected]>; Mipenghui (Kevin Mi)
<[email protected]>; Jie Chen <[email protected]>; Zhuangshunwan
<[email protected]>; Guyunan (Yunan Gu, IP Technology Research Dept. NW)
<[email protected]>; [email protected] <[email protected]>
Subject: New Version Notification for draft-gu-grow-bmp-vpn-label-00.txt
A new version of I-D, draft-gu-grow-bmp-vpn-label-00.txt
has been successfully submitted by Yunan Gu and posted to the IETF
repository.
Name: draft-gu-grow-bmp-vpn-label
Revision: 00
Title: VPN Label Monitoring Using BMP
Document date: 2018-07-02
Group: Individual Submission
Pages: 8
URL:
https://www.ietf.org/internet-drafts/draft-gu-grow-bmp-vpn-label-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gu-grow-bmp-vpn-label/
Htmlized: https://tools.ietf.org/html/draft-gu-grow-bmp-vpn-label-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-vpn-label
Abstract:
The BGP Monitoring Protocol (BMP) is designed to monitor BGP running
status, such as BGP peer relationship establishment and termination
and route updates. This document provides a method of collecting the
VPN label using BMP, as well as an implementation example.
-------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------
Name: draft-zhuang-grow-monitoring-bgp-parameters
Revision: 00
Title: Monitoring BGP Parameters Using BMP
Document date: 2018-07-02
Group: Individual Submission
Pages: 7
URL:
https://www.ietf.org/internet-drafts/draft-zhuang-grow-monitoring-bgp-parameters-00.txt
Status:
https://datatracker.ietf.org/doc/draft-zhuang-grow-monitoring-bgp-parameters/
Htmlized:
https://tools.ietf.org/html/draft-zhuang-grow-monitoring-bgp-parameters-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-zhuang-grow-monitoring-bgp-parameters
Abstract:
The BGP Monitoring Protocol (BMP) [RFC7854] is designed to monitor
BGP [RFC4271] running status, such as BGP peer relationship
establishment and termination and route updates. Without BMP, manual
query is required if you want to know about BGP running status.
This document provides the use cases that the BMP station can get the
optional and default configure parameters of the monitored network
device via BMP.
Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
