Network Working Group V. Ayyangar Internet-Draft AT&T Labs Request For Comments: xxxx T. Jayawardena Intended Status: Informational AT&T Labs Expires: June, 2007 January 2007 LDP OSPF Synchronization and VPN Traffic Blackholing draft-jayawardena-ldp-ospf-vpn-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on June 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Ayyangar and Jayawardena Expires June, 2007 [Page 1] Inernet-Draft LDP OSPF Synchronization and VPN Traffic January 2007 Abstract This document describes two types of situations where VPN and non-VPN traffic dependent on label forwarding can be blackholed despite the use of LDP OSPF synchronization which helps minimize such blackholing. Ways of mitigating these situations are also discussed. Here, by VPN is meant a layer 3, MPLS-based VPN. 1. Introduction The LDP IGP synchronization feature is described in an Internet- Draft, [DR-LDP-IGP-SYNC]. This feature works as follows: If LDP is not operational on a link, VPN traffic that is forwarded on the link will be dropped, i.e. blackholed. The LDP IGP synchronization feature raises the IGP cost of a link to LSInfinity (0xFFFF, see [RFC3137]) when LDP is not fully operational on the link. This makes traffic avoid such links when an alternate path to the destination exists. However, even with LDP IGP synchronization feature enabled, there are situations where traffic is blackholed. Two types of such situations are discussed in section 3 using OSPF as the IGP. These traffic blackholing scenarios apply to both VPN traffic, as well as, non-VPN traffic which depends on a label for its forwarding. An example of the latter is a network with an Internet-route-free core where Internet traffic is forwarded using labels. The following discussion focuses on OSPF as the IGP. 2. LDP OSPF Synchronization The LDP OSPF synchronization feature is implemented by raising the OSPF cost of a link to LSInfinity (hexadecimal 0xFFFF or decimal 65535) by a router when LDP is not fully operational on the link. This high OSPF cost is used as the link cost in the router LSA generated by the router. This continues until, based on heuristics, the originating router decides that LDP is fully operational on the link. At that point, the router LSA is resent with the link OSPF cost set to the configured value. Each LDP neighbor autonomously decides when LDP is fully operational on a link. This approach allows implementing LDP OSPF synchronization without changes to existing LDP functionality. In [DR-LDP-IGP-SYNC], a suggested heuristic is to wait some time period after LDP is established on a link before the OSPF cost is Ayyangar and Jayawardena Expires June, 2007 [Page 2] Inernet-Draft LDP OSPF Synchronization and VPN Traffic January 2007 lowered to the configured value. One particular heuristic used in implementations is to wait a time period 't' after a router finishes sending all its LDP labels to a given LDP neighbor on a link before regenerating its router LSA with the link cost set to the configured value. In some implementations, the value of 't' is user- configurable, in others it is set to a constant value. Also, this is a global timer which is used independently on each LDP-enabled interface. As a result, during an LDP up convergence event on the router, the router LSA will be generated each time the router decides to lower the OSPF cost on a link. Thus, on a router with many links, the router LSA is generated many times during an LDP up convergence event. 3. Traffic Blackholing Two types of traffic blackholing scenarios are discussed below using examples of small networks. These examples are meant only as a discussion tool. 3.1 Type I Traffic Blackholing This type of blackholing arises due to a router lowering the OSPF cost on a link before it has received all its LDP neighbor's labels. Since the decision to reduce the OSPF cost on a link is based on heuristics, it is possible to reduce the cost prematurely - before the router has received all labels from its LDP neighbor. This is illustrated in figure 3.a and 3.b. Ayyangar and Jayawardena Expires June, 2007 [Page 3] Inernet-Draft LDP OSPF Synchronization and VPN Traffic January 2007 +---+ +----------| E |---------| | +---+ | ^ | 100 100 | | | | | v | | +---+ 65535 +---+ | C |--------------------| D | +---+ +---+ | | ^ | | | | | 100 100 | v | | +---+ +---+ | A | | B | +---+ +---+ Figure 3.a - All links are in OSPF area 0. Routers C and D announce LSInfinity (decimal 65535) as the OSPF cost of CD since each router is still sending labels to its LDP neighbor. +---+ |----------| E |---------+ | +---+ | | 100 100 | | | | | +---+ 100 65535 +---+ | C |--------------------| D | +---+ ---> +---+ | | ^ | | | | | 100 100 | v | | +---+ +---+ | A | | B | +---+ +---+ Figure 3.b - Router C lowers its OSPF cost on link CD although it has not yet received a label for the traffic destination from D. Traffic is blackholed on C. Ayyangar and Jayawardena Expires June, 2007 [Page 4] Inernet-Draft LDP OSPF Synchronization and VPN Traffic January 2007 3.2 Type II Traffic Blackholing This type of traffic blackholing arises at an ABR. Intra-area OSPF routes are preferred over inter-area routes regardless of the cost. Therefore, an LDP failure and the accompanying high OSPF cost due to LDP OSPF synchronization do not cause traffic to take a lower- cost route when the choice is between intra-area vs. inter-area routes. An example is shown in figure 3.c. +---+ |----------| E |---------| | +---+ | | 100 100 | | | | area 0 | | | +---+ 65535 +---+ | C |--------------------| D | +---+ ----> +---+ | | ^ | area 1 | | | | 100 100 | v | | | | +---+ +---+ | A | | B | +---+ +---+ Figure 3.c - Links AC, CD and DB are in OSPF area 1 and links CE and ED are in area 0. Routers C and D announce LSInfinity values on link CD since LDP has failed on CD. Traffic is blackholed on router C since intra-area OSPF routes are preferred over inter-area routes regardless of cost. Short duration Type II traffic blackholing can occur during an LDP convergence event on an ABR due to variations in time taken to exchange LDP labels on links in different OSPF areas. This situation is most likely to occur in networks having ABRs connected to several OSPF areas and having a large number of LDP labels. Consider the network in figure 3.d. Traffic from router A to B takes the path AC- CF-FE-EB that avoids router D since all links on D have an LSInfinity cost due to LDP OSPF synchronization caused by LDP restarting on router D. Ayyangar and Jayawardena Expires June, 2007 [Page 5] Inernet-Draft LDP OSPF Synchronization and VPN Traffic January 2007 The situation shown in figure 3.e will result if routers C and D lower OSPF costs of area 0 links CD and DE while labels are still being exchanged on link DE in area 1. -> +---+ -> |------------------| F |--------------------| | +---+ | ^ | 100 100 | | | | | v | area 0 | | | +---+ 65535 +---+ 65535 +---+ | C |----------------| D |------------------| E | +---+ +---+------------------+---+ | | 65535 | ^ | | | | | 50 | 65535 50 | | area 2 | | area 1 | v | | | +---+ | +---+ | | A | |---------| B |--------+ +---+ +---+ Figures 3.d - All links on D have configured costs of 50. LDP is restarting on router D. Due to LDP OSPF synchronization, all links on D have LSInfinity cost. There are two links between D and E, one in area 0 and the other in area 1. Traffic from A to B takes the path AC-CF-FE-EB. Ayyangar and Jayawardena Expires June, 2007 [Page 6] Inernet-Draft LDP OSPF Synchronization and VPN Traffic January 2007 +---+ |------------------| F |--------------------| | +---+ | | 100 100 | | | | area 0 | | | +---+ 50 +---+ 50 +---+ | C |----------------| D |------------------| E | +---+ -> +---+------------------+---+ | | 65535 | ^ | | | | | 50 | | 65535 50 | area 2 | v | area 1 | | | | +---+ | +---+ | | A | |---------| B |--------| +---+ +---+ Figure 3.e - From router C's perspective the best route to B is via D, using the path CD-DE-EB with a total cost of 150. In the network in 3.e, the best path from C to B is CD-DE-EB, where the area 0 link DE is used in the shortest path. However, router D prefers the intra-area route DB regardless of the cost. So, traffic is blackholed on D until D receives a label to reach router B over an area 1 link. 4. Mitigiation Type I traffic blackholing can be minimized by tuning the user- configurable timer 't' discussed in section 2. The timer value can be chosen using test measurements of the time needed for both LDP neighbors to exchange their labels during various network conditions. When the network has alternate paths with sufficient bandwidth, the timer value can be set to 90th or 95th percentile of the statistical sample of the measured time needed for this label exchange. LDP OSPF synchronization does not prevent Type II traffic blackholing in failure scenarios like the one in figure 3.c and 3.e. In some situations type II blackholing can be avoided by using OSPF topologies that are not susceptible to this type of blackholing. For example, if link CD (figure 3.c) is placed in area 0 type II blackholing will not occur. Ayyangar and Jayawardena Expires June, 2007 [Page 7] Inernet-Draft LDP OSPF Synchronization and VPN Traffic January 2007 In situations where changing an OSPF topology is not practical for some reason, type II blackholing can be minimized by the use of a tunable global timer on ABRs. The timer is started during an LDP convergence event involving links of both area zero and one or more non-zero area. OSPF costs are not lowered on area zero links until the timer expires. Setting such a timer value appropriately will help lower OSPF costs on non-zero area links before area zero links during LDP OSPF synchronization. In example 3.e, if router D lowers area 1 OSPF costs before lowering the cost on the area 0 link DE there will be no blackholing. In [RFC4222], there are recommendations for achieving scalability and stability in large OSPF networks. One of these (item 5) is to throttle OSPF adjacencies to be brought up simultaneously to some number 'n'. In this regard, the use of a priority list dictating the order in which self-generated adjacency requests are sent is suggested. On ABRs, listing all non-zero-area neighbors before area- zero neighbors in such a list will reduce occurrences of type II blackholing in large OSPF networks by promoting convergence of non- zero area neighbors before those in area 0. 5. Summary Two types of situations are discussed where traffic is blackholed despite the use of LDP OSPF synchronization. One of these is due to practical limitations in implementing LDP OSPF synchronization while the other is due to a fundamental rule in OSPF combined with a certain type of failure mode. Both these situations do not detract from the use of LDP OSPF synchronization to prevent traffic blackholing due to more common LDP failures. By careful design and tuning timer values even the blackholing in these situations can be avoided or minimized. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations The techniques described in this document do not introduce any new security issues into the OSPF and LDP protocols. Ayyangar and Jayawardena Expires June, 2007 [Page 8] Inernet-Draft LDP OSPF Synchronization and VPN Traffic January 2007 8. Acknowledgments We thank Jay Borkenhagen, Tuan Duong, Rich Kwapniewski and Aswatnarayan Raghuram for valuable suggestions and discussions on blackholing scenarios described here. We thank Jerry Ash for editorial help and suggestions. 9. Normative References [RFC3137] A. Retana et al., "OSPF Stub Router avertissement", RFC 3137, June 2001 [RFC4222] Choudhury G.(Editor), "Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance", RFC 4222, October, 2005 10. Informative References [DR-LDP-IGP-SYNC] Jork, M., Atlas, A. and Fang, L., "LDP IGP Synchronization", work-in-progress, draft-jork- ldp-igp-sync-00, 2006 Ayyangar and Jayawardena Expires June, 2007 [Page 9] Inernet-Draft LDP OSPF Synchronization and VPN Traffic January 2007 Author's Addresses Vijay Ayyangar AT&T Labs Room C5-2D16, 200 Laurel Av. Middletown, NJ 07748, USA Email: vayyangar@att.com Thusitha Jayawardena AT&T Labs Room C1-2D04, 200 Laurel Av. Middletown, NJ 07748, USA Email: tj@att.com Ayyangar and Jayawardena Expires June, 2007 [Page 10] Inernet-Draft LDP OSPF Synchronization and VPN Traffic January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ayyangar and Jayawardena Expires June, 2007 [Page 11]