Last Call Review of draft-ietf-grow-bgp-reject-04
review-ietf-grow-bgp-reject-04-opsdir-lc-martinez-2017-04-19-00
| Request | Review of | draft-ietf-grow-bgp-reject |
|---|---|---|
| Requested revision | No specific revision (document currently at 08) | |
| Type | Last Call Review | |
| Team | Ops Directorate (opsdir) | |
| Deadline | 2017-04-18 | |
| Requested | 2017-04-04 | |
| Authors | Jared Mauch , Job Snijders , Greg Hankins | |
| Draft last updated | 2017-04-19 | |
| Completed reviews |
Opsdir Last Call review of -04
by
Carlos M. Martínez
(diff)
Secdir Last Call review of -05 by Takeshi Takahashi (diff) Genart Last Call review of -04 by Dale R. Worley (diff) Rtgdir Last Call review of -04 by Russ White (diff) Secdir Telechat review of -08 by Takeshi Takahashi Genart Telechat review of -07 by Dale R. Worley (diff) Genart Telechat review of -08 by Dale R. Worley |
|
| Assignment | Reviewer | Carlos M. Martínez |
| State | Completed | |
| Review |
review-ietf-grow-bgp-reject-04-opsdir-lc-martinez-2017-04-19
|
|
| Reviewed revision | 04 (document currently at 08) | |
| Result | Ready | |
| Completed | 2017-04-19 |
review-ietf-grow-bgp-reject-04-opsdir-lc-martinez-2017-04-19-00
I have reviewed this draft as part of the last-call reviews of the Operations Directorate. These comments should be taken by authors and WG chairs just as any other last-call comment. In its abstract this document mentions: "This document defines the default behavior of a BGP speaker when there is no import or export policy associated with an External BGP session." Introduction The document's introduction describes a well known operational caveat that has caused countless headaches over the years to those involved in BGP operations. A BGP speaker may, and in may cases, will, accept and publish anythin to its neighbors when there is no more specific routing policy applied. Proposed solution The document proposes a set of default behaviours for BGP speakers in the absence of configured routing policies. The document references RFC4271 in the second paragraph. I believe it would benefit from referencing 4271 in the third paragraph for the definition of "EBGP peer". The fourth paragraph proposes a default operating mode of "import nothing" and "export nothing". This terminology should be familiar for anyone working on BGP operations. I however believe the reader would benefit from a provided definition of these terms. The above comments are all minor points and Overall I believe the document is clear and well written and ready to move forward.