--- 1/draft-ietf-mpls-ldp-dod-02.txt 2012-08-02 20:14:11.053342640 +0200 +++ 2/draft-ietf-mpls-ldp-dod-03.txt 2012-08-02 20:14:11.113341869 +0200 @@ -1,24 +1,24 @@ Network Working Group T. Beckhaus Internet-Draft Deutsche Telekom AG Intended status: Informational B. Decraene -Expires: January 16, 2013 France Telecom +Expires: February 3, 2013 France Telecom K. Tiruveedhula Juniper Networks M. Konstantynowicz L. Martini Cisco Systems, Inc. - July 15, 2012 + August 2, 2012 LDP Downstream-on-Demand in Seamless MPLS - draft-ietf-mpls-ldp-dod-02 + draft-ietf-mpls-ldp-dod-03 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 January 16, 2013. + This Internet-Draft will expire on February 3, 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 @@ -89,34 +89,34 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 28 - 6.1.1. Access to network packet flow direction . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 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. @@ -484,24 +484,20 @@ traffic flows, AGN1x will be responding to access-originated LDP DoD label requests with label mappings based on its BGP labeled unicast reachability for requested FECs. 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 @@ -877,42 +872,59 @@ 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]: - 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 - If operating in Downstream on Demand mode, an + LSR will request label mappings only from the next hop LSR + according to routing. The main advantage of the conservative mode + 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 - 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. + o Liberal mode - When operating in Downstream on Demand mode with + Liberal Label retention, an LSR might choose to request label + mappings for all known prefixes from all peer LSRs. The main + advantage of the Liberal Label retention mode is that reaction to + 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 - [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. + Note that the conservative label retention mode would prevent LSRs + from requesting and maintaining 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 any local + protection schemes that rely on using alternate next-hops in case of + the primary next-hop failure. Such schemes include IPFRR LFA if + access IGP is used, or a primary and backup static route + configuration. Using LDP DoD in combination with liberal retention + 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 + [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. @@ -1376,21 +1389,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 and Ina Minei for their suggestions and review. + Leymann, Geraldine Calvignac and Ina Minei 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.