draft-ietf-idr-rfc5575bis-16.txt		draft-ietf-idr-rfc5575bis-17.txt
	IDR Working Group C. Loibl		IDR Working Group C. Loibl
	Internet-Draft Next Layer Communications		Internet-Draft Next Layer Communications
	Obsoletes: 5575,7674 (if approved) S. Hares		Obsoletes: 5575,7674 (if approved) S. Hares
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: December 2, 2019 R. Raszuk		Expires: December 20, 2019 R. Raszuk
	Bloomberg LP		Bloomberg LP
	D. McPherson		D. McPherson
	Verisign		Verisign
	M. Bacher		M. Bacher
	T-Mobile Austria		T-Mobile Austria
	May 31, 2019		June 18, 2019
	Dissemination of Flow Specification Rules		Dissemination of Flow Specification Rules
	draft-ietf-idr-rfc5575bis-16		draft-ietf-idr-rfc5575bis-17
	Abstract		Abstract
	This document defines a Border Gateway Protocol Network Layer		This document defines a Border Gateway Protocol Network Layer
	Reachability Information (BGP NLRI) encoding format that can be used		Reachability Information (BGP NLRI) encoding format that can be used
	to distribute traffic Flow Specifications. This allows the routing		to distribute traffic Flow Specifications. This allows the routing
	system to propagate information regarding more specific components of		system to propagate information regarding more specific components of
	the traffic aggregate defined by an IP destination prefix.		the traffic aggregate defined by an IP destination prefix.
	It specifies IPv4 traffic Flow Specifications via a BGP NLRI which		It specifies IPv4 traffic Flow Specifications via a BGP NLRI which
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 December 2, 2019.		This Internet-Draft will expire on December 20, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 17, line 28 ¶		skipping to change at page 17, line 28 ¶
	The first step of the BGP Route Selection procedure (Section 9.1.2 of		The first step of the BGP Route Selection procedure (Section 9.1.2 of
	[RFC4271] is to exclude from the selection procedure routes that are		[RFC4271] is to exclude from the selection procedure routes that are
	considered non-feasible. In the context of IP routing information,		considered non-feasible. In the context of IP routing information,
	this step is used to validate that the NEXT_HOP attribute of a given		this step is used to validate that the NEXT_HOP attribute of a given
	route is resolvable.		route is resolvable.
	The concept can be extended, in the case of Flow Specification NLRI,		The concept can be extended, in the case of Flow Specification NLRI,
	to allow other validation procedures.		to allow other validation procedures.
	A Flow Specification NLRI must be validated such that it is		A Flow Specification NLRI must be validated such that it is
	considered feasible if and only if:		considered feasible if and only if all of the below is true:
	a) The originator of the Flow Specification matches the originator		a) A destination prefix component is embedded in the Flow
			Specification.
			b) The originator of the Flow Specification matches the originator
	of the best-match unicast route for the destination prefix		of the best-match unicast route for the destination prefix
	embedded in the Flow Specification.		embedded in the Flow Specification.
	b) There are no more specific unicast routes, when compared with		c) There are no more specific unicast routes, when compared with
	the flow destination prefix, that has been received from a		the flow destination prefix, that has been received from a
	different neighboring AS than the best-match unicast route, which		different neighboring AS than the best-match unicast route, which
	has been determined in step a).		has been determined in rule b).
			Rule a) MAY be relaxed by configuration, permitting Flow
			Specifications that include no destination prefix component. If such
			is the case, rules b) and c) are moot and MUST be disregarded.
	By originator of a BGP route, we mean either the BGP originator path		By originator of a BGP route, we mean either the BGP originator path
	attribute, as used by route reflection, or the transport address of		attribute, as used by route reflection, or the transport address of
	the BGP peer, if this path attribute is not present.		the BGP peer, if this path attribute is not present.
	BGP implementations MUST also enforce that the AS_PATH attribute of a		BGP implementations MUST also enforce that the AS_PATH attribute of a
	route received via the External Border Gateway Protocol (eBGP)		route received via the External Border Gateway Protocol (eBGP)
	contains the neighboring AS in the left-most position of the AS_PATH		contains the neighboring AS in the left-most position of the AS_PATH
	attribute. While this rule is optional in the BGP specification, it		attribute. While this rule is optional in the BGP specification, it
	becomes necessary to enforce it for security reasons.		becomes necessary to enforce it for security reasons.
End of changes. 8 change blocks.
	8 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/