Last Call Review of draft-ietf-idr-bgp-open-policy-18
review-ietf-idr-bgp-open-policy-18-rtgdir-lc-robles-2021-12-08-00
Request | Review of | draft-ietf-idr-bgp-open-policy |
---|---|---|
Requested revision | No specific revision (document currently at 24) | |
Type | Last Call Review | |
Team | Routing Area Directorate (rtgdir) | |
Deadline | 2021-12-08 | |
Requested | 2021-11-18 | |
Requested by | Alvaro Retana | |
Authors | Alexander Azimov , Eugene Bogomazov , Randy Bush , Keyur Patel , Kotikalapudi Sriram | |
I-D last updated | 2021-12-08 | |
Completed reviews |
Secdir Early review of -15
by Alexey Melnikov
(diff)
Rtgdir Early review of -15 by Mach Chen (diff) Rtgdir Last Call review of -18 by Ines Robles (diff) Genart Last Call review of -18 by Gyan Mishra (diff) Secdir Last Call review of -18 by Alexey Melnikov (diff) |
|
Comments |
The rtg-dir reviewed -15, but there have been significant changes to the text (not the mechanism) since then. Please re-review. |
|
Assignment | Reviewer | Ines Robles |
State | Completed | |
Request | Last Call review on draft-ietf-idr-bgp-open-policy by Routing Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/rtg-dir/jiJ89hDBp_qGE0b7rN5Vpz0Q6Jc | |
Reviewed revision | 18 (document currently at 24) | |
Result | Ready | |
Completed | 2021-12-08 |
review-ietf-idr-bgp-open-policy-18-rtgdir-lc-robles-2021-12-08-00
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.