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/