draft-ietf-mpls-ldp-interarea-00.txt   draft-ietf-mpls-ldp-interarea-01.txt 
Network Working Group B Decraene Network Working Group B. Decraene
Internet Draft JL Le Roux Internet Draft J.L. Le Roux
Document: draft-ietf-mpls-ldp-interarea-00.txt France Telecom Document: draft-ietf-mpls-ldp-interarea-01.txt France Telecom
Expiration Date: January 2008 I. Minei
I Minei
Juniper Networks, Inc. Juniper Networks, Inc.
November 2007
LDP extension for Inter-Area LSP LDP extension for Inter-Area LSP
Status of this Memo Status of this Memo
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 Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 7 skipping to change at page 2, line 7
document proposes a new optional label mapping procedure for the document proposes a new optional label mapping procedure for the
Label Distribution Protocol (LDP). Label Distribution Protocol (LDP).
This procedure allows the use of a label if the Forwarding This procedure allows the use of a label if the Forwarding
Equivalence Class (FEC) Element matches an entry in the routing table Equivalence Class (FEC) Element matches an entry in the routing table
(RIB). Matching is defined by an IP longest match search and does not (RIB). Matching is defined by an IP longest match search and does not
mandate an exact match. mandate an exact match.
Table of Contents Table of Contents
1. Conventions used in this document..........................2 1. Conventions used in this document...........................2
2. Terminology................................................2 2. Terminology.................................................2
3. Introduction...............................................2 3. Introduction................................................2
4. Problem statement..........................................3 4. Problem statement...........................................3
5. Label Mapping Procedure....................................4 5. Label Mapping Procedure.....................................4
6. Application examples.......................................5 6. Application examples........................................5
6.1. Inter-area LSPs..........................................5 6.1. Inter-area LSPs.............................................5
6.2. Use of static routes.....................................7 6.2. Use of static routes........................................7
7. Caveats for deployment.....................................7 7. Caveats for deployment......................................7
7.1. Deployment consideration.................................7 7.1. Deployment consideration....................................7
7.2. Impact on routing convergence time ......................8 7.2. Impact on routing convergence time..........................8
8. Security Considerations....................................8 8. Security Considerations.....................................8
9. References.................................................8 9. IANA Considerations.........................................8
9.1. Normative References.....................................8 10. References..................................................8
9.2. Informative References ..................................8 10.1. Normative References........................................8
10. Acknowledgments...........................................9 10.2. Informative References......................................8
11. Author's Addresses .......................................9 11. Acknowledgments.............................................9
12. Author's Addresses..........................................9
1. Conventions used in this document 1. 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 this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2. Terminology 2. Terminology
IGP Area: OSPF Area or IS-IS level IGP Area: OSPF Area or IS-IS level
skipping to change at page 3, line 29 skipping to change at page 3, line 29
4. Problem statement 4. Problem statement
Provider based MPLS VPN networks are expanding with the success of Provider based MPLS VPN networks are expanding with the success of
Layer 3 VPN ([L3-VPN]) and the new deployments of layer 2 VPNs Layer 3 VPN ([L3-VPN]) and the new deployments of layer 2 VPNs
([VPLS-BGP], [VPLS-LDP]). Service Provider MPLS backbones are ([VPLS-BGP], [VPLS-LDP]). Service Provider MPLS backbones are
significantly growing both in terms of density with the addition of significantly growing both in terms of density with the addition of
PEs to connect new customers and in terms of footprint as traditional PEs to connect new customers and in terms of footprint as traditional
layer two aggregation networks may be replaced by IP/MPLS networks. layer two aggregation networks may be replaced by IP/MPLS networks.
As a consequence many providers need to introduce IGP areas. Inter- As a consequence many providers need to introduce IGP areas. Inter-
area LSPs, that is LSPs that traverse at least two IGP areas are area LSPs, that is LSPs that traverse at least two IGP areas, are
required to ensure MPLS connectivity between PEs located in distinct required to ensure MPLS connectivity between PEs located in distinct
IGP areas. IGP areas.
To set up the required MPLS LSPs between PEs in different IGP areas, To set up the required MPLS LSPs between PEs in different IGP areas,
services providers have currently three solutions: LDP with IGP route services providers have currently three solutions: LDP with IGP route
leaking, BGP [MPLS-BGP] over LDP with MPLS hierarchy, or also inter- leaking, BGP [MPLS-BGP] over LDP with MPLS hierarchy, or also inter-
area RSVP-TE [ID-RSVP-TE]. area RSVP-TE [ID-RSVP-TE].
IGP route leaking consists in redistributing all /32 PE loopback IGP route leaking consists in redistributing all /32 PE loopback
addresses across area boundaries. As a result, LDP finds in the RIB addresses across area boundaries. As a result, LDP finds in the RIB
skipping to change at page 4, line 4 skipping to change at page 4, line 4
and RIB maintained by every LSR of the domain (whatever the and RIB maintained by every LSR of the domain (whatever the
area/level it belongs to) cannot be minimized. area/level it belongs to) cannot be minimized.
Service providers may also set up these inter-area LSPs by using MPLS Service providers may also set up these inter-area LSPs by using MPLS
hierarchy with BGP [MPLS-BGP] as a label distribution protocol hierarchy with BGP [MPLS-BGP] as a label distribution protocol
between areas. The BGP next hop would typically be the ABRs and the between areas. The BGP next hop would typically be the ABRs and the
BGP-created LSPs would be nested within intra-area LSPs setup by LDP BGP-created LSPs would be nested within intra-area LSPs setup by LDP
between PEs and ABRs and between ABRs. between PEs and ABRs and between ABRs.
This solution is not adequate for Service Providers which don't want This solution is not adequate for Service Providers which don't want
to run BGP on their P routers as it requires BGP on all ABRs. In to run BGP on their P routers as it requires BGP on all ABRs. In
addition, this scheme has an impact on the availability, as the addition, MPLS hierarchy does not allow locally protecting the LSP
recovery upon ABR failure relies on BGP convergence. Also MPLS against ABR failures (IP / LDP Fast Reroute), and hence ensuring sub-
hierarchy does not allow locally protecting the LSP against ABR 50ms recovery upon ABR failure. The resulting convergence time may
failures (LDP Fast Reroute), and hence ensuring sub-50ms recovery not be acceptable for stringent SLAs required for voice or mission
upon ABR failure. The resulting convergence time may not be critical applications. Finally, this solution requires a significant
acceptable for stringent SLAs required for voice or mission critical migration effort for Service Providers which started with LDP and IGP
applications. Finally, this solution requires a significant migration route leaking to quickly set-up the fist inter-area LSPs.
effort for Service Providers which started with LDP and IGP route
leaking to quickly set-up the fist inter-area LSPs.
Service providers may also setup these inter-area LSPs by using Service providers may also setup these inter-area LSPs by using
inter-area RSVP-TE [ID-RSVP-TE]. This is a relevant solution when inter-area RSVP-TE [ID-RSVP-TE]. This is a relevant solution when
RSVP-TE is already used for setting up intra-area LSPs, and inter- RSVP-TE is already used for setting up intra-area LSPs, and inter-
area traffic engineering features are required. In return this is not area traffic engineering features are required. In return this is not
a desired solution when LDP is already used for setting up intra-area a desired solution when LDP is already used for setting up intra-area
LSPs, and inter-area traffic engineering features are not required. LSPs, and inter-area traffic engineering features are not required.
To avoid the above drawbacks, there is a need for an LDP based To avoid the above drawbacks, there is a need for an LDP based
solution which allows setting up contiguous inter-area LSPs while solution which allows setting up contiguous inter-area LSPs while
skipping to change at page 8, line 11 skipping to change at page 8, line 11
path does not support this procedure, then the LSP initiated on the path does not support this procedure, then the LSP initiated on the
egress LSR stops at this non compliant LSR. There are no other egress LSR stops at this non compliant LSR. There are no other
adverse effects. adverse effects.
If all IP prefixes are leaked in the IGP backbone area and only stub If all IP prefixes are leaked in the IGP backbone area and only stub
areas use IP aggregation, LSRs in the backbone area don't need to be areas use IP aggregation, LSRs in the backbone area don't need to be
compliant with this document. compliant with this document.
7.2. Impact on routing convergence time 7.2. Impact on routing convergence time
IGP convergence is based on two factors: the SPF calculation and
FIB/LFIB update time. The SPF calculation scales O(N*Log(N)) where N
is the number of Nodes. The FIB/LFIB update scales O(P) where P is
the number of modified prefixes. Currently, with most routers
implementations, the FIB/LFIB update is the dominant component [1].
The solution documented in this draft reduces the Linkstate database
size and the number of FIB entries. However, it does not decrease the
number of LFIB entries.
In case of failure of the egress LER node, given that the IGP In case of failure of the egress LER node, given that the IGP
aggregates IP route on ABRs, the routing convergence behavior is aggregates IP route on ABRs, the routing convergence behavior is
changed compared to [LDP]. As the IGP does not carries specifics changed compared to [LDP]. As the IGP does not carries specifics
prefixes outside of the egress area, the IGP will not propagate the prefixes outside of the egress area, the IGP will not propagate the
notification of node failure outside of the area and therefore notification of node failure outside of the area and therefore
notification will rely on LDP. The FEC(s) of the egress LER will be notification will rely on LDP. The FEC(s) of the egress LER will be
removed in an ordered way through the end-to-end propagation of the removed in an ordered way through the end-to-end propagation of the
LDP withdraw message. This failure notification may be faster or LDP withdraw message. This failure notification may be faster or
slower depending on the implementations, the IGP timers used and the slower depending on the implementations, the IGP timers used and the
network topology (network diameter). In typical topologies, the network topology (network diameter). In typical topologies, the
convergence time is expected to be similar. convergence time is expected to be similar or even faster since there
is no need to wait for three consecutive SPF/PRC timers.
For all others failures (links, Ps and ABRs nodes), the failure For all others failures (links, Ps and ABRs nodes), the failure
notification and the convergence is unchanged. notification and the convergence are unchanged.
8. Security Considerations 8. Security Considerations
The longest match Label Mapping procedure described in this document The longest match Label Mapping procedure described in this document
does not introduce any change as far as the Security Consideration does not introduce any change as far as the Security Consideration
section of [LDP] is concerned. section of [LDP] is concerned.
9. References 9. IANA Considerations
9.1. Normative References
[LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. This document has no actions for IANA.
Thomas, "LDP Specification", RFC 3036, January 2001
[MPLS] E. Rosen, A. Viswanathan, R. Callon, " Multiprotocol 10. References
Label Switching Architecture", RFC 3031, January 2001
9.2. Informative References 10.1. Normative References
[MP-BGP] Bates, T., Chandra, R., Katz, D. and Rekhter, Y, [LDP] L. Andersson, I. Minei, B. Thomas, "LDP Specification",
"Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. RFC 5036, October 2007
10.2. Informative References
[L3-VPN] Rosen, E., Rekhter, Y. ," BGP/MPLS IP Virtual Private [L3-VPN] Rosen, E., Rekhter, Y. ," BGP/MPLS IP Virtual Private
Networks (VPNs) ", RFC 4374, February 2006 Networks (VPNs) ", RFC 4374, February 2006
[MPLS-BGP] Rekhter, Y., Rosen, E., "Carrying Label Information in [MPLS-BGP] Rekhter, Y., Rosen, E., "Carrying Label Information in
[IS-IS] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and [IS-IS] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", RFC 1195, December 1990 Dual Environments", RFC 1195, December 1990
[VPLS-BGP] Kompella, K., Rekhter, Y., "Virtual Private LAN Service [VPLS-BGP] Kompella, K., Rekhter, Y., "Virtual Private LAN Service
(VPLS) Using BGP for Auto-discovery and Signaling", RFC 4761, (VPLS) Using BGP for Auto-discovery and Signaling", RFC 4761,
January 2007. January 2007.
[VPLS-LDP] Lasserre, M., Kompella, V., "Virtual Private LAN Service [VPLS-LDP] Lasserre, M., Kompella, V., "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC
4762, January 2007. 4762, January 2007.
[ID-RSVP-TE] Farrel, Ayyangar, Vasseur, " Inter domain MPLS and [ID-RSVP-TE] Farrel, Ayyangar, Vasseur, " Inter domain MPLS and
GMPLS Traffic Engineering - RSVP-TE extensions", draft-ietf- GMPLS Traffic Engineering - RSVP-TE extensions", draft-ietf-
ccamp-inter-domain-rsvp-te, work in progress. ccamp-inter-domain-rsvp-te, work in progress.
10. Acknowledgments [1] Francois, P., Filsfils, C., and Evans, J. 2005. "Achieving sub-
second IGP convergence in large IP networks". ACM SIGCOMM
11. Acknowledgments
Authors would like to thank Yakov Rekhter, Stefano Previdi, Vach Authors would like to thank Yakov Rekhter, Stefano Previdi, Vach
Kompella, Bob Thomas, Luca Martini, Benoit Fondeviole, Gilles Bourdon Kompella, Bob Thomas, Luca Martini, Clarence Filsfils, Benoit
and Christian Jacquenet for the useful discussions on this subject, Fondeviole, Gilles Bourdon and Christian Jacquenet for the useful
their review and comments. discussions on this subject, their review and comments.
11. Author's Addresses 12. Author's Addresses
Bruno Decraene Bruno Decraene
France Telecom France Telecom
38-40 rue du General Leclerc 38-40 rue du General Leclerc
92794 Issy Moulineaux cedex 9 92794 Issy Moulineaux cedex 9
France France
bruno.decraene@orange-ftgroup.com bruno.decraene@orange-ftgroup.com
Jean-Louis Le Roux Jean Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
jeanlouis.leroux@orange-ftgroup.com jeanlouis.leroux@orange-ftgroup.com
Ina Minei Ina Minei
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
ina@juniper.net ina@juniper.net
Intellectual Property Considerations Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
 End of changes. 20 change blocks. 
51 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/