| < draft-ietf-mpls-ldp-igp-sync-03.txt | draft-ietf-mpls-ldp-igp-sync-04.txt > | |||
|---|---|---|---|---|
| Network Working Group M. Jork | Network Working Group M. Jork | |||
| Internet Draft NextPoint Networks | Internet Draft NextPoint Networks | |||
| Category: Informational Alia Atlas | Category: Informational Alia Atlas | |||
| Expires: May 2008 British Telecom | Expires: June 17, 2009 British Telecom | |||
| L. Fang | L. Fang | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| November 3, 2008 | December 17, 2008 | |||
| LDP IGP Synchronization | LDP IGP Synchronization | |||
| draft-ietf-mpls-ldp-igp-sync-03.txt | 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 | ||||
| not specify an Internet standard of any kind. Distribution of this | ||||
| memo is unlimited. | ||||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six | |||
| months and may be updated, replaced, or obsoleted by other | months and may be updated, replaced, or obsoleted by other documents | |||
| documents at any time. It is inappropriate to use Internet-Drafts | at any time. It is inappropriate to use Internet-Drafts as | |||
| as reference material or to cite them other than as "work in | reference material or to cite them other than as "work in progress." | |||
| progress." | ||||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| Copyright Notice | This Internet-Draft will expire on June 18, 2009. | |||
| Copyright (C) The IETF Trust (2008). | ||||
| Abstract | Copyright and License Notice | |||
| In certain networks there is a dependency on edge-to-edge LSPs setup | Copyright (c) 2008 IETF Trust and the persons identified as the | |||
| by LDP, e.g. networks that are used for MPLS VPN applications. For | document authors. All rights reserved. | |||
| such applications it is not possible to rely on IP forwarding if the | ||||
| MPLS LSP is not operating appropriately. Blackholing of labeled | ||||
| traffic can occur in situations where the IGP is operational on a | ||||
| link but LDP is not operational on that link. While the link could | ||||
| still be used for IP forwarding, it is not useful for MPLS | ||||
| LDP IGP Synchronization November 2008 | ||||
| forwarding, for example, MPLS VPN; BGP route free core; or IP | LDP IGP Synchronization December 2008 | |||
| address carried in the packet is out of the RFC1918 space. This | ||||
| document describes a mechanism to avoid traffic loss due to this | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| condition without introducing any protocol changes. | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | ||||
| publication of this document. Please review these documents | ||||
| carefully, as they describe your rights and restrictions with | ||||
| respect to this document. | ||||
| Abstract | ||||
| In certain networks there is a dependency on edge-to-edge Label | ||||
| Switched Paths (LSPs) setup by Label Distribution Protocol (LDP), | ||||
| e.g., networks that are used for MultiProtocol Label Switching | ||||
| (MPLS) Virtual Private Network (VPN) applications. For such | ||||
| applications it is not possible to rely on Internet Protocol (IP) | ||||
| forwarding if the MPLS LSP is not operating appropriately. | ||||
| Blackholing of labeled traffic can occur in situations where the | ||||
| Interior Gateway Protocol (IGP) is operational on a link but LDP is | ||||
| not operational on that link. While the link could still be used for | ||||
| IP forwarding, it is not useful for MPLS forwarding, for example, | ||||
| MPLS VPN; Border Gateway Protocol (BGP) route free core; or IP | ||||
| address carried in the packet is out of the RFC 1918 [RFC 1918] | ||||
| space. This document describes a mechanism to avoid traffic loss due | ||||
| to this condition without introducing any protocol changes. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction..................................................2 | 1. Introduction..................................................3 | |||
| 2. Proposed Solution.............................................3 | 2. Proposed Solution.............................................3 | |||
| 3. Applicability.................................................4 | 3. Applicability.................................................5 | |||
| 4. Interaction With TE Tunnels...................................5 | 4. Interaction with TE Tunnels...................................5 | |||
| 5. Security Considerations.......................................5 | 5. Security Considerations.......................................6 | |||
| 6. IANA Considerations...........................................5 | 6. IANA Considerations...........................................6 | |||
| 7. Normative References..........................................6 | 7. Normative References..........................................6 | |||
| 8. Informational References......................................6 | 8. Informational References......................................6 | |||
| 9. Author's Addresses............................................6 | 9. Authors' Addresses............................................7 | |||
| 10. Acknowledgements.............................................8 | 10. Acknowledgments..............................................7 | |||
| Conventions used in this document | Conventions used in this document | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | |||
| this document are to be interpreted as described in RFC2119 [RFC | this document are to be interpreted as described in RFC2119 [RFC | |||
| 2119]. | 2119]. | |||
| LDP IGP Synchronization December 2008 | ||||
| 1. Introduction | 1. Introduction | |||
| LDP [RFC5036] 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 OSPF [RFC2328] or | complete network domain covered by an IGP such as Open Shortest | |||
| IS-IS [ISO.10589.1992], i.e. all links in the domain MAY have IGP | Path First (OSPF) [RFC 2328] or Intermediate system to intermediate | |||
| as well as LDP adjacencies. | system (IS-IS) [ISO.10589.1992], i.e., all links in the domain have | |||
| IGP as 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 switched paths. In a L2 or L3 VPN scenario for example, a | label switched paths. In a layer 2 (L2) or layer 3 (L3) VPN | |||
| given PE router relies on the availability of a complete MPLS | scenario for example, a given Provider-Edge(PE) router relies on | |||
| forwarding path to the other PE routers for the VPNs it serves. | the availability of a complete MPLS forwarding path to the other PE | |||
| This means that along the IP shortest path from one PE router to | routers for the VPNs it serves. This means that along the IP | |||
| the other, all the links need to have operational LDP sessions and | shortest path from one PE router to the other, all the links need | |||
| the necessary label binding must have been exchanged over those | to have operational LDP sessions and the necessary label binding | |||
| sessions. If only one link along the IP shortest path is not | must have been exchanged over those sessions. If only one link | |||
| covered by an LDP session, a blackhole exists and services | along the IP shortest path is not covered by an LDP session, a | |||
| depending on MPLS forwarding will fail. This might be a transient | blackhole exists and services depending on MPLS forwarding will | |||
| LDP IGP Synchronization November 2008 | fail. This might be a transient or a persistent error condition. | |||
| Some of the reasons for it could be | ||||
| or a persistent error condition. 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 | |||
| distributed all the label bindings. | distributed all the label bindings. | |||
| LDP protocol has currently no way to correct the issue, LDP is not | LDP protocol has currently no way to correct the issue, LDP is not | |||
| a routing protocol; it can not re-direct traffic to an alternate | a routing protocol; it cannot re-direct traffic to an alternate IGP | |||
| IGP path. | path. | |||
| 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 IP | |||
| forwarding decisions but no coupling between the IGP and LDP | 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 link but LDP is not, a potential network problem exists. So the | a 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. | |||
| This has some similarity to the mechanism specified in [RFC3137] | LDP IGP Synchronization December 2008 | |||
| This has some similarity to the mechanism specified in [RFC 3137] | ||||
| 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 [RFC3137] 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 in here applies on a per-link basis. | described in 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 link, the IGP will advertise the link with maximum cost to | given link, the IGP will advertise the link with maximum cost to | |||
| avoid any transit traffic over it if possible. In the case of | avoid any transit traffic over it if possible. In the case of | |||
| OSPF, this cost is LSInfinity (16-bit value 0xFFFF) as proposed in | OSPF, this cost is LSInfinity (16-bit value 0xFFFF) as proposed in | |||
| [RFC3137]. In the case of ISIS, the max metric value is 2^24-2 | [RFC 3137]. In the case of ISIS, the max metric value is 2^24-2 | |||
| (0xFFFFFE). Indeed, if a link is configured with 2^24-1 (the | (0xFFFFFE). Indeed, if a link is configured with 2^24-1 (the | |||
| maximum link metric per [RFC3784]) then this link is not advertised | maximum link metric per [RFC 5305]) then this link is not | |||
| in the topology. It is important to keep the link in the topology | advertised in the topology. It is important to keep the link in the | |||
| to allow for IP traffic to use the link as a last resort in case of | topology to allow for IP traffic to use the link as a last resort | |||
| 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 at the other end of the link and all label bindings have been | peer 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 | |||
| LDP IGP Synchronization November 2008 | condition cannot generally be verified by a router and some | |||
| condition can not generally be verified by a router and some | ||||
| estimated may have to be used. A simple implementation strategy is | estimated 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 the concerns of the | |||
| large variations of the LIB table size and the equipment | large variations of the Label Information Base (LIB) table size and | |||
| capabilities. In addition, this is a current work in progress on LDP | the equipment capabilities. In addition, this is a current work in | |||
| End-of-LIB as specified in [LDP End-of-LIB], it enables the LDP | progress on LDP End-of-LIB as specified in [LDP End-of-LIB], it | |||
| speaker to signal the completion of its initial advertisement | enables the LDP speaker to signal the completion of its initial | |||
| following session establish. When LDP End-of-LIB is implemented, the | advertisement following session establish. When LDP End-of-LIB is | |||
| configurable hold down timer is no longer needed. The neighbor LDP | implemented, the configurable hold down timer is no longer needed. | |||
| session is considered fully operational when the End-of-LIB | The neighbor LDP session is considered fully operational when the | |||
| 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 changes and is a local implementation issue. | protocol 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-Fail]. | been discussed in an IEEE Communications Magazine paper [LDP | |||
| Failure Recovery]. | ||||
| 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 is 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 up or when there is a genuine problem on a link. In the | comes up or when there is a genuine problem on a link. In the | |||
| latter case an implementation should issue network management alerts | latter case an implementation should issue network management alerts | |||
| skipping to change at page 5, line 5 ¶ | skipping to change at page 5, line 28 ¶ | |||
| 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 alternate paths with sufficient bandwidth in the network should | of alternate paths with sufficient bandwidth in the network should | |||
| one link be assigned to the maximum cost due to unavailability of | one link be assigned to the maximum cost due to unavailability of | |||
| LDP service over it. | LDP service over it. | |||
| LDP IGP Synchronization November 2008 | ||||
| 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 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 which 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. | any 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 problem very similar to the case of a regular LDP session over a | a problem very similar to the case of a regular LDP session over a | |||
| link (the case discussed so far): when the TE tunnel is used for IP | link (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 LDP connectivity problems. Again, raising the IP cost of the | avoid LDP connectivity problems. Again, raising the IP cost of the | |||
| tunnel while there is no operational LDP session will solve the | tunnel while there is no operational LDP session will solve the | |||
| problem. When there is no IGP adjacency over the tunnel and the | problem. When there is no IGP adjacency over the tunnel and the | |||
| tunnel is not advertised as link into the IGP, this becomes a local | tunnel is not advertised as link into the IGP, this becomes a local | |||
| issue of the tunnel headend router. | issue of the tunnel headend router. | |||
| LDP IGP Synchronization December 2008 | ||||
| 5. Security Considerations | 5. Security Considerations | |||
| A DoS attack brings down LDP service on a link or prevents it from | A DoS attack that brings down LDP service on a link or prevents it | |||
| becoming operational on a link could be one of the possibilities | from becoming operational on a link could be one of the | |||
| that causes LDP related traffic blackholing. This document does not | possibilities that causes LDP related traffic blackholing. This | |||
| address how to prevent LDP session failure. The mechanism described | document does not address how to prevent LDP session failure. The | |||
| here is to prevent the link to be used when LDP is not operational | mechanism described here prevents the use of the link when LDP is | |||
| while IGP is. Assigning the IGP cost to maximum on the link where | not operational while IGP is. Assigning the IGP cost to maximum on | |||
| LDP is failed and IGP is not should not introduce new security | the link where LDP is failed and IGP is not should not introduce | |||
| threats. The operation is internal in the router to allow LDP and | new security threats. The operation is internal in the router to | |||
| IGP to communicate and react. Making many LDP links unavailable, | allow LDP and IGP to communicate and react. Making many LDP links | |||
| however, is a security threat which can cause traffic being dropped | unavailable, however, is a security threat which can cause traffic | |||
| due to limited available network capacity. This may be trigged by | being dropped due to limited available network capacity. This may | |||
| operational error or implementation error. They are considered as | be triggered by operational error or implementation error. They are | |||
| general Security issues and should follow the current best security | considered as general Security issues and should follow the current | |||
| practice. | best security practice [MPLS-GMPLS-Security]. | |||
| 6. IANA Considerations | 6. IANA Considerations | |||
| LDP IGP Synchronization November 2008 | ||||
| This document has no actions for IANA. | This document has no actions for IANA. | |||
| 7. Normative References | 7. Normative References | |||
| [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., | [RFC 5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., | |||
| and B. Thomas, "LDP Specification", RFC 5036, October 2007. | and B. Thomas, "LDP Specification", RFC 5036, October 2007. | |||
| [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | [RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April | |||
| 1998. | ||||
| 8. Informational References | 8. Informational References | |||
| [RFC 1918] Rekhter, Y., "Address Allocation for Private Internets", | ||||
| BCP: 5, RFC 1918, February 1996. | ||||
| [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997 | Requirement Levels", BCP 14, RFC 2119, March 1997 | |||
| [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. | [RFC 3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. | |||
| McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001. | McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001. | |||
| [RFC3784] Smit, H., Li, T., Intermediate System to Intermediate | [RFC 5305] Li, T., Smit, H., Intermediate System to Intermediate | |||
| System (IS-IS) Extension for Traffic Engineering, June 2004. | System (IS-IS) Extension for Traffic Engineering, October 2008. | |||
| LDP IGP Synchronization December 2008 | ||||
| [ISO.10589.1992]International Organization for | [ISO.10589.1992]International Organization for | |||
| Standardization,"Intermediate system to intermediate system intra- | Standardization,"Intermediate system to intermediate system intra- | |||
| domain-routing routine information exchange protocol for use in | domain-routing routine information exchange protocol for use in | |||
| conjunction with the protocol for providing the connectionless-mode | conjunction with the protocol for providing the connectionless-mode | |||
| Network Service (ISO 8473)", ISO Standard 10589, 1992. | Network Service (ISO 8473)", ISO Standard 10589, 1992. | |||
| [LDP-Fail] Fang, L., Atlas, A., Chiussi, F., Kompella, K., and | [LDP Failure Recovery] Fang, L., Atlas, A., Chiussi, F., Kompella, | |||
| Swallow, G., "LDP Failure Detection and Recovery", IEEE | K., and Swallow, G., "LDP Failure Detection and Recovery", IEEE | |||
| Communications Magazine, Vol.42, No.10, October 2004. | Communications Magazine, Vol.42, No.10, October 2004. | |||
| [LDP End-of-LIB] Asati, R., LDP End-of-LIB, draft-ietf-mpls-ldp- | [LDP End-of-LIB] Asati, R., LDP End-of-LIB, draft-ietf-mpls-ldp- | |||
| end-of-lib-01.txt, September 2008. | end-of-lib-01.txt, work in progress, September 2008. | |||
| 9. Author's Addresses | [MPLS-GMPLS-Security] Fang. L., Ed., "Security Framework for MPLS | |||
| and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-security- | ||||
| framework-04.txt, work in progress, November 2008. | ||||
| 9. Authors' Addresses | ||||
| Markus Jork | Markus Jork | |||
| NextPoint Networks | NextPoint Networks | |||
| 3 Fedral St. | 3 Fedral St. | |||
| Billerica, MA 01821 | Billerica, MA 01821 | |||
| USA | USA | |||
| Email: mjork@nextpointnetworks.com | Email: mjork@nextpointnetworks.com | |||
| Alia Atlas | Alia Atlas | |||
| British Telecom | British Telecom | |||
| Email: alia.atlas@bt.com | Email: alia.atlas@bt.com | |||
| LDP IGP Synchronization November 2008 | ||||
| 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 | Email: lufang@cisco.com | |||
| Phone: 1 (978) 936-1633 | ||||
| Full Copyright Statement | 10. Acknowledgments | |||
| Copyright (C) The IETF Trust (2008). | ||||
| 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. | ||||
| LDP IGP Synchronization November 2008 | ||||
| 10. Acknowledgements | ||||
| Funding for the RFC Editor function is provided by the IETF | Funding for the RFC Editor function is provided by the IETF | |||
| Administrative Support Activity (IASA). | Administrative Support Activity (IASA). | |||
| The authors would like to thank Loa Andersson for his review and | The authors would like to thank Bruno Decraene for his in depth | |||
| comments, thank Bruno Decraene for his in depth discussion, | discussion and comments; thank Dave Ward for his helpful review and | |||
| comments and helpful suggestions, and thank Dave Ward for his AD | input; and thank Loa Andersson, Ross Callon, Amanda Baber, Francis | |||
| review comments and suggestions. | 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. 44 change blocks. | ||||
| 143 lines changed or deleted | 134 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||