Last Call Review of draft-ietf-idr-bgp-open-policy-18
review-ietf-idr-bgp-open-policy-18-genart-lc-mishra-2021-12-21-00
| Request | Review of | draft-ietf-idr-bgp-open-policy |
|---|---|---|
| Requested revision | No specific revision (document currently at 24) | |
| Type | Last Call Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2021-12-17 | |
| Requested | 2021-12-03 | |
| Authors | Alexander Azimov , Eugene Bogomazov , Randy Bush , Keyur Patel , Kotikalapudi Sriram | |
| I-D last updated | 2021-12-21 | |
| 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) |
|
| Assignment | Reviewer | Gyan Mishra |
| State | Completed | |
| Request | Last Call review on draft-ietf-idr-bgp-open-policy by General Area Review Team (Gen-ART) Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/bnQ6_d1J8TSN6zw-579JvK8bxkQ | |
| Reviewed revision | 18 (document currently at 24) | |
| Result | Ready w/nits | |
| Completed | 2021-12-21 |
review-ietf-idr-bgp-open-policy-18-genart-lc-mishra-2021-12-21-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-idr-bgp-open-policy-?? Reviewer: Gyan Mishra Review Date: 2021-12-21 IETF LC End Date: 2021-12-17 IESG Telechat date: Not scheduled for a telechat Summary: This draft provides a new BGP open role capability and OTC path attribute to detect and mitigate route leaks automatically. I have been following this draft on IDR and supported through Adoption and WGLC. This document has matured and is ready for publication. The new BGP role capabilities mismatch code 2 subcode 8 discussed on ML seems to have multiple implementations deployed and one confined by Cisco. I agree that the authors should request a new subcode for the role mismatch notification. Major issues: None Minor issues: None Nits/editorial comments: Comment related to Gao-Rexford model. The Gao-Rexford Model only has 3 peer types North bound upstream Provider, Southbound Customer and lateral same tier level peer. With the role capabilities, RS and RS-Client is added which makes it slightly different but almost identical. In describing the role types would it make sense to have a graphical depiction of Gao-Redford model with the role capabilities on adjacent peers to help explain the role relationship for local and remote-as. Just an idea to help explain the role capabilities. In the role correctness section scenario where the peer receives multiple role capabilities to send role mismatch notification. What if there is a timing issue and the multiple are received after the BGP open and peer is established possible sequence of events issue. Is it possible the peer may not get a mismatch notification if the peer establishes prior to getting a different capabilities where a mismatch or problem exists that is missed that could result in a route leak. I am thinking of possibly false positive or negative or negative during BGP open capabilities exchange