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, . [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, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . 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, . 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]