MPLS Working Group Internet Draft Bill Jensen Document: draft-jensen-mpls-interop-00.txt University of WI Expires: December 2002 Ananda Sen Gupta Agilent Technologies Ben Schultz University of NH Mark Dyga Laurel Networks June 2002 General Summary of Interoperability Testing Results and Experiences draft-jensen-mpls-interop-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document describes certain issues observed during a recent large MPLS Interoperability Test Event conducted by the Interoperability Work Group of the MPLS Forum. The aim of this document is to make the vendor and service provider community aware of these issues. Certain recommendations have also been provided in the document in the expectation that a discussion will ensue to get these issues resolved. Jensen, et al. Expires - December 2002 [Page 1] draft-jensen-mpls-interop-00.txt June 2002 Conventions used in this document 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 [2]. Table of Contents 1. Introduction ............................................... 2 2. Testing Methodology ........................................ 3 3. Testing Results and Recommendations ........................ 3 6. Security Considerations .................................... 7 7. References ................................................. 7 8. Acknowledgments ............................................ 8 9. Author's Addresses ......................................... 8 1. Introduction In late 2001, the MPLS Forum attempted to bring together the various companies working towards the common goal of interoperability under the banner of the Interoperability WG and created a plan to showcase the state of the MPLS technology during mid-2002 at a public event - Supercomm 2002. To reach this goal, a pre-staging event (referred to as "Hot Stage") was held with twenty-seven different network devices. During the ten working days of intensive testing during the Hot Stage, a number of interoperability issues were identified, which have been listed here. Different issues were identified with different devices and this is a summary of those findings. The list does not apply to any specific vendor equipment as is. The aim of this list is to make the vendor and service provider community aware of these issues. Some recommendations have been provided as possible ways for resolving these issues to achieve the maximum interoperability. There may be other ways of solving these issues, and we hope that a discussion will ensue to resolve these issues, either by moving this draft forward, or by making required changes in other RFCs or by fresh implementation agreements. Of course, it is quite possible that maximum interoperability may not be the goal of a particular NEM or SP. Jensen, et al. Expires - December 2002 [Page 2] draft-jensen-mpls-interop-00.txt June 2002 2. Testing Methodology The Testing: The test network consisted of a core network running RSVP-TE and LDP and an edge network running VPN services over the core. A detailed test plan was developed to conduct this testing in a systematic manner with testing between groups of two and four before the full network was built. This allowed the participants to isolate and fix interoperability issues, resulting in a time and troubleshooting savings when building the network. The test plan was developed by the Interoperability Work Group at the MPLS Forum. Volunteer teams from University of New Hampshire and Networld+Interop MPLS iLABs facilitated the Hot Stage event. The testing configuration of the groups of four MPLS-enabled devices looked as follows: +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | CE1 |-----| PE1 |-----| P1 |-----| P2 |-----| PE2 |-----| CE2 | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ Test equipment was used to emulate CE router capability and to send traffic from both ends. 3. Testing Results and Recommendations The discussion here is limited to implementation issues regarding the features relevant to the MPLS WG. There were a few Layer 1 and Layer 2 issues as well as some other practical logistical issues. These have not been listed here. 3.1 OSPF-TE implementation issue: Description: TE extensions to OSPF may not be supported by all equipment. While this by itself should have no effect on signaling protocols, this leads to interoperability issues. A number of implementations require TE enabled for OSPF in order that the TE database (TEDB) is filled, for use by RSVP-TE to set up LSPs. Jensen, et al. Expires - December 2002 [Page 3] draft-jensen-mpls-interop-00.txt June 2002 Temporary Resolution, if any: Say Device R1 required OSPF-TE for use by RSVP-TE. Say Device R2 can support RSVP-TE without OSPF-TE, but can support OSPF-TE as well as OSPF on different interfaces. Say Device R3 supports OSPF only. The connection was then chosen to be: [R1]-----[R2]-----[R3] Recommendation: If the RSVP-TE implementation requires checking nexthop in the TEDB for setting up tunnels, then this problem may not get resolved without a working OSPF-TE exchange. Typically R1 would check it's TEDB for a path to R3, but it would not find a valid TE path to get there. A workaround would be for R1 to configure an explicit hop by hop path (ERO) through the network. R1 would check the first hop of the RSVP tunnel against it's TEDB. If the OSPF-TE exchange did not take place, the nexthop would not be in the TEDB and the tunnel would not be setup. If the OSPF-TE exchange did take place, the first hop for R1 would be in it's TEDB and the path message would be sent out. R2 does not check the nexthop against the TEDB and forwards the path message to R3 permitting the tunnel to be setup. 3.2 Signaling Protocol Issue: Description: Some implementations supported only LDP or only RSVP-TE. Temporary Resolution, if any: The RSVP-TE only routers were used in the core, the LDP only routers at the edge setting up LSPs through P routers which supported both protocols and the ability to run LDP over RSVP. Recommendation: The implementation of protocols is a choice but implementation of RSVP-TE to participate in the core seems to be a practical necessity. Implementing both protocols, on the other hand, is clearly advantageous in ensuring interoperability. 3.3 LDP Issue: Description: Some implementations had LDP protocol mode of label distribution as DoD only or DU only, and would reject the session building attempts of the other. Jensen, et al. Expires - December 2002 [Page 4] draft-jensen-mpls-interop-00.txt June 2002 Temporary Resolution, if any: No resolution possible, when either the initialization messages or Label Mappings were rejected. Recommendation: Recommendations in [RFC3036] needs to be followed to avoid deadlocks. 3.4 RSVP-TE Issue #1 Description: Reservation Style (as defined in [RFC3209]) supported by Edge equipment is inflexible û a particular PE supports either of FF or SE only, while the PE it is trying to create an LSP to supports the other style, resulting in LSP set up failure. LSP does not get set up because: a. Egress PE rejects PATH b. P router rejects non-matching RESV message upon receiving mapping from Egress c. Ingress PE rejects RESV Temporary Resolution, if any: No resolution possible where the PE routers supported only one of the filter styles and were strict about the message contents. Recommendation: RFC 3209 states that the receiver determines the reservation style, which should be accepted by the sender. Thus P router and PE router's RSVP-TE implementations need to reflect this. 3.5 RSVP-TE Issue #2: Description: ERO supported, but router identifier in the ERO uses either the loopback address or the interface address. Sometimes the interface address may need to be the incoming address of next hop router or outgoing interface address of current router. When this usage is incompatible, the ERO gets rejected by the P routers and the LSP is not set up. Temporary Resolution, if any: In many sections of the network, an LSP could be set up only by not using an ERO, due to incompatibility in this area. Jensen, et al. Expires - December 2002 [Page 5] draft-jensen-mpls-interop-00.txt June 2002 Recommendation: More discussion is necessary in the industry to have a common understanding of this, or all implementations need to support all types of ERO contents and information on this should be made available. 3.6 RSVP-TE Issue #3: Description: Some routers support sending of the optional RESV_CONFIRM object, and some implementations cannot handle this message. Temporary Resolution, if any: For the routers which supported configuration of RESV_CONFIRM object, it was turned off. For other cases, there was no resolution. Recommendation: The sending of optional RESV_CONFIRM object needs to be either accepted or ignored by a receiving router. The other option is to keep RESV_CONFIRM configurable, so that it can be turned off. 3.7 Label Engine Issue: Description: Some P routers did not accept Explicit NULL labels from the PE routers. Temporary Resolution, if any: PE routers were configured not to send Explicit NULL labels on the PE- P links. Recommendation: P routers need to be capable of handling Explicit NULL labels as this is a common and sometimes a necessity. 6. Security Considerations This document does not add any new security issues beyond those noted in [RFC2547, RFC2205, RFC3036, BGP-VPN, L2-TRANS, L2-ENCAP]. Jensen, et al. Expires - December 2002 [Page 6] draft-jensen-mpls-interop-00.txt June 2002 7. References [RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 1999. [RFC3209] Awduche, D., Berger, L., Li, T., Srinivasan, V., Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B., "LDP Specification", RFC 3036, January 2001. [BGP-VPN] Rosen, E., et al., öBGP/MPLS VPNsö, draft-ietf-ppvpn- rfc2547bis-01.txt [L2-TRANS] Martini, L., et al.,ôTransport of Layer 2 Frames Over MPLSö, draft-martini-12-circuit-trans-mpls-09.txt [L2-ENCAP] Martini, L., et al., ôEncapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networksö, draft-martini-12- circuit-encap-mpls-04.txt 8. Acknowledgments We wish to thank James Leu, Ron Pashby, Ankur Chadda, Kari Revier, John Maynard, Nathaniel Milliken, and Erik Cummings for their valuable contributions. The Hot Stage event brought together twenty-one equipment manufacturers, who provided substantial time and resources to make this Interoperability event successful. The participating vendors were Agilent Technologies, Alcatel, Avici Systems, Celox Networks, Charlotte's Web Networks, Ericsson, Extreme Networks, Foundry Networks, Ixia, Juniper Networks, Laurel Networks, Lucent Technologies, Mahi Networks, Marconi Communications, Nettest, Riverstone Networks, Spirent Communications, Tenor Networks, Intel, Unisphere Networks and Vivace Networks. Jensen, et al. Expires - December 2002 [Page 7] draft-jensen-mpls-interop-00.txt June 2002 9. Author's Addresses Bill Jensen University of Wisconsin - Madison 1210 West Dayton Street Madison, WI 53706 Email: wej@doit.wisc.edu Ananda Sen Gupta Agilent Technologies 2 Technology Park Drive Westford, MA 01886 Email: ananda_sengupta@agilent.com Ben Schultz University of New Hampshire InterOperability Lab 219 Morse Hall Durham, NH 03824 Email: schultz@iol.unh.edu Mark Dyga Laurel Networks 1300 Omega Drive Pittsburgh, PA 15205 Email: mdyga@laurelnetworks.com Jensen, et al. Expires - December 2002 [Page 8]