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

Gyan Mishra <> Fri, 12 June 2020 17:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 315BC3A1214 for <>; Fri, 12 Jun 2020 10:46:51 -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 w8G4RpJlFS0Q for <>; Fri, 12 Jun 2020 10:46:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0AFED3A1209 for <>; Fri, 12 Jun 2020 10:46:49 -0700 (PDT)
Received: by with SMTP id m81so11149320ioa.1 for <>; Fri, 12 Jun 2020 10:46:48 -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=kFzwimaSicA/oYiTsS2Y9FuX/wdpBU2l/nQWJWZxqt0=; b=tlXXFGD3/u3iJPu/udT+VT44u1LnAENubQYPCfJ1yVwzlrq7jp9IRB9q5C7bX0xIPe S5StxfKlQvqZzLXF5aXzdQ1Q6aSmzVR063hHKxhVeXqyT3qtrsT5pugk2t7Pn4COG0mR n701rO/AftQmhSGA22l0PYKMKAEtygEY+L0lpGIUPIv9uilup/6t4BxI9fdLYJFLJCVH V1rGD9WfgEOPyM8u1OsUgb3ypXxyDTSts8uyjgk/d3E548LUbqCJxJZ9U56otr2Jr8Ww fVrUPobprTpoeQjK26wMTcSU8xEYy0qIpcRq1EcpDXurxiZKYB4LmA5T3ivFikMQy2EH vtkQ==
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=kFzwimaSicA/oYiTsS2Y9FuX/wdpBU2l/nQWJWZxqt0=; b=qmypQ7OaoEq6Dw/sSWnV5VNbUwXXlhyW685yxaKdEP+UWSUZOWpF87d4tiQ/2d6auh yV2CaEet4+dMa4RMjFO41Cc4mWzlxJ5oMvKwV+hUJGBC4pCA+BZGeUvqvYRr7yYv9jO8 UA0Gy8HpaPrylECSKjAKW/CI1D8HlwOLQmoG05Z9XhYbC4g+hdJgMl/jIKXMaHVTyCNb 3vmqw/OR692hY4O01xYSmeRAisN0/F1Jrs+RWIfk7yGiW4TepLuEQc3X5OF2QHWHRc7y 4lDloCOQp9rX0vCuDdf6ex2ue4hIb5VQgd4UkAg37J3eZGdhiFj94TGAb9AblHINhYU7 16GQ==
X-Gm-Message-State: AOAM5323VnbZ8QfXn1LOcSQJVeW++jQL9qYmW4pY0kYP/3ZQPqAeJCX3 OLBozLDvqnOf2qFmEN/B4n1E6PvjhwbDbsX3LnPLP7u+XSo=
X-Google-Smtp-Source: ABdhPJyCMtyq9ZJ9tnxIiuAPUSEbUgR1GNTb1xYEQ6kEo+FlevVlybmSo+QEexvV6xYSMq37zqxwY4sebuxOTrKrcpY=
X-Received: by 2002:a6b:fc0d:: with SMTP id r13mr14731461ioh.40.1591984007331; Fri, 12 Jun 2020 10:46:47 -0700 (PDT)
MIME-Version: 1.0
References: <005901d63ab5$d6003e00$8200ba00$> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Fri, 12 Jun 2020 13:46:36 -0400
Message-ID: <>
To: Pavel Lunin <>
Cc: Susan Hares <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="0000000000003ec15405a7e6a945"
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 17:46:51 -0000

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,
> 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