draft-vandevelde-idr-flowspec-path-redirect-02.txt		draft-vandevelde-idr-flowspec-path-redirect-03.txt
	IDR Working Group G. Van de Velde, Ed.		IDR Working Group G. Van de Velde, Ed.
	Internet-Draft W. Henderickx		Internet-Draft W. Henderickx
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Nokia
	Expires: September 18, 2016 K. Patel		Expires: January 9, 2017 K. Patel
	A. Sreekantiah		A. Sreekantiah
	Cisco Systems		Cisco Systems
	March 17, 2016		Z. Li
			S. Zhuang
			N. Wu
			Huawei Technologies
			July 8, 2016
	Flowspec Indirection-id Redirect		Flowspec Indirection-id Redirect
	draft-vandevelde-idr-flowspec-path-redirect-02		draft-vandevelde-idr-flowspec-path-redirect-03
	Abstract		Abstract
	Flow-spec is an extension to BGP that allows for the dissemination of		Flowspec is an extension to BGP that allows for the dissemination of
	traffic flow specification rules. This has many possible		traffic flow specification rules. This has many possible
	applications but the primary one for many network operators is the		applications but the primary one for many network operators is the
	distribution of traffic filtering actions for DDoS mitigation. The		distribution of traffic filtering actions for DDoS mitigation. The
	flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for		flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for
	policy-based forwarding but this mechanism is not always sufficient,		policy-based forwarding but this mechanism is not always sufficient,
	particular if the redirected traffic needs to be steered into an		particularly if the redirected traffic needs to be steered into an
	engineered path or into a service plane.		engineered path or into a service plane.
	This document defines a new redirect-to-INDIRECTION_ID (32-bit or		This document defines a new extended community known as redirect-to-
	128-bit) flow-spec action to provide advanced redirection		indirection-id (32-bit) flowspec action to provide advanced
	capabilities. When activated, the flowspec Indirection-id is used to		redirection capabilities on flowspec clients. When activated, the
	identify the next-hop redirect information within a router locallized		flowspec extended community is used by a flowspec client to find the
	Indirection-id table. This allows a flowspec controller to signal		correct next-hop entry within a localised indirection-id mapping
	redirection towards a next-hop IP address, a shortest path tunnel, a		table.
	traffic engineered tunnel or a next-next-hop engineered tunnel
	interface.		The functionality present in this draft allows a network controller
			to decouple flowspec functionality from the creation and maintainance
			of the network's service plane itself including the setup of tunnels
			and other service constructs that could be managed by other network
			devices.
	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 RFC 2119 [1].		document are to be interpreted as described in RFC 2119 [1].
	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 10 ¶		skipping to change at page 2, line 20 ¶
	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 September 18, 2016.		This Internet-Draft will expire on January 9, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. INDIRECTION_ID and INDIRECTION_ID Table . . . . . . . . . . . 3		2. indirection-id and indirection-id table . . . . . . . . . . . 3
	3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4		3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 4		3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 4
	3.2. Redirection to path-engineered tunnels . . . . . . . . . 4		3.2. Redirection to path-engineered tunnels . . . . . . . . . 4
	3.3. Redirection to Next-next-hop tunnels . . . . . . . . . . 5		3.3. Redirection to Next-next-hop tunnels . . . . . . . . . . 5
	4. Redirect to INDIRECTION-ID Communities . . . . . . . . . . . 6		4. Redirect to indirection-id Community . . . . . . . . . . . . 6
	5. Redirect using locallized INDIRECTION_ID Router Mapping . . . 7		5. Redirect using localised indirection-id mapping table . . . . 8
	6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 8		6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 9		10.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Flow-spec RFC5575 [2] is an extension to BGP that allows for the		Flowspec RFC5575 [2] is an extension to BGP that allows for the
	dissemination of traffic flow specification rules. This has many		dissemination of traffic flow specification rules. This has many
	possible applications but the primary one for many network operators		possible applications, however the primary one for many network
	is the distribution of traffic filtering actions for DDoS mitigation.		operators is the distribution of traffic filtering actions for DDoS
			mitigation.
	Every flow-spec route is effectively a rule, consisting of a matching		Every flowspec policy route is effectively a rule, consisting of a
	part (encoded in the NLRI field) and an action part (encoded in one		matching part (encoded in the NLRI field) and an action part (encoded
	or more BGP extended community). The flow-spec standard RFC5575 [2]		in one or more BGP extended communities). The flow-spec standard
	defines widely-used filter actions such as discard and rate limit; it		RFC5575 [2] defines widely-used filter actions such as discard and
	also defines a redirect-to-VRF action for policy-based forwarding.		rate limit; it also defines a redirect-to-VRF action for policy-based
	Using the redirect-to-VRF action for redirecting traffic towards an		forwarding. Using the redirect-to-VRF action to steer traffic
	alternate destination is useful for DDoS mitigation but using this		towards an alternate destination is useful for DDoS mitigation but
	technology can be cumbersome when there is need to redirect the		using this technology can be cumbersome when there is need to steer
	traffic onto an engineered traffic path.		the traffic onto an engineered traffic path.
	This draft proposes a new redirect-to-Indirection-id flow-spec action		This draft proposes a new redirect-to-indirection-id flowspec action
	facilitating an anchor point for policy-based forwarding onto an		facilitating an anchor point for policy-based forwarding onto an
	engineered path or into a service plane. The router consuming and		engineered path or into a service plane. The flowspec client
	utilizing the flowspec rule makes a local mapping between the		consuming and utilizing the new flowspec indirection-id extended-
	flowspec signalled redirect Indirection-id and locally available		community finds the redirection information within a localised
	redirection information referenced by the Indirection-id. This		indirection-id mapping table. The localised mapping table is a table
	locally available redirection information is derived from out-of-band		construct providing at one side the table key and at the other side
	programming or signalling.		next-hop information. The table key consists out the combination of
			indirection-id type and indirection-id 32-bit value.
	The redirect-to-Indirection-id is encoded in a newly defined BGP		The redirect-to-indirection-id flowspec action is encoded in a newly
	extended Indirection_ID community.		defined BGP extended community. In addition, the type of redirection
			can be configured as an extended community indirection-id type field.
	The construction of the Indirection-id redirect table and the		This draft defines the indirection-id extended-community and the
	technology used to create an engineered path are out-of-scope of this		wellknown indirection-id types. The specific solution to construct
			the localised indirection-id mapping table are out-of-scope of this
	document.		document.
	2. INDIRECTION_ID and INDIRECTION_ID Table		2. indirection-id and indirection-id table
	An INDIRECTION_ID is an abstract number (32-bit or 128-bit value)		An indirection-id is an abstract number (32-bit value) used as
	used as identifier for a localised redirection decision. e.g. When a		identifier for a localised indirection decision. The indirection-id
	BGP flowspec controller intends to redirect a flow using te redirect-		will allow a flowspec client to redirect traffic into a service plane
	to-INDIRECTION_ID action then it has the ability to redirect the flow		or onto an engineered traffic path. e.g. When a BGP flowspec
	to a destination abstracted as the INDIRECTION_ID. The device		controller signals a flowspec client the indirection-id extended
	receiving the BGP flowspec rule will use the INDIRECTION_ID to		community, then the flowspec client uses the indirection-id to make a
	identify the next-hop and the relevant tunnel encapsulations that		recursive lookup to retrieve next-hop information found in a
	need to be pushed by a localised recursive lookup using information		localised indirection mapping table.
	located within the INDIRECTION_ID table.
	The INDIRECTION_ID Table is a router localised table. The table		The indirection-id table is a router localised table. The
	content is constructed out of INDIRECTION_IDs and corresponding		indirection-id table is constructed out of table keys mapped to
	redirect information which may be of rescursive or non-recursive		flowspec client localised redirection information. The table key is
	nature. When the redirect information is non-recursive, then the		created by the combination of the indirection-id type and the
	represented information MUST be sufficient to identify the local		indirection-id 32-bit value. Each entry in the indirection-table key
	egress interface and the corresponding required encapsulations.		maps to sufficient information (parameters regarding encapsulation,
	However, if the information is recursive, then the represented		interface, QoS, etc...) to successfully redirect traffic.
	information MUST be sufficient to identify the local egress interface
	and corresponding encapsulations using additional recursions.
	3. Use Case Scenarios		3. Use Case Scenarios
	This section describes use-case scenarios when deploying redirect-to-		This section describes use-case scenarios when deploying redirect-to-
	INDIRECTION_ID.		indirection-id.
	3.1. Redirection shortest Path tunnel		3.1. Redirection shortest Path tunnel
	A first use-case is allowing a BGP Flowspec controller send a single		A first use-case is allowing a BGP Flowspec controller to send a
	flowspec policy message (redirect-to-INDIRECTION_ID#1) to many BGP		single flowspec policy route (i.e. flowspec_route#1) to many BGP
	flowspec consuming routers. This message is instructing the Flowspec		flowspec clients. This flowspec route signals the Flowspec clients
	recipient routers to redirect traffic onto a tunnel to a single IP		to redirect traffic onto a tunnel towards a single IP destination
	destination address.		address.
	For this use-case scenario, each flowspec recipient router has a		For this first use-case scenario, the flowspec client receives from
	tunnel configured following the shortest path towards a tunnel IP		the flowspec controller a flowspec route (i.e. flowspec_route#1)
	destination address. Each tunnel can have its own unique		including the redirect-to-indirection-id extended community. The
	encapsulation associated. Each tunnel is associated with an		redirect-to-indirection-id extended community contains the key
	INDIRECTION_ID, and for this example it is on all recipient routers		(indirection-id type + indirection-id 32-bit value) to select the
	INDIRECTION_ID#1. Both manual and orchestrated tunnel provisioning		corresponding next-hop information from the flowpsec client localised
	is supported, however for large scale deployment automation is		indirection-id table. The resulting next-hop information for this
	advisable.		use-case is a remote tunnel end-point IP address with accordingly
			sufficient tunnel encapsulation information to forward the packet
			accordingly.
	When using this setup, a BGP flowspec controller can send a single		For redirect to shortest path tunnel it is required that the tunnel
	BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#1. This BGP		MUST be operational and allow packets to be exchanged between tunnel
	Flowspec NLRI is received by all recipient routers. Each of the		head- and tail-end.
	recipient routers performs a locallised recursive lookup for
	INDIRECTION_ID#1 in the INDIRECTION_ID Table and identifies the
	corresponding locallised tunnel redirect information. This
	locallised tunnel information is now used to redirect traffic
	matching the Flowspec policy towards a tunnel, each potentially using
	its own unique tunnel encapsulation.
	3.2. Redirection to path-engineered tunnels		3.2. Redirection to path-engineered tunnels
	A second use-case is allowing a BGP Flowspec controller send a single		For a second use-case, it is expected that the flowspec client
	flowspec policy message (redirect-to-INDIRECTION_ID#2) to many BGP		redirect traffic matches the flowspec rule, onto a path engineered
	flowspec consuming routers. This message is instructing the Flowspec		tunnel. The path engineered tunnel on the flowspec client SHOULD be
	recipient routers to redirect traffic onto a path engineered tunnel.		created by out-of-band mechanisms. Each path engineered tunnel
			deployed for flowspec redirection, has a unque key as an identifier.
	For this use-case scenario, each flowspec recipient router has a path		consequently, the key (=indirection-id type and indirection-id 32-bit
	engineered tunnel configured. Each tunnel can have its own unique		value) uniquely identifies a single path engineered tunnel on the
	encapsulation and engineered path associated. Each tunnel is		flowspec client. The localised indirection-id mapping table is the
	associated with an INDIRECTION_ID, and for this example it is on all		collection of all keys corresponding all path engineered tunnels on
	recipient routers INDIRECTION_ID#2. Both manual and orchestrated		the flowspec client.
	tunnel provisioning is supported, however for large scale deployment
	automation is advisable.
	A first example using this setup, is when a BGP flowspec controller		For this second use-case scenario, the flowspec controller sends a
	sends a single BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#2.		flowspec route (i.e. flowspec_route#2) to the flowspec clients. The
	This BGP Flowspec NLRI is received by all recipient routers. Each of		flowspec clients, respectively receive the flowspec route. The
	the recipient routers performs a locallised recursive lookup for		redirect-to-indirection-id extended community contains the key
	INDIRECTION_ID#2 in the INDIRECTION_ID Table and identifies the		(indirection type + indirection-id 32-bit value) to select the
	corresponding locallised tunnel redirect information. This		corresponding next-hop information from the flowpsec client localised
	locallised tunnel information is now used to redirect traffic		indirection-id table. The resulting next-hop information for this
	matching the Flowspec policy towards a path engineered tunnel.		use-case is path engineered tunnel information and has sufficient
			tunnel encapsulation information to forward the packet according the
			expectations of the flowspec controller.
	A second example can be found in segment routed networks where path		A concrete example of this use-case can be found in segment routed
	engineered tunnels can be setup by means of a controller signaling		networks where path engineered tunnels can be setup by means of a
	explicit paths to peering routers. In such a case, the		controller signaling explicit paths to peering routers. In such a
	INDIRECTION_ID references to a Segment Routing Binding SID. The		case, the indirection-id references to a Segment Routing Binding SID,
	Binding SID is a segment identifier value (as per segment routing		while the indirection-id type references the Bindging SID semantic.
			The Binding SID is a segment identifier value (as per segment routing
	definitions in [I-D.draft-ietf-spring-segment-routing] [6]) used to		definitions in [I-D.draft-ietf-spring-segment-routing] [6]) used to
	associate with a explicit path and can be setup by a controller using		associate with an explicit path and can be setup by a controller
	BGP as specified in [I-D.sreekantiah-idr-segment-routing-te] [5] or		using BGP as specified in [I-D.sreekantiah-idr-segment-routing-te]
	using PCE as detailed in draft-ietf-pce-segment-routing [7]. When a		[5] or using PCE as detailed in draft-ietf-pce-segment-routing [7].
	BGP speaker receives a flow-spec route with a 'redirect to Binding		When a BGP speaker receives a flow-spec route with a 'redirect to
	SID' extended community, it installs a traffic filtering rule that		Binding SID' extended community, it installs a traffic filtering rule
	matches the packets described by the NLRI field and redirects them to		that matches the packets described by the NLRI field and redirects
	the explicit path associated with the Binding SID. The explicit path		them to the explicit path associated with the Binding SID. The
	is specified as a set/stack of segment identifiers as detailed in the		explicit path is specified as a set/stack of segment identifiers as
	previous documents. The stack of segment identifiers is now imposed		detailed in the previous documents. The stack of segment identifiers
	on packets matching the flow-spec rule to perform redirection as per		is now imposed on packets matching the flow-spec rule to perform
	the explicit path setup prior. The encoding of the Binding SID value		redirection as per the explicit path setup prior. The encoding of
	is specified in section 4, with the indirection field now encoding		the Binding SID value is specified in section 4, with the
	the associated value for the binding SID.		indirection-id field now encoding the associated value for the
			binding SID.
	3.3. Redirection to Next-next-hop tunnels		3.3. Redirection to Next-next-hop tunnels
	A Third use-case is allowing a BGP Flowspec controller send a single		A Third use-case is when a BGP Flowspec controller sends a single
	flowspec policy message (redirect-to-INDIRECTION_ID#3) to many BGP		flowspec policy route to flowpsec clients to signal redirection
	flowspec consuming routers. This message is instructing the Flowspec		towards next-next-hop tunnels. In this use-case The flowspec rule is
	recipient routers to redirect traffic onto a shortest or engineered		instructing the Flowspec client to redirect traffic using a sequence
	path to a tunnel end-point and onwards to the next-hop-interface on		of indirection-id extended communities. The sequence of indirection-
	this end-point. This type of tunnel is used for example for Segment		ids is managed using Tunnel IDs (TID). i.e. a classic example would
	Routing Central Egress Path Engineering [4].		be DDoS mitigation towards Segment Routing Central Egress Path
			Engineering [4]. To steer DDoS traffic towards egress peer
			engineering paths, a first indirection-id will steer traffic onto a
			tunnel to an egress router, while a second indirection-id is used
			steer the traffic at this egress router onto a particular interface
			or towards a peer. The flowspec client will for this use-case
			dynamically append all segment routing segments to steer the DDoS
			traffic through the EPE path.
	For this use-case scenario, each flowspec recipient router constructs		To achieve this type of redirection to next-next-hop tunnels,
	redirect information using two tunnel components. The first		multiple indirection-ids, each using a unique Tunnel ID are imposed
	component is a shortest or engineered path towards a network egress		upon a the flowspec policy rule. The Tunnel ID will allow the
	router. The second component is the interface used on this network		flowspec client to sequence the indirection-ids for correct next-
	egress router to which the redirected traffic needs to be steered		next-hop tunnel constructs.
	upon. The combination of these two components allows steering
	towards the next-hop of the egress router, allowing for example the
	Central Egress Path Engineering using BGP Flowspec [4].
	The redirection towards a next-next-hop tunnel can be done by using		4. Redirect to indirection-id Community
	either a single INDIRECTION_ID representing the combined path to the
	egress router and steering the traffic to the egress interface, or by
	using individual INDIRECTION_IDs each representing a tunnel component
	(One INDIRECTION_ID value to identify the path towards the egress
	router and another INDIRECTION_ID value to identify the egress
	interface on this egress router towards the next-next-hop). When
	using individual INDIRECTION_IDs it is required to use INDIRECTION_ID
	community Tunnel IDs (TID) each identifying a component of the
	complete redirect path attached to the NLRI.
	i.e. when using next-next-hop tunnels, a BGP flowspec controller can		This document defines a new BGP extended community known as a
	send a single BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#3.		Redirect-to-indirection-id extended community. This extended
	This BGP Flowspec NLRI is received by all recipient routers. Each of		community is a new transitive extended community with the Type and
	the recipient routers performs a locallised recursive lookup for		the Sub-Type field to be assigned by IANA. The format of this
	INDIRECTION_ID#3 in the INDIRECTION_ID Table and identifies the		extended community is show in Figure 1.
	corresponding locallised tunnel redirect information (=path to the
	egress router and the next-hop egress interface on this router).
	Traffic matching the flowspec policy is redirected towards the
	recursively found redirection information.
	4. Redirect to INDIRECTION-ID Communities		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Sub-Type | Flags(1 octet)| Indirection ID|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Generalized indirection_id |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	This document defines a new BGP extended community. The extended		Figure 1
	communities have a type indicating they are transitive and IPv4-
	address-specific or IPv6-address-specific, depending on whether the
	INDIRECTION_ID is 32-bit or 128-bit. The sub-type value [to be
	assigned by IANA] indicates that the global administrator and local
	administrator fields encode a flow-spec 'redirect to INDIRECTION_ID'
	action. In the new extended community the 4-byte or 16-byte global
	administrator field encodes the 32-bit or 128-bit INDIRECTION_ID's
	providing the INDIRECTION_ID to allow a local to the router mapping
	reference to an engineered Path. The 2-byte local administrator
	field is formatted as shown in Figure 1.
	0 1		The meaning of the extended community fields are as follows:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |B|TID|C|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1		Type: 1 octet to be assigned by IANA.
	In the local administrator field the least-significant bit is defined		Sub-Type: 1 octet to be assigned by IANA.
	as the 'C' (or copy) bit. When the 'C' bit is set the redirection
	applies to copies of the matching packets and not to the original
	traffic stream.
	The 'TID' field identifies a 2 bit Table-id field. This field is		Flags: 1 octet field. Following Flags are defined.
	used to provide the router consuming the flowspec rule an indication
	how and where to use the INDIRECTION_ID when redirecting traffic.
	Bit 2 is defined to be the 'B' (Binding) bit. When the 'B' bit is		0 1
	set, the value encoded in the global administrator field is a Binding		0 1 2 3 4 5 6 7
	Segment Identifier value the use of which is detailed in section 3.2.		+-+-+-+-+-+-+-+-+
			| RES | TID |C|
			+-+-+-+-+-+-+-+-+
	All bits other than the 'C', 'TID' and 'B' bits in the local		Figure 2
	administrator field MUST be set to 0 by the originating BGP speaker
	and ignored by receiving BGP speakers.
	5. Redirect using locallized INDIRECTION_ID Router Mapping		The least-significant Flag bit is defined as the 'C' (or copy) bit.
			When the 'C' bit is set the redirection applies to copies of the
			matching packets and not to the original traffic stream.
	When a BGP speaker receives a flow-spec route with a 'redirect to		The 'TID' field identifies a 4 bit Table-id field. This field is
	INDIRECTION_ID' extended community and this route represents the one		used to provide the flowspec client an indication how and where to
	and only best path, it installs a traffic filtering rule that matches		sequence the received indirection-ids to redirecting traffic. TID
	the packets described by the NLRI field and redirects them (C=0) or		value 0 indicates that Table-id field is NOT set and SHOULD be
	copies them (C=1) towards the INDIRECTION_ID local recursed Path.		ignored.
	The BGP speaker is expected to do a local INDIRECTION_ID Table lookup
	to identify the redirection information.
	The router local INDIRECTION_ID table contains a list of		All bits other than the 'C' and 'TID' bits MUST be set to 0 by the
	INDIRECTION_ID's each mapped to redirect information. The redirect		originating BGP speaker and ignored by receiving BGP speakers.
	information can be non-recursive (i.e. there is only one option
	available in the INDIRECTION_ID Table) or recursive (i.e. L3 VPN, L2
	VPN, a pre-programmed routing topology, etc... ).
	o When the redirect information is non-recursive then the packet is		Indirection ID: 1 octet value. This draft defines following
	redirected based upon the information found in the Table.		indirection_id Types:
	o In case of a next-hop tunnel, the traffic matching the flowspec		0 - Localised ID
	rule is redirected to the next-hop tunnel. This tunnel could be
	instantiated through various means (i.e. manual configuration,
	PCEP, RSVP-TE, WAN Controller, Segment Routing, etc...).
	o In case of redirection to a local next-hop interface, the traffic		1 - Node ID
	matching the flowspec rule is redirected to the local next-hop
	interface.
	o In case the INDIRECTION_ID Table lookup results in redirect		2 - Agency ID
	information identifying an additional layer of recursion, then
	this will trigger the flow to be redirected based upon an		3 - AS (Autonomous System) ID
	additional routing lookup within the realm of the additional layer
	of recursion.		4 - Anycast ID
			5 - Multicast ID
			6 - Tunnel ID (Tunnel Binding ID )
			7 - VPN ID
			8 - OAM ID
			9 - ECMP (Equal Cost Multi-Path) ID
			10 - QoS ID
			11 - Bandwidth-Guarantee ID
			12 - Security ID
			13 - Multi-Topology ID
			5. Redirect using localised indirection-id mapping table
			When a BGP speaker receives a flowspec policy route with a 'redirect
			to indirection-id' extended community and this route represents the
			one and only best path or an equal cost multipath, it installs a
			traffic filtering rule that matches the packets described by the NLRI
			field and redirects them (C=0) or copies them (C=1) towards the
			indirection-id local recursed path. To construct the local recursed
			path, the flowspec client does a local indirection-id mapping table
			lookup using the key comprised of the indirection-id 32-bit value and
			indirection-id type to retrieve the correct redirection information.
	6. Validation Procedures		6. Validation Procedures
	The validation check described in RFC5575 [2] and revised in [3]		The validation check described in RFC5575 [2] and revised in [3]
	SHOULD be applied by default to received flow-spec routes with a		SHOULD be applied by default to received flow-spec routes with a
	'redirect to INDIRECTION_ID' extended community. This means that a		'redirect to indirection-id' extended community. This means that a
	flow-spec route with a destination prefix subcomponent SHOULD NOT be		flow-spec route with a destination prefix subcomponent SHOULD NOT be
	accepted from an EBGP peer unless that peer also advertised the best		accepted from an EBGP peer unless that peer also advertised the best
	path for the matching unicast route.		path for the matching unicast route.
	It is possible from a semenatics perspective to have multiple		It is possible from a semenatics perspective to have multiple
	redirect actions defined within a single flowspec rule. When a BGP		redirect actions defined within a single flowspec rule. When a BGP
	flowspec NLRI has a 'redirect to INDIRECTION_ID' extended community		flowspec NLRI has a 'redirect to indirection-id' extended community
	attached resulting in valid redirection then it MUST take priority		attached resulting in valid redirection then it MUST take priority
	above all other redirect actions emposed. However, if the 'redirect		above all other redirect actions emposed. However, if the 'redirect
	to INDIRECTION_ID' does not result in a valid redirection, then the		to indirection-id' does not result in a valid redirection, then the
	flowspec rule must be processed as if the 'redirect to		flowspec rule must be processed as if the 'redirect to indirection-
	INDIRECTION_ID' community was not attached to the flowspec route and		id' community was not attached to the flowspec route and MUST provide
	MUST provide an indication within the BGP routing table that the		an indication within the BGP routing table that the respective
	'redirect to INDIRECTION_ID' resulted in an invalid redirection		'redirect to indirection-id' resulted in an invalid redirection
	action.		action.
	7. Security Considerations		7. Security Considerations
	A system using 'redirect-to-INDIRECTION_ID' extended community can		A system using 'redirect-to-indirection-id' extended community can
	cause during the redirect mitigation of a DDoS attack result in an		cause during the redirect mitigation of a DDoS attack result in
	overflow of traffic being received by the mitigation infrastructure.		overflow of traffic received by the mitigation infrastructure.
	8. Acknowledgements		8. Acknowledgements
	This document received valuable comments and input from IDR working		This document received valuable comments and input from IDR working
	group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert		group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert
	Raszuk, Jeff Haas, Susan Hares and Lucy Yong		Raszuk, Jeff Haas, Susan Hares and Lucy Yong
	9. IANA Considerations		9. IANA Considerations
	This document requests a new sub-type from the "Transitive IPv4-		This document requests a new type and sub-type for the Redirect to
	Address-Specific" extended community registry. The sub-type name		indirection-id Extended community from the "Transitive Extended
	shall be 'Flow-spec Redirect to 32-bit Path-id'.		community" registry. The Type name shall be "Redirect to
			indirection-id Extended Community" and the Sub-type name shall be
			'Flow-spec Redirect to 32-bit Path-id'.
	This document requests a new sub-type from the "Transitive IPv6-		In addition, this document requests IANA to create a new registry for
	Address-Specific" extended community registry. The sub-type name		Redirect to indirection-id Extended Community INDIRECTION-IDs as
	shall be 'Flow-spec Redirect to 128-bit Path-id'.		follows:
			Under "Transitive Extended Community:"
			Registry: "Redirect Extended Community indirection_id"
			Reference: [RFC-To-Be]
			Registration Procedure(s): First Come, First Served
			Registry: "Redirect Extended Community indirection_id"
			Value Code Reference
			0 Localised ID [RFC-To-Be]
			1 Node ID [RFC-To-Be]
			2 Agency ID [RFC-To-Be]
			3 AS (Autonomous System) ID [RFC-To-Be]
			4 Anycast ID [RFC-To-Be]
			5 Multicast ID [RFC-To-Be]
			6 Tunnel ID (Tunnel Binding ID ) [RFC-To-Be]
			7 VPN ID [RFC-To-Be]
			8 OAM ID [RFC-To-Be]
			9 ECMP (Equal Cost Multi-Path) ID [RFC-To-Be]
			10 QoS ID [RFC-To-Be]
			11 Bandwidth-Guarantee ID [RFC-To-Be]
			12 Security ID [RFC-To-Be]
			13 Multi-Topology ID [RFC-To-Be]
			Figure 3
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate		[1] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997,		Requirement Levels", BCP 14, RFC 2119, March 1997,
	<http://xml.resource.org/public/rfc/html/rfc2119.html>.		<http://xml.resource.org/public/rfc/html/rfc2119.html>.
	[2] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,		[2] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
	and D. McPherson, "Dissemination of Flow Specification		and D. McPherson, "Dissemination of Flow Specification
	skipping to change at page 9, line 42 ¶		skipping to change at page 10, line 42 ¶
	"Segment Routing Architecture", December 2015.		"Segment Routing Architecture", December 2015.
	[7] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S.,		[7] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S.,
	Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J.,		Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J.,
	Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti,		Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti,
	"PCEP Extensions for Segment Routing", December 2015.		"PCEP Extensions for Segment Routing", December 2015.
	Authors' Addresses		Authors' Addresses
	Gunter Van de Velde (editor)		Gunter Van de Velde (editor)
	Alcatel-Lucent		Nokia
	Antwerp		Antwerp
	BE		BE
	Email: gunter.van_de_velde@alcatel-lucent.com		Email: gunter.van_de_velde@nokia.com
	Wim Henderickx		Wim Henderickx
	Alcatel-Lucent		Nokia
	Antwerp		Antwerp
	BE		BE
	Email: wim.henderickx@alcatel-lucent.com		Email: wim.henderickx@nokia.com
	Keyur Patel		Keyur Patel
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: keyupate@cisco.com		Email: keyupate@cisco.com
	Arjun Sreekantiah		Arjun Sreekantiah
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: asreekan@cisco.com		Email: asreekan@cisco.com
			Zhenbin Li
			Huawei Technologies
			Huawei Bld., No. 156 Beiquing Rd
			Beijing 100095
			China
			Email: lizhenbin@huawei.com
			Shunwan Zhuang
			Huawei Technologies
			Huawei Bld., No. 156 Beiquing Rd
			Beijing 100095
			China
			Email: zhuangshunwan@huawei.com
			Nan Wu
			Huawei Technologies
			Huawei Bld., No. 156 Beiquing Rd
			Beijing 100095
			China
			Email: eric.wu@huawei.com
End of changes. 58 change blocks.
	239 lines changed or deleted		275 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/