draft-ietf-mpls-ldp-interarea-02.txt   draft-ietf-mpls-ldp-interarea-03.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-02.txt France Telecom Document: draft-ietf-mpls-ldp-interarea-03.txt France Telecom
Expiration Date: August 2008 Intended status: Standards Track
I. Minei Expiration Date: August 2008 I. Minei
Juniper Networks, Inc. Juniper Networks, Inc.
February 2008 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
skipping to change at page 3, line 5 skipping to change at page 3, line 5
3. Introduction 3. Introduction
Link state IGPs such as OSPF [OSPFv2] and IS-IS [IS-IS] allow the Link state IGPs such as OSPF [OSPFv2] and IS-IS [IS-IS] allow the
partition of an autonomous system into areas or levels so as to partition of an autonomous system into areas or levels so as to
increase routing scalability within a routing domain. increase routing scalability within a routing domain.
However, [LDP] requires that the IP address of the FEC Element should However, [LDP] requires that the IP address of the FEC Element should
*exactly* match an entry in the IP RIB: according to [LDP] section *exactly* match an entry in the IP RIB: according to [LDP] section
3.5.7.1 (Label Mapping Messages Procedures) "An LSR receiving a Label 3.5.7.1 (Label Mapping Messages Procedures) "An LSR receiving a Label
Mapping message from a downstream LSR for a Prefix or Host Address Mapping message from a downstream LSR for a Prefix SHOULD NOT use the
FEC Element should not use the label for forwarding unless its label for forwarding unless its routing table contains an entry that
routing table contains an entry that exactly matches the FEC exactly matches the FEC Element.".
Element".
Therefore, MPLS LSPs between LERs in different areas/levels are not Therefore, MPLS LSPs between LERs in different areas/levels are not
setup unless the exact (/32 for IPv4) loopback addresses of all the setup unless the specific (e.g. /32 for IPv4) loopback addresses of
LERs are redistributed across all areas. all the LERs are redistributed across all areas.
The problem statement is discussed in section 4. Then, in section 5 The problem statement is discussed in section 4. Then, in section 5
we extend the Label Mapping Procedure defined in [LDP] so as to we extend the Label Mapping Procedure defined in [LDP] so as to
support the setup of contiguous inter-area LSPs while maintaining IP support the setup of contiguous inter-area LSPs while maintaining IP
prefix aggregation on the ABRs. This basically consists of allowing prefix aggregation on the ABRs. This basically consists of allowing
for "Longest Match Based" Label Mapping. for "Longest Match Based" Label Mapping.
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
skipping to change at page 3, line 38 skipping to change at page 3, line 37
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 specific 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
an exact match for its FEC and sets up the LSP. an exact match for its FEC and sets up the LSP.
As a consequence, the potential benefits that a multi-area domain may As a consequence, the potential benefits that a multi-area domain may
yield are significantly diminished since a lot of addresses have to yield are significantly diminished since a lot of addresses have to
be redistributed by ABRs, and the number of IP entries in the LSDB be redistributed by ABRs, and the number of IP entries in the LSDB
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
skipping to change at page 4, line 20 skipping to change at page 4, line 19
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
avoiding leaking of /32 PE loopback addresses across area boundaries, avoiding leaking of specific PE loopback addresses across area
and hence keeping all the benefits of IGP hierarchy. boundaries, and hence keeping all the benefits of IGP hierarchy.
In that context, this document defines a new LDP Label Mapping In that context, this document defines a new LDP Label Mapping
Procedure so as to support the setup of contiguous inter-area LSPs Procedure so as to support the setup of contiguous inter-area LSPs
while maintaining IP prefix aggregation on the ABRs. This procedure while maintaining IP prefix aggregation on the ABRs. This procedure
is similar to the one defined in [LDP] but performs a longest match is similar to the one defined in [LDP] but performs a longest match
when searching the FEC element in the RIB. when searching the FEC element in the RIB.
5. Label Mapping Procedure 5. Label Mapping Procedure
This document defines a new label mapping procedure for LDP. It MUST This document defines a new label mapping procedure for [LDP]. It is
be possible to activate/deactivate this procedure by configuration applicable to IPv4 and IPv6 prefix FEC elements (addresses families 1
and it SHOULD be deactivated by default. It MAY be possible to and 2 as per [ASSIGNED_AF]). It MUST be possible to activate /
activate it on a per prefix basis. deactivate this procedure by configuration and it SHOULD be
deactivated by default. It MAY be possible to activate it on a per
prefix basis.
With this new longest match label mapping procedure, a LSR receiving With this new longest match label mapping procedure, a LSR receiving
a Label Mapping message from a neighbor LSR for a Prefix Address FEC a Label Mapping message from a neighbor LSR for a Prefix Address FEC
Element (FEC1) SHOULD use the label for MPLS forwarding if its Element (FEC1) SHOULD use the label for MPLS forwarding if its
routing table contains an entry that matches the FEC Element and the routing table contains an entry that matches the FEC Element and the
advertising LSR is a next hop to reach the FEC. If so, it SHOULD advertising LSR is a next hop to reach the FEC. If so, it SHOULD
advertise the received FEC Element (FEC1) and a label to its LDP advertise the received FEC Element (FEC1) and a label to its LDP
peers. peers.
Note that this is the specific FEC (FEC1) that LDP re-advertise to Note that this is the specific FEC (FEC1) that LDP re-advertise to
its peers, and not the aggregated prefix found in the IP RIB during its peers, and not the aggregated prefix found in the IP RIB during
skipping to change at page 5, line 10 skipping to change at page 5, line 10
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 are FECs selected by this "Longest Match" label mapping procedure are
distributed in an ordered way.. distributed in an ordered way. In case of LER failure, the removal of
In case of LER failure, the removal of reachability to the FEC occurs reachability to the FEC occurs using standard LDP procedures as
using standard LDP procedures as defined in [LDP]. Similarly, the FEC defined in [LDP]. Similarly, the FEC will be removed in an ordered
will be removed in an ordered way through the propagation of label way through the propagation of label withdraw messages. The use of
withdraw messages. The use of this reachability information by this (un)reachability information by application layers using the
application layers using the MPLS LSP (e.g., BGP) is outside the MPLS LSP (e.g., BGP) is outside the scope of this document.
scope of this document.
As per [LDP], 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 this longest match procedure, multiple FECs may be concerned by
single RIB prefix change. The LSR must check all the FECs which are a a single RIB prefix change. The LSR must check all the FECs which are
subset of this RIB prefix. So some LDP reactions following a RIB a subset of this RIB prefix. So some LDP reactions following a RIB
event are changed: event are changed:
- When a new prefix appears in the RIB, the LSR MUST check if this - When a new prefix appears in the RIB, the LSR MUST check if this
prefix is a better match for some existing FECs. E.g. the FEC prefix is a better match for some existing FECs. E.g. the FEC
elements 192.0.2.1/32 and 192.0.2.2/32 used the IP RIB entry elements 192.0.2.1/32 and 192.0.2.2/32 used the IP RIB entry
192.0.0/16 and a new more specific IP RIB entry 192.0.2/24 192.0.0/16 and a new more specific IP RIB entry 192.0.2/24
appears. This may result in changing the LSR used as next hop appears. This may result in changing the LSR used as next hop
and hence the NHLFE for this FEC. and hence the NHLFE for this FEC.
- When a prefix disappears in the RIB, the LSR MUST check all FEC - When a prefix disappears in the RIB, the LSR MUST check all FEC
elements which are using this RIB prefix as best match. For each elements which are using this RIB prefix as best match. For each
FEC, if another RIB prefix is found as best match, LDP MUST use FEC, if another RIB prefix is found as best match, LDP MUST use
skipping to change at page 6, line 30 skipping to change at page 6, line 30
+----------+ +-------------+ +----------+ +-------------+
| | | |
+--------------------------+ +--------------------------+
Figure 1: An IGP domain with two areas attached to the Backbone Figure 1: An IGP domain with two areas attached to the Backbone
Area. Area.
Note that this applies equally to IS-IS and OSPF. An ABR refers here Note that this applies equally to IS-IS and OSPF. An ABR refers here
either to an OSPF ABR or to an IS-IS L1/L2 node. either to an OSPF ABR or to an IS-IS L1/L2 node.
All routers are MPLS enabled and MPLS connectivity (ie an LSP) is All routers are MPLS enabled and MPLS connectivity (i.e. an LSP) is
required between all PE routers. required between all PE routers.
In the "egress" area "C", the records available are: In the "egress" area "C", the records available are:
IGP RIB LDP FEC elements: IGP RIB LDP FEC elements:
192.0.2.1/32 192.0.2.1/32 192.0.2.1/32 192.0.2.1/32
192.0.2.2/32 192.0.2.2/32 192.0.2.2/32 192.0.2.2/32
192.0.2.3/32 192.0.2.3/32 192.0.2.3/32 192.0.2.3/32
The area border router ABR1 advertises in the backbone area: The area border router ABR1 advertises in the backbone area:
- the aggregated IP prefix 192.0.2/24 in the IGP - the aggregated IP prefix 192.0.2/24 in the IGP
- all the individual IP FEC elements (/32) in LDP - all the specific IP FEC elements (/32) in LDP
In the "backbone" area "B", the records available are: In the "backbone" area "B", the records available are:
IGP RIB LDP FEC elements: IGP RIB LDP FEC elements:
192.0.2/24 192.0.2.1/32 192.0.2/24 192.0.2.1/32
192.0.2.2/32 192.0.2.2/32
192.0.2.3/32 192.0.2.3/32
The area border router ABR2 advertises in the area "A": The area border router ABR2 advertises in the area "A":
- an aggregated IP prefix 192.0/16 in the IGP - an aggregated IP prefix 192.0/16 in the IGP
- all the individual IP FEC elements (/32) in LDP - all the individual IP FEC elements (/32) in LDP
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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 A service provider currently leaking specific LER's loopback
addresses in the IGP and now considering performing IP aggregation on addresses in the IGP and now considering performing IP aggregation on
ABR should be aware that this may result in suboptimal routing as ABR should be aware that this may result in suboptimal routing as
discussed in [RFC 2966]. discussed in [RFC 2966].
If all IP prefixes are leaked in the IGP backbone area and only stub This extension does not necessarily require an AS wide deployment but
areas use IP aggregation, LSRs in the backbone area don't need to be can be used on a per area basis. For example, if all specific IP
compliant with this document. 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 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 link state 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 carry 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. So application notification of node failure outside of the area. So application
layers using the LSP may, as a local decision, use the availability layers using the LSP may, as a local decision, use the availability
of the MPLS LSP -as advertised by LDP- to achieve LER egress fault of the MPLS LSP -as advertised by LDP- to achieve LER egress fault
notification in addition to application layer fault detection notification in addition to application layer fault detection
mechanisms. For some applications (e.g., BGP) this is expected to be 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 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. way through the end-to-end propagation of the LDP withdraw message.
Compared to the IGP, this LDP failure notification may be faster or 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.
skipping to change at page 9, line 12 skipping to change at page 9, line 12
This document has no actions for IANA. This document has no actions for IANA.
10. References 10. References
10.1. Normative References 10.1. Normative References
[LDP] L. Andersson, I. Minei, B. Thomas, "LDP Specification", [LDP] L. Andersson, I. Minei, B. Thomas, "LDP Specification",
RFC 5036, October 2007 RFC 5036, October 2007
[ASSIGNED_AF] http://www.iana.org/assignments/address-family-
numbers
10.2. Informative References 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
skipping to change at page 10, line 5 skipping to change at page 10, line 5
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, Clarence Filsfils, Kireeti Kompella, Luca Kompella, Bob Thomas, Clarence Filsfils, Kireeti Kompella, Luca
Martini, Sina Mirtorabi, Dave McDysan, Benoit Fondeviole, Gilles Martini, Sina Mirtorabi, Dave McDysan, Benoit Fondeviole, Gilles
Bourdon and Christian Jacquenet for the useful discussions on this Bourdon and Christian Jacquenet for the useful discussions on this
subject, their review and comments. subject, their review and comments.
Authors' Addresses 12. Authors' Addresses
Bruno Decraene Bruno Decraene
France Telecom France Telecom
38 rue du General Leclerc 38 rue du General Leclerc
92794 Issy Moulineaux cedex 9 92794 Issy Moulineaux cedex 9
France France
EMail: bruno.decraene@orange-ftgroup.com EMail: bruno.decraene@orange-ftgroup.com
Jean-Louis Le Roux Jean-Louis Le Roux
skipping to change at page 10, line 28 skipping to change at page 10, line 28
22307 Lannion Cedex 22307 Lannion Cedex
France France
EMail: 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
EMail: 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
 End of changes. 17 change blocks. 
36 lines changed or deleted 41 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/