--- 1/draft-ietf-idr-bgp-open-policy-12.txt 2020-07-07 13:13:55.860798602 -0700 +++ 2/draft-ietf-idr-bgp-open-policy-13.txt 2020-07-07 13:13:55.888799316 -0700 @@ -1,25 +1,25 @@ Network Working Group A. Azimov Internet-Draft Qrator Labs & Yandex Intended status: Standards Track E. Bogomazov -Expires: January 4, 2021 Qrator Labs +Expires: January 8, 2021 Qrator Labs R. Bush Internet Initiative Japan & Arrcus, Inc. K. Patel Arrcus K. Sriram USA NIST - July 3, 2020 + July 7, 2020 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 Route leaks are the propagation of BGP prefixes which violate assumptions of BGP topology relationships; e.g. passing a route learned from one lateral peer to another lateral peer or a transit provider, passing a route learned from one transit provider to another transit provider or a lateral peer. Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the eBGP @@ -47,21 +47,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -155,22 +155,22 @@ routes they accept. Violation of the above rules may result in route leaks and MUST not be allowed. Automatic enforcement of these rules should significantly reduce route leaks that may otherwise occur due to manual configuration mistakes. While enforcing the above rules will address most BGP peering scenarios, their configuration is not part of BGP itself; therefore, configuration of ingress and egress prefix filters is still strongly advised. 3. BGP Role - BGP Role is a new configuration option that can be configured on any - BGP session. BGP Roles reflect the agreement between two BGP + BGP Role is a new configuration option that is configured on a per- + session basis. BGP Roles reflect the agreement between two BGP speakers about their relationship. One of the Roles described below SHOULD be configured on each eBGP session between ISPs that carry IPv4 and(or) IPv6 unicast prefixes. Allowed Role values for eBGP sessions between ISPs are: o Provider - sender is a transit provider to neighbor; o Customer - sender is a transit customer of neighbor;