draft-ietf-rtgwg-multihomed-prefix-lfa-01.txt   draft-ietf-rtgwg-multihomed-prefix-lfa-02.txt 
Routing Area Working Group P. Sarkar, Ed. Routing Area Working Group P. Sarkar, Ed.
Internet-Draft Individual Internet-Draft Individual
Intended status: Informational S. Hegde Updates: 5286 (if approved) S. Hegde
Expires: July 20, 2017 C. Bowers Intended status: Standards Track C. Bowers
Juniper Networks, Inc. Expires: January 26, 2018 Juniper Networks, Inc.
U. Chunduri, Ed. U. Chunduri, Ed.
Huawei Technologies Huawei Technologies
J. Tantsura J. Tantsura
Individual Individual
B. Decraene B. Decraene
Orange Orange
H. Gredler H. Gredler
RtBrick, Inc. RtBrick, Inc.
January 16, 2017 July 25, 2017
LFA selection for Multi-Homed Prefixes LFA selection for Multi-Homed Prefixes
draft-ietf-rtgwg-multihomed-prefix-lfa-01 draft-ietf-rtgwg-multihomed-prefix-lfa-02
Abstract Abstract
This document shares experience gained from implementing algorithms This document shares experience gained from implementing algorithms
to determine Loop-Free Alternates for multi-homed prefixes. In to determine Loop-Free Alternates for multi-homed prefixes. In
particular, this document provides explicit inequalities that can be particular, this document provides explicit inequalities that can be
used to evaluate neighbors as a potential alternates for multi-homed used to evaluate neighbors as a potential alternates for multi-homed
prefixes. It also provides detailed criteria for evaluating prefixes. It also provides detailed criteria for evaluating
potential alternates for external prefixes advertised by OSPF ASBRs. 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 Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 4 skipping to change at page 2, line 6
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 2, line 48
4.2.4. RFC1583compatibility is set to enabled . . . . . . . 10 4.2.4. RFC1583compatibility is set to enabled . . . . . . . 10
4.2.5. Type 7 routes . . . . . . . . . . . . . . . . . . . . 10 4.2.5. Type 7 routes . . . . . . . . . . . . . . . . . . . . 10
4.2.6. Inequalities to be applied for alternate ASBR 4.2.6. Inequalities to be applied for alternate ASBR
selection . . . . . . . . . . . . . . . . . . . . . . 10 selection . . . . . . . . . . . . . . . . . . . . . . 10
4.2.6.1. Forwarding address set to non-zero value . . . . 10 4.2.6.1. Forwarding address set to non-zero value . . . . 10
4.2.6.2. ASBRs advertising type1 and type2 cost . . . . . 11 4.2.6.2. ASBRs advertising type1 and type2 cost . . . . . 11
5. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 12 5. LFA Extended Procedures . . . . . . . . . . . . . . . . . . . 12
5.1. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 12 5.1. Links with IGP MAX_METRIC . . . . . . . . . . . . . . . . 12
5.2. Multi Topology Considerations . . . . . . . . . . . . . . 13 5.2. Multi Topology Considerations . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The use of Loop-Free Alternates (LFA) for IP Fast Reroute is The use of Loop-Free Alternates (LFA) for IP Fast Reroute is
specified in [RFC5286]. Section 6.1 of [RFC5286] describes a method specified in [RFC5286]. Section 6.1 of [RFC5286] describes a method
to determine loop-free alternates for a multi-homed prefixes (MHPs). to determine loop-free alternates for a multi-homed prefixes (MHPs).
This document describes a procedure using explicit inequalities that This document describes a procedure using explicit inequalities that
can be used by a computing router to evaluate a neighbor as a can be used by a computing router to evaluate a neighbor as a
potential alternate for a multi-homed prefix. The results obtained potential alternate for a multi-homed prefix. The results obtained
skipping to change at page 3, line 28 skipping to change at page 3, line 30
computing LFAs for multi-homed prefixes in OSPF. This document computing LFAs for multi-homed prefixes in OSPF. This document
provides detailed criteria for evaluating potential alternates for provides detailed criteria for evaluating potential alternates for
external prefixes advertised by OSPF ASBRs, as well as explicit external prefixes advertised by OSPF ASBRs, as well as explicit
inequalities. inequalities.
This document also provide clarifications, additional considerations This document also provide clarifications, additional considerations
to [RFC5286], to address a few coverage and operational observations. to [RFC5286], to address a few coverage and operational observations.
These observations are in the area of handling IS-IS attach (ATT) bit 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 in Level-1 (L1) area, links provisioned with MAX_METRIC for traffic
engineering (TE) purposes and in the area of Multi Topology (MT) IGP 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. Section 5.
1.1. Acronyms 1.1. Acronyms
AF - Address Family AF - Address Family
ATT - IS-IS Attach Bit ATT - IS-IS Attach Bit
ECMP - Equal Cost Multi Path ECMP - Equal Cost Multi Path
skipping to change at page 5, line 40 skipping to change at page 5, line 40
for P with the N as the alternate neighbor. for P with the N as the alternate neighbor.
2.a. If LFA inequality condition is met, 2.a. If LFA inequality condition is met,
select N as a LFA for prefix P. select N as a LFA for prefix P.
2.b. Else, N is not a LFA for prefix P. 2.b. Else, N is not a LFA for prefix P.
Figure 2: Rules for selecting LFA for MHPs Figure 2: Rules for selecting LFA for MHPs
In case an alternate neighbor N is also one of the prefix-originators 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. 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 SHOULD evaluate one of the corresponding LFA inequalities, as
mentioned in Figure 1, once for each remote node that originated the mentioned in Figure 1, once for each remote node that originated the
prefix. In case the inequality is satisfied by the neighbor N router 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. 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- When computing a downstream-only LFA, in addition to being a prefix-
originator of P, router N MUST also satisfy the downstream-only LFA originator of P, router N MUST also satisfy the downstream-only LFA
inequality specified in Figure 1. inequality specified in Figure 1.
For more specific rules please refer to the later sections of this For more specific rules please refer to the later sections of this
skipping to change at page 6, line 22 skipping to change at page 6, line 22
the router to simplify the multi-homed prefix calculation by assuming the router to simplify the multi-homed prefix calculation by assuming
that the MHP is solely attached to the router that was its pre- that the MHP is solely attached to the router that was its pre-
failure optimal point of attachment, at the expense of potentially failure optimal point of attachment, at the expense of potentially
lower coverage. If an implementation chooses to simplify the multi- lower coverage. If an implementation chooses to simplify the multi-
homed prefix calculation by assuming that the MHP is solely attached homed prefix calculation by assuming that the MHP is solely attached
to the router that was its pre-failure optimal point of attachment, to the router that was its pre-failure optimal point of attachment,
the procedure described in this memo can potentially improve coverage the procedure described in this memo can potentially improve coverage
for equal cost multi path (ECMP) MHPs without incurring extra for equal cost multi path (ECMP) MHPs without incurring extra
computational cost. computational cost.
While the approach as specified in [RFC5286] Section 6.1 last The approach specified in [RFC5286] Section 6.1 last paragraph, is to
paragraph, is to simplify the MHP as solely attached to the router simplify the MHP as solely attached to the router that was its pre-
that was its pre-failure optimal point of attachment; though it is a failure optimal point of attachment; though it is a scalable approach
scalable approach and simplifies computation, [RFC5286] notes this and simplifies computation, [RFC5286] notes this may result in little
may result in little less coverage. 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 alternatives without any additional cost for equal cost multi path
MHPs as described through the below example network. The approach MHPs as described through the below example network. The approach
specified here MAY also be applicable for handling default routes as specified here MAY also be applicable for handling default routes as
explained in Section 3.2. explained in Section 3.2.
5 +---+ 8 +---+ 5 +---+ 5 +---+ 8 +---+ 5 +---+
+-----| S |------| A |-----| B | +-----| S |------| A |-----| B |
| +---+ +---+ +---+ | +---+ +---+ +---+
| | | | | |
| 5 | 5 | | 5 | 5 |
skipping to change at page 14, line 25 skipping to change at page 14, line 25
of the network with MT-ID 0. Here with single decision process both 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 IPv4 and IPv6 next-hops are computed for all the prefixes in the
network and similarly with one LFA computation from all eligible network and similarly with one LFA computation from all eligible
neighbors per [RFC5286], all potential alternatives can be computed. neighbors per [RFC5286], all potential alternatives can be computed.
6. Acknowledgements 6. Acknowledgements
Thanks to Alia Atlas and Salih K A for their useful feedback and Thanks to Alia Atlas and Salih K A for their useful feedback and
inputs. inputs.
7. IANA Considerations 7. Security Considerations
N/A. - No protocol changes are proposed in this document.
8. Security Considerations
This document does not introduce any change in any of the protocol This document does not introduce any change in any of the protocol
specifications and also this does not introduce any new security specifications and also this does not introduce any new security
issues other than as noted in the LFA base specification [RFC5286]. 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 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195, dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/rfc1195>. December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References 8.2. Informative References
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 3137, McPherson, "OSPF Stub Router Advertisement", RFC 3137,
DOI 10.17487/RFC3137, June 2001, DOI 10.17487/RFC3137, June 2001,
<http://www.rfc-editor.org/info/rfc3137>. <http://www.rfc-editor.org/info/rfc3137>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007, RFC 4915, DOI 10.17487/RFC4915, June 2007,
<http://www.rfc-editor.org/info/rfc4915>. <http://www.rfc-editor.org/info/rfc4915>.
 End of changes. 14 change blocks. 
27 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/