[Gen-art] Genart last call review of draft-ietf-idr-bgp-open-policy-18

[Gyan Mishra via Datatracker <[e-mail]>]

Reviewer: Gyan Mishra
Review result: Ready with Nits

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