Skip to main content

Last Call Review of draft-ietf-grow-bgp-reject-04

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
I-D 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
Request Last Call review on draft-ietf-grow-bgp-reject by Ops Directorate Assigned
Reviewed revision 04 (document currently at 08)
Result Ready
Completed 2017-04-19
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

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

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.