Subject: Re: [Idr] New Version Notification for draft-ietf-idr-bgp-open-policy-21.txt

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 24 Jan 2022 22:12:27 +0000

We (authors) have incorporated changes based on consideration of comments and nits from all IESG reviews received so far. Version-21 reflects these changes.

Thank you.

Sriram / Alexander

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: Saturday, January 22, 2022 2:13 PM
To: Alexander Azimov <[email-masked]>; Eugene Bogomazov <[email-masked]>; Keyur Patel <[email-masked]>; Sriram, Kotikalapudi (Fed) <[email-masked]>; Randy Bush <[email-masked]>
Subject: New Version Notification for draft-ietf-idr-bgp-open-policy-21.txt

A new version of I-D, draft-ietf-idr-bgp-open-policy-21.txt

has been successfully submitted by Alexander Azimov and posted to the IETF repository.

Name:                draft-ietf-idr-bgp-open-policy

Revision:           21

Title:                   Route Leak Prevention and Detection using Roles in UPDATE and OPEN Messages

Document date:            2022-01-22

Group:               idr

Pages:                14

URL:            https://www.ietf.org/archive/id/draft-ietf-idr-bgp-open-policy-21.txt

Status:         https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy

Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-open-policy-21

Abstract:

   Route leaks are the propagation of BGP prefixes that violate

   assumptions of BGP topology relationships, e.g., announcing a route

   learned from one transit provider to another transit provider or a

   lateral (i.e., non-transit) peer or announcing a route learned from

   one lateral peer to another lateral peer or a transit provider.

   These are usually the result of misconfigured or absent BGP route

   filtering or lack of coordination between autonomous systems (ASes).

   Existing approaches to leak prevention rely on marking routes by

   operator configuration, with no check that the configuration

   corresponds to that of the eBGP neighbor, or enforcement that the two

   eBGP speakers agree on the peering relationship.  This document

   enhances the BGP OPEN message to establish an agreement of the

   peering relationship on each eBGP session between autonomous systems

   in order to enforce appropriate configuration on both sides.

   Propagated routes are then marked according to the agreed

   relationship, allowing both prevention and detection of route leaks.