--- 1/draft-ietf-mpls-ldp-dod-03.txt 2013-02-04 04:35:41.527829039 +0100 +++ 2/draft-ietf-mpls-ldp-dod-04.txt 2013-02-04 04:35:41.579791543 +0100 @@ -1,24 +1,24 @@ Network Working Group T. Beckhaus Internet-Draft Deutsche Telekom AG Intended status: Informational B. Decraene -Expires: February 3, 2013 France Telecom +Expires: August 7, 2013 France Telecom K. Tiruveedhula Juniper Networks M. Konstantynowicz L. Martini Cisco Systems, Inc. - August 2, 2012 + February 3, 2013 LDP Downstream-on-Demand in Seamless MPLS - draft-ietf-mpls-ldp-dod-03 + draft-ietf-mpls-ldp-dod-04 Abstract Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand @@ -43,97 +43,99 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 3, 2013. + This Internet-Draft will expire on August 7, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Reference Topologies . . . . . . . . . . . . . . . . . . . . . 5 2.1. Access Topologies with Static Routing . . . . . . . . . . 6 - 2.2. Access Topologies with Access IGP . . . . . . . . . . . . 9 - 3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 11 - 3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 11 - 3.1.1. AN with Static Routing . . . . . . . . . . . . . . . . 11 - 3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . . 13 - 3.2. Service Provisioning and Activation . . . . . . . . . . . 13 - 3.3. Service Changes and Decommissioning . . . . . . . . . . . 16 - 3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 16 - 3.5. Network Transport Failure . . . . . . . . . . . . . . . . 17 - 3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 17 - 3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 17 - 3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 18 - 3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . . 19 - 3.5.5. AGN Network-side Reachability Failure . . . . . . . . 19 - 4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1. LDP Label Distribution Control and Retention Modes . . . . 20 - 4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 22 - 4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22 - 4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 23 - 4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 23 - 4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 24 - 4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24 - 4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26 - 4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27 - 4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 28 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 - 5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 29 - 6.1.1. Access to network packet flow direction . . . . . . . 29 - 6.1.2. Network to access packet flow direction . . . . . . . 29 - 6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 30 - 6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 31 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 + 2.2. Access Topologies with Access IGP . . . . . . . . . . . . 8 + 3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 10 + 3.1.1. AN with Static Routing . . . . . . . . . . . . . . . . 10 + 3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . . 12 + 3.2. Service Provisioning and Activation . . . . . . . . . . . 12 + 3.3. Service Changes and Decommissioning . . . . . . . . . . . 15 + 3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 15 + 3.5. Network Transport Failure . . . . . . . . . . . . . . . . 16 + 3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 16 + 3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 16 + 3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 17 + 3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . . 18 + 3.5.5. AGN Network-side Reachability Failure . . . . . . . . 18 + 4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1. LDP Label Distribution Control and Retention Modes . . . . 19 + 4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 21 + 4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 21 + 4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 22 + 4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 22 + 4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 23 + 4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 23 + 4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 25 + 4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 26 + 4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 27 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 27 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 28 + 6.1.1. Access to network packet flow direction . . . . . . . 28 + 6.1.2. Network to access packet flow direction . . . . . . . 28 + 6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 29 + 6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 30 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction 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 packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold. - In general MPLS routers implement either LDP or RSVP for MPLS label - distribution. The focus of this document is on LDP, as Seamless MPLS - design does not include a requirement for general purpose explicit - traffic engineering and bandwidth reservation. This document is - focusing on the unicast connectivity only. Multicast connectivity is - subject for further study. + In general MPLS Label Switching Routers implement either LDP or RSVP + for MPLS label distribution. + + The focus of this document is on LDP, as Seamless MPLS design does + not include a requirement for general purpose explicit traffic + engineering and bandwidth reservation. Document concentrates on the + unicast connectivity only. Multicast connectivity is subject for + further study. In Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], IP/MPLS protocol optimization is possible due to a relatively simple access network topologies. Examples of such topologies involving access nodes (AN) and aggregation nodes (AGN) include: a. A single AN homed to a single AGN. b. A single AN dual-homed to two AGNs. @@ -150,43 +152,35 @@ with either static routes or dedicated access IGP. Note that in all of the above topologies AGNs act as the access border routers (access ABRs) connecting the access topology to the rest of the network. Hence in many cases it is sufficient for ANs to have a default route pointing towards AGNs in order to achieve complete network connectivity from ANs to the network. The amount of MPLS forwarding state however requires additional consideration. In general MPLS routers implement LDP Downstream Unsolicited (LDP DU) label advertisement [RFC5036] and advertise MPLS - labels for all valid routes in their RIB. This is seen as a very - insufficient approach for ANs, as they only require a small subset of - the total routes (and associated labels) based on the required + labels for all valid routes in their RIB. This is seen as an + inadequate approach for ANs, which requires a small subset of the + total routes (and associated labels) based on the required connectivity for the provisioned services. And although filters can be applied to those LDP DU labels advertisements, it is not seen as a suitable tool to facilitate any-to-any AN-driven connectivity between access and the rest of the MPLS network. This document describes an access node driven "subscription model" for label distribution in the access. The approach relies on the standard LDP Downstream-on-Demand (LDP DoD) label advertisements as specified in [RFC5036]. LDP DoD enables on-demand label distribution ensuring that only required labels are requested, provided and installed. - Note that LDP DoD implementation is not widely available in today's - IP/MPLS devices despite the fact that it has been described in the - LDP specification [RFC5036]. This is due to the fact that the - originally LDP DoD advertisement mode was aimed mainly at ATM and - Frame Relay MPLS implementations, where conserving label space used - on the links was essential for compatibility with ATM and Frame Relay - LSRs. - The following sections describe a set of reference access topologies considered for LDP DoD usage and their associated IP routing configurations, followed by LDP DoD use cases and LDP DoD procedures in the context of Seamless MPLS design. 2. Reference Topologies LDP DoD use cases are described in the context of a generic reference end-to-end network topology based on Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] shown in Figure 1 @@ -401,25 +396,21 @@ IPVPN [RFC4364]. Described LDP DoD operations apply equally to all reference access topologies described in Section 2. Operations that are specific to certain access topologies are called out explicitly. References to upstream and downstream nodes are made in line with the definition of upstream and downstream LSR [RFC3031]. This document is focusing on IPv4 LDP DoD procedures. Similar - procedures are required for IPv6 LDP DoD, however some extension - specific to IPv6 are likely to apply including LSP mapping, peer - discovery, transport connection establishment. These will be added - in this document once LDP IPv6 standardization is advanced as per - [I-D.ietf-mpls-ldp-ipv6]. + procedures will apply to IPv6 LDP DoD [I-D.ietf-mpls-ldp-ipv6]. 3.1. Initial Network Setup An access node is commissioned without any services provisioned on it. The AN may request labels for loopback addresses of any AN, AGN or other nodes within Seamless MPLS network for operational and management purposes. It is assumed that AGN1x has required IP/MPLS configuration for network-side connectivity in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. @@ -455,28 +446,29 @@ towards AGN1x. Upstream AN/AGN1x should request labels over LDP DoD session(s) from downstream AN/AGN1x for configured static routes if those static routes are configured with LDP DoD request policy and if they are pointing to a next-hop selected by routing. It is expected that all configured /32 and /128 static routes to be used for LDP DoD are configured with such policy on AN/AGN1x. Downstream AN/AGN1x should respond to the label request from the - upstream AN/AGN1x with a label mapping (if requested route is present - in its RIB, and there is a valid label binding from its downstream), - and must install the advertised label as an incoming label in its - label table (LIB) and its forwarding table (LFIB). Upstream AN/AGN1x - must also install the received label as an outgoing label in their - LIB and LFIB. If the downstream AN/AGN1x does have the route present - in its RIB, but does not have a valid label binding from its - downstream, it should forward the request to its downstream. + upstream AN/AGN1x with a label mapping if requested route is present + in its RIB, and there is a valid label binding from its downstream or + it is the egress node. In such case downstream AN/AGN1x must install + the advertised label as an incoming label in its label table (LIB) + and its forwarding table (LFIB). Upstream AN/AGN1x must also install + the received label as an outgoing label in their LIB and LFIB. If + the downstream AN/AGN1x does have the route present in its RIB, but + does not have a valid label binding from its downstream, it should + forward the request to its downstream. In order to facilitate ECMP and IPFRR LFA local-repair, the upstream AN/AGN1x must also send LDP DoD label requests to alternate next-hops per its RIB, and install received labels as alternate entries in its LIB and LFIB. AGN1x node on the network side may use BGP labeled unicast [RFC3107] in line with the Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In such a case AGN1x will be redistributing its static routes pointing to local ANs into BGP labeled unicast to facilitate network- @@ -858,23 +850,24 @@ LDP protocol specification [RFC5036] defines two modes for label distribution control, following the definitions in MPLS architecture [RFC3031]: o Independent mode - an LSR recognizes a particular FEC and makes a decision to bind a label to the FEC independently from distributing that label binding to its label distribution peers. A new FEC is recognized whenever a new route becomes valid on the LSR. - 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 - label binding for that FEC from its next-hop LSR for that FEC. + o Ordered mode - an LSR needs to bind a label to a particular FEC if + it knows how to forward packets for that FEC ( i.e. it has a route + corresponding to that FEC ) and if it has already received at + least one label request message from an upstream LSR. Using independent label distribution control with LDP DoD and access static routing would prevent the access LSRs from propagating label binding failure along the access topology, making it impossible for 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 retention, following the definitions in MPLS architecture [RFC3031]: @@ -1389,22 +1382,22 @@ o different crypto keys for use in authentication procedures for these locations. o stricter network protection mechanisms including DoS protection, interface and session flap dampening. 7. Acknowledgements The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai - Leymann, Geraldine Calvignac and Ina Minei for their suggestions and - review. + Leymann, Geraldine Calvignac, Ina Minei, Eric Gray and Lizhong Jin + for their suggestions and review. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. @@ -1412,22 +1405,22 @@ 8.2. Informative References [I-D.ietf-mpls-ldp-ipv6] Asati, R., Manral, V., Papneja, R., and C. Pignataro, "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-07 (work in progress), June 2012. [I-D.ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", - draft-ietf-mpls-seamless-mpls-01 (work in progress), - March 2012. + draft-ietf-mpls-seamless-mpls-02 (work in progress), + October 2012. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.