--- 1/draft-ietf-rtgwg-multihomed-prefix-lfa-01.txt 2017-07-25 08:13:17.747136886 -0700 +++ 2/draft-ietf-rtgwg-multihomed-prefix-lfa-02.txt 2017-07-25 08:13:17.783137736 -0700 @@ -1,37 +1,39 @@ Routing Area Working Group P. Sarkar, Ed. Internet-Draft Individual -Intended status: Informational S. Hegde -Expires: July 20, 2017 C. Bowers - Juniper Networks, Inc. +Updates: 5286 (if approved) S. Hegde +Intended status: Standards Track C. Bowers +Expires: January 26, 2018 Juniper Networks, Inc. U. Chunduri, Ed. Huawei Technologies J. Tantsura Individual B. Decraene Orange H. Gredler RtBrick, Inc. - January 16, 2017 + July 25, 2017 LFA selection for Multi-Homed Prefixes - draft-ietf-rtgwg-multihomed-prefix-lfa-01 + draft-ietf-rtgwg-multihomed-prefix-lfa-02 Abstract This document shares experience gained from implementing algorithms to determine Loop-Free Alternates for multi-homed prefixes. In particular, this document provides explicit inequalities that can be used to evaluate neighbors as a potential alternates for multi-homed prefixes. It also provides detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs. + This documents updates and expands some of the "Routing Aspects" as + specified in Section 6 of [RFC5286]. 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 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -39,21 +41,22 @@ 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 July 20, 2017. + + This Internet-Draft will expire on January 26, 2018. Copyright Notice Copyright (c) 2017 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 @@ -80,25 +83,25 @@ 4.2.4. RFC1583compatibility is set to enabled . . . . . . . 10 4.2.5. Type 7 routes . . . . . . . . . . . . . . . . . . . . 10 4.2.6. Inequalities to be applied for alternate ASBR selection . . . . . . . . . . . . . . . . . . . . . . 10 4.2.6.1. Forwarding address set to non-zero value . . . . 10 4.2.6.2. ASBRs advertising type1 and type2 cost . . . . . 11 5. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 12 5.1. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 12 5.2. Multi Topology Considerations . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 - 9.2. Informative References . . . . . . . . . . . . . . . . . 15 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 8.2. Informative References . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The use of Loop-Free Alternates (LFA) for IP Fast Reroute is specified in [RFC5286]. Section 6.1 of [RFC5286] describes a method to determine loop-free alternates for a multi-homed prefixes (MHPs). This document describes a procedure using explicit inequalities that can be used by a computing router to evaluate a neighbor as a potential alternate for a multi-homed prefix. The results obtained @@ -110,21 +113,21 @@ computing LFAs for multi-homed prefixes in OSPF. This document provides detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs, as well as explicit inequalities. This document also provide clarifications, additional considerations to [RFC5286], to address a few coverage and operational observations. These observations are in the area of handling IS-IS attach (ATT) bit in Level-1 (L1) area, links provisioned with MAX_METRIC for traffic engineering (TE) purposes and in the area of Multi Topology (MT) IGP - deployments. All these are elaborated in detail in Section 3.2 and + deployments. These are elaborated in detail in Section 3.2 and Section 5. 1.1. Acronyms AF - Address Family ATT - IS-IS Attach Bit ECMP - Equal Cost Multi Path @@ -209,21 +212,21 @@ for P with the N as the alternate neighbor. 2.a. If LFA inequality condition is met, select N as a LFA for prefix P. 2.b. Else, N is not a LFA for prefix P. Figure 2: Rules for selecting LFA for MHPs In case an alternate neighbor N is also one of the prefix-originators of prefix P, N MAY be selected as a valid LFA for P. - However if N is not a prefix-originator of P, the computing router + However, if N is not a prefix-originator of P, the computing router SHOULD evaluate one of the corresponding LFA inequalities, as mentioned in Figure 1, once for each remote node that originated the prefix. In case the inequality is satisfied by the neighbor N router S MUST choose neighbor N, as one of the valid LFAs for the prefix P. When computing a downstream-only LFA, in addition to being a prefix- originator of P, router N MUST also satisfy the downstream-only LFA inequality specified in Figure 1. For more specific rules please refer to the later sections of this @@ -239,27 +242,27 @@ the router to simplify the multi-homed prefix calculation by assuming that the MHP is solely attached to the router that was its pre- failure optimal point of attachment, at the expense of potentially lower coverage. If an implementation chooses to simplify the multi- homed prefix calculation by assuming that the MHP is solely attached to the router that was its pre-failure optimal point of attachment, the procedure described in this memo can potentially improve coverage for equal cost multi path (ECMP) MHPs without incurring extra computational cost. - While the approach as specified in [RFC5286] Section 6.1 last - paragraph, is to simplify the MHP as solely attached to the router - that was its pre-failure optimal point of attachment; though it is a - scalable approach and simplifies computation, [RFC5286] notes this - may result in little less coverage. + The approach specified in [RFC5286] Section 6.1 last paragraph, is to + simplify the MHP as solely attached to the router that was its pre- + failure optimal point of attachment; though it is a scalable approach + and simplifies computation, [RFC5286] notes this may result in little + less coverage. - This memo improves the above approach to provide loop-free + This document improves the above approach to provide loop-free alternatives without any additional cost for equal cost multi path MHPs as described through the below example network. The approach specified here MAY also be applicable for handling default routes as explained in Section 3.2. 5 +---+ 8 +---+ 5 +---+ +-----| S |------| A |-----| B | | +---+ +---+ +---+ | | | | 5 | 5 | @@ -585,44 +588,40 @@ of the network with MT-ID 0. Here with single decision process both IPv4 and IPv6 next-hops are computed for all the prefixes in the network and similarly with one LFA computation from all eligible neighbors per [RFC5286], all potential alternatives can be computed. 6. Acknowledgements Thanks to Alia Atlas and Salih K A for their useful feedback and inputs. -7. IANA Considerations - - N/A. - No protocol changes are proposed in this document. - -8. Security Considerations +7. Security Considerations This document does not introduce any change in any of the protocol specifications and also this does not introduce any new security issues other than as noted in the LFA base specification [RFC5286]. -9. References +8. References -9.1. Normative References +8.1. Normative References [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . -9.2. Informative References +8.2. Informative References [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, DOI 10.17487/RFC3137, June 2001, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, .