draft-ietf-rtgwg-bgp-pic-03.txt		draft-ietf-rtgwg-bgp-pic-04.txt
	Network Working Group A. Bashandy, Ed.		Network Working Group A. Bashandy, Ed.
	Internet Draft C. Filsfils		Internet Draft C. Filsfils
	Intended status: Informational Cisco Systems		Intended status: Informational Cisco Systems
	Expires: May 2017 P. Mohapatra		Expires: November 2017 P. Mohapatra
	Sproute Networks		Sproute Networks
	November 22, 2016		May 22, 2017
	BGP Prefix Independent Convergence		BGP Prefix Independent Convergence
	draft-ietf-rtgwg-bgp-pic-03.txt		draft-ietf-rtgwg-bgp-pic-04.txt
	Abstract		Abstract
	In the network comprising thousands of iBGP peers exchanging millions		In the network comprising thousands of iBGP peers exchanging millions
	of routes, many routes are reachable via more than one next-hop.		of routes, many routes are reachable via more than one next-hop.
	Given the large scaling targets, it is desirable to restore traffic		Given the large scaling targets, it is desirable to restore traffic
	after failure in a time period that does not depend on the number of		after failure in a time period that does not depend on the number of
	BGP prefixes. In this document we proposed an architecture by which		BGP prefixes. In this document we proposed an architecture by which
	traffic can be re-routed to ECMP or pre-calculated backup paths in a		traffic can be re-routed to ECMP or pre-calculated backup paths in a
	timeframe that does not depend on the number of BGP prefixes. The		timeframe that does not depend on the number of BGP prefixes. The
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on May 22, 2016.		This Internet-Draft will expire on November 22, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	skipping to change at page 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction...................................................3
	1.1. Conventions used in this document.........................4		1.1. Conventions used in this document.........................4
	1.2. Terminology...............................................4		1.2. Terminology...............................................4
	2. Overview.......................................................6		2. Overview.......................................................6
	2.1. Dependency................................................6		2.1. Dependency................................................6
	2.1.1. Hierarchical Hardware FIB............................6		2.1.1. Hierarchical Hardware FIB............................6
	2.1.2. Availability of more than one primary or secondary BGP		2.1.2. Availability of more than one primary or secondary BGP
	next-hops...................................................7		next-hops...................................................7
	2.1.3. Pre-Computation of a secondary BGP next-hop.....Error!
	Bookmark not defined.
	2.2. BGP-PIC Illustration......................................7		2.2. BGP-PIC Illustration......................................7
	3. Constructing the Shared Hierarchical Forwarding Chain..........9		3. Constructing the Shared Hierarchical Forwarding Chain..........9
	3.1. Constructing the BGP-PIC forwarding Chain.................9		3.1. Constructing the BGP-PIC forwarding Chain.................9
	3.1.1. Example: Primary-Backup Path Scenario...............10		3.2. Example: Primary-Backup Path Scenario....................10
	4. Forwarding Behavior...........................................11		4. Forwarding Behavior...........................................11
	5. Handling Platforms with Limited Levels of Hierarchy...........12		5. Handling Platforms with Limited Levels of Hierarchy...........12
	5.1. Flattening the Forwarding Chain..........................12		5.1. Flattening the Forwarding Chain..........................12
	5.2. Example: Flattening a forwarding chain...................14		5.2. Example: Flattening a forwarding chain...................14
	6. Forwarding Chain Adjustment at a Failure......................21		6. Forwarding Chain Adjustment at a Failure......................21
	6.1. BGP-PIC core.............................................22		6.1. BGP-PIC core.............................................22
	6.2. BGP-PIC edge.............................................23		6.2. BGP-PIC edge.............................................23
	6.2.1. Adjusting forwarding Chain in egress node failure...23		6.2.1. Adjusting forwarding Chain in egress node failure...23
	6.2.2. Adjusting Forwarding Chain on PE-CE link Failure....23		6.2.2. Adjusting Forwarding Chain on PE-CE link Failure....23
	6.3. Handling Failures for Flattened Forwarding Chains........24		6.3. Handling Failures for Flattened Forwarding Chains........24
	skipping to change at page 8, line 8 ¶		skipping to change at page 8, line 8 ¶
	Figure 1 VPN prefix reachable via multiple PEs		Figure 1 VPN prefix reachable via multiple PEs
	Referring to Figure 1, suppose the iPE (the ingress PE) receives		Referring to Figure 1, suppose the iPE (the ingress PE) receives
	NLRIs for the VPN prefixes VPN-IP1 and VPN-IP2 from two egress PEs,		NLRIs for the VPN prefixes VPN-IP1 and VPN-IP2 from two egress PEs,
	ePE1 and ePE2 with next-hop BGP-NH1 and BGP-NH2, respectively.		ePE1 and ePE2 with next-hop BGP-NH1 and BGP-NH2, respectively.
	Assume that ePE1 advertise the VPN labels VPN-L11 and VPN-L12 while		Assume that ePE1 advertise the VPN labels VPN-L11 and VPN-L12 while
	ePE2 advertise the VPN labels VPN-L21 and VPN-L22 for VPN-IP1 and		ePE2 advertise the VPN labels VPN-L21 and VPN-L22 for VPN-IP1 and
	VPN-IP2, respectively. Suppose that BGP-NH1 and BGP-NH2 are resolved		VPN-IP2, respectively. Suppose that BGP-NH1 and BGP-NH2 are resolved
	via the IGP prefixes IGP-IP1 and IGP-P2, where each happen to have 2		via the IGP prefixes IGP-IP1 and IGP-P2, where each happen to have 2
	ECMP paths with IGP-NH1 and IGP-NH2 reachable via the interfaces I1		ECMP paths with IGP-NH1 and IGP-NH2 reachable via the interfaces I1
	and I2, respectively. Suppose that local labels (whether LDP[5] or		and I2, respectively. Suppose that local labels (whether LDP [5] or
	segment routing [14]) on the downstream LSRs for IGP-IP1 are IGP-L11		segment routing [14]) on the downstream LSRs for IGP-IP1 are IGP-L11
	and IGP-L12 while for IGP-P2 are IGP-L21 and IGP-L22. As such, the		and IGP-L12 while for IGP-P2 are IGP-L21 and IGP-L22. As such, the
	routing table at iPE is as follows:		routing table at iPE is as follows:
	65000:11.1.1.0/24		65000:11.1.1.0/24
	via ePE1 (192.0.2.1), VPN Label: VPN-L11		via ePE1 (192.0.2.1), VPN Label: VPN-L11
	via ePE2 (192.0.2.2), VPN Label: VPN-L21		via ePE2 (192.0.2.2), VPN Label: VPN-L21
	65000:11.1.2.0/24		65000:11.1.2.0/24
	via ePE1 (192.0.2.1), VPN Label: VPN-L12		via ePE1 (192.0.2.1), VPN Label: VPN-L12
	skipping to change at page 20, line 37 ¶		skipping to change at page 20, line 37 ¶
	correct VPN label "VPN-L22", which is the label advertised by		correct VPN label "VPN-L22", which is the label advertised by
	ePE2 for the prefix "VPN-IP2"		ePE2 for the prefix "VPN-IP2"
	o The third entry has the index "1". This is because the third		o The third entry has the index "1". This is because the third
	entry corresponds to ePE3. Hence when the hashing is performed		entry corresponds to ePE3. Hence when the hashing is performed
	by the forwarding engine results in using the third entry in		by the forwarding engine results in using the third entry in
	the flattened pathlist, the forwarding engine will pick the		the flattened pathlist, the forwarding engine will pick the
	correct VPN label "VPN-L32", which is the label advertised by		correct VPN label "VPN-L32", which is the label advertised by
	"ePE3" for the prefix "VPN-IP2"		"ePE3" for the prefix "VPN-IP2"
	Now let's try and apply the forwarding steps in Section 4. together		Now let's try and apply the forwarding steps in Section 4 together
	with the additional step in Section 5.1 to the flattened forwarding		with the additional step in Section 5.1 to the flattened forwarding
	chain illustrated in Figure 6.		chain illustrated in Figure 6.
	o Suppose a packet arrives at "iPE" and matches the VPN prefix		o Suppose a packet arrives at "iPE" and matches the VPN prefix
	"VPN-IP2"		"VPN-IP2"
	o The forwarding engine walks to the parent of the "VPN-IP2", which		o The forwarding engine walks to the parent of the "VPN-IP2", which
	is the flattened pathlist and applies a hashing algorithm to pick		is the flattened pathlist and applies a hashing algorithm to pick
	a path		a path
	skipping to change at page 25, line 34 ¶		skipping to change at page 25, line 34 ¶
	that flattening forwarding chains usually results in moderate loss		that flattening forwarding chains usually results in moderate loss
	of BGP-PIC benefits. Further analysis is needed to corroborate and		of BGP-PIC benefits. Further analysis is needed to corroborate and
	quantify this statement.		quantify this statement.
	7. Properties		7. Properties
	7.1. Coverage		7.1. Coverage
	All the possible failures, except CE node failure, are covered,		All the possible failures, except CE node failure, are covered,
	whether they impact a local or remote IGP path or a local or remote		whether they impact a local or remote IGP path or a local or remote
	BGP next-hop as described in Section 6. This section provides		BGP next-hop as described in Section 6. This section provides
	details for each failure and now the hierarchical and shared FIB		details for each failure and now the hierarchical and shared FIB
	structure proposed in this document allows recovery that does not		structure proposed in this document allows recovery that does not
	depend on number of BGP prefixes.		depend on number of BGP prefixes.
	7.1.1. A remote failure on the path to a BGP next-hop		7.1.1. A remote failure on the path to a BGP next-hop
	Upon IGP convergence, the IGP leaf for the BGP next-hop is updated		Upon IGP convergence, the IGP leaf for the BGP next-hop is updated
	upon IGP convergence and all the BGP depending routes leverage the		upon IGP convergence and all the BGP depending routes leverage the
	new IGP forwarding state immediately. Details of this behavior can		new IGP forwarding state immediately. Details of this behavior can
	be found in Section 6.1.		be found in Section 6.1.
End of changes. 10 change blocks.
	11 lines changed or deleted		9 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/