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@xxxxxxxx> 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
