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

Susan Hares <shares@ndzh.com> Wed, 24 June 2020 20:24 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B7E3A1163 for <idr@ietfa.amsl.com>; Wed, 24 Jun 2020 13:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0rJ4v5P_CXZ for <idr@ietfa.amsl.com>; Wed, 24 Jun 2020 13:24:54 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9807B3A115E for <idr@ietf.org>; Wed, 24 Jun 2020 13:24:54 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.22.63;
From: Susan Hares <shares@ndzh.com>
To: "'idr@ietf. org'" <idr@ietf.org>
Date: Wed, 24 Jun 2020 16:24:49 -0400
Message-ID: <008501d64a65$83435a70$89ca0f50$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0086_01D64A43.FC340460"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdZKZO/nwN7MaswAQHK4ayTN0ompqQ==
Content-Language: en-us
X-Antivirus: AVG (VPS 200624-2, 06/24/2020), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/G1o_hYmZ0Vxo61SRTW8fMFLGHuI>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18) - Extended until
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2020 20:24:57 -0000

Greetings:

 

Since this draft was revised on 6/16, this WG LC is extended until 2 weeks after that date (6/30/2020).  

 

In the meantime, we’ll be busy finishing the details that go with submission: 

·         I’ve asked the authors to check with the implementers to verify that this does change the implementation report,  and 

·         I’ll finalize my shepherd’s report. 

 

The first step of the shepherd report is to provide a summary to the IDR WG on this WG LC.  

 

This summary will be sent in a separate message you can reply to that summary specifically. 

 

Sue Hares 

 

 

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

 

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: https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-11

 

 

пт, 12 июн. 2020 г. в 20:47, Gyan Mishra <hayabusagsm@gmail.com>:

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 <plunin@plunin.net> 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
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

-- 

 <http://www.verizon.com/> Image removed by sender.

Gyan Mishra

Network Solutions Architect 

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

 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr




 

-- 

Best regards,

Alexander Azimov