draft-ietf-mpls-ldp-dod-01.txt   draft-ietf-mpls-ldp-dod-02.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: September 13, 2012 France Telecom Expires: January 16, 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.
March 12, 2012 July 15, 2012
LDP Downstream-on-Demand in Seamless MPLS LDP Downstream-on-Demand in Seamless MPLS
draft-ietf-mpls-ldp-dod-01 draft-ietf-mpls-ldp-dod-02
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 September 13, 2012. This Internet-Draft will expire on January 16, 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 26 skipping to change at page 3, line 26
3.3. Service Changes and Decommissioning . . . . . . . . . . . 16 3.3. Service Changes and Decommissioning . . . . . . . . . . . 16
3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 16 3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 16
3.5. Network Transport Failure . . . . . . . . . . . . . . . . 17 3.5. Network Transport Failure . . . . . . . . . . . . . . . . 17
3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 17 3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 17
3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 17 3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 17
3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 18 3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 18
3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . . 19 3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . . 19
3.5.5. AGN Network-side Reachability Failure . . . . . . . . 19 3.5.5. AGN Network-side Reachability Failure . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . . . . . . . 21 4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 22
4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22 4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22
4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 22 4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 23
4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 22 4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 23
4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . 28
6.1.1. Access to network packet flow direction . . . . . . . 28 6.1.1. Access to network packet flow direction . . . . . . . 28
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 . . . . . . . . . . . . . . . . . . 30 6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 31 8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
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
skipping to change at page 13, line 15 skipping to change at page 13, line 15
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 Similarly to the static route case, upstream AN/AGN1x should request
labels over LDP DoD session(s) from downstream AN/AGN1x for all /32 labels over LDP DoD session(s) from downstream AN/AGN1x for all /32
or /128 routes received over the access IGP. or /128 routes received over the access IGP.
Routers request labels over LDP DoD session(s) according to their
needs for MPLS connectivity (LSPs). In particular if AGNs, as per
Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute
routes from the IGP into BGP labeled unicast [RFC3107], they should
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
advertised label as an incoming label in its LIB and LFIB. Upstream advertised label as an incoming label in its LIB and LFIB. Upstream
AN/AGN1x must also install the received label as an outgoing label in AN/AGN1x must also install the received label as an outgoing label in
their LIB and LFIB. their LIB and LFIB.
Identically to the static route case, in order to facilitate ECMP and Identically to the static route case, in order to facilitate ECMP and
IPFRR LFA local-repair, upstream AN/AGN1x must also send LDP DoD IPFRR LFA local-repair, upstream AN/AGN1x must also send LDP DoD
skipping to change at page 21, line 6 skipping to change at page 21, line 10
decision to bind a label to the FEC independently from decision to bind a label to the FEC independently from
distributing that label binding to its label distribution peers. distributing that label binding to its label distribution peers.
A new FEC is recognized whenever a new route becomes valid on the A new FEC is recognized whenever a new route becomes valid on the
LSR. LSR.
o Ordered mode - an LSR binds a label to a particular FEC if it is o Ordered mode - an LSR binds a label to a particular FEC if it is
the egress router for that FEC or if it has already received a the egress router for that FEC or if it has already received a
label binding for that FEC from its next-hop LSR for that FEC. label binding for that FEC from its next-hop LSR for that FEC.
Using independent label distribution control with LDP DoD and access Using independent label distribution control with LDP DoD and access
static routing will 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 to binding failure along the access topology, making it impossible for
switchover to an alternate path, even if such a path exists. upstream LSR to be notified about the downstream failure and for an
application using the LSP to switchover to an alternate path, even if
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 Liberal mode - LSR retains every label mappings received from a
peer LSR, regardless of whether the peer LSR is the next-hop for peer LSR, regardless of whether the peer LSR is the next-hop for
the advertised mapping. This mode allows for quicker adaptation the advertised mapping. This mode allows for quicker adaptation
to routing changes. to routing changes.
o Conservative mode - LSR retains advertised label mappings only if o Conservative mode - LSR retains advertised label mappings only if
they will be used to forward packets, that is only if they are they will be used to forward packets, that is only if they are
received from a valid next-hop LSR according to routing. This received from a valid next-hop LSR according to routing. This
mode allows LSR to maintain fewer labels, but slows down LSR mode allows LSR to maintain fewer labels, but slows down LSR
adaptation to routing changes. adaptation to routing changes.
Using conservative label retention mode with LDP DoD will prevent the Due to the fact that according to LDP protocol specification
access LSRs (AN and AGN1x nodes) from implementing IPFRR LFA [RFC5036] conservative label retention mode calls for allocating and
alternate based local-repair, as label mapping request can not be maintaining label mappings only if they are used for the forwarding
sent to alternate next-hops. of data, when used with LDP DoD the conservative label retention mode
would prevent LSRs operating in this mode to request and maintain
label mappings for any backup routes that are not used for
forwarding. This in turn would prevent the access LSRs (AN and AGN1x
nodes) from implementing IPFRR LFA alternate based local-repair, as
label mapping request can not be sent to alternate next-hops.
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.
In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an
access ABR connecting access and metro domains. To enable failure access ABR connecting access and metro domains. To enable failure
propagation between those domains, access ABR MUST implement ordered propagation between those domains, access ABR MUST implement ordered
label distribution control when redistributing access static routes label distribution control when redistributing routes/FEC between the
and/or access IGP routes into the network-side BGP labeled unicast access-side (using LDP DoD and static or access IGP) and the network-
[RFC3107] or core IGP with LDP Downstream Unsolicited label side ( using BGP labeled unicast [RFC3107] or core IGP with LDP
advertisement. Downstream Unsolicited label advertisement.
4.2. IPv6 Support 4.2. IPv6 Support
Current LDP protocol specification [RFC5036] defines procedures and Current LDP protocol specification [RFC5036] defines procedures and
messages for exchanging FEC-label bindings over IPv4 and/or IPv6 messages for exchanging FEC-label bindings over IPv4 and/or IPv6
networks. However number of IPv6 usage areas are not clearly networks. However number of IPv6 usage areas are not clearly
specified including: packet to LSP mapping for IPv6 destination specified including: packet to LSP mapping for IPv6 destination
router, no IPv6 specific LSP identifier, no LDP discovery using IPv6 router, no IPv6 specific LSP identifier, no LDP discovery using IPv6
multicast address, separate LSPs for IPv4 and IPv6, and others. multicast address, separate LSPs for IPv4 and IPv6, and others.
skipping to change at page 23, line 6 skipping to change at page 23, line 16
label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447]. label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447].
4.4. Label Request Procedures 4.4. Label Request Procedures
4.4.1. Access LSR/ABR Label Request 4.4.1. Access LSR/ABR Label Request
Upstream access LSR/ABR will request label bindings from adjacent Upstream access LSR/ABR will request label bindings from adjacent
downstream access LSR/ABR based on the following trigger events: downstream access LSR/ABR based on the following trigger events:
a. Access LSR/ABR is configured with /32 static route with LDP DoD a. Access LSR/ABR is configured with /32 static route with LDP DoD
label request policy in line with intitial network setup use case label request policy in line with initial network setup use case
described in Section 3.1. described in Section 3.1.
b. Access LSR/ABR is configured with a service in line with service b. Access LSR/ABR is configured with a service in line with service
use cases described in Section 3.2 and Section 3.3. use cases described in Section 3.2 and Section 3.3.
c. Access LSR/ABR link to adjacent node comes up and LDP DoD session c. Configuration with access static routes - Access LSR/ABR link to
is established. In this case access LSR should send label adjacent node comes up and LDP DoD session is established. In
request messages for all /32 static routes configured with LDP this case access LSR should send label request messages for all
DoD policy and all /32 routes related to provisioned services /32 static routes configured with LDP DoD policy and all /32
that are not covered by default route. In line with use cases routes related to provisioned services that are covered by
described in Section 3.5. default route.
d. In all above cases requests MUST be sent to next-hop LSR(s) and d. Configuration with access IGP - Access LSR/ABR link to adjacent
node comes up and LDP DoD session is established. In this case
access LSR should send label request messages for all /32 routes
learned over the access IGP and all /32 routes related to
provisioned services that are covered by access IGP routes.
e. In all above cases requests MUST be sent to next-hop LSR(s) and
alternate LSR(s). alternate LSR(s).
Downstream access LSR/ABR will respond with label mapping message Downstream access LSR/ABR will respond with label mapping message
with a non-null label if any of the below conditions are met: with a non-null label if any of the below conditions are met:
a. Downstream access LSR/ABR - requested FEC is an IGP or static a. Downstream access LSR/ABR - requested FEC is an IGP or static
route and there is an LDP label already learnt from the next- route and there is an LDP label already learnt from the next-
next-hop downstream LSR (by LDP DoD or LDP DU). If there is no next-hop downstream LSR (by LDP DoD or LDP DU). If there is no
label for the requested FEC and there is an LDP DoD session to label for the requested FEC and there is an LDP DoD session to
the next-next-hop downstream LSR, downstream LSR MUST send a the next-next-hop downstream LSR, downstream LSR MUST send a
skipping to change at page 31, line 49 skipping to change at page 32, line 8
[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.
8.2. Informative References 8.2. Informative References
[I-D.ietf-mpls-ldp-ipv6] [I-D.ietf-mpls-ldp-ipv6]
Pignataro, C., Asati, R., Papneja, R., and V. Manral, Asati, R., Manral, V., Papneja, R., and C. Pignataro,
"Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-06 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-07
(work in progress), January 2012. (work in progress), June 2012.
[I-D.ietf-mpls-seamless-mpls] [I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", M., and D. Steinberg, "Seamless MPLS Architecture",
draft-ietf-mpls-seamless-mpls-01 (work in progress), draft-ietf-mpls-seamless-mpls-01 (work in progress),
March 2012. March 2012.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
skipping to change at page 32, line 43 skipping to change at page 33, line 10
Synchronization", RFC 5443, March 2009. Synchronization", RFC 5443, March 2009.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
Authors' Addresses Authors' Addresses
Thomas Beckhaus Thomas Beckhaus
Deutsche Telekom AG Deutsche Telekom AG
Heinrich-Hertz-Strasse 3-7 Heinrich-Hertz-Strasse 3-7
Darmstadt, 64307 Darmstadt 64307
Germany Germany
Phone: +49 6151 58 12825 Phone: +49 6151 58 12825
Fax:
Email: thomas.beckhaus@telekom.de Email: thomas.beckhaus@telekom.de
URI:
Bruno Decraene Bruno Decraene
France Telecom France Telecom
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy Moulineaux cedex 9, 92794 Issy Moulineaux cedex 9 92794
France France
Phone:
Fax:
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
URI:
Kishore Tiruveedhula Kishore Tiruveedhula
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
USA USA
Phone: 1-(978)-589-8861 Phone: 1-(978)-589-8861
Fax:
Email: kishoret@juniper.net Email: kishoret@juniper.net
URI:
Maciek Konstantynowicz Maciek Konstantynowicz
Cisco Systems, Inc. Cisco Systems, Inc.
10 New Square Park, Bedfont Lakes
London
United Kingdom
Phone: Email: maciek@cisco.com
Fax:
Email: maciek@bgp.nu
URI:
Luca Martini Luca Martini
Cisco Systems, Inc. Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400 9155 East Nichols Avenue, Suite 400
Englewood, CO 80112 Englewood, CO 80112
USA USA
Phone:
Fax:
Email: lmartini@cisco.com Email: lmartini@cisco.com
URI:
 End of changes. 29 change blocks. 
48 lines changed or deleted 58 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/