Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes
on special request. The purpose of the review is to provide assistance to
the Routing ADs. For more information about the Routing Directorate,
please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-bmwg-bgp-basic-convergence-01
http://tools.ietf.org/id/draft-ietf-bmwg-bgp-basic-convergence-01.txt
Reviewer: Terry Manderson
Review Date: 18/04/2014
IETF LC End Date: N/A - WG requested Routing Area Directorate review
Intended Status: Standards Track

Summary: 

I have some minor concerns about this document that I think should be
resolved before publication.

Comments:

This document is clearly written and for the most part easy to understand.
The steps are
enumerated, which is very helpful. I would have prefered to see the
reference topology figures repeated closer to the test case where they are
used, but this is a matter of style.


Major Issues:

No major issues found

Minor Issues:

Section 3 (figures 1-4): please define The Helper node (HLP) before its
use. It is first defined in section 5.1.2

Section 4.5: Please clarify if the interface media types and throughput
must all be exactly the same for all devices in all the test cases, or
that the media types and throughput are to be the same for iterations of
the test cases. I re-read that Para several times and could infer either
situation.

Section 4.10: Can you please highlight the impact on the tests for where
routing processor redundancy cannot be disabled, or if unwilling to do
that suggest that the impacts or assessment of impacts are out of scope of
this draft.

Section 5.: Point B. I assume you mean Hard Reset here. For understanding
purposes you may like to consider adding the term in parenthesis.

Section 5.1.1: Pont B introduces "peer x of Emulator". I find this wording
terse, can you please clarify what this is as I couldn't see in the text
of section 3.

	Point D: "peer-x" is used here. Is this the same term as point B?

	It appears as I read through the points, that Peer-X (possibly otherwise
known as 'SOME_ASN-X) is the test case nomenclature representation of the
emulator function. It may be worth stating that up front to be pragmatic
and help the reader.


Section 5.1.2:

	This section introduces a NTP time source to the test case, that isn't
described in "Section 3. Test Topologies". While not a critical concern to
someone implementing the topologies, it may help them by highlighting the
necessity of NTP in section 3.

Section 5.1.5

	Is the omission of normative language in the points, specifically A,B,
and C intentional?

Section 5.5, Point B. The language here surrounding the time source is
different than in earlier text, is that intentional?

Nits:

Section 1.1, Para 3: s/functional/functions/
Section 4.2, Para 1: s/or through neighbor/or through a neighbor/
Section 4.4, Para 3: s/a)default/a) default/
		s/b)platform-specific/b) platform-specific/
		s/c)values/c) values/
Section 4.6, Para 3: s/)is/) is/

Section 5.1.1, second last para: s/Stand Deviation/Standard Deviation/

Section 5.2.1, 
	Point C. "Tx1", do you simply mean "Tx" as described in Figure 1?
	Point C. s/(Tx1)Interface/(Tx1) Interface/
	Point E. s/Trr2/Tr2/
	Point F. "(Drr1)" Can you clarify this is the intended nomenclature for
this egress interface on the DUT?

Section 5.3, Point E s/route say/route, say/ - I'd expect the RFC editor
may suggest using "e.g".

Section 5.6, Point B(6) s/(e.g. route A)/(e.g. routeA)/ - "RouteA" appears
to be the selected form from earlier parts of the draft.
	(same for other occurrences in the remainder of the Draft (eg S5.8 point
N,Q, .)


Section 5.8. point F. s/Autonomous System.s/Autonomous Systems/
Section 5.8. Point S. s/Node -1/Node-1/


Cheers
Terry