Internet DRAFT - draft-gu-grow-bmp-vpn-label
draft-gu-grow-bmp-vpn-label
Network Working Group Y. Gu
Internet-Draft Huawei
Intended status: Standards Track J. Chen
Expires: January 3, 2019 Tencent
P. Mi
S. Zhuang
Z. Li
Huawei
July 02, 2018
VPN Label Monitoring Using BMP
draft-gu-grow-bmp-vpn-label-00
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.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019.
Gu, et al. Expires January 3, 2019 [Page 1]
Internet-Draft VPN Label Monitoring July 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Extension of BMP Peer Up Message . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The Border Gateway Protocol (BGP) [RFC4271], as an inter-Autonomous
(AS) routing protocol, is used to exchange network reachability
information between BGP systems. Later on, [RFC4760] extends BGP to
carry not only the routing information for BGP, but also for multiple
Network Layer protocols (e.g., IPv6, Multicast, etc.), known as the
MP-BGP (Multiprotocol BGP). The MP-BGP is currently widely deployed
in case of MPLS L3VPN, to exchange VPN labels learned for the routes
from the customer sites over the MPLS network.
The BGP Monitoring Protocol (BMP) [RFC7854] has been proposed around
2006 to monitor the BGP routing information, which includes the
monitoring of BGP peer status, BGP route update, and BGP route
statistics. BMP is realized through setting up the TCP session
between the monitored BGP device and the BMP monitoring station, and
then periodic/event-triggerred messages are sent unidirectionaly from
the monitored device to the BMP monitoring station. Before BMP was
introduced, such information could be only obtained through manual
query, such as screen scraping. The introduction of BMP greatly
improves the BGP routing monitoring efficiency without interrupting
or interfering the ongoing services.
Gu, et al. Expires January 3, 2019 [Page 2]
Internet-Draft VPN Label Monitoring July 2018
Currently, BMP is mainly utilized to monitor the public BGP routes.
There are also cases that the VPN (Virtual Private Network) route/
label information is needed. For example, for the purpose of Traffic
Engineering (TE), the network operator may insert explicit routes,
subject to certain constraints or optimization ceriteria, into
related routers with high local preferences so that these routes will
be selected and installed into the routing table. Under the VPN
environment, the VPN route labels should be collected from the
devices, and be distributed back jointly with the explicit routes to
the devices, so that the devices can use the VPN labels to correlate
the received routes with the approriate VRFs (VPN Routing and
Forwarding tables). The collection and distribution of such labels
could be done by an SDN (Software Defined Network) controller, or an
route monitoring station equipped with the traffic optimization
module.
The VPN routes between CE (Customer Edge) and PE (Provider Edge) can
be monitored by BMP using the "RD Instance Peer Type". However, such
VPN routes between CE and PE do not include the VPN labels, since
labels are allocated at the PE side. 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. An existing method to collect the VPN route label,
considering the L3VPN scenario, is by setting up BGP VPNv4 peering
relationship between the monitored device and the monitoring station/
controller. The label information is then extracted from the
collected VPN-IPv4 routes, carried by the BGP NLRI (Network Layer
Reachability Information). However, there are several shortcomings
of collecting the VPN label using this method.
o The VPN labels, instead of the VPNv4 routes, are the necessary
information for fulfilling the traffic optimization purpose.
Thus, extracting the label from the VPNv4 route requires extra
work compared with directly collecting the label information
alone.
o The same VPN label is sometims used for several VPNv4 routes.
Depending on the implementation scenarios, there are typically
different ways of allocating the VPN route labels: per route per
label, per VRF per label, per interface per label, and so on. For
example, in the Multi-AS VPN case, the redistribution of labeled
VPN-IPv4 routes from one AS to another can be realized through
setting up the EBGP peering between ASBRs (Autonomous System
Border Routers) of different ASes. In this case, the per route
per label allocation method is preferred. However, per route per
label allocation can be very consuming as for the label space,
thus, in many cases the per VRF per label allocation is adopted.
Gu, et al. Expires January 3, 2019 [Page 3]
Internet-Draft VPN Label Monitoring July 2018
As a result, repeatedly reporting the same label for several
routes wastes network resources.
o The VPN label changes are typically less dynamic compared with the
time-varying VPNv4 routes. Thus, acquiring the label information
through the real-time monitoring of VPNv4 routes is not quite
necessary.
All in all, it's more efficient to collect the VPN label
independently than extracting it from the collected VPNv4 routes. In
this document, we propose a method to utilize BMP to monitor the VPN
label. In Section 2, the VPN label is defined to be encapsulated in
the BMP Peer Up Notification message, and in Section 3, a specific
implementation example is provided to show case the usage of the
collected VPN label.
2. Extension of BMP Peer Up Message
The Peer Up message of BMP, defined in [RFC7854], is used to indicate
the come-up of a peering session. The VPN route label can be carried
in the Peer Up message and reported to the BMP monitoring station in
the TLV format. The Information TLV defined in [RFC7854] can be used
to encode the label, and new Information Types are defined. Each
Information TLV contains at most one label, and one or more
Information TLVs can be included in the Peer Up Notification when
necessary.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Information Type | Information Length |
+-------------------------------+-------------------------------+
+ Information (variable) +
~ ~
+---------------------------------------------------------------+
o Information Type (2 bytes): indicates the type of the Inoformation
TLV. Depending on the label allocation method, the following new
types are defined:
* Type = TBD1: VPN Label, allocated per VRF per label.
* Type = TBD2: VPN Label, allocated per interface per label.
* Type = TBD3: VPN Label, allocated per route per label.
* Type = TBD4: VPN Label, allocated per next hop per label.
Gu, et al. Expires January 3, 2019 [Page 4]
Internet-Draft VPN Label Monitoring July 2018
o Information Length (2 bytes): indicates the length of the
following Inforamtion field, in bytes.
o Information (variable): specifies the Label information according
to the Information Type.
* If the Information Type is VPN Label, allocated per VRF per
label, the Information field should be the VPN label (20 bits),
padded with zeros to 24 bits (3 bytes). The corresponding
Length field should be set to 3.
* 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.
* 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.
* 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.
Considering the per VRF per label allocation, instead of extracting
this same label information from all the monitored VPNv4 routes, it
an be reported only once to save both device and network resources.
Similarly, for the per interface per label and per next hop per
label, label reporting frequencies can be reduced compared with the
VPNv4 routes minotoring. Even for the per route per label case,
reporting only the label information can be immune from the update of
route changes, and reduce the reported information size.
3. Operation
In this section, we use an example of traffic optimization
applicaiton to more specifically explain how the BMP VPN label
collection functions. An Internet content provider (ICP) may own a
Backbone network as the DCI (Data Center Interconnection) and
Internet access solutions. Such backbone network may implement
Gu, et al. Expires January 3, 2019 [Page 5]
Internet-Draft VPN Label Monitoring July 2018
different VPNs as the bearer networks for different services, and the
granularity depends on specific service requirement. Each VPN,
piggybacking on the backbone network, may connect to the Internet
through other ISPs' (Internet Service Providers') networks.
Different Internet Exchange (IX) devices are deployed for the
Internet traffic exchange between the ICP and different ISPs.
Suppose two ISPs are considered in this example, ISP A and ISP B, as
shown in the following figure.The ICP backbone network, implements
VPN 1 for a specific service. This VPN exchanges Internet traffic
with ISP A and ISP B through IX device A and IX device B,
respetively. Prefixes are advertised from ISP A (considered as CE A
of VPN 1) and ISP B (CE B) to the IX A (PE A) and IX B (PE B),
repectively. Consider the case that ISP B advertises a more specific
prefix (20.1.128.0/17) than ISP A (20.1.0.0/16). Both routes would
be learnt by the PE devices of VPN 1, and be installed on both PE A's
and PE B's routing tables. Now suppose there's a packet with
destination 20.1.128.1, then according to the Longest prefix match
(LPM) rule, PE B will be used as the ICP's exit for this packet.
Similarly, more traffic with such prefixes may choose to exit the ICP
to other ISPs through PE B, while PE A is lightly burdened, which
leads to unbalanced traffic load and even traffic congestion at PE B.
+---------+ +---------------------+
| ISP A | 20.1.0.0/16 +----+ |
| | +-------------> |IX A| |
+---------+ +-+--+ |
| |
| ICP VPN 1 |
| |
| |
+---------+ 20.1.128.0/17 +-+--+ |
| ISP B | +-------------> |IX B| |
| | +----+ |
+---------+ +---------------------+
The above mentioned issue can be solved as follows. Through traffic
monitoring, the SDN controller can reoptimize the traffic load
through explicit routes installation into PE A and PE B. The Next
Hop field is indicated explicitly by the controller for the routes
that need to be adjusted. For example, for the destination prefix
20.1.128.1, its next hop in the explicit route sent to PE A is set to
the router's address in ISP A, while the next hop in the explicit
route sent to PE B is set to PE A. Simutainiously, BMP is used to
collect VPN 1's route labels from PE A (Label: 1000) and PE B (Label:
2000). Assume in this example, the labels are allocated per VRF per
label, then Label 1000 is the label allocated to PE A for VRF 1, and
Label 2000 is the label allocated to PE B for VRF 1. The explicit
Gu, et al. Expires January 3, 2019 [Page 6]
Internet-Draft VPN Label Monitoring July 2018
routes distributed to PE A and PE B are specified in the following
figures, respectively. After receiving the explicit route, PE A/B
may use the label information to correlate the route to the correct
VRF and then install it into VRF 1. Thus, part of the traffic may
exit VPN 1 through PE A to balance the traffic load.
+-------------------------+-------+-------------+
|Dest. Addr./Mask| NH | Label | Local Pref. |
+-----------------------------------------------+
| 20.1.128.0/17 | ISP A | 1000 | 200 |
+----------------+--------+-------+--------------
+-------------------------+-------+-------------+
|Dest. Addr./Mask| NH | Label | Local Pref. |
+-----------------------------------------------+
| 20.1.128.0/17 | PE A | 1000 | 200 |
+----------------+--------+-------+--------------
4. Acknowledgements
TBD.
5. IANA Considerations
TBD.
6. Security Considerations
TBD.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
Gu, et al. Expires January 3, 2019 [Page 7]
Internet-Draft VPN Label Monitoring July 2018
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>.
Authors' Addresses
Yunan Gu
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: guyunan@huawei.com
Jie Chen
Tencent
Email: jasonjchen@tencent.com
Penghui Mi
Huawei
Shenzhen, Guangdong
China
Email: mipenghui@huawei.com
Shunwan Zhuang
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Zhenbin Li
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Gu, et al. Expires January 3, 2019 [Page 8]
