draft-ietf-mpls-ldp-igp-sync-04.txt | rfc5443.txt | |||
---|---|---|---|---|
Network Working Group M. Jork | Network Working Group M. Jork | |||
Internet Draft NextPoint Networks | Request for Comments: 5443 GENBAND | |||
Category: Informational Alia Atlas | Category: Informational A. Atlas | |||
Expires: June 17, 2009 British Telecom | British Telecom | |||
L. Fang | L. Fang | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
December 17, 2008 | ||||
LDP IGP Synchronization | LDP IGP Synchronization | |||
draft-ietf-mpls-ldp-igp-sync-04.txt | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted to IETF in full conformance with | ||||
the provisions of BCP 78 and BCP 79. | ||||
This memo provides information for the Internet community. It does | This memo provides information for the Internet community. It does | |||
not specify an Internet standard of any kind. Distribution of this | not specify an Internet standard of any kind. Distribution of this | |||
memo is unlimited. | memo is unlimited. | |||
By submitting this Internet-Draft, each author represents that any | Copyright Notice | |||
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 BCP 78 and 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 18, 2009. | ||||
Copyright and License Notice | ||||
Copyright (c) 2008 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
LDP IGP Synchronization December 2008 | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents in effect on the date of | |||
(http://trustee.ietf.org/license-info) in effect on the date of | publication of this document (http://trustee.ietf.org/license-info). | |||
publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
carefully, as they describe your rights and restrictions with | and restrictions with respect to this document. | |||
respect to this document. | ||||
This document may contain material from IETF Documents or IETF | ||||
Contributions published or made publicly available before November | ||||
10, 2008. The person(s) controlling the copyright in some of this | ||||
material may not have granted the IETF Trust the right to allow | ||||
modifications of such material outside the IETF Standards Process. | ||||
Without obtaining an adequate license from the person(s) controlling | ||||
the copyright in such materials, this document may not be modified | ||||
outside the IETF Standards Process, and derivative works of it may | ||||
not be created outside the IETF Standards Process, except to format | ||||
it for publication as an RFC or to translate it into languages other | ||||
than English. | ||||
Abstract | Abstract | |||
In certain networks there is a dependency on edge-to-edge Label | In certain networks, there is dependency on the edge-to-edge Label | |||
Switched Paths (LSPs) setup by Label Distribution Protocol (LDP), | Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP), | |||
e.g., networks that are used for MultiProtocol Label Switching | e.g., networks that are used for Multiprotocol Label Switching (MPLS) | |||
(MPLS) Virtual Private Network (VPN) applications. For such | Virtual Private Network (VPN) applications. For such applications, | |||
applications it is not possible to rely on Internet Protocol (IP) | it is not possible to rely on Internet Protocol (IP) forwarding if | |||
forwarding if the MPLS LSP is not operating appropriately. | the MPLS LSP is not operating appropriately. Blackholing of labeled | |||
Blackholing of labeled traffic can occur in situations where the | traffic can occur in situations where the Interior Gateway Protocol | |||
Interior Gateway Protocol (IGP) is operational on a link but LDP is | (IGP) is operational on a link on which LDP is not. While the link | |||
not operational on that link. While the link could still be used for | could still be used for IP forwarding, it is not useful for MPLS | |||
IP forwarding, it is not useful for MPLS forwarding, for example, | forwarding, for example, MPLS VPN applications or Border Gateway | |||
MPLS VPN; Border Gateway Protocol (BGP) route free core; or IP | Protocol (BGP) route-free cores. This document describes a mechanism | |||
address carried in the packet is out of the RFC 1918 [RFC 1918] | to avoid traffic loss due to this condition without introducing any | |||
space. This document describes a mechanism to avoid traffic loss due | protocol changes. | |||
to this condition without introducing any protocol changes. | ||||
Table of Contents | Table of Contents | |||
1. Introduction..................................................3 | 1. Introduction ....................................................2 | |||
2. Proposed Solution.............................................3 | 1.1. Conventions Used in This Document ..........................3 | |||
3. Applicability.................................................5 | 2. Proposed Solution ...............................................3 | |||
4. Interaction with TE Tunnels...................................5 | 3. Applicability ...................................................4 | |||
5. Security Considerations.......................................6 | 4. Interaction with TE Tunnels .....................................5 | |||
6. IANA Considerations...........................................6 | 5. Security Considerations .........................................5 | |||
7. Normative References..........................................6 | 6. References ......................................................6 | |||
8. Informational References......................................6 | 6.1. Normative References .......................................6 | |||
9. Authors' Addresses............................................7 | 6.2. Informative References .....................................6 | |||
10. Acknowledgments..............................................7 | 7. Acknowledgments .................................................6 | |||
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 RFC2119 [RFC | ||||
2119]. | ||||
LDP IGP Synchronization December 2008 | ||||
1. Introduction | 1. Introduction | |||
LDP [RFC 5036] establishes MPLS LSPs along the shortest path to a | LDP [RFC 5036] establishes MPLS LSPs along the shortest path to a | |||
destination as determined by IP forwarding. In a common network | destination as determined by IP forwarding. In a common network | |||
design, LDP is used to provide label switched paths throughout the | design, LDP is used to provide Label Switched Paths throughout the | |||
complete network domain covered by an IGP such as Open Shortest | complete network domain covered by an IGP such as Open Shortest Path | |||
Path First (OSPF) [RFC 2328] or Intermediate system to intermediate | First (OSPF) [RFC2328] or Intermediate System to Intermediate System | |||
system (IS-IS) [ISO.10589.1992], i.e., all links in the domain have | (IS-IS) [ISO.10589.1992]; i.e., all links in the domain have IGP as | |||
IGP as well as LDP adjacencies. | well as LDP adjacencies. | |||
A variety of services a network provider may want to deploy over an | A variety of services a network provider may want to deploy over an | |||
LDP enabled network depend on the availability of edge to edge | LDP-enabled network depend on the availability of edge-to-edge label | |||
label switched paths. In a layer 2 (L2) or layer 3 (L3) VPN | switched paths. In a layer 2 (L2) or layer 3 (L3) VPN scenario, for | |||
scenario for example, a given Provider-Edge(PE) router relies on | example, a given Provider-Edge (PE) router relies on the availability | |||
the availability of a complete MPLS forwarding path to the other PE | of a complete MPLS forwarding path to the other PE routers for the | |||
routers for the VPNs it serves. This means that along the IP | VPNs it serves. This means that all the links along the IP shortest | |||
shortest path from one PE router to the other, all the links need | path from one PE router to the other need to have operational LDP | |||
to have operational LDP sessions and the necessary label binding | sessions, and the necessary label binding must have been exchanged | |||
must have been exchanged over those sessions. If only one link | over those sessions. If only one link along the IP shortest path is | |||
along the IP shortest path is not covered by an LDP session, a | not covered by an LDP session, a blackhole exists and services | |||
blackhole exists and services depending on MPLS forwarding will | depending on MPLS forwarding will fail. This might be a transient or | |||
fail. This might be a transient or a persistent error condition. | a persistent error condition. Some of the reasons for this could be: | |||
Some of the reasons for it could be | ||||
- A configuration error | - A configuration error. | |||
- An implementation bug | - An implementation bug. | |||
- The link has just come up and has an IGP adjacency but LDP has | - The link has just come up and has an IGP adjacency but LDP has | |||
either not yet established an adjacency or session or | either not yet established an adjacency or session, or has not yet | |||
distributed all the label bindings. | distributed all the label bindings. | |||
LDP protocol has currently no way to correct the issue, LDP is not | The LDP protocol has currently no way to correct the issue. LDP is | |||
a routing protocol; it cannot re-direct traffic to an alternate IGP | not a routing protocol; it cannot re-direct traffic to an alternate | |||
path. | IGP path. | |||
1.1. 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 [RFC2119]. | ||||
2. Proposed Solution | 2. Proposed Solution | |||
The problem described above exists because LDP is tied to IP | The problem described above exists because LDP is tied to | |||
forwarding decisions but no coupling between the IGP and LDP | IP-forwarding decisions but no coupling between the IGP and LDP | |||
operational state on a given link exists. If IGP is operational on | operational state on a given link exists. If IGP is operational on a | |||
a link but LDP is not, a potential network problem exists. So the | link but LDP is not, a potential network problem exists. So the | |||
solution described by this document is to discourage a link from | solution described by this document is to discourage a link from | |||
being used for IP forwarding as long as LDP is not fully | being used for IP forwarding as long as LDP is not fully operational. | |||
operational. | ||||
LDP IGP Synchronization December 2008 | ||||
This has some similarity to the mechanism specified in [RFC 3137] | This has some similarity to the mechanism specified in [RFC3137], | |||
which allows an OSPF router to advertise that it should not be used | which allows an OSPF router to advertise that it should not be used | |||
as a transit router. One difference is that [RFC 3137] raises the | as a transit router. One difference is that [RFC 3137] raises the | |||
link costs on all (stub) router links, while the mechanism | link costs on all (stub) router links, while the mechanism described | |||
described in here applies on a per-link basis. | here applies on a per-link basis. | |||
In detail: when LDP is not "fully operational" (see below) on a | In detail: when LDP is not "fully operational" (see below) on a given | |||
given link, the IGP will advertise the link with maximum cost to | link, the IGP will advertise the link with maximum cost to avoid any | |||
avoid any transit traffic over it if possible. In the case of | transit traffic over it. In the case of OSPF, this cost is | |||
OSPF, this cost is LSInfinity (16-bit value 0xFFFF) as proposed in | LSInfinity (16-bit value 0xFFFF), as proposed in [RFC3137]. In the | |||
[RFC 3137]. In the case of ISIS, the max metric value is 2^24-2 | case of ISIS, the maximum metric value is 2^24-2 (0xFFFFFE). Indeed, | |||
(0xFFFFFE). Indeed, if a link is configured with 2^24-1 (the | if a link is configured with 2^24-1 (the maximum link metric per | |||
maximum link metric per [RFC 5305]) then this link is not | [RFC5305]), then this link is not advertised in the topology. It is | |||
advertised in the topology. It is important to keep the link in the | important to keep the link in the topology to allow IP traffic to use | |||
topology to allow for IP traffic to use the link as a last resort | the link as a last resort in case of massive failure. | |||
in case of massive failure. | ||||
LDP is considered fully operational on a link when an LDP hello | LDP is considered fully operational on a link when an LDP hello | |||
adjacency exists on it, a suitable associated LDP session (matching | adjacency exists on it, a suitable associated LDP session (matching | |||
the LDP Identifier of the hello adjacency) is established to the | the LDP Identifier of the hello adjacency) is established to the peer | |||
peer at the other end of the link and all label bindings have been | at the other end of the link, and all label bindings have been | |||
exchanged over the session. At the present time, the latter | exchanged over the session. At the present time, the latter | |||
condition cannot generally be verified by a router and some | condition cannot generally be verified by a router and some | |||
estimated may have to be used. A simple implementation strategy is | estimation may have to be used. A simple implementation strategy is | |||
to use a configurable hold down timer to allow LDP session | to use a configurable hold-down timer to allow LDP session | |||
establishment before declaring LDP fully operational. The default | establishment before declaring LDP fully operational. The default | |||
timer is not defined in this document due to the concerns of the | timer is not defined in this document due to concerns of the large | |||
large variations of the Label Information Base (LIB) table size and | variations of the Label Information Base (LIB) table size and | |||
the equipment capabilities. In addition, this is a current work in | equipment capabilities. In addition, there is a current work in | |||
progress on LDP End-of-LIB as specified in [LDP End-of-LIB], it | progress on LDP End-of-LIB as specified in [End-of-LIB], which | |||
enables the LDP speaker to signal the completion of its initial | enables the LDP speaker to signal the completion of its initial | |||
advertisement following session establish. When LDP End-of-LIB is | advertisement following session establishment. When LDP End-of-LIB | |||
implemented, the configurable hold down timer is no longer needed. | is implemented, the configurable hold-down timer is no longer needed. | |||
The neighbor LDP session is considered fully operational when the | The neighbor LDP session is considered fully operational when the | |||
End-of-LIB notification message is received. | End-of-LIB notification message is received. | |||
This is typically sufficient to deal with the link when it is being | This is typically sufficient to deal with the link when it is being | |||
brought up. LDP protocol extensions to indicate the complete | brought up. LDP protocol extensions to indicate the complete | |||
transmission of all currently available label bindings after a | transmission of all currently available label bindings after a | |||
session has come up are conceivable but not addressed in this | session has come up are conceivable, but not addressed in this | |||
document. | document. | |||
The mechanism described in this document does not entail any | The mechanism described in this document does not entail any protocol | |||
protocol changes and is a local implementation issue. | changes and is a local implementation issue. | |||
The problem space and solution specified in this document have also | The problem space and solution specified in this document have also | |||
been discussed in an IEEE Communications Magazine paper [LDP | been discussed in an IEEE Communications Magazine paper | |||
Failure Recovery]. | [LDP-Fail-Rec]. | |||
LDP IGP Synchronization December 2008 | ||||
3. Applicability | 3. Applicability | |||
In general, the proposed procedure is applicable in networks where | In general, the proposed procedure is applicable in networks where | |||
the availability of LDP signaled MPLS LSPs and avoidance of | the availability of LDP-signaled MPLS LSPs and avoidance of | |||
blackholes for MPLS traffic is more important than always choosing | blackholes for MPLS traffic are more important than always choosing | |||
an optimal path for IP forwarded traffic. Note however that non- | an optimal path for IP-forwarded traffic. Note however that non- | |||
optimal IP forwarding only occurs for a short time after a link | optimal IP forwarding only occurs for a short time after a link comes | |||
comes up or when there is a genuine problem on a link. In the | up or when there is a genuine problem on a link. In the latter case, | |||
latter case an implementation should issue network management alerts | an implementation should issue network management alerts to report | |||
to report the error condition and enable the operator to address it. | the error condition and enable the operator to address it. | |||
Example network scenarios that benefit from the mechanism described | Example network scenarios that benefit from the mechanism described | |||
here are MPLS VPNs and BGP-free core network designs where traffic | here are MPLS VPNs and BGP-free core network designs where traffic | |||
can only be forwarded through the core when LDP forwarding state is | can only be forwarded through the core when LDP forwarding state is | |||
available throughout. | available throughout. | |||
The usefulness of this mechanism also depends on the availability | The usefulness of this mechanism also depends on the availability of | |||
of alternate paths with sufficient bandwidth in the network should | alternate paths with sufficient bandwidth in the network should one | |||
one link be assigned to the maximum cost due to unavailability of | link be assigned to the maximum cost due to the unavailability of LDP | |||
LDP service over it. | service over it. | |||
On broadcast links with more than one IGP/LDP peer, the cost-out | On broadcast links with more than one IGP/LDP peer, the cost-out | |||
procedure can only be applied to the link as a whole and not an | procedure can only be applied to the link as a whole and not to an | |||
individual peer. So a policy decision has to be made whether the | individual peer. So a policy decision has to be made whether the | |||
unavailability of LDP service to one peer should result in the | unavailability of LDP service to one peer should result in the | |||
traffic being diverted away from all the peers on the link. | traffic being diverted away from all the peers on the link. | |||
4. Interaction with TE Tunnels | 4. Interaction with TE Tunnels | |||
In some networks, LDP is used in conjunction with RSVP-TE which sets | In some networks, LDP is used in conjunction with RSVP-TE, which sets | |||
up traffic-engineered tunnels. The path computation for the TE | up traffic-engineered tunnels. The path computation for the TE | |||
tunnels is based on the TE link cost which is flooded by the IGP in | tunnels is based on the TE link cost that is flooded by the IGP in | |||
addition to the regular IP link cost. The mechanism described in | addition to the regular IP link cost. The mechanism described in | |||
this document should only be applied to the IP link cost to prevent | this document should only be applied to the IP link cost to prevent | |||
any unnecessary TE tunnel reroutes. | unnecessary TE tunnel reroutes. | |||
In order to establish LDP LSPs across a TE tunnel, a targeted LDP | In order to establish LDP LSPs across a TE tunnel, a targeted LDP | |||
session between the tunnel endpoints needs to exist. This presents | session between the tunnel endpoints needs to exist. This presents a | |||
a problem very similar to the case of a regular LDP session over a | problem very similar to the case of a regular LDP session over a link | |||
link (the case discussed so far): when the TE tunnel is used for IP | (the case discussed so far): when the TE tunnel is used for IP | |||
forwarding, the targeted LDP session needs to be operational to | forwarding, the targeted LDP session needs to be operational to avoid | |||
avoid LDP connectivity problems. Again, raising the IP cost of the | LDP connectivity problems. Again, raising the IP cost of the tunnel | |||
tunnel while there is no operational LDP session will solve the | while there is no operational LDP session will solve the problem. | |||
problem. When there is no IGP adjacency over the tunnel and the | When there is no IGP adjacency over the tunnel and the tunnel is not | |||
tunnel is not advertised as link into the IGP, this becomes a local | advertised as a link into the IGP, this becomes a local issue of the | |||
issue of the tunnel headend router. | tunnel headend router. | |||
LDP IGP Synchronization December 2008 | ||||
5. Security Considerations | 5. Security Considerations | |||
A DoS attack that brings down LDP service on a link or prevents it | A Denial-of-Service (DoS) attack that brings down LDP service on a | |||
from becoming operational on a link could be one of the | link or prevents it from becoming operational on a link could be one | |||
possibilities that causes LDP related traffic blackholing. This | possible cause of LDP-related traffic blackholing. This document | |||
document does not address how to prevent LDP session failure. The | does not address how to prevent LDP session failure. The mechanism | |||
mechanism described here prevents the use of the link when LDP is | described here prevents the use of the link where LDP is not | |||
not operational while IGP is. Assigning the IGP cost to maximum on | operational while IGP is. Assigning the IGP cost to maximum on such | |||
the link where LDP is failed and IGP is not should not introduce | a link should not introduce new security threats. The operation is | |||
new security threats. The operation is internal in the router to | internal to the router to allow LDP and IGP to communicate and react. | |||
allow LDP and IGP to communicate and react. Making many LDP links | Making many LDP links unavailable, however, is a security threat that | |||
unavailable, however, is a security threat which can cause traffic | can cause dropped traffic due to limited available network capacity. | |||
being dropped due to limited available network capacity. This may | This may be triggered by operational error or implementation error. | |||
be triggered by operational error or implementation error. They are | These errors are considered general security issues and implementors | |||
considered as general Security issues and should follow the current | should follow the current best security practice [MPLS-GMPLS-Sec]. | |||
best security practice [MPLS-GMPLS-Security]. | ||||
6. IANA Considerations | ||||
This document has no actions for IANA. | 6. References | |||
7. Normative References | 6.1. Normative References | |||
[RFC 5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
and B. Thomas, "LDP Specification", RFC 5036, October 2007. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April | [RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April | |||
1998. | 1998. | |||
8. Informational References | [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, | |||
Ed., "LDP Specification", RFC 5036, October 2007. | ||||
[RFC 1918] Rekhter, Y., "Address Allocation for Private Internets", | 6.2. Informative References | |||
BCP: 5, RFC 1918, February 1996. | ||||
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate | [End-of-LIB] Asati, R., LDP End-of-LIB, Work in Progress, January | |||
[RFC 3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. | 2009. | |||
McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001. | ||||
[RFC 5305] Li, T., Smit, H., Intermediate System to Intermediate | [ISO.10589.1992] International Organization for Standardization, | |||
System (IS-IS) Extension for Traffic Engineering, October 2008. | "Intermediate system to intermediate system intra- | |||
domain-routing routine information exchange protocol | ||||
for use in conjunction with the protocol for | ||||
providing the connectionless-mode Network Service | ||||
(ISO 8473)", ISO Standard 10589, 1992. | ||||
LDP IGP Synchronization December 2008 | [LDP-Fail-Rec] Fang, L., Atlas, A., Chiussi, F., Kompella, K., and | |||
G. Swallow, "LDP Failure Detection and Recovery", | ||||
IEEE Communications Magazine, Vol.42, No.10, October | ||||
2004. | ||||
[ISO.10589.1992]International Organization for | [MPLS-GMPLS-Sec] Fang. L., Ed., "Security Framework for MPLS and | |||
Standardization,"Intermediate system to intermediate system intra- | GMPLS Networks", Work in Progress, November 2008. | |||
domain-routing routine information exchange protocol for use in | ||||
conjunction with the protocol for providing the connectionless-mode | ||||
Network Service (ISO 8473)", ISO Standard 10589, 1992. | ||||
[LDP Failure Recovery] Fang, L., Atlas, A., Chiussi, F., Kompella, | [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. | |||
K., and Swallow, G., "LDP Failure Detection and Recovery", IEEE | McPherson, "OSPF Stub Router Advertisement", RFC | |||
Communications Magazine, Vol.42, No.10, October 2004. | 3137, June 2001. | |||
[LDP End-of-LIB] Asati, R., LDP End-of-LIB, draft-ietf-mpls-ldp- | [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic | |||
end-of-lib-01.txt, work in progress, September 2008. | Engineering", RFC 5305, October 2008. | |||
[MPLS-GMPLS-Security] Fang. L., Ed., "Security Framework for MPLS | 7. Acknowledgments | |||
and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-security- | ||||
framework-04.txt, work in progress, November 2008. | ||||
9. Authors' Addresses | The authors would like to thank Bruno Decraene for his in-depth | |||
discussion and comments, Dave Ward for his helpful review and input, | ||||
and Loa Andersson, Ross Callon, Amanda Baber, Francis Dupont, Donald | ||||
Eastlake, Russ Housley, Pasi Eronen, Dan Romascanu, Bin Mo, Lan | ||||
Zheng, Bob Thomas, and Dave Ojemann for their reviews and comments. | ||||
Authors' Addresses | ||||
Markus Jork | Markus Jork | |||
NextPoint Networks | GENBAND | |||
3 Fedral St. | 3 Federal St. | |||
Billerica, MA 01821 | Billerica, MA 01821 | |||
USA | USA | |||
Email: mjork@nextpointnetworks.com | ||||
EMail: Markus.Jork@genband.com | ||||
Alia Atlas | Alia Atlas | |||
British Telecom | British Telecom | |||
Email: alia.atlas@bt.com | ||||
EMail: alia.atlas@bt.com | ||||
Luyuan Fang | Luyuan Fang | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
300 Beaver Brook Road | 300 Beaver Brook Road | |||
Boxborough, MA 01719 | Boxborough, MA 01719 | |||
USA | USA | |||
Email: lufang@cisco.com | ||||
Phone: 1 (978) 936-1633 | ||||
10. Acknowledgments | EMail: lufang@cisco.com | |||
Phone: 1 (978) 936-1633 | ||||
Funding for the RFC Editor function is provided by the IETF | ||||
Administrative Support Activity (IASA). | ||||
The authors would like to thank Bruno Decraene for his in depth | ||||
discussion and comments; thank Dave Ward for his helpful review and | ||||
input; and thank Loa Andersson, Ross Callon, Amanda Baber, Francis | ||||
Dupont, Donald Eastlake, Russ Housley, Pasi Eronen, Dan Romascanu, | ||||
LDP IGP Synchronization December 2008 | ||||
Bin Mo, Lan Zheng, Bob Thomas, and Dave Ojemann for their review | ||||
and comments. | ||||
End of changes. 54 change blocks. | ||||
210 lines changed or deleted | 181 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |