< draft-litkowski-idr-flowspec-interfaceset-02.txt		draft-litkowski-idr-flowspec-interfaceset-03.txt >
	Routing Area Working Group S. Litkowski		Routing Area Working Group S. Litkowski
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track A. Simpson		Intended status: Standards Track A. Simpson
	Expires: September 6, 2015 Alcatel Lucent		Expires: June 10, 2016 Alcatel Lucent
	K. Patel		K. Patel
	Cisco		Cisco
	J. Haas		J. Haas
	Juniper Networks		Juniper Networks
	March 5, 2015		December 8, 2015
	Applying BGP flowspec rules on a specific interface set		Applying BGP flowspec rules on a specific interface set
	draft-litkowski-idr-flowspec-interfaceset-02		draft-litkowski-idr-flowspec-interfaceset-03
	Abstract		Abstract
	BGP Flow-spec is an extension to BGP that allows for the		BGP Flow-spec is an extension to BGP that allows for the
	dissemination of traffic flow specification rules. The primary		dissemination of traffic flow specification rules. The primary
	application of this extension is DDoS mitigation where the flowspec		application of this extension is DDoS mitigation where the flowspec
	rules are applied in most cases to all peering routers of the		rules are applied in most cases to all peering routers of the
	network.		network.
	This document will present another use case of BGP Flow-spec where		This document will present another use case of BGP Flow-spec where
	skipping to change at page 2, line 20 ¶		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 6, 2015.		This Internet-Draft will expire on June 10, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 44 ¶		skipping to change at page 2, line 44 ¶
	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. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Specific filtering for DDoS . . . . . . . . . . . . . . . 3		1.1. Specific filtering for DDoS . . . . . . . . . . . . . . . 3
	1.2. ACL maintenance . . . . . . . . . . . . . . . . . . . . . 4		1.2. ACL maintenance . . . . . . . . . . . . . . . . . . . . . 4
	2. Collaborative filtering and managing filter direction . . . . 5		2. Collaborative filtering and managing filter direction . . . . 5
	3. Interface specific filtering using BGP flowspec . . . . . . . 6		3. Interface specific filtering using BGP flowspec . . . . . . . 6
	4. Interface-set extended community . . . . . . . . . . . . . . 6		4. Interface-set extended community . . . . . . . . . . . . . . 7
	5. Interaction with permanent traffic actions . . . . . . . . . 7		5. Interaction with permanent traffic actions . . . . . . . . . 8
	5.1. Interaction with interface ACLs . . . . . . . . . . . . . 8		5.1. Interaction with interface ACLs . . . . . . . . . . . . . 9
	5.2. Interaction with flow collection . . . . . . . . . . . . 9		5.2. Interaction with flow collection . . . . . . . . . . . . 10
	6. Scaling of per interface rules . . . . . . . . . . . . . . . 10		6. Scaling of per interface rules . . . . . . . . . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Deployment considerations . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	10. Normative References . . . . . . . . . . . . . . . . . . . . 11		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
			11.1. Normative References . . . . . . . . . . . . . . . . . . 12
			11.2. Informative References . . . . . . . . . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Use case		1. Use case
	1.1. Specific filtering for DDoS		1.1. Specific filtering for DDoS
	----------------- --- (ebgp) - Peer3 (BW 10G)		----------------- --- (ebgp) - Peer3 (BW 10G)
	/ \/		/ \/
	| /|		| /|
	| PE --- (ebgp) - Transit1(BW 4x10G)		| PE --- (ebgp) - Transit1(BW 4x10G)
	Cust1 --- (ebgp) --- PE |		Cust1 --- (ebgp) --- PE |
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 30 ¶
	Cust2 --- (ebgp) --- PE |----- (ebgp) - Customer3		Cust2 --- (ebgp) --- PE |----- (ebgp) - Customer3
	/| |		/| |
	Peer1(BW10G)-(ebgp) | PE --- (ebgp) - Transit2(BW 4x10G)		Peer1(BW10G)-(ebgp) | PE --- (ebgp) - Transit2(BW 4x10G)
	| |		| |
	\ /		\ /
	------------------		------------------
	Figure 1		Figure 1
	The figure 1 above displays a typical service provider Internet		The figure 1 above displays a typical service provider Internet
	network owing Customers, Peers and Transit. To protect proactively		network owing Customers, Peers and Transit. To protect pro actively
	against some attacks (e.g. DNS, NTP ...), the service provider may		against some attacks (e.g. DNS, NTP ...), the service provider may
	want to deploy some rate-limiting of some flows on peers and transit		want to deploy some rate-limiting of some flows on peers and transit
	links. But depending on link bandwidth, the provider may want to		links. But depending on link bandwidth, the provider may want to
	apply different rate-limiting values.		apply different rate-limiting values.
	For 4*10G links peer/transit, it may want to apply a rate-limiting of		For 4*10G links peer/transit, it may want to apply a rate-limiting of
	DNS flows of 1G, while on 10G links, the rate-limiting would be set		DNS flows of 1G, while on 10G links, the rate-limiting would be set
	to 250Mbps. Customer interfaces must not be rate-limited.		to 250Mbps. Customer interfaces must not be rate-limited.
	BGP Flow-spec infrastructure may already be present on the network,		BGP Flow-spec infrastructure may already be present on the network,
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 29 ¶
	Peer1 ------ (ebgp) -- | PE ------ (ebgp) - Transit2		Peer1 ------ (ebgp) -- | PE ------ (ebgp) - Transit2
	| |		| |
	\ /		\ /
	----------------		----------------
	Figure 2		Figure 2
	The figure 1 above displays a typical service provider multiservice		The figure 1 above displays a typical service provider multiservice
	network owing Customers, Peers and Transit for Internet, as well as		network owing Customers, Peers and Transit for Internet, as well as
	VPN services. The service provider requires to ensure security of		VPN services. The service provider requires to ensure security of
	its infrastructure by applying ACLs at network boundary. Maintaing		its infrastructure by applying ACLs at network boundary. Maintaining
	and deploying ACLs on hundreds/thousands of routers is really painful		and deploying ACLs on hundreds/thousands of routers is really painful
	and time consuming and a service provider would be interrested to		and time consuming and a service provider would be interested to
	deploy/updates ACLs using BGP Flowspec. In this scenario, depending		deploy/updates ACLs using BGP Flowspec. In this scenario, depending
	on the interface type (Internet customer, VPN customer, Peer, Transit		on the interface type (Internet customer, VPN customer, Peer, Transit
	...) the content of the ACL may be different.		...) the content of the ACL may be different.
	We can imagine two cases :		We foresee two main cases :
	o Maintaining complete ACLs using flowspec : in this case all the		o Maintaining complete ACLs using flowspec : in this case all the
	ingress ACL are maintained and deployed using BGPFlowspec. See		ingress ACL are maintained and deployed using BGPFlowspec. See
	section Section 7 for more details on security aspects.		section Section 8 for more details on security aspects.
	o Requirement of a quick deployment of a new filtering term due to a		o Requirement of a quick deployment of a new filtering term due to a
	security alert : new security alerts often requires a fast		security alert : new security alerts often requires a fast
	deployment of new ACL terms. Using traditional CLI and hop by hop		deployment of new ACL terms. Using traditional CLI and hop by hop
	provisionning, such deployment takes time and network is		provisioning, such deployment takes time and network is
	unprotected during this time window. Using BGP flowspec to deploy		unprotected during this time window. Using BGP flowspec to deploy
	such rule, a service provider can protect its network in few		such rule, a service provider can protect its network in few
	seconds. Then the SP can decide to keep the rule permanentely in		seconds. Then the SP can decide to keep the rule permanently in
	BGP Flowspec or update its ACL or remove the entry (in case		BGP Flowspec or update its ACL or remove the entry (in case
	equipments are not vulnerable anymore).		equipments are not vulnerable anymore).
	Section Section 3 will detail a solution to address this use case		Section Section 3 will detail a solution to address this use case
	using BGP Flowspec.		using BGP Flowspec.
	2. Collaborative filtering and managing filter direction		2. Collaborative filtering and managing filter direction
	[RFC5575] states in Section 5. : "This mechanism is primarily		[RFC5575] states in Section 5. : "This mechanism is primarily
	designed to allow an upstream autonomous system to perform inbound		designed to allow an upstream autonomous system to perform inbound
	filtering in their ingress routers of traffic that a given downstream		filtering in their ingress routers of traffic that a given downstream
	AS wishes to drop.".		AS wishes to drop.".
	In case of networks collaborating in filtering, there is a use case		In case of networks collaborating in filtering, there is a use case
	for performing outbound filtering. Outbound filtering permits to		for performing outbound filtering. Outbound filtering allows to
	apply traffic action one step before and so may permit to prevent		apply traffic action one step before and so may allow to prevent
	impact like congestions.		impact like congestions.
	----------------------		----------------------
	/ \		/ \
	| Upstream provider |		| Upstream provider |
	\ /		\ /
	-----------------------		-----------------------
	| |		| |
	|P2 |P1		|P2 |P1
	----------------------		----------------------
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 41 ¶
	-----------------------		-----------------------
	Figure 3		Figure 3
	In the figure above, MyAS is connected to an upstream provider. If a		In the figure above, MyAS is connected to an upstream provider. If a
	malicious traffic comes in from the upstream provider, it may		malicious traffic comes in from the upstream provider, it may
	congestion P1 or P2 links. If MyAS apply inbound filtering on P1/P2		congestion P1 or P2 links. If MyAS apply inbound filtering on P1/P2
	using BGP Flowspec, the congestion issue will not be solved.		using BGP Flowspec, the congestion issue will not be solved.
	Using collaborative filtering, the upstream provider may propose to		Using collaborative filtering, the upstream provider may propose to
	MyAS to filter malicious traffic destinated to MyAS. We propose to		MyAS to filter malicious traffic sent to it. We propose to enhance
	enhance [RFC5575] to make myAS able to send BGP FlowSpec updates (on		[RFC5575] to make myAS able to send BGP FlowSpec updates (on eBGP
	eBGP sessions) to the upstream provider to request outbound filtering		sessions) to the upstream provider to request outbound filtering on
	on peering interfaces towards MyAS. When the upstream provider will		peering interfaces towards MyAS. When the upstream provider will
	receive the BGP Flowspec update from MyAS, the BGP flowspec update		receive the BGP Flowspec update from MyAS, the BGP flowspec update
	will contain request for outbound filtering on a specific set of		will contain request for outbound filtering on a specific set of
	interfaces. The upstream provider will apply automatically the		interfaces. The upstream provider will apply automatically the
	requested filter and congestion will be prevented.		requested filter and congestion will be prevented.
	3. Interface specific filtering using BGP flowspec		3. Interface specific filtering using BGP flowspec
	The use case detailled above requires application of different BGP		The use case detailed above requires application of different BGP
	Flowspec rules on different set of interfaces. The basic		Flowspec rules on different set of interfaces. The basic
	specification detailled in [RFC5575] does not address this and does		specification detailed in [RFC5575] does not address this and does
	not give any detail on where the FlowSpec filter need to be applied.		not give any detail on where the FlowSpec filter need to be applied.
	We propose to introduce an identification of interfaces within BGP		We propose to introduce, within BGP Flowspec, an identification of
	Flowspec. All interfaces may be associated to one or more group-		interfaces where a particular filter should apply on. Identification
	identifiers and a BGP Flowspec rule may also be associated with one		of interfaces within BGP Flowspec will be done through group
	or more group-identifiers including a filtering direction		identifiers. A group identifier marks a set of interfaces sharing a
	(input/output/both) , so the FlowSpec rule will be applied only on		common administrative property. Like a BGP community, the group
	interfaces belonging the the group identifier included in the BGP		identifier itself does not have any significance. It is up to the
	FlowSpec update.		network administrator to associate a particular meaning to a group
			identifier value (e.g. group ID#1 associated to Internet customer
			interfaces). The group identifier is a local interface property.
			Any interface may be associated with one or more group identifiers
			using manual configuration.
			When a filtering rule advertised through BGP Flowspec must be applied
			only to particular sets of interfaces, the BGP Flowspec BGP update
			will contain the identifiers associated with the relevant sets of
			interfaces. In addition to the group identifiers, it will also
			contain the direction the filtering rule must be applied in (see
			Section 4).
			Configuration of group identifiers associated to interfaces may
			change over time. An implementation MUST ensure that the filtering
			rules (learned from BGP Flowspec) applied to a particular interface
			are always updated when the group identifier mapping is changing.
	Considering figure 2, we can imagine the following design :		Considering figure 2, we can imagine the following design :
	o Internet customer interfaces are associated with group-identifier		o Internet customer interfaces are associated with group-identifier
	1.		1.
	o VPN customer interfaces are associated with group-identifier 2.		o VPN customer interfaces are associated with group-identifier 2.
	o All customer interfaces are associated with group-identifier 3.		o All customer interfaces are associated with group-identifier 3.
	skipping to change at page 6, line 43 ¶		skipping to change at page 7, line 10 ¶
	o All external provider interfaces are associated with group-		o All external provider interfaces are associated with group-
	identifier 6.		identifier 6.
	o All interfaces are associated with group-identifier 7.		o All interfaces are associated with group-identifier 7.
	If the service provider wants to deploy a specific inbound filtering		If the service provider wants to deploy a specific inbound filtering
	on external provider interfaces only, the provider can send the BGP		on external provider interfaces only, the provider can send the BGP
	flow specification using group-identifier 6 and including inbound		flow specification using group-identifier 6 and including inbound
	direction.		direction.
			There are some cases where nodes are dedicated to specific functions
			(Internet peering, Internet Edge, VPN Edge, Service Edge ...), in
			this kind of scenario, there is an interest for a constrained
			distribution of filtering rules that are using the interface specific
			filtering. Without the constrained route distribution, all nodes
			will received all the filters even if they are not interested in
			those filters. Constrained route distribution of flowspec filters
			would allow for a more optimized distribution.
	4. Interface-set extended community		4. Interface-set extended community
	This document proposes a new BGP extended community called "flow spec		This document proposes a new BGP Route Target extended community
	interface-set". This new BGP extended community is part of		called "flowspec interface-set". This document so expands the
	TRANSITIVE FOUR-OCTET AS-SPECIFIC EXTENDED COMMUNITY and has subtype		definition of the Route Target extended community to allow a new
	TBD.		value of high order octet (Type field) to be TBD (in addition to the
			values specified in [RFC4360]).
	The Global Administrator field of this community MUST be set to the		In order to ease intra-AS and inter-AS use cases, this document
	ASN of the originating router. The Local Administrator field is		proposes to have a transitive as well as a non transitive version of
	encoded as follows :		this extended community.
	0 1 2 3 4 5 6 7		This new BGP Route Target extended community is encoded as follows :
	+---+---+---+---+---+---+---+---+
	| O | I | Group Identifier :		0 1 2 3
	+---+---+---+---+---+---+---+---+		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
	: Group Identifier (cont.) |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+---+---+---+---+---+---+---+---+		| Type (TBD) | 0x02 | Autonomous System Number :
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			: AS Number (cont.) |O|I| Group Identifier |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The flags are :		The flags are :
	o O : if set, the flow specification rule MUST be applied in		o O : if set, the flow specification rule MUST be applied in
	outbound direction to the interface set referenced by the		outbound direction to the interface set referenced by the
	following group-identifier.		following group-identifier.
	o I : if set, the flow specification rule MUST be applied in input		o I : if set, the flow specification rule MUST be applied in input
	direction to the interface set referenced by the following group-		direction to the interface set referenced by the following group-
	identifier.		identifier.
	skipping to change at page 7, line 41 ¶		skipping to change at page 8, line 24 ¶
	Multiple instances of the interface-set community may be present in a		Multiple instances of the interface-set community may be present in a
	BGP update. This may appear if the flow rule need to be applied to		BGP update. This may appear if the flow rule need to be applied to
	multiple set of interfaces.		multiple set of interfaces.
	Multiple instances of the community in a BGP update MUST be		Multiple instances of the community in a BGP update MUST be
	interpreted as a "OR" operation : if a BGP update contains two		interpreted as a "OR" operation : if a BGP update contains two
	interface-set communities with group ID 1 and group ID 2, the filter		interface-set communities with group ID 1 and group ID 2, the filter
	would need to be installed on interfaces belonging to Group ID 1 or		would need to be installed on interfaces belonging to Group ID 1 or
	Group ID 2.		Group ID 2.
			As using a Route Target, route distribution of flowspec NLRI with
			interface-set may be subject to constrained distribution as defined
			in [RFC4684]. Constrained route distribution for flowspec routes
			using interface-set requires discussion and will be addressed in a
			future revision of the document.
	5. Interaction with permanent traffic actions		5. Interaction with permanent traffic actions
	[RFC5575] states that BGP Flowspec is primarily designed to allow		[RFC5575] states that BGP Flowspec is primarily designed to allow
	upstream AS to perform inbound filtering in their ingress routers.		upstream AS to perform inbound filtering in their ingress routers.
	This specification does not precise where this ingress filtering		This specification does not precise where this ingress filtering
	should happen in the packet processing pipe.		should happen in the packet processing pipe.
	This proposal enhances [RFC5575] in order to add action on traffic		This proposal enhances [RFC5575] in order to add action on traffic
	coming from or going to specific interfaces. Based on this		coming from or going to specific interfaces. Based on this
	enhancement, some new requirements come to implementations.		enhancement, some new requirements come to implementations.
	skipping to change at page 8, line 22 ¶		skipping to change at page 9, line 13 ¶
	will BGP flowspec actions.		will BGP flowspec actions.
	5.1. Interaction with interface ACLs		5.1. Interaction with interface ACLs
	Deploying interface specific filters using BGP FlowSpec (dynamic		Deploying interface specific filters using BGP FlowSpec (dynamic
	entries) may interfere with existing permanent interface ACL (static		entries) may interfere with existing permanent interface ACL (static
	entries). The content of the existing permanent ACL MUST NOT be		entries). The content of the existing permanent ACL MUST NOT be
	altered by dynamic entries coming from BGP FlowSpec. Permanent ACLs		altered by dynamic entries coming from BGP FlowSpec. Permanent ACLs
	are using a specific ordering which is not compatible with the		are using a specific ordering which is not compatible with the
	ordering of FS rules and misordering of ACL may lead to undesirable		ordering of FS rules and misordering of ACL may lead to undesirable
	behavior. In order, to keep a deterministic and well known		behaviour. In order, to keep a deterministic and well known
	behaviour, an implementation SHOULD process the BGP FlowSpec ACL as		behaviour, an implementation SHOULD process the BGP FlowSpec ACL as
	follows :		follows :
	o In inbound direction, the permanent ACL action is applied first		o In inbound direction, the permanent ACL action is applied first
	followed by FlowSpec action. This gives the primary action to the		followed by FlowSpec action. This gives the primary action to the
	permanent ACL as it is done today.		permanent ACL as it is done today.
	o In outbound direction, FlowSpec action action is applied first		o In outbound direction, FlowSpec action action is applied first
	followed by permanent ACL. This gives the final action to the		followed by permanent ACL. This gives the final action to the
	permanent ACL as it is done today.		permanent ACL as it is done today.
	skipping to change at page 10, line 15 ¶		skipping to change at page 11, line 7 ¶
	6. Scaling of per interface rules		6. Scaling of per interface rules
	Creating rules that are applied on specific interfaces may create		Creating rules that are applied on specific interfaces may create
	forwarding rules that may be harder to share.		forwarding rules that may be harder to share.
	An implementation SHOULD take care about trying to keep sharing		An implementation SHOULD take care about trying to keep sharing
	forwarding structures as much as possible in order to limit the		forwarding structures as much as possible in order to limit the
	scaling impact. How the implementation would do so is out of scope		scaling impact. How the implementation would do so is out of scope
	of the document.		of the document.
	7. Security Considerations		7. Deployment considerations
			There are some cases where a particular BGP Flowspec NLRI may be
			advertised to different interface groups with a different action.
			For example, a service provider may want to discard all ICMP traffic
			from customer interfaces to infrastructure addresses and want to
			rate-limit the same traffic when it comes from some internal
			platforms. These particular cases require ADD-PATH to be deployed in
			order to ensure that all paths (NLRI+interface group+actions) are
			propagated within the BGP control plane. Without ADD-PATH, only a
			single "NLRI+interface group+actions" will be propagated, so some
			filtering rules will never be applied.
			8. Security Considerations
	Managing permanent Access Control List by using BGP Flowspec as		Managing permanent Access Control List by using BGP Flowspec as
	described in Section 1.2 helps in saving roll out time of such ACL.		described in Section 1.2 helps in saving roll out time of such ACL.
	However some ACL especially at network boundary are critical for the		However some ACL especially at network boundary are critical for the
	network security and loosing the ACL configuration may lead to		network security and loosing the ACL configuration may lead to
	network open for attackers.		network open for attackers.
	By design, BGP flowspec rules are ephemeral : the flow rule exists in		By design, BGP flowspec rules are ephemeral : the flow rule exists in
	the router while the BGP session is UP and the BGP path for the rule		the router while the BGP session is UP and the BGP path for the rule
	is valid. We can imagine a scenario where a Service Provider is		is valid. We can imagine a scenario where a Service Provider is
	skipping to change at page 10, line 43 ¶		skipping to change at page 12, line 5 ¶
	ACLs should protect the BGP session from being attacked.		ACLs should protect the BGP session from being attacked.
	In order to complement the BGP flowspec solution is such deployment		In order to complement the BGP flowspec solution is such deployment
	scenario and provides security against such attack, a service		scenario and provides security against such attack, a service
	provider may activate Long lived Graceful Restart		provider may activate Long lived Graceful Restart
	[I-D.uttaro-idr-bgp-persistence] on the BGP session owning Flowspec		[I-D.uttaro-idr-bgp-persistence] on the BGP session owning Flowspec
	address family. So in case of BGP session to be down, the BGP paths		address family. So in case of BGP session to be down, the BGP paths
	of Flowspec rules would be retained and the flowspec action will be		of Flowspec rules would be retained and the flowspec action will be
	retained.		retained.
	8. Acknowledgements		9. Acknowledgements
	Authors would like to thanks Wim Hendrickx for his valuable comments.		Authors would like to thanks Wim Hendrickx for his valuable comments.
	9. IANA Considerations		10. IANA Considerations
	This document requests a new sub-type from the "TRANSITIVE FOUR-OCTET		This document requests a new type from the "BGP Transitive Extended
	AS-SPECIFIC EXTENDED COMMUNITY SUB-TYPES" extended community		Community Types" extended community registry. This type name shall
	registry. The sub-type name shall be 'Flow spec interface-set'.		be 'FlowSpec'.
	10. Normative References		This document requests a new type from the "BGP Non-Transitive
			Extended Community Types" extended community registry. This type
			name shall be 'FlowSpec'.
	[I-D.uttaro-idr-bgp-persistence]		This document requests creation of a new registry called "FlowSpec
	Uttaro, J., Chen, E., Decraene, B., and J. Scudder,		Extended Community Sub-Types". This registry contains values of the
	"Support for Long-lived BGP Graceful Restart", draft-		second octet (the "Sub-Type" field) of an extended community when the
	uttaro-idr-bgp-persistence-03 (work in progress), November		value of the first octet (the "Type" field) is to one of those
	2013.		allocated in this document.
			Within this new registry, this document requests a new subtype
			(suggested value 0x02), this sub-type shall be named "interface-set".
			11. References
			11.1. Normative References
			[I-D.ietf-idr-rtc-no-rt]
			Rosen, E., Patel, K., Haas, J., and R. Raszuk, "Route
			Target Constrained Distribution of Routes with no Route
			Targets", draft-ietf-idr-rtc-no-rt-04 (work in progress),
			November 2015.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
			[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
			Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
			February 2006, <http://www.rfc-editor.org/info/rfc4360>.
			[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
			R., Patel, K., and J. Guichard, "Constrained Route
			Distribution for Border Gateway Protocol/MultiProtocol
			Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
			Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
			November 2006, <http://www.rfc-editor.org/info/rfc4684>.
	[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,		[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
	and D. McPherson, "Dissemination of Flow Specification		and D. McPherson, "Dissemination of Flow Specification
	Rules", RFC 5575, August 2009.		Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
			<http://www.rfc-editor.org/info/rfc5575>.
			11.2. Informative References
			[I-D.uttaro-idr-bgp-persistence]
			Uttaro, J., Chen, E., Decraene, B., and J. Scudder,
			"Support for Long-lived BGP Graceful Restart", draft-
			uttaro-idr-bgp-persistence-03 (work in progress), November
			2013.
	Authors' Addresses		Authors' Addresses
	Stephane Litkowski		Stephane Litkowski
	Orange		Orange
	Email: stephane.litkowski@orange.com		Email: stephane.litkowski@orange.com
	Adam Simpson		Adam Simpson
	Alcatel Lucent		Alcatel Lucent
End of changes. 32 change blocks.
	63 lines changed or deleted		151 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/