Network Working Group H. Ni Internet-Draft S. Zhuang Intended status: Standards Track Z. Li Expires: August 17, 2014 Huawei Technologies February 13, 2014 BGP Extensions for Service-Driven Co-Routed MPLS Traffic Engineering LSP draft-ni-l3vpn-bgp-ext-sd-co-lsp-01 Abstract In some large scale L3VPN deployment scenarios like mobile backhaul network, it is required that tunnels between two PEs could be setup automatically driven by L3VPN service to reduce manual configuration effort. Moreover the tunnels must be setup co-routed for the goodness of performance monitoring and uniform protection behavior for link failure on two directions. This is described in [I-D.li- mpls-serv-driven-co-lsp-fmwk]. This document introduces a new BGP VT route based on [I-D.ni-bgp-ext-l3vpn-pm]. The route is utilized by on side PE to advertise Tunnel ID to other side PE, so inverse direction co-routed LSPs can be setup based on path information of member LSPs in the first tunnel. 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 http://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 August 17, 2014. Ni, et al. Expires August 17, 2014 [Page 1] Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014 Copyright Notice Copyright (c) 2014 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 (http://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. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 3. VT Tunnel-ID Signal Route Definition . . . . . . . . . . . . 3 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Active/Passive PE Selection . . . . . . . . . . . . . . . 6 4.2. VPN Membership Auto Discovery . . . . . . . . . . . . . . 6 4.3. Active PE Advertise VT Tunnel-ID Signal Route . . . . . . 6 4.4. Passive PE advertise Tunnel ID to Active PE . . . . . . . 7 4.5. VT Tunnel-ID Signal Route Application . . . . . . . . . . 7 5. VT Tunnel-ID Signal Route Selection Consideration . . . . . . 8 6. Deployment Consideration . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction In some large scale L3VPN deployment scenarios like mobile backhaul network, it is required that LSPs between two PEs could be setup automatically driven by L3VPN service to reduce manual configuration effort and the LSPs must be setup co-routed for the goodness of performance monitoring and uniform protection behavior under link failure, which is in detail described in [I-D.li-mpls-serv-driven- co-lsp-fmwk]. This document introduces a new BGP Tunnel-ID Signal Route under VT SAFI([I-D.ni-bgp-ext-l3vpn-pm]). After VPN-membership discovered one PE can use the route to proactively advertise one direction MPLS TE Tunnel ID to remote PE, the latter can setup inverse direction co- routed LSPs based on path information of member LSPs of the first Ni, et al. Expires August 17, 2014 [Page 2] Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014 tunnel. For RSVP-TE type LSP, the path information could be got from RRO naturally. The extension is based on VT SAFI defined in [I-D.ni-l3vpn-ext-l3vpn- pm]. Type 1(VT VPN Membership A-D Route) is utilized to support VPN- membership auto-discovery between a pair of VRFs. A new Type 3 VT Route, namely VT Tunnel-ID Signal Route, is defined in this document. 2. Terminologies This document uses the terminologies defined in [RFC3031], [RFC3209], [RFC4026] and [I-D.ni-l3vpn-ext-l3vpn-pm]. ERT: Export Route Target IRT: Import Route Target LSP: Label Switched Path LSR: Label Switching Router MPLS: Multi Protocol Label Switching PE: Provider Edge Router in BGP/MPLS VPN RRO: Record Route Object RSVP-TE: Traffic Engineering Extensions of RSVP VT: VRF-to-VRF Tunnel 3. VT Tunnel-ID Signal Route Definition VT Tunnel-ID Signal Route defined as Type 3 Route under BGP VT NLRI +----------------------------------------------+ | Route Type (1 octet) | +----------------------------------------------+ | Length (1 octet) | +----------------------------------------------+ | Route Type Specific (Variable) | +----------------------------------------------+ Figure 1 IPv4 VT-Family NLRI Ni, et al. Expires August 17, 2014 [Page 3] Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014 a) Route Type: Type 3: indicates VT Tunnel-ID Signal Route b) Length indicates Route Type Specific field's length in octets c) Route Type specific contains VT Tunnel-ID Signal Route information, encoded as following diagram. +----------------------------------------------+ | Local VRF's RD (8 octets) | +----------------------------------------------+ | Local Router's IP Address | +----------------------------------------------+ | Remote VRF's RD (8 octets) | +----------------------------------------------+ | Remote Router's IP Address | +----------------------------------------------+ | Tunnel Type (1 octet) | +----------------------------------------------+ | Flags (1 octet) | +----------------------------------------------+ | Tunnel ID (variable) | +----------------------------------------------+ Figure 2 VT VRF-to-VRF Tunnel-ID Signal Route Format a) Local VRF's RD Route Distinguisher of one VRF on advertising PE encoded as [RFC4364] definition. b) Local Router's IP Address: Advertising PE's IPv4/IPv6 address. c) Remote VRF's RD Route Distinguisher of one VRF on Receiving PE encoded as [RFC4364] definition. d) Remote Router's IP Address: Receiving PE's IPv4/IPv6 address. e) Tunnel Type: Indicates type of tunnel Type 0: RESERVED Type 1: RSVP-TE Tunnel Type other: To be defined later if necessary f) Flags: 8-bits Flags Ni, et al. Expires August 17, 2014 [Page 4] Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | reserved |R| +-+-+-+-+-+-+-+-+ Figure 3 Tunnel Flags Format The high-order 7 bits are RESERVED and MUST be filled with ZERO, the lowest R bit is defined to indicate Tunnel's direction: 0-Passive: indicate the tunnel is setup by Passive PE 1-Active: indicate the tunnel is setup by Active PE g) Tunnel ID Tunnel Identifier defined according to specific Tunnel type. For RSVP-TE type tunnel defined in this document, Tunnel Identifier is < tunnel end point address, Reserved, Tunnel ID, Extended Tunnel ID> as carried in the RSVP-TE LSP's SESSION Object [RFC3209]. Following diagram describes RSVP-TE IPv4 Tunnel ID as example. +----------------------------------------------------------+ | IPv4 tunnel end point address (4 octets) | +----------------------------------------------------------+ | MUST be zero (2 octets) | Tunnel ID (2 octets) | +----------------------------------------------------------+ | Extended Tunnel ID (4 octets) | +----------------------------------------------------------+ Figure 4 RSVP-TE Tunnel Identifier Format a) IPv4 tunnel end point address: 4 octets IPv4 address of Egress PE. b) Tunnel ID: 2 octets Tunnel Identifier allocated by Ingress PE which remains constant over the life of the RSVP-TE tunnel. c) Extended Tunnel ID: 4 octets Extended Tunnel Identifier which also remains constant over the life of the RSVP-TE Tunnel, MUST be filled with ZERO or IPv4 Address of Ingress PE. which indicates a pair of VRFs is defined as the Prefix of VT Tunnel-ID Signal Route. Ni, et al. Expires August 17, 2014 [Page 5] Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014 4. Operations 4.1. Active/Passive PE Selection For a pair of PEs which are going to exchange VT Tunnel-ID Signal Routes need to select Active PE/Passive PE first. The selection SHOULD be done by two ways: a) Locally decided by manually configuration. That is one PE is configured as Active PE and other PE is configured as Passive PE. b) Doing auto-selection in BGP's Capability Negotiation phase. Router IDs of the two PEs are compared as unsigned integers, the PE with larger Router ID value MUST be selected as Active PE and the PE with smaller Router ID value is selected as Passive PE. 4.2. VPN Membership Auto Discovery Following the detailed description in [I-D.ni-bgp-ext-l3vpn-pm], all PEs firstly need to send VT VPN A-D Routes to do VPN membership discovery. 4.3. Active PE Advertise VT Tunnel-ID Signal Route Once found a pair of VRFs between Active PE and Passive PE belongs to the same VPN, Active PE MUST initialize setup a RSVP-TE tunnel to Passive PE for the pair of VRFs. Once Tunnel ID is allocated locally, Active PE MUST advertise the RSVP TE tunnel info to Passive PE by using VT Tunnel-ID Signal Route: Local VRF's RD: MUST be filled with Route Distinguisher value of the Local VRF. Local Router's IP Address: MUST be filled with Active PE's IPv4/IPv6 Address. Remote VRF's RD: MUST be filled with Route Distinguisher value of the remote VRF on Passive PE which belongs to same L3VPN with Local VRF. Remote Router's IP Address: MUST be filled with Passive PE's IPv4/ IPv6 Address. Tunnel Type: MUST be filled with a valid Tunnel Type value, for example filled with value <1> which indicates RSVP-TE Tunnel. Flags: the high-order 7 bits MUST be filled with ZERO and "R" bit flag MUST be filled with value <1> which indicates the tunnel is initialized by Active PE. Ni, et al. Expires August 17, 2014 [Page 6] Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014 Tunnel ID: field MUST be filled with IP address of Passive PE, field MUST be filled with the Tunnel Identifier value allocated by Active PE, filed MUST be filled with ZERO or IP address of Active PE. Note that if tunnel goes down, the responding VT Tunnel-ID Signal Route Withdrawal message SHOULD NOT be sent out. 4.4. Passive PE advertise Tunnel ID to Active PE After receiving VT Tunnel-ID Signal Route from Active PE, Passive PE gets all LSP's path information under the Tunnel and setup inverse direction RSVP-TE LSPs following same path. Once Tunnel ID is allocated locally, the Tunnel ID information MUST be advertised from Passive PE to Active PE through VT Tunnel-ID Signal Route: Local VRF's RD: MUST be filled with Route Distinguisher value of the Local VRF on Passive PE. Local Router's IP Address: MUST be filled with Passive PE's IPv4/IPv6 Address. Remote VRF's RD: MUST be filled with Route Distinguisher value of the remote VRF on Active PE which belongs to same L3VPN with Local VRF. Remote Router's IP Address: MUST be filled with Active PE's IPv4/IPv6 Address. Tunnel Type: MUST be filled with a valid Tunnel Type value, usually the tunnel Type SHOULD be same with previous Tunnel Type setup by Active PE. Flags: Filled "R" Flag with value "0" which indicates the tunnel is setup by Passive PE. Tunnel ID: "IPv4 tunnel end point address" field MUST be filled with IP address of Active PE, "Tunnel ID" field MUST be filled with the Tunnel Identifier value allocated by Passive PE, "Extended Tunnel ID" MUST be filled with ZERO or IP Address of Passive PE. 4.5. VT Tunnel-ID Signal Route Application When Active PE and Passive PE learnt VT Tunnel-ID Signal Routes from each other, both PEs need binding two uni-direction Tunnels together for the L3VPN. It means L3VPN traffic is transit over the tunnels and that if Active PE changes LSP in Active Tunnel, Passive PE MUST Ni, et al. Expires August 17, 2014 [Page 7] Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014 detect it and manipulate the reverse direction LSP in Passive Tunnel accordingly through RSVP protocol. 5. VT Tunnel-ID Signal Route Selection Consideration VT Tunnel-ID Signal Route SHOULD follow the BGP best route selection procedure described in [RFC4271]. VT Tunnel-ID Signal Route MUST be advertised ONLY to the Peer from which the best VT VPN A-D route is received. VT VPN A-D route is the one which carries the same Remote VRF's RD value and Remote PE's IP address. If Peer receives VT Tunnel-ID Signal Route originated from itself, the route MUST be ignored. 6. Deployment Consideration This document currently supports deploying VT Tunnel-ID Signal Route in 2 manners: Inner-AS L3VPN: with Full-mesh IBGP sessions or Router Reflectors. Inter-AS L3VPN: with Option A (VRF-to-VRF)[RFC4364]. How to support Inter-AS L3VPN Option B(MP-EBGP) [RFC4364] and Option-C (Multi-Hop MP-EBGP) [RFC4364] will be described in this draft's future version. 7. Security Considerations This extension to BGP does not change the underlying security issues. 8. IANA Considerations A new SAFI value to present VT Subsequent Address Family is required and to be allocated by IANA. 9. Normative References [I-D.li-mpls-serv-driven-co-lsp-fmwk] Li, Z. and J. Dong, "A Framework for Service-Driven Co- Routed MPLS Traffic Engineering LSPs", draft-li-mpls-serv- driven-co-lsp-fmwk-02 (work in progress), January 2014. Ni, et al. Expires August 17, 2014 [Page 8] Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014 [I-D.ni-l3vpn-pm-bgp-ext] Ni, H., Zhuang, S., and Z. Li, "BGP Extension For L3VPN Performance Monitoring", draft-ni-l3vpn-pm-bgp-ext-00 (work in progress), July 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. Authors' Addresses Hui Ni Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: nihui@huawei.com Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Ni, et al. Expires August 17, 2014 [Page 9] Internet-Draft BGP Extension for Carry LSP ID In L3VPN February 2014 Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Ni, et al. Expires August 17, 2014 [Page 10]