Packet Loss and Delay Measurement for MPLS Networks
RFC 6374
Yes
No Objection
Recuse
Note: This ballot was opened for revision 04 and is now closed.
(Adrian Farrel; former steering group member) (was Discuss, Yes) Yes
(Dan Romascanu; former steering group member) (was Discuss) Yes
(Ron Bonica; former steering group member) Yes
Please add text to section 2.9.10 stating that in the following conditions, delay measurement will be useless: - when the two router clocks differ by a significant portion of the round trip time - when probe processing contributes significantly to round trip time
(David Harrington; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
#1) Section 3.1 and 3.2 contains the following: TLV Block Optional block of Type-Length-Value fields Should Optional be OPTIONAL to indicate support requirement? #2) Section 4.2.2 contains the following: When transmitting an LM Query over a channel, the Version field MUST be set to 0. Shouldn't "over a channel" be removed? Isn't version always set to 0? #3) Section 4.2.2 contains the following: The Origin Timestamp field SHOULD be set to the time at which this message is transmitted, hmmm so what other time would be put there? The definition from earlier sections is: Origin Timestamp: Timestamp recording the transmit time of the query message. #4) Section 4.3.1 contains the following: When transmitting a DM Query over a channel, Shouldn't "over a channel" be removed? Isn't version always set to 0?
(Stephen Farrell; former steering group member) (was Discuss) No Objection
(1) Section 2 as a whole is very wordy. While its fine to spell things out for clarity, this text perhaps demands too little from the reader, at the expense of clarity for the capable reader. (In other words, this seems just too long:-) Feel free to entirely ignore this comment though. (2) The "(B1,...,Bk)" notation isn't clear in 2.6 - are we measuring (A,B1) and (A,B2) etc. or are we measuring what happens on the path from A to Bk via B1,B2...etc.? Since the section is about unidirectional LSPs it may be easier to just deal with A and B here. (3) (2.9.3) Saying that the detailed measurement behavaiour "MUST be made clear to the user" seems wrong in two respects - a) a programmer won't know what'll be clear to all future users of their code, and b) there may be no (human) user that can see the direct mesurements, (the humans might only see derived statistics I guess). I also don't quite know how I'd test for that MUST. Maybe just loose the 2119 language there? (4) 2.9.5 assumes that intermediate nodes can reply to LM/DM messages, but that hasn't yet been stated. (5) Two timestamp formats are supported - would be good to include examples of each at the point where that's first mentioned in detail.
(Wesley Eddy; former steering group member) (was Discuss) No Objection
(Stewart Bryant; former steering group member) Recuse