Network Working Group Rahul Aggarwal Internet Draft Juniper Networks Expiration Date: December 2003 Robert Raszuk Francois Le Faucheur Cisco Systems, Inc. Cristallo Geoffrey Jeremy De Clercq Alcatel Signaling Tunnel Encapsulation/Deencapsulation Capabilities draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026, except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document proposes a mechanism for signaling a PE router's tunnel encapsulation capabilities. One example is its capability to encapsulate MPLS using dynamic GRE and/or IP. This is applicable when a MPLS packet is tunneled using dynamic GRE and/or IP encapsulation [MPLS-IP-GRE] between PE routers. For instance the draft-raggarwa-ppvn-tunnel-encap-sig-01.txt [Page 1] Internet Draft draft-raggarwa-ppvn-tunnel-encap-sig-01.txt June 2003 MPLS packet may be a 2547 based MPLS VPN packet [2547bis], a layer 2 packet transported using MPLS [MARTINI], a MPLS tunneled IPv6 packet or a MPLS IPv6 VPN packet [BGP-VPN-IPv6]. Adding such a mechanism has several benefits. It helps in blackhole avoidance and eases transitioning from MPLS tunneling based Layer 3/Layer 2 VPNs to GRE/IP tunneling based Layer 3/Layer 2 VPNs (and vice versa). Such a mechanism is needed where a network may be using MPLS and GRE (or IP) for tunneling, simultaneously in different parts of the network. It can help in encapsulation selection when multiple tunneling technologies are supported. 2. Specification of Requirements 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]. 3. Summary for Sub-IP Area 3.1. Related documents See the Reference Section 3.2. Where does it fit in the Picture of the Sub-IP Work This work fits in the PPVPN WG. 3.3. Why is it Targeted at this WG [2547bis] is a product of the PPVPN WG. This document specifies a mechanism that proposes a lightweight mechanism for signaling a PE router's capability to encapsulate MPLS using dynamic GRE and/or IP. This is applicable when a 2547 based MPLS VPN packet is tunneled using a dynamic GRE and/or IP encapsulation [MPLS-IP-GRE] between PE routers. Since the procedures described in this document are directly related to [2547bis], it would be logical to target this document at the PPVN WG. 4. Mechanism Mutliple applications such as 2547 VPNs, Layer 2 VPNs, point to point Layer 2 transport over MPLS, IPv6 over IPv4 MPLS or IPv6 VPN over MPLS may use dynamic GRE or IP encapsulation for tunneling traffic across a network backbone. This document uses the term 'soft GRE' to refer to dynamic GRE encapsulation. If a PE router is using soft GRE or IP encapsulation for tunneling traffic for one or more of these draft-raggarwa-ppvn-tunnel-encap-sig-01.txt [Page 2] Internet Draft draft-raggarwa-ppvn-tunnel-encap-sig-01.txt June 2003 applications, across the backbone, it is not possible currently for it to dynamically learn the encapsulation capability of the remote PE router. In the context of 2547 based VPNs this PE router does not know the MPLS in soft GRE or MPLS in IP encapsulation capability of the BGP next-hop to which the traffic is destined. This document proposes a simple signaling mechanism by way of which this PE router can learn the MPLS in soft GRE or MPLS in IP encaspulation capability of the remote PE routers. This is achieved by propagating this information in BGP or in LDP. 4.1 BGP Extension A PE advertises its tunnel encapsulation capabilities in BGP using a new attribute that can be attached to a NLRI advertisement. We define a new subsequent address family identifier (SAFI) to be assigned by IANA. for carrying the tunnel encapsulation capabilities. Typically a PE can advertise a loopback address as an NLRI using a IPv4/IPv6 AFI and the new tunnel encapsulation capability SAFI. The encapsulation capabilities associated with this loopback address can be specified by attaching the new attribute. The new tunnel encapsulation capability attribute is optional and transitive with type code to be assigned by IANA. The value field of the attribute contains a mandatory capability TLV with the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x01 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Encapsulation Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The encapsulation capabilities bit-mask indicates all the encapsulations supported by the BGP speaker for the advertised NLRI and is encoded in the two least significant octets. The following encapsulation capabilities are defined as of now: 0x0001 - IPv4 in IPv4 0x0002 - IPv4 in GRE 0x0004 - IPv4 in IPSec 0x0008 - GRE in IPSec 0x0010 - MPLS in soft GRE 0x0020 - MPLS in IPv4 0x0040 - MPLS in IPv6 0x0080 - MPLS in L2TPv3 0x0100 - IPv6 in IPv4 0x0200 - IPv6 in MPLS draft-raggarwa-ppvn-tunnel-encap-sig-01.txt [Page 3] Internet Draft draft-raggarwa-ppvn-tunnel-encap-sig-01.txt June 2003 The mandatory capability TLV may be followed by TLVs that contain encapsulation specific information. Such TLVs will be specified in encapsulation specific documents. 4.2 LDP Extension MPLS in soft GRE or MPLS in IP encapsulation capability may need to be advertised when LDP signaling is used for establishing pseudo wires [MARTINI] or for Layer 2 VPNs [LDP-SIG]. When BGP is used as a discovery mechanism for Layer 2 VPNs BGP extensions proposed in 4.1 should be sufficient for determining the right encapsulation to use. If this is not the case, the encapsulation capability is advertised in LDP. This is done at the time of LDP session establishment. We define a LDP Tunnel Encapsulation Capabilities Session TLV for this purpose. This TLV is advertised as an optional parameter in the LDP Initialization message. The type of this optional paramenter has to be assigned by IANA and has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Type = TBD | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Encapsulation Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Encapsulation bit-mask indicates all the encapsulations supported by the PE originating the Initialization message. They are encoded in the two least significant octets: 0x01 - MPLS in soft GRE 0x02 - MPLS in IPv4 0x04 - MPLS in IPv6 0x08 - MPLS in L2TPv3 4.3 Applicability of BGP and LDP Extensions The decision to use BGP or LDP for advertising the tunnel encapsulation capability depends on the application. For 2547 based VPNs this information is advertised in BGP advertisements using the Tunnel encapsulation attribute. This is also true for BGP based Layer 2 VPNs [BGP-L2VPN]. BGP may be used as an auto-discovery mechanism for Layer 2 VPNs established using LDP signaling [BGP-AUTO]. In this case Tunnel encapsulation attribute can be added to the BGP auto-discovery advertisements to convey the encapsulation capability. For IPv6 tunneling and IPv6 VPN applications BGP Tunnel attribute can be used [BGP-VPN-IPv6]. draft-raggarwa-ppvn-tunnel-encap-sig-01.txt [Page 4] Internet Draft draft-raggarwa-ppvn-tunnel-encap-sig-01.txt June 2003 There may be cases when LDP is used for establishing pseudo wires and Layer 2 VPNs [MARTINI, LDP-SIG], and BGP is not used as an auto-discovery protocol. In this case the encapsulation capability can be advertised using the Encapsulation TLV in the LDP Initialization message. 5. Usage We describe the usage of this signaling enhancement in the context of 2547, though its equally applicable to Layer 2 VPNs and other tunneling applications. With this mechanism a PE can 'signal' its tunnel enapsulation capabilities including MPLS in IP or MPLS in soft GRE encapsulation capability to other PEs. A PE (say PE1) now has two pieces of information while determining if VPN routes learned from a remote PE (say PE2) are eligible for MPLS in IP or MPLS in soft GRE encapsulation: o Is PE1 configured to support MPLS in IP or MPLS in soft GRE encapsulation o Does PE2 support MPLS in IP or MPLS in soft GRE encapsulation. This is learned via the mechanism described above. If both the above are true, the VPN route can be installed in the VRF and tunneled using IP or soft GRE. Else the VPN route cannot be tunneled using IP or soft GRE. However it can still be tunneled using MPLS or some other tunneling mechanism. If PE2 supports multiple encapsulations, this mechanism can be used to pick one of the encapsulations based on local policy at PE1. In certain implementations BGP may propagate the capability of PE2 to the local RIB. Hence the local RIB can determine if a particular next-hop is eligible for MPLS in IP or MPLS in soft GRE enapsulation. 6. Benefits This mechanism adds several benefits: 6.1. Blackhole Avoidance Without this mechanism its possible in certain cases for a local PE to tunnel packets to a remote PE using an encapsulation that is not supported by the remote PE. For instance without knowing the MPLS in IP or MPLS in soft GRE capability of the remote PE, the local PE, if configured for MPLS in IP or MPLS in soft GRE, can start sending IP or GRE encapsulated MPLS traffic to the remote PE even if the remote PE doesn't support MPLS in IP or MPLS in soft GRE encapsulation. This can happen if the remote PE is running a software version that is not capable of performing the corresponding de-encapsulation or if its simply not configured to support the expected de-encapsulation. This can result in blackholing the MPLS traffic. draft-raggarwa-ppvn-tunnel-encap-sig-01.txt [Page 5] Internet Draft draft-raggarwa-ppvn-tunnel-encap-sig-01.txt June 2003 This mechanism avoids that as the local PE will never send IP or GRE encapsulated VPN traffic to the remote PE unless the remote PE advertises that its MPLS in IP or MPLS in soft GRE capable. 6.2. Co-existing MPLS and IP or Soft GRE tunneling It is conceivable that in a network providing 2547 based VPN service some of the PEs are attached to a part of the backbone which runs MPLS while other PEs are attached to a part of the backbone where MPLS is not running. Thus some of the PEs may support MPLS in soft GRE or MPLS in IP while others may support only MPLS tunneling. Further still its conceivable that one may wish to use soft GRE tunneling for certain VPN routes and MPLS tunneling for other VPN routes destined to the same PE. An example would be a co-existing IPSec over GRE and MPLS tunneling service for VPN-routes. Hence if LDP is used for MPLS tunneling, a given PE (say PE1) may be configured to run LDP and support soft GRE at the same time. The reason being that some of the remote PEs can only use MPLS tunneling. However currently there is no way for a remote PE (say PE2) that supports soft GRE to know the tunneling tecnology to use while sending MPLS VPN traffic to PE1. If it prefers using soft GRE it cannot be sure that PE1 supports soft GRE and it cannot rely on the LDP FECs received from PE1 to make this decision. The mechanism proposed in this document solves this problem as PE2 can learn the soft GRE capability of PE1. VPN routes advertised by a PE may be advertised with different next-hops if this PE wants the remote PEs to use different tunneling technologies for different next-hops. Hence this PE may wish to receive GRE encapsulated VPN traffic for some VPN routes and MPLS encapsulated VPN traffic for other VPN routes. It is possible to advertise the soft GRE capability only for certain VPN routes, associated with a particular next-hop. 6.3. Transitioning An operator may wish to transition some or all of the routers in a 2547 based network from using MPLS based tunneling to soft GRE or IP based tunneling and vice-versa. This approach greatly simplifies this transition. Once the remote soft GRE or IP encapsulation capability is known a PE can determine if it wishes to use MPLS or GRE or IP to encapsulate the traffic. Without this mechanism an operator transitioning certain routers from MPLS based tunneling to GRE based tunneling needs to enable soft GRE on all such routers before MPLS can be turned off on any of the routers. Similarly, without this mechanism, an operator transitioning certain routers from soft GRE based tunneling to MPLS tunneling needs to enable MPLS on all such routers before soft GRE can be turned off on any of the routers. draft-raggarwa-ppvn-tunnel-encap-sig-01.txt [Page 6] Internet Draft draft-raggarwa-ppvn-tunnel-encap-sig-01.txt June 2003 7. Deployment Considerations It is recommended that an implementation provide a configuration option to trigger the announcement of a PE's encapsulation capabilities in BGP or LDP. This will help in selective deployment of this mechanism. 8. IANA Considerations This document requires the use of a new BGP SAFI, a new BGP attribute and a LDP Tunnel encapsulation TLV. These values have to be assigned by IANA. 9. Security Considerations This document does not introduce any new security issues. The security issues identified in [BGP-EXT-COM], [RFC3036], [MPLS-IP-GRE] and [2547bis] are still relevant. 10. Acknowledgements We would like to thank Enke Chen, Jenny Yuan, Naiming Shen, Acee Lindem, and Ravi Chandra for their valuable contributions to this document and for helping in evolving this mechanism. Thanks to Yakov Rekhter for his comments and valuable suggestions. We would also like to thank Eric Rosen and Pedro Roque Marques for their comments. 11. References [BGP-EXT-COM] S.R. Sangli et. al., "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext-communities-05.txt. [RFC3036] L. Andersson et. al., "LDP Specification", Request For Comments 3036. [MPLS-IP-GRE] T. Worster et. al., "Encapsulating MPLS in IP or GRE", draft-rosen-mpls-in-ip-or-gre-00.txt. [2547bis] Rosen, E. et. al., "BGP/MPLS VPNs," Internet-draft draft-ietf-ppvpn-rfc2547bis-04.txt, January 2002. [MARTINI] L. Martini. et. al., "Transport of Layer 2 Frames Over MPLS", draft-ietf-pwe3-control-protocol-00.txt. [BGP-L2VPN] K. Kompella et. al., "Layer 2 VPNs over Tunnels", draft-kompella-ppvpn-l2vpn-02.txt. draft-raggarwa-ppvn-tunnel-encap-sig-01.txt [Page 7] Internet Draft draft-raggarwa-ppvn-tunnel-encap-sig-01.txt June 2003 [BGP-AUTO] Ould-Brahim et. al., "Using BGP as an Auto-Discovery Mechanism for Network based VPNs", draft-ietf-ppvpn-bgpvpn-auto-05.txt. [LDP-SIG] E. Rosen, "LDP-based Signaling for L2VPNs", draft-rosen-ppvpn-l2-signaling-02.txt. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [BGP-VPN-IPv6] J. De Clercq et. al., "BGP-MPLS VPN extension for IPv6 VPN", draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt. 12. Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Robert Raszuk Cisco Systems, Inc. Al Jerozolimskie 146C 02-305 Warsaw, Poland Email: rraszuk@cisco.com Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France Email: flefauch@cisco.com Cristallo Geoffrey Alcatel Fr. Wellesplein 1, 2018 Antwerp, Belgium Email: geoffrey.cristallo@alcatel.be Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Email: Jeremy.De_Clercq@alcatel.be draft-raggarwa-ppvn-tunnel-encap-sig-01.txt [Page 8]