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

Susan Hares <> Tue, 30 June 2020 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 074693A0936 for <>; Tue, 30 Jun 2020 07:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_DOS_OUTLOOK_TO_MX_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EMuy7MS3cSr4 for <>; Tue, 30 Jun 2020 07:10:50 -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 544F23A0920 for <>; Tue, 30 Jun 2020 07:10:49 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=;
From: "Susan Hares" <>
To: "'Pavel Lunin'" <>, "'Alexander Azimov'" <>
Cc: "'Gyan Mishra'" <>, "'idr@ietf. org'" <>
References: <005901d63ab5$d6003e00$8200ba00$> <> <> <> <>
In-Reply-To: <>
Date: Tue, 30 Jun 2020 10:10:31 -0400
Message-ID: <01a701d64ee8$379020e0$a6b062a0$>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_01A8_01D64EC6.B0833BD0"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQJt5doQ6e6HVnKlM9657bF+XPJm0QLFoBTsAjKBHbcBPQQLGAKWfeWdp3unXGA=
X-Antivirus: AVG (VPS 200630-2, 06/30/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: Tue, 30 Jun 2020 14:10:53 -0000



Thank you for this email regarding the resolution of your concern with version 11.   




From: Pavel Lunin [] 
Sent: Tuesday, June 16, 2020 7:18 PM
To: Alexander Azimov
Cc: Gyan Mishra; idr@ietf. org; Susan Hares
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.


Hi Susan and all,


I have read the new version (-11) and discussed it with Alexander off list. The document is now more explicit about non eBGP and non Internet-routing use cases both in terms of how the roles and OTC should be implemented and how they should be configured.


So all types of BGP sessions can potentially be configured with roles but the document explicitly states that it makes no assumption regarding any use cases other than plain vanilla inet/inet6 unicast eBGP between network operators.


It looks clear to me.


I also asked Alexander about the following case:


- Operator A announces to operator B an eBGP route with the OTC attribute set (operator B is a customer of operator A)

- The route is than propagated through the operator's B network via iBGP

- At some distinct point, operator B, in it's turn, announces the route to its customer C via eBGP.


Alexander explained that this is covered by the following phrase:


>Once the OTC attribute has been set, it MUST be preserved unchanged


So no matter how the route is propagated within the operator's B network (vanilla iBGP, inet-vpn, evpn type5 or whatever else) the original OTC value must be preserved just like it happens for AS-PATH. It also sound legitimate for me.


So I fully support publication of this document.







‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Tuesday, June 16, 2020 9:59 PM, Alexander Azimov <> wrote:


Dear colleagues,


In the last days, I have accumulated comments that were received both on-list and off-list. I'd like to thank all who contributed to the improved quality of the document. Accompanied by minor changes there are two important edits that I'd like to highlight:

*	We clearly specified the scope of the Roles configuration: 'BGP Roles SHOULD be configured on each eBGP session between ISPs that carry IPv4 and(or) IPv6 unicast prefixes'. In section 8 there is also an explicit statement that the applicability of Roles for other address families is out of scope of this document.
*	The registry for Roles now has three parts: Expert Review (0-127), First Come First Served (128-251), and Experimental Use (252-255). The statement is added that guarantees that newly defined roles will not pair with Roles defined in the draft.

Since these changes don't affect the OTC/Role mechanics no changes and needed in the implementations.

The new version of the draft is available:



пт, 12 июн. 2020 г. в 20:47, Gyan Mishra <>om>:

Hi Susan


I agree with Pavel’s important point in the draft in that this feature would be for “inter domain” which from internet perspective would be ASBRs ties interconnection between providers thus “eBGP” only and could be over AFI/SAFI 1/1 2/1 1/128 2/128.  


I mention the SAFI 128 as the internet has mix of carriers having internet table carried in 3 scenarios — global table IP backbone, global table over mpls, IP VPN.  In the IP VPN case their are providers that segregate global table to be clean of customer routes with only connected interfaces IGP for P,PE,RR reachability and Internet table carried in a dedicated internet VRF.  In those cases inter-as carriers may do mpls inter-as option or if IP only an IP based bgp policy.  Their maybe some cases but less often where MPLS is used over internet and public internet and private is carried over the same MPLS transport.


Those permutations of the operators network inter-as types maybe important to mention as may impact the use of role feature.


The main use case is for internet providers but could be used for large enterprises as well. 


Once vendors implement the feature any operator can use for any use case so which is why it’s critical to keep disabled by Default.


That being said we would not want the role priority feature to be Default enabled since you cannot distinguish eBGP or iBGP from a MP reach capability standpoint it really has to be disabled by Default.  This would allow in a controlled fashion by operators to enable on their “inter-as” ASBR-ASBR boundary ties only.


Kind Regards 




On Wed, Jun 10, 2020 at 9:02 PM Pavel Lunin <> wrote:

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.







Idr mailing list


 <> Image removed by sender.

Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD



Idr mailing list




Best regards,

Alexander Azimov