Re: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.

Susan Hares <> Fri, 12 June 2020 13:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 868DA3A0915 for <>; Fri, 12 Jun 2020 06:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.224
X-Spam-Level: *
X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id szIIDOsH1CaQ for <>; Fri, 12 Jun 2020 06:15:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B65EF3A0905 for <>; Fri, 12 Jun 2020 06:15:37 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=;
From: "Susan Hares" <>
To: "'Pavel Lunin'" <>
Cc: "'idr@ietf. org'" <>
References: <005901d63ab5$d6003e00$8200ba00$> <>
In-Reply-To: <>
Date: Fri, 12 Jun 2020 09:15:21 -0400
Message-ID: <004501d640bb$869b1220$93d13660$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01D64099.FF897220"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQJt5doQ6e6HVnKlM9657bF+XPJm0QLFoBTsp4990+A=
X-Antivirus: AVG (VPS 200611-0, 06/11/2020), Outbound message
X-Antivirus-Status: Not-Tested
Archived-At: <>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jun 2020 13:15:40 -0000



Thank you for this feedback. I expect a new revision of the draft-ietf-idr-bgp-open-policy within a few days.  We will continue the discussion on this point until we reach a full resolution. 


As shepherd, I am waiting for -11.txt to see if this addresses your issues.      




From: Pavel Lunin [] 
Sent: Wednesday, June 10, 2020 9:02 PM
To: Susan Hares
Cc: 'idr@ietf. org'
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.


Hi Susan,


1) I support the advancement of this draft to publication. 


A little comment though. The so called "Gao-Rexford model" and more generally role-based relationships logic is mostly applicable to eBGP sessions. iBGP sessions are usually 'complex' in terms used in this document, so assigning roles to iBGP speakers seems practically unnecessary. From the implementation point of view it doesn't change a lot: ability to assign roles to iBGP speakers doesn't seem to make any harm, and having the option of not assigning the roles lets the network operators make the decision whether they want to change the today's behavior of iBGP default policies.


However from the operational point of view it's somewhat unclear if authors propose to configure roles on iBGP sessions. The general term "BGP" is used everywhere throughout the document (with an exception of only one occurrence), so it might seem that the document recommends to set the roles on all iBGP sessions as well as eBGP. Here it might look evident that the general context is inter-domain routing, so the document covers eBGP. However the potential audience of this document is very broad, including people not very experienced in BGP operational practices (this is were route leaks often come from) so I would suggest to make this point more explicit. Probably some occurrences of the word 'BGP' should be replaced by 'eBGP' or just a little sentence/paragraph is needed to make this point clearer.


> By default, strict mode SHOULD be set to false for backward compatibility with BGP speakers that do not yet support this mechanism.

Same here. "Backward compatibility" suggests that in future all or almost all BGP sessions should be configured with roles while it's not totally correct: iBGP speakers won't probably ever need roles and role-based policies.


This being said, this nuance only affects operational practice recommendations. Protocol behavior specification, as defined by the document, looks good: both eBGP and iBGP can be configured with roles if needed.


2) Deployments of this extension will be valuable for almost all use cases where eBGP is used to exchange public Internet routes.



Kind regards,




Please comment on the following questions:

1) Is this specification ready for publication?

2) Are there deployments where this BGP protocol extension is valuable?

3) Do you believe the error code handling is ready for publication?


The shepherd for this draft is Susan Hares. 

During the WG LC, the shepherd’s report will be sent.