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]