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

Gyan, thank you for your review and everyone else on the follow-on discussion. I have entered a No Objection ballot for this document.

Lars

> On 2021-12-22, at 3:01, Gyan Mishra via Datatracker <noreply@ietf.org> wrote:
> 
> 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
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Attachment: signature.asc