Skip to main content

Last Call Review of draft-ietf-bmwg-bgp-basic-convergence-04

Request Review of draft-ietf-bmwg-bgp-basic-convergence
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-11-10
Requested 2014-10-30
Authors Rajiv Papneja , Bhavani Parise , Susan Hares , Dean Lee , Ilya Varlashkin
Draft last updated 2014-11-11
Completed reviews Genart Last Call review of -04 by Joel M. Halpern (diff)
Secdir Last Call review of -04 by Chris M. Lonvick (diff)
Opsdir Last Call review of -04 by Scott O. Bradner (diff)
Assignment Reviewer Scott O. Bradner
State Completed
Review review-ietf-bmwg-bgp-basic-convergence-04-opsdir-lc-bradner-2014-11-11
Reviewed revision 04 (document currently at 05)
Result Has Nits
Completed 2014-11-11
as a document that describes testing devices that are not in a operating 
network while they are being tested, this document can not have a direct
imoact on Internet operations but the results of this type of testing can 
be of help to network operators when they select network devices

some comments/questions on the contents of the draft:


  "FIB (Data plane) convergence is defined as the completion of all FIB
   changes so that all forwarded traffic now takes the new proposed
   route. "

should route be singular or plural - i.e. is the assumption that the 
routing table converges to a single next hop? (at least for the test traffic)
if so, does the draft specifically say that (or does rfc 4098 and I missed it)
note: figure 1 shows multiple peering links - sec 4.1 seems to argue for 
multiple peers

  "Data plane convergence is different than control plane
   convergence within a node."

might want to say how they are different

since reporting requiremenst are covered in section 6 should
	they also be mentioned here? (if so, how about in section 4.2)

secton 4.4  & 4.8
	maybe replace TCP MD5 with TCP Authentication Option (2 places)
	or at least mention it

section 4.4 basic test settings - maybe say why these values were chosen

section 4.7  agree as to the importance fo rrepeating trials - is 
there a recognized source that discusses "generally accepted testing 
practices regarding repeatability ..."?

section 5 
	what about Graceful Restart (RFC 4724) - would that impact the 
	clean start desire?

section 5.1.1
      "D.  Start the traffic from the Emulator tx towards the DUT
          targeted at a routes specified in route mixture (ex. routeA)"

	change "a routes" to "a route" or "the routes"

 E & F - as noted earlier in the document - these times should be very
	close to the same - is it actually worth the additional complexity
	to collect the time when the update is received?
	also 5.1.2 H & I,  etc

section 5.1.2 mentions NTP but section 5.1.1 does not - is there a reason?

section 5.2.1 - since the shutdown event is not timed - does this test
	provide a useful measurement? (or should the time be recorded and
	its just not mentioned?)

section 5.3 - F - implies that the time is recorded but not actually say
	say that it is

	general comment - review all steps of all tests to be sure that 
	NTP is called for when it is needed  and that event times are 
	specifically called for when they are needed and use consistent
	langage in each case

	the overall requiremenst - e.g. NTP could also just be noted
	before the test descriptions and not inlcuded in each one if
	it is needed in all of them - same with advice about 
	nukbers of routes (do tests with different numbers or routes
	up to the full Internet table)

section 6 - should this also include the number of AS Paths?