draft-ietf-mpls-ldp-dod-02.txt   draft-ietf-mpls-ldp-dod-03.txt 
Network Working Group T. Beckhaus Network Working Group T. Beckhaus
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Informational B. Decraene Intended status: Informational B. Decraene
Expires: January 16, 2013 France Telecom Expires: February 3, 2013 France Telecom
K. Tiruveedhula K. Tiruveedhula
Juniper Networks Juniper Networks
M. Konstantynowicz M. Konstantynowicz
L. Martini L. Martini
Cisco Systems, Inc. Cisco Systems, Inc.
July 15, 2012 August 2, 2012
LDP Downstream-on-Demand in Seamless MPLS LDP Downstream-on-Demand in Seamless MPLS
draft-ietf-mpls-ldp-dod-02 draft-ietf-mpls-ldp-dod-03
Abstract Abstract
Seamless MPLS design enables a single IP/MPLS network to scale over Seamless MPLS design enables a single IP/MPLS network to scale over
core, metro and access parts of a large packet network infrastructure core, metro and access parts of a large packet network infrastructure
using standardized IP/MPLS protocols. One of the key goals of using standardized IP/MPLS protocols. One of the key goals of
Seamless MPLS is to meet requirements specific to access, including Seamless MPLS is to meet requirements specific to access, including
high number of devices, their position in network topology and their high number of devices, their position in network topology and their
compute and memory constraints that limit the amount of state access compute and memory constraints that limit the amount of state access
devices can hold.This can be achieved with LDP Downstream-on-Demand devices can hold.This can be achieved with LDP Downstream-on-Demand
skipping to change at page 2, line 8 skipping to change at page 2, line 8
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2013. This Internet-Draft will expire on February 3, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 34 skipping to change at page 3, line 34
4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 20 4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 20
4.1. LDP Label Distribution Control and Retention Modes . . . . 20 4.1. LDP Label Distribution Control and Retention Modes . . . . 20
4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 22 4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 22
4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22 4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22
4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 23 4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 23
4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 23 4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 23
4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 24 4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 24
4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24 4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24
4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26 4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26
4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27 4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27
4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27 4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 28 6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 29
6.1.1. Access to network packet flow direction . . . . . . . 28 6.1.1. Access to network packet flow direction . . . . . . . 29
6.1.2. Network to access packet flow direction . . . . . . . 29 6.1.2. Network to access packet flow direction . . . . . . . 29
6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 30 6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 30
6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 31 6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single
IP/MPLS network to scale over core, metro and access parts of a large IP/MPLS network to scale over core, metro and access parts of a large
packet network infrastructure using standardized IP/MPLS protocols. packet network infrastructure using standardized IP/MPLS protocols.
One of the key goals of Seamless MPLS is to meet requirements One of the key goals of Seamless MPLS is to meet requirements
specific to access, including high number of devices, their position specific to access, including high number of devices, their position
in network topology and their compute and memory constraints that in network topology and their compute and memory constraints that
limit the amount of state access devices can hold. limit the amount of state access devices can hold.
skipping to change at page 13, line 11 skipping to change at page 13, line 11
traffic flows, AGN1x will be responding to access-originated LDP DoD traffic flows, AGN1x will be responding to access-originated LDP DoD
label requests with label mappings based on its BGP labeled unicast label requests with label mappings based on its BGP labeled unicast
reachability for requested FECs. reachability for requested FECs.
3.1.2. AN with Access IGP 3.1.2. AN with Access IGP
If access IGP is used, AN(s) advertise their loopbacks over the If access IGP is used, AN(s) advertise their loopbacks over the
access IGP with configured metrics. AGN1x advertise a default route access IGP with configured metrics. AGN1x advertise a default route
over the access IGP. over the access IGP.
Similarly to the static route case, upstream AN/AGN1x should request
labels over LDP DoD session(s) from downstream AN/AGN1x for all /32
or /128 routes received over the access IGP.
Routers request labels over LDP DoD session(s) according to their Routers request labels over LDP DoD session(s) according to their
needs for MPLS connectivity (LSPs). In particular if AGNs, as per needs for MPLS connectivity (LSPs). In particular if AGNs, as per
Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute
routes from the IGP into BGP labeled unicast [RFC3107], they should routes from the IGP into BGP labeled unicast [RFC3107], they should
request labels over LDP DoD session(s) for those routes. request labels over LDP DoD session(s) for those routes.
Identically to the static route case, downstream AN/AGN1x should Identically to the static route case, downstream AN/AGN1x should
respond to the label request from the upstream AN/AGN1x with a label respond to the label request from the upstream AN/AGN1x with a label
mapping (if the requested route is present in its RIB, and there is a mapping (if the requested route is present in its RIB, and there is a
valid label binding from its downstream), and must install the valid label binding from its downstream), and must install the
skipping to change at page 21, line 19 skipping to change at page 21, line 15
Using independent label distribution control with LDP DoD and access Using independent label distribution control with LDP DoD and access
static routing would prevent the access LSRs from propagating label static routing would prevent the access LSRs from propagating label
binding failure along the access topology, making it impossible for binding failure along the access topology, making it impossible for
upstream LSR to be notified about the downstream failure and for an upstream LSR to be notified about the downstream failure and for an
application using the LSP to switchover to an alternate path, even if application using the LSP to switchover to an alternate path, even if
such a path exists. such a path exists.
LDP protocol specification [RFC5036] defines two modes for label LDP protocol specification [RFC5036] defines two modes for label
retention, following the definitions in MPLS architecture [RFC3031]: retention, following the definitions in MPLS architecture [RFC3031]:
o Liberal mode - LSR retains every label mappings received from a o Conservative mode - If operating in Downstream on Demand mode, an
peer LSR, regardless of whether the peer LSR is the next-hop for LSR will request label mappings only from the next hop LSR
the advertised mapping. This mode allows for quicker adaptation according to routing. The main advantage of the conservative mode
to routing changes. is that only the labels that are required for the forwarding of
data are allocated and maintained. This is particularly important
in LSRs where the label space is inherently limited, such as in an
ATM switch. A disadvantage of the conservative mode is that if
routing changes the next hop for a given destination, a new label
must be obtained from the new next hop before labeled packets can
be forwarded.
o Conservative mode - LSR retains advertised label mappings only if o Liberal mode - When operating in Downstream on Demand mode with
they will be used to forward packets, that is only if they are Liberal Label retention, an LSR might choose to request label
received from a valid next-hop LSR according to routing. This mappings for all known prefixes from all peer LSRs. The main
mode allows LSR to maintain fewer labels, but slows down LSR advantage of the Liberal Label retention mode is that reaction to
adaptation to routing changes. routing changes can be quick because labels already exist. The
main disadvantage of the liberal mode is that unneeded label
mappings are distributed and maintained.
Due to the fact that according to LDP protocol specification Note that the conservative label retention mode would prevent LSRs
[RFC5036] conservative label retention mode calls for allocating and from requesting and maintaining label mappings for any backup routes
maintaining label mappings only if they are used for the forwarding that are not used for forwarding. This in turn would prevent the
of data, when used with LDP DoD the conservative label retention mode access LSRs (AN and AGN1x nodes) from implementing any local
would prevent LSRs operating in this mode to request and maintain protection schemes that rely on using alternate next-hops in case of
label mappings for any backup routes that are not used for the primary next-hop failure. Such schemes include IPFRR LFA if
forwarding. This in turn would prevent the access LSRs (AN and AGN1x access IGP is used, or a primary and backup static route
nodes) from implementing IPFRR LFA alternate based local-repair, as configuration. Using LDP DoD in combination with liberal retention
label mapping request can not be sent to alternate next-hops. mode allows the LSR to request labels for the specific FEC from
primary next-hop LSR(s) and the alternate next-hop LSR(s) for this
FEC.
Note that even though LDP DoD operates in a liberal retention mode,
if used with access IGP and if no LFA exists, the LDP DoD will
introduce additional delay in traffic restoration as the labels for
the new next-hop will get requested only after the access IGP
convergence.
Adhering to the overall design goals of Seamless MPLS Adhering to the overall design goals of Seamless MPLS
[I-D.ietf-mpls-seamless-mpls], specifically achieving a large network [I-D.ietf-mpls-seamless-mpls], specifically achieving a large network
scale without compromising fast service restoration, all access LSRs scale without compromising fast service restoration, all access LSRs
(AN and AGN1x nodes) MUST use LDP DoD advertisement mode with: (AN and AGN1x nodes) MUST use LDP DoD advertisement mode with:
o Ordered label distribution control - enables propagation of label o Ordered label distribution control - enables propagation of label
binding failure within the access topology. binding failure within the access topology.
o Liberal label retention - enables pre-programming of alternate o Liberal label retention - enables pre-programming of alternate
next-hops with associated FEC labels. next-hops with associated FEC labels.
skipping to change at page 31, line 39 skipping to change at page 31, line 48
o different crypto keys for use in authentication procedures for o different crypto keys for use in authentication procedures for
these locations. these locations.
o stricter network protection mechanisms including DoS protection, o stricter network protection mechanisms including DoS protection,
interface and session flap dampening. interface and session flap dampening.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai
Leymann and Ina Minei for their suggestions and review. Leymann, Geraldine Calvignac and Ina Minei for their suggestions and
review.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] 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.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
 End of changes. 14 change blocks. 
33 lines changed or deleted 47 lines changed or added

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