draft-ietf-mpls-ldp-interarea-01.txt   draft-ietf-mpls-ldp-interarea-02.txt 
Network Working Group B. Decraene Network Working Group B. Decraene
Internet Draft J.L. Le Roux Internet Draft J.L. Le Roux
Document: draft-ietf-mpls-ldp-interarea-01.txt France Telecom Document: draft-ietf-mpls-ldp-interarea-02.txt France Telecom
Expiration Date: August 2008
I. Minei I. Minei
Juniper Networks, Inc. Juniper Networks, Inc.
November 2007 February 2008
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.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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. IANA Considerations.........................................8 9. IANA Considerations.........................................8
10. References..................................................8 10. References..................................................9
10.1. Normative References........................................8 10.1. Normative References........................................9
10.2. Informative References......................................8 10.2. Informative References......................................9
11. Acknowledgments.............................................9 11. Acknowledgments.............................................9
12. Author's Addresses..........................................9 12. Author's Addresses.........................................10
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 5, line 9 skipping to change at page 5, line 9
By "matching FEC Element", one should understand an IP longest match. By "matching FEC Element", one should understand an IP longest match.
That is, either the LDP FEC element exactly matches an entry in the That is, either the LDP FEC element exactly matches an entry in the
IP RIB or the FEC element is a subset of an IP RIB entry. There is no IP RIB or the FEC element is a subset of an IP RIB entry. There is no
match for other cases such as the FEC element is a superset of a RIB match for other cases such as the FEC element is a superset of a RIB
entry. entry.
Note that with this longest match Label Mapping Procedure, each LSP Note that with this longest match Label Mapping Procedure, each LSP
established by LDP still strictly follows the shortest path(s) established by LDP still strictly follows the shortest path(s)
defined by the IGP. defined by the IGP.
FECs selected by this "Longest Match" label mapping procedure will be FECs selected by this "Longest Match" label mapping procedure are
distributed in an ordered way. However this procedure is applicable distributed in an ordered way..
to both independent and ordered distribution control mode. In case of LER failure, the removal of reachability to the FEC occurs
using standard LDP procedures as defined in [LDP]. Similarly, the FEC
will be removed in an ordered way through the propagation of label
withdraw messages. The use of this reachability information by
application layers using the MPLS LSP (e.g., BGP) is outside the
scope of this document.
As per RFC 3036, LDP has already some interactions with the RIB. In As per [LDP], LDP has already some interactions with the RIB. In
particular, it needs to be aware of the following events: particular, it needs to be aware of the following events:
- prefix UP when a new IP prefix appears in the RIB - prefix UP when a new IP prefix appears in the RIB
- prefix DOWN when an existing prefix disappears - prefix DOWN when an existing prefix disappears
- next-hop change when an existing prefix have new next hop - next-hop change when an existing prefix have new next hop
following a routing change. following a routing change.
With the longest match procedure, multiple FECs may be concerned by a With the longest match procedure, multiple FECs may be concerned by a
single RIB prefix change. The LSR must check all the FECs which are a single RIB prefix change. The LSR must check all the FECs which are a
subset of this RIB prefix. So some LDP reactions following a RIB subset of this RIB prefix. So some LDP reactions following a RIB
event are changed: event are changed:
skipping to change at page 7, line 41 skipping to change at page 7, line 41
The LDP specification defined in [LDP] would require on the ingress The LDP specification defined in [LDP] would require on the ingress
LER the configuration and the maintenance of one IP route per egress LER the configuration and the maintenance of one IP route per egress
LER and per outgoing interface. LER and per outgoing interface.
The longest match Label Mapping Procedure described in this document The longest match Label Mapping Procedure described in this document
only requires one IP route per outgoing interface. only requires one IP route per outgoing interface.
7. Caveats for deployment 7. Caveats for deployment
7.1. Deployment consideration 7.1. Deployment considerations
LSRs compliant with this document are backward compatible with LSRs LSRs compliant with this document are backward compatible with LSRs
that comply with [LDP]. that comply with [LDP].
For the successful establishment of end-to-end MPLS LSPs whose FEC For the successful establishment of end-to-end MPLS LSPs whose FEC
are aggregated in the RIB, this specification must be implemented on are aggregated in the RIB, this specification must be implemented on
all LSRs in all areas where IP aggregation is used. If an LSR on the all LSRs in all areas where IP aggregation is used. If an LSR on the
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.
A service provider currently leaking specific (/32) LER's loopback
addresses in the IGP and now considering performing IP aggregation on
ABR should be aware that this may result in suboptimal routing as
discussed in [RFC 2966].
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 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 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 is the number of Nodes. The FIB/LFIB update scales O(P) where P is
the number of modified prefixes. Currently, with most routers the number of modified prefixes. Currently, with most routers
implementations, the FIB/LFIB update is the dominant component [1]. implementations, the FIB/LFIB update is the dominant component [1].
The solution documented in this draft reduces the Linkstate database The solution documented in this draft reduces the Linkstate database
size and the number of FIB entries. However, it does not decrease the size and the number of FIB entries. However, it does not decrease the
number of LFIB entries. 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 carry 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. So application
notification will rely on LDP. The FEC(s) of the egress LER will be layers using the LSP may, as a local decision, use the availability
removed in an ordered way through the end-to-end propagation of the of the MPLS LSP -as advertised by LDP- to achieve LER egress fault
LDP withdraw message. This failure notification may be faster or notification in addition to application layer fault detection
mechanisms. For some applications (e.g., BGP) this is expected to be
faster. LDP will withdraw the FEC(s) of the egress LER in an ordered
way through the end-to-end propagation of the LDP withdraw message.
Compared to the IGP, this LDP 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 or even faster since there convergence time is expected to be similar or even faster since there
is no need to wait for three consecutive SPF/PRC timers. 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 are unchanged. notification and the convergence are unchanged.
8. Security Considerations 8. Security Considerations
skipping to change at page 9, line 19 skipping to change at page 9, line 29
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.
[RFC 2966] Li, T., Przygienda, T., Smit, H., "Domain-wide Prefix
Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[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.
[1] Francois, P., Filsfils, C., and Evans, J. 2005. "Achieving sub- [1] Francois, P., Filsfils, C., and Evans, J. 2005. "Achieving sub-
second IGP convergence in large IP networks". ACM SIGCOMM second IGP convergence in large IP networks". ACM SIGCOMM
11. Acknowledgments 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, Clarence Filsfils, Benoit Kompella, Bob Thomas, Clarence Filsfils, Kireeti Kompella, Luca
Fondeviole, Gilles Bourdon and Christian Jacquenet for the useful Martini, Sina Mirtorabi, Dave McDysan, Benoit Fondeviole, Gilles
discussions on this subject, their review and comments. Bourdon and Christian Jacquenet for the useful discussions on this
subject, their review and comments.
12. Author's Addresses Authors' Addresses
Bruno Decraene Bruno Decraene
France Telecom France Telecom
38-40 rue du General Leclerc 38 rue du General Leclerc
92794 Issy Moulineaux cedex 9 92794 Issy Moulineaux cedex 9
France France
bruno.decraene@orange-ftgroup.com
Jean Louis Le Roux EMail: bruno.decraene@orange-ftgroup.com
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
EMail: 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
EMail: 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
skipping to change at page 10, line 36 skipping to change at page 11, line 7
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
 End of changes. 19 change blocks. 
26 lines changed or deleted 49 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/