draft-ietf-idr-bgp-open-policy-12.txt		draft-ietf-idr-bgp-open-policy-13.txt
	Network Working Group A. Azimov		Network Working Group A. Azimov
	Internet-Draft Qrator Labs & Yandex		Internet-Draft Qrator Labs & Yandex
	Intended status: Standards Track E. Bogomazov		Intended status: Standards Track E. Bogomazov
	Expires: January 4, 2021 Qrator Labs		Expires: January 8, 2021 Qrator Labs
	R. Bush		R. Bush
	Internet Initiative Japan & Arrcus, Inc.		Internet Initiative Japan & Arrcus, Inc.
	K. Patel		K. Patel
	Arrcus		Arrcus
	K. Sriram		K. Sriram
	USA NIST		USA NIST
	July 3, 2020		July 7, 2020
	Route Leak Prevention using Roles in Update and Open messages		Route Leak Prevention using Roles in Update and Open messages
	draft-ietf-idr-bgp-open-policy-12		draft-ietf-idr-bgp-open-policy-13
	Abstract		Abstract
	Route leaks are the propagation of BGP prefixes which violate		Route leaks are the propagation of BGP prefixes which violate
	assumptions of BGP topology relationships; e.g. passing a route		assumptions of BGP topology relationships; e.g. passing a route
	learned from one lateral peer to another lateral peer or a transit		learned from one lateral peer to another lateral peer or a transit
	provider, passing a route learned from one transit provider to		provider, passing a route learned from one transit provider to
	another transit provider or a lateral peer. Existing approaches to		another transit provider or a lateral peer. Existing approaches to
	leak prevention rely on marking routes by operator configuration,		leak prevention rely on marking routes by operator configuration,
	with no check that the configuration corresponds to that of the eBGP		with no check that the configuration corresponds to that of the eBGP
	skipping to change at page 2, line 12 ¶		skipping to change at page 2, line 12 ¶
	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 January 4, 2021.		This Internet-Draft will expire on January 8, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 4, line 27 ¶		skipping to change at page 4, line 27 ¶
	routes they accept. Violation of the above rules may result in route		routes they accept. Violation of the above rules may result in route
	leaks and MUST not be allowed. Automatic enforcement of these rules		leaks and MUST not be allowed. Automatic enforcement of these rules
	should significantly reduce route leaks that may otherwise occur due		should significantly reduce route leaks that may otherwise occur due
	to manual configuration mistakes. While enforcing the above rules		to manual configuration mistakes. While enforcing the above rules
	will address most BGP peering scenarios, their configuration is not		will address most BGP peering scenarios, their configuration is not
	part of BGP itself; therefore, configuration of ingress and egress		part of BGP itself; therefore, configuration of ingress and egress
	prefix filters is still strongly advised.		prefix filters is still strongly advised.
	3. BGP Role		3. BGP Role
	BGP Role is a new configuration option that can be configured on any		BGP Role is a new configuration option that is configured on a per-
	BGP session. BGP Roles reflect the agreement between two BGP		session basis. BGP Roles reflect the agreement between two BGP
	speakers about their relationship. One of the Roles described below		speakers about their relationship. One of the Roles described below
	SHOULD be configured on each eBGP session between ISPs that carry		SHOULD be configured on each eBGP session between ISPs that carry
	IPv4 and(or) IPv6 unicast prefixes.		IPv4 and(or) IPv6 unicast prefixes.
	Allowed Role values for eBGP sessions between ISPs are:		Allowed Role values for eBGP sessions between ISPs are:
	o Provider - sender is a transit provider to neighbor;		o Provider - sender is a transit provider to neighbor;
	o Customer - sender is a transit customer of neighbor;		o Customer - sender is a transit customer of neighbor;
End of changes. 5 change blocks.
	6 lines changed or deleted		6 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/