--- 1/draft-ietf-mpls-ldp-dod-01.txt 2012-07-15 21:15:01.277675477 +0200 +++ 2/draft-ietf-mpls-ldp-dod-02.txt 2012-07-15 21:15:01.357344124 +0200 @@ -1,24 +1,24 @@ Network Working Group T. Beckhaus Internet-Draft Deutsche Telekom AG Intended status: Informational B. Decraene -Expires: September 13, 2012 France Telecom +Expires: January 16, 2013 France Telecom K. Tiruveedhula Juniper Networks M. Konstantynowicz L. Martini Cisco Systems, Inc. - March 12, 2012 + July 15, 2012 LDP Downstream-on-Demand in Seamless MPLS - draft-ietf-mpls-ldp-dod-01 + draft-ietf-mpls-ldp-dod-02 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,21 +43,21 @@ 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 September 13, 2012. + This Internet-Draft will expire on January 16, 2013. Copyright Notice Copyright (c) 2012 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 @@ -81,41 +81,41 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . 21 + 4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 22 4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22 - 4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 22 - 4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 22 - 4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 23 + 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 . . . . . . . . . . . . . . . . . . . . . . . 27 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . 29 6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 30 - 6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 30 + 6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 31 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 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 @@ -488,20 +488,26 @@ 3.1.2. AN with Access IGP If access IGP is used, AN(s) advertise their loopbacks over the access IGP with configured metrics. AGN1x advertise a default route 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 + 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 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 valid label binding from its downstream), and must install the 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 their LIB and LFIB. Identically to the static route case, in order to facilitate ECMP and IPFRR LFA local-repair, upstream AN/AGN1x must also send LDP DoD @@ -861,61 +868,68 @@ 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. Using independent label distribution control with LDP DoD and access - static routing will prevent the access LSRs from propagating label - binding failure along the access topology, making it impossible to - switchover to an alternate path, even if such a path exists. + 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]: o Liberal mode - LSR retains every label mappings received from a peer LSR, regardless of whether the peer LSR is the next-hop for the advertised mapping. This mode allows for quicker adaptation to routing changes. o Conservative mode - LSR retains advertised label mappings only if they will be used to forward packets, that is only if they are received from a valid next-hop LSR according to routing. This mode allows LSR to maintain fewer labels, but slows down LSR adaptation to routing changes. - Using conservative label retention mode with LDP DoD will 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. + Due to the fact that according to LDP protocol specification + [RFC5036] conservative label retention mode calls for allocating and + maintaining label mappings only if they are used for the forwarding + 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 [I-D.ietf-mpls-seamless-mpls], specifically achieving a large network scale without compromising fast service restoration, all access LSRs (AN and AGN1x nodes) MUST use LDP DoD advertisement mode with: o Ordered label distribution control - enables propagation of label binding failure within the access topology. o Liberal label retention - enables pre-programming of alternate next-hops with associated FEC labels. In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an access ABR connecting access and metro domains. To enable failure propagation between those domains, access ABR MUST implement ordered - label distribution control when redistributing access static routes - and/or access IGP routes into the network-side BGP labeled unicast - [RFC3107] or core IGP with LDP Downstream Unsolicited label - advertisement. + label distribution control when redistributing routes/FEC between the + access-side (using LDP DoD and static or access IGP) and the network- + side ( using BGP labeled unicast [RFC3107] or core IGP with LDP + Downstream Unsolicited label advertisement. 4.2. IPv6 Support Current LDP protocol specification [RFC5036] defines procedures and messages for exchanging FEC-label bindings over IPv4 and/or IPv6 networks. However number of IPv6 usage areas are not clearly specified including: packet to LSP mapping for IPv6 destination router, no IPv6 specific LSP identifier, no LDP discovery using IPv6 multicast address, separate LSPs for IPv4 and IPv6, and others. @@ -957,34 +971,40 @@ label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447]. 4.4. Label Request Procedures 4.4.1. Access LSR/ABR Label Request Upstream access LSR/ABR will request label bindings from adjacent downstream access LSR/ABR based on the following trigger events: 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. b. Access LSR/ABR is configured with a service in line with service 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 - is established. In this case access LSR should send label - request messages for all /32 static routes configured with LDP - DoD policy and all /32 routes related to provisioned services - that are not covered by default route. In line with use cases - described in Section 3.5. + c. Configuration with access static routes - 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 static routes configured with LDP DoD policy and all /32 + routes related to provisioned services that are covered by + 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). Downstream access LSR/ABR will respond with label mapping message 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 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 label for the requested FEC and there is an LDP DoD session to the next-next-hop downstream LSR, downstream LSR MUST send a @@ -1369,23 +1391,23 @@ [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. 8.2. Informative References [I-D.ietf-mpls-ldp-ipv6] - Pignataro, C., Asati, R., Papneja, R., and V. Manral, - "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-06 - (work in progress), January 2012. + 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. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. @@ -1410,58 +1432,48 @@ Synchronization", RFC 5443, March 2009. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. Authors' Addresses Thomas Beckhaus Deutsche Telekom AG Heinrich-Hertz-Strasse 3-7 - Darmstadt, 64307 + Darmstadt 64307 Germany Phone: +49 6151 58 12825 - Fax: Email: thomas.beckhaus@telekom.de - URI: Bruno Decraene France Telecom 38-40 rue du General Leclerc - Issy Moulineaux cedex 9, 92794 + Issy Moulineaux cedex 9 92794 France - Phone: - Fax: Email: bruno.decraene@orange.com - URI: Kishore Tiruveedhula Juniper Networks 10 Technology Park Drive Westford, Massachusetts 01886 USA Phone: 1-(978)-589-8861 - Fax: Email: kishoret@juniper.net - URI: Maciek Konstantynowicz Cisco Systems, Inc. + 10 New Square Park, Bedfont Lakes + London + United Kingdom - Phone: - Fax: - Email: maciek@bgp.nu - URI: + Email: maciek@cisco.com Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 USA - Phone: - Fax: Email: lmartini@cisco.com - URI: