Last Call Review of draft-ietf-grow-ix-bgp-route-server-operations-03
review-ietf-grow-ix-bgp-route-server-operations-03-opsdir-lc-comstedt-2014-10-17-00
Request | Review of | draft-ietf-grow-ix-bgp-route-server-operations |
---|---|---|
Requested revision | No specific revision (document currently at 05) | |
Type | Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2014-10-14 | |
Requested | 2014-09-12 | |
Authors | Nick Hilliard , Elisa Jasinska , Robert Raszuk , Niels Bakker | |
I-D last updated | 2014-10-17 | |
Completed reviews |
Genart Last Call review of -03
by Dan Romascanu
(diff)
Genart Telechat review of -03 by Dan Romascanu (diff) Secdir Last Call review of -03 by Catherine Meadows (diff) Opsdir Last Call review of -03 by Niclas Comstedt (diff) Rtgdir Last Call review of -03 by John Scudder (diff) |
|
Assignment | Reviewer | Niclas Comstedt |
State | Completed | |
Request | Last Call review on draft-ietf-grow-ix-bgp-route-server-operations by Ops Directorate Assigned | |
Reviewed revision | 03 (document currently at 05) | |
Result | Has nits | |
Completed | 2014-10-17 |
review-ietf-grow-ix-bgp-route-server-operations-03-opsdir-lc-comstedt-2014-10-17-00
Hi, I reviewed draft-ietf-grow-ix-bgp-route-server-operations-03 for its operational impact. Intended status: Informational Summary: This is a document focused on operational considerations for running a BGP route-server in an Internet Exchange context. As such its operationally focused by nature. I found it well written with no real concerns or issues. I do have some minor comments and questions. - Should there be a recommendation around path hiding? As the doc goes along its gets clearer around recommendations - 4.2.1.3, this I think is a little too loose but cleared up later (in 4.8). Before getting to 4.8 it seems this lacks a suitable recommendation (see next item) - Section 4.8, NH validation a ‘must’ instead of ’should’? With the RS approach this validation isn’t easily done by the clients and is important. So feels like this validation should either be available by the client (explicit enforcement) or generically validated (i.e. ‘must’). /nco