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

Alexander Azimov <> Tue, 16 June 2020 20:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E03483A08AC for <>; Tue, 16 Jun 2020 13:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E98AT1hGjpZm for <>; Tue, 16 Jun 2020 13:00:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 97A5F3A08AA for <>; Tue, 16 Jun 2020 13:00:00 -0700 (PDT)
Received: by with SMTP id 25so20363718oiy.13 for <>; Tue, 16 Jun 2020 13:00:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4/KOe5ph7F1pF5DOn5ev73ObnstvybUujoDg1paWTFo=; b=JkR01iNcX6C+AbfdfYsyUhqEJ1Wg8LT07dXX6EhzSbVQz6jBFMw7QnohRydqtLBKkM ljaeC7HTpa5VcZYzfSeQd0Jl5Ydslt9irjob+IkfvDySGnCV6hSWsZN++68nm/Hofoey nTDqD3VWE0VEDueyNw9S5UAxvl1t/TMeGZMFmB6EVj4gc3jIPI9uGDYmWO6bjTqh9B7a S+ZbqLErSVDSxEgG3iPtoh9VQl/C6peiv0QZcYBdnCqpYHUDLLXlMGTFjSa2CTOG25Lt ieSKVo68B7HItzMPmdoBh4vssB74B9+SUWXbOhftVYqBKs+xSI4obDX+evQRcSgGOZdT XcbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4/KOe5ph7F1pF5DOn5ev73ObnstvybUujoDg1paWTFo=; b=Rc8JZmMzDQ6LMN7+z44c0aR1ndI8Lw4moKhK1rBt8JVNUotcIQA9/c1ASJy7bGvCz9 Hfrgh5FTQXwb9X2c/eq+H8A367ulNNwJahcaxBU6DXG74dtzTORMCCIoN4lnrYJ0EsY3 eLn+Wzrc8ogCBzfhChKbzxeu7NEcc0vYv4taVQFqF2b77y7KfEdFqIBSS9xG30gnxu76 pMMdZQfQmEk1UQIKsCWc+QlSncGmC/E7hRTQ6JJgI6wdPWilRCc4q4CMZ1tnjFDD5msU F7++mJhA3G+bnfZjg3bO0VI5O63MR/U9aFHxo+Kc5cf/2YWGyOUT1ohZhA6yi9k9zZBm n6vA==
X-Gm-Message-State: AOAM530A6Zh3cDDB4wJXAlnFHqWxdmLJBaVpHbE7tsD0cppRuT8sEW1J e6LdnWUZaCPMJVHD/1t5ftEzcyquRcUdIhxM7DQ=
X-Google-Smtp-Source: ABdhPJxS8+Ws0d1/SADRxzksjwm9kdWmEEV3ZbPUUjMjvQ+IE9kEUJD2fNNXX2gOQl26RKSf1Nx33+NWM3NMYu5diog=
X-Received: by 2002:aca:d884:: with SMTP id p126mr4976444oig.4.1592337599711; Tue, 16 Jun 2020 12:59:59 -0700 (PDT)
MIME-Version: 1.0
References: <005901d63ab5$d6003e00$8200ba00$> <> <>
In-Reply-To: <>
From: Alexander Azimov <>
Date: Tue, 16 Jun 2020 22:59:48 +0300
Message-ID: <>
To: Gyan Mishra <>
Cc: Pavel Lunin <>, "idr@ietf. org" <>, Susan Hares <>
Content-Type: multipart/alternative; boundary="000000000000fe4da205a838fcad"
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, 16 Jun 2020 20:00:03 -0000

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
> Gyan
> 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,
>> Pavel
>> 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.
>> Cheers,
>> _______________________________________________
>> Idr mailing list
> --
> <>
> *Gyan Mishra*
> *Network Solutions A**rchitect *
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
> _______________________________________________
> Idr mailing list

Best regards,
Alexander Azimov