From nobody Wed Dec 8 02:54:38 2021 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDB73A0D49; Wed, 8 Dec 2021 02:54:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ines Robles via Datatracker To: Cc: draft-ietf-idr-bgp-open-policy.all@ietf.org, idr@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163896087171.25408.8356261453414272739@ietfa.amsl.com> Reply-To: Ines Robles Date: Wed, 08 Dec 2021 02:54:31 -0800 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-idr-bgp-open-policy-18 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 10:54:32 -0000 Reviewer: Ines Robles Review result: Ready Hello, I have been selected to do a routing directorate review of this draft. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-idr-bgp-open-policy-18 Reviewer: Ines Robles Review Date: 08-12-2021 Intended Status: Standards Track Summary: This document provides configuration automation using BGP Roles. An optional, transitive BGP Path Attribute, called Only to Customer (OTC), is specified. It prevents ASes from creating leaks and detects leaks created by the ASes in the middle of an AS path. This document is basically ready for publication, I have some minor comments/questions below. Major issues: None Minor issues: None Nits/Comments/Questions: 1- It would be nice to mention in the first paragraph of Section 4 when you present the OTC Attribute that is included into the UPDATE message. 2- Should the attribute-flags of the OTC attribute mentioned explicitly in Section 4? e.g. the high order bit (bit 0) is 1 (optional); the bit 1 is 1 (transitive); the bit 2 (partial bit) is 0/1(?), etc? 4- In Section 4, the ingress policies guide to leak detection and the egress policies guide to leak prevention. Correct? 5- Section 5: Is there a formal definition for complex peering relationships? Should it be added into terminology section? Maybe defining what is a simple peering relationship and then stating that what is not simple is complex? How are the security considerations in complex peering relationships? Thanks for this document, Ines. From nobody Wed Dec 8 08:26:51 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE1F3A00E1; Wed, 8 Dec 2021 08:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 uNIg5bP4oNCA; Wed, 8 Dec 2021 08:26:38 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 72ECB3A00E0; Wed, 8 Dec 2021 08:26:34 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.107.67.11; From: "Susan Hares" To: "'Ines Robles'" , Cc: , , References: <163896087171.25408.8356261453414272739@ietfa.amsl.com> In-Reply-To: <163896087171.25408.8356261453414272739@ietfa.amsl.com> Date: Wed, 8 Dec 2021 11:26:20 -0500 Message-ID: <010d01d7ec50$5b874710$1295d530$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGP+gRuQ82HQI9eOxBib51Gbn5+yqy4rFxw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [RTG-DIR] [Idr] Rtgdir last call review of draft-ietf-idr-bgp-open-policy-18 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 16:26:42 -0000 Ines:=20 Thank you for your careful and detailed review. The authors will = respond to you on the nits.=20 Sue Hares (chair, shepherd)=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ines Robles via = Datatracker Sent: Wednesday, December 8, 2021 5:55 AM To: rtg-dir@ietf.org Cc: draft-ietf-idr-bgp-open-policy.all@ietf.org; idr@ietf.org; = last-call@ietf.org Subject: [Idr] Rtgdir last call review of = draft-ietf-idr-bgp-open-policy-18 Reviewer: Ines Robles Review result: Ready Hello, I have been selected to do a routing directorate review of this draft. For more information about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-idr-bgp-open-policy-18 Reviewer: Ines Robles Review Date: 08-12-2021 Intended Status: Standards Track Summary: This document provides configuration automation using BGP Roles. An = optional, transitive BGP Path Attribute, called Only to Customer (OTC), is = specified. It prevents ASes from creating leaks and detects leaks created by the ASes = in the middle of an AS path. This document is basically ready for publication, I have some minor comments/questions below. Major issues: None Minor issues: None Nits/Comments/Questions: 1- It would be nice to mention in the first paragraph of Section 4 when = you present the OTC Attribute that is included into the UPDATE message. 2- Should the attribute-flags of the OTC attribute mentioned explicitly = in Section 4? e.g. the high order bit (bit 0) is 1 (optional); the bit 1 is = 1 (transitive); the bit 2 (partial bit) is 0/1(?), etc? 4- In Section 4, the ingress policies guide to leak detection and the = egress policies guide to leak prevention. Correct? 5- Section 5: Is there a formal definition for complex peering = relationships? Should it be added into terminology section? Maybe defining what is a = simple peering relationship and then stating that what is not simple is = complex? How are the security considerations in complex peering relationships? Thanks for this document, Ines. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr