--- 1/draft-atlas-mpls-ldp-mrt-02.txt 2014-12-15 08:14:51.828222271 -0800 +++ 2/draft-atlas-mpls-ldp-mrt-03.txt 2014-12-15 08:14:51.864223143 -0800 @@ -1,30 +1,30 @@ MPLS Working Group A. Atlas Internet-Draft K. Tiruveedhula Intended status: Standards Track C. Bowers -Expires: April 30, 2015 Juniper Networks +Expires: June 18, 2015 Juniper Networks J. Tantsura Ericsson IJ. Wijnands Cisco Systems, Inc. - October 27, 2014 + December 15, 2014 LDP Extensions to Support Maximally Redundant Trees - draft-atlas-mpls-ldp-mrt-02 + draft-atlas-mpls-ldp-mrt-03 Abstract - This document specifies extensions to LDP to support the creation of - label-switched paths for Maximally Redundant Trees (MRT). A prime - use of MRTs is for unicast and multicast IP/LDP Fast-Reroute, which - we will refer to as MRT-FRR. + This document specifies extensions to the Label Distribution + Protocol(LDP) to support the creation of label-switched paths for + Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast + and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR. The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for LSRs and LERs advertising the MRT Capability. MRT-FRR uses LDP multi-topology extensions and requires three different multi-topology IDs to be allocated from the LDP MT-ID space. @@ -36,21 +36,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 April 30, 2015. + This Internet-Draft will expire on June 18, 2015. Copyright Notice Copyright (c) 2014 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 @@ -60,21 +60,22 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview of LDP Signaling Extensions for MRT . . . . . . . . 5 4.1. MRT Capability Advertisement . . . . . . . . . . . . . . 5 - 4.1.1. Interaction of LDP MRT Capability with IPv4 and IPv6 6 + 4.1.1. Interaction of MRT Capability and MT Capability . . . 6 + 4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 6 4.2. Use of the Rainbow MRT MT-ID . . . . . . . . . . . . . . 7 4.3. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . 7 5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 7 5.1. MRT-specific behavior . . . . . . . . . . . . . . . . . . 8 5.1.1. ABR behavior and use of the Rainbow FEC . . . . . . . 8 5.1.2. Proxy-node attachment router behavior . . . . . . . . 9 5.2. LDP protocol procedures in the context of MRT label distribution . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. LDP peer in RFC5036 . . . . . . . . . . . . . . . . . 10 5.2.2. Next hop in RFC5036 . . . . . . . . . . . . . . . . . 10 @@ -83,21 +84,21 @@ requirements in RFC5036 . . . . . . . . . . . . . . . 12 5.2.5. Validating FECs in routing table . . . . . . . . . . 13 5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 13 5.2.7. Not propagating Rainbow FEC label mappings . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction This document describes the LDP signaling extension and associated behavior necessary to support the architecture that defines how IP/ LDP Fast-Reroute can use MRTs [I-D.ietf-rtgwg-mrt-frr-architecture]. It is necessary to be familiar with the architecture in [I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the LDP extensions for behavior are needed. @@ -126,23 +127,23 @@ capability extension is needed for LDP. An LDP implementation supporting MRT MUST also follow the rules described here for originating and managing FECs related to MRT, as indicated by their multi-topology ID. Network reconvergence is described in [I-D.ietf-rtgwg-mrt-frr-architecture] and the worst-case network convergence time can be flooded via the extension in Section 7 of [I-D.atlas-ospf-mrt]. IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and node failures in an arbitrary network topology where the failure - doesn't split the network. It can also be deployed incrementally; an - MRT Island is formed of connected supporting routers and the MRTs are - computed inside that island. + doesn't partition the network. It can also be deployed + incrementally; an MRT Island is formed of connected supporting + routers and the MRTs are computed inside that island. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 3. Terminology For ease of reading, some of the terminology defined in @@ -185,51 +186,44 @@ Island Border Router (IBR): A router in the MRT Island that is connected to a router not in the MRT Island and both routers are in a common area or level. Island Neighbor (IN): A router that is not in the MRT Island but is adjacent to an IBR and in the same area/level as the IBR.. 4. Overview of LDP Signaling Extensions for MRT - Routers need to know which of their neighbors support MRT. - Supporting MRT indicates several different aspects of behavior, as - listed below. + Routers need to know which of their LDP neighbors support MRT. This + is communicated using the MRT Capability Advertisement. Supporting + MRT indicates several different aspects of behavior, as listed below. - 1. Support for Multi-Topology (MT) - this MAY also be indicated via - the Multi-Topology LDP Capability [RFC7307]. + 1. Sending and receiving multi-topology FEC elements, as defined in + [RFC7307]. - 2. Understand the Rainbow MRT MT-ID and apply the associated labels - to all relevant MT-IDs. + 2. Understanding the Rainbow MRT MT-ID and applying the associated + labels to all relevant MT-IDs. - 3. Advertise the Rainbow MRT MT-ID to the appropriate neighbors for - the associated prefix. + 3. Advertising the Rainbow MRT FEC to the appropriate neighbors for + the appropriate prefix. 4. If acting as LDP egress for a prefix in the default topology, - also advertise and act as egress for the same prefix in MRT-Red - and MRT-Blue. + also acting as egress for the same prefix in MRT-Red and MRT- + Blue. 5. For a FEC learned from a neighbor that does not support MRT, - originate FECS for MRT-Red and MRT-Blue with the same prefix. + originating FECs for MRT-Red and MRT-Blue with the same prefix. This MRT Island egress behavior is to support an MRT Island that does not include all routers in the area/level. 4.1. MRT Capability Advertisement - It is not possible to support MRT without supporting the LDP multi- - topology extensions, but it is possible that the only use of the - multi-topology extensions is for MRT. In that case, a router MAY not - negotiate the multi-topology capability and only negotiate the MRT - Capability with its LDP peers. Negotiation of the multi-topology - capability is not required with negotiation of the MRT capability. - A new MRT Capability Parameter TLV is defined in accordance with LDP Capability definition guidelines[RFC5561]. The LDP MRT capability can be advertised during LDP session initialization or after the LDP session is established. Advertisement of the MRT capability indicates support of the procedures for establishing the MRT-Blue and MRT-Red LSP paths detailed in this document. If the peer has not advertised the MRT capability, then it indicates that LSR does not support MRT procedures. @@ -262,26 +256,46 @@ MRT Capability: TBA-MRT-LDP-1 (To Be Allocated by IANA) Length: The length (in octets) of TLV. Its value is 1. S-bit: The State bit MUST be 1 if used in LDP "Initialization" message. MAY be set to 0 or 1 in dynamic "Capability" message to advertise or withdraw the capability respectively, as described in [RFC5561]. -4.1.1. Interaction of LDP MRT Capability with IPv4 and IPv6 +4.1.1. Interaction of MRT Capability and MT Capability - An LSR which advertises the MRT LDP capability is expected to - advertise MRT-related FEC-label bindings for both IPv4 and IPv6 - address families, if the LSR originates shortest-path FEC-label - bindings for those address families. + An LSR advertising the LDP MRT Capability MUST also advertise the LDP + Multi-topology (MT) capability. If an LSR negotiates LDP MRT + Capability with an LDP neighbor without also negotiating the LDP MT + Capability, the LSR MUST behave as if LDP MRT Capability has not been + negotiated and respond with the "MRT Capability negotiated without MT + Capability" status code in the LDP Notification message (defined in + the document). The E-bit of this Notification should be set to 0 to + indicate that this is an Advisory Notification. The LDP session + SHOULD NOT be terminated. + +4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 + + The MRT LDP Capability Advertisement does not distinguish between + IPv4 and IPv6 address families. An LSR which advertises the MRT LDP + capability is expected to advertise MRT-related FEC-label bindings + for the same address families for which it advertises shortest-path + FEC-label bindings. Therefore, an LSR advertising MRT LDP capability + and shortest path FEC-label bindings for IPv4 only (or IPv6 only) + would be expected to advertise MRT-related FEC-label binding for IPv4 + only (or IPv6 only). An LSR advertising the MRT LDP capability and + shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected + to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6. + In this scenario, advertising MRT-related FEC-label bindings only for + IPv4 only (or only for IPv6) is not supported. 4.2. Use of the Rainbow MRT MT-ID Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the need for an area border router (ABR) to have different neighbors use different MPLS labels when sending traffic to the ABR for the same FEC. More detailed discussion of the Rainbow MRT MT-ID is provided in Section 5.1.1. Another use for the Rainbow MRT MT-ID is for an LSR to send the @@ -611,31 +625,41 @@ 7. IANA Considerations IANA is requested to allocate a value for the new LDP Capability TLV (the first free value in the range 0x0500 to 0x05FF) from the LDP registry "TLV Type Name Space": MRT Capability TLV (TBA-MRT-LDP-1). Value Description Reference Notes / Reg. Date ------------- ------------------ ------------ ----------------- TBA-MRT-LDP-1 MRT Capability TLV [This draft] + IANA is requested to allocate a value for the new LDP Status Code + (the first free value in the range 0x00000032-0x00000036) from the + LDP registry "Status Code Name Space": "MRT Capability negotiated + without MT Capability" (TBA-MRT-LDP-3). + +Value E Description Reference Notes / Reg. Date +------------- - ------------------------- --------- ----------------- +TBA-MRT-LDP-3 0 MRT Capability negotiated [This draft] + without MT Capability + IANA is requested to allocate a value from the MPLS Multi-Topology Identifiers Name Space [RFC7307]: Rainbow MRT MT-ID (TBA-MRT-LDP-2). Value Purpose Reference ------------- ------------------ ------------ TBA-MRT-LDP-2 Rainbow MRT MT-ID [This draft] 8. Acknowledgements - The authors would like to thank Ross Callon and Loa Andersson for - their suggestions. + The authors would like to thank Ross Callon, Loa Andersson, Stewart + Bryant, Mach Chen, and Greg Mirsky for their suggestions. 9. References 9.1. Normative References [I-D.ietf-rtgwg-mrt-frr-algorithm] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. Gopalan, "Algorithms for computing Maximally Redundant Trees for IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr- algorithm-01 (work in progress), July 2014.