Re: [Gen-art] Gen-art telechat review: draft-ietf-opsawg-oam-overview-14.txt

[Jari Arkko <[e-mail]>]

Thank you for the review. I'm happy to hear that the document has improved significantly since 2013.

Still, a number of smaller editorial issues. Authors - have you seen these?

Jari

On Mar 21, 2014, at 8:04 PM, Elwyn Davies <[e-mail]> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-opsawg-oam-overview-14.txt
> Reviewer: Elwyn Davies
> Review Date: 21 March 2014
> IETF LC End Date: Jan 2013
> IESG Telechat date: 27 March 2014
> 
> Summary:
> Ready with nits and a couple of very minor issues.
> I was pleased that this version of the document seems to have been
> greatly improved since -08 which I reviewed previously in Jan 2013, and
> the scope is now quite clear.  Thanks for the work that has been done!  
> 
> Major issues:
> None.
> 
> Minor issues:
> General:  I wondered about the wisdom of using more or less mnemonic
> tags for the multitude of references but on reflection the mnemonic
> value is probably worthwhile.  I toyed with the idea of adding the RFC
> number next to the reference in the text on first occurrence so that
> people don't have to keep skipping off to the references, but in the end
> this is probably a silly idea.
> 
> s2.2.9, Discussion: The added complexity of P2MP is called out but
> nothing is said about MP2MP, which I think would be even more tricky.
> Would it be useful to say something also about MP2MP? [*Are* there any
> tools for this case?]
> 
> s4.4.1, para 6: There seems to be possibly a minor contradiction between
> the statements:
> 
>> LSP Ping is easily extensible to
>>   include additional information needed to support new functionality,
>>   by use of Type-Length-Value (TLV) constructs.
> 
> and
> 
>> The usage of TLVs is
>>   typically not easy to perform in hardware, and is thus typically
>>   handled by the control plane.
> 
> What is the implication of adding a new TLV as regards hardware and
> performance? Does the second statement mean that either the hardware
> will throw away messages with unknown, new TLVs, complain about such
> messages or have poor performance?  If so, the "easily" in the first
> statement is possibly "easily but impractically".  A little explanation
> is probably needed (or maybe this is just too complex to explain here).
> Maybe reducing all this to "LSP Ping is extensible using additional TLVs
> but there may be hardware issues (see RFC...)." 
> 
> Nits/editorial comments:
> General: s/i.e./i.e.,/, s/e.g./e.g.,/ (a couple of missing cases)
> 
> General: It would be helpful to use non-breaking hyphens in MPLS-TP and
> all references if possible.
> 
> s1.2, first bullet: s/Standard development/Standards development/
> 
> s1.3: It would be useful to put a forward reference to the terminology
> section 2.1 to cover the various acronyms and abbreviations in Table 1.
> 
> s3, 2nd bullet: s/also allows to detect/also allows detection of/  It
> might also be appropriate to be a bit less definite about localization -
> add in 'attempts' or 'tries' maybe?
> 
> s3, Delay Measurement: Maybe mention 'jitter' as an alternative for
> delay variation.
> 
> s4.3.3, 2nd bullet: s/a failure is detected/a failure is reported/
> 
> s4.3.3, last para: s/i.e. no failures are detected,/i.e., when no
> failures have been detected,/
> 
> s4.3.3, last para: "...negotiated transmission time" Do you mean
> "transmission rate" as mentioned in the previous para?  If not it might
> be good to make it clear that this isn't a typo.
> 
> s4.4.1, para 4 (after 2nd bullet): s/and also Maximum Transmission Unit
> (MTU) problems/and also identify Maximum Transmission Unit (MTU)
> problems/
> 
> s4.4.1, para 5: s/the MPLS faults/MPLS faults/
> 
> s4.5.1, 2nd bullet: 
>> and there is a need to
>>      differentiate OAM packets from data plane ones.
> This is slightly confusing - the congruence requirement makes all the
> packets (OAM and user) to be data plane packets. How about:
> 
>> and there is a need to
>>      differentiate OAM packets from ordinary user packets in the data plane.
> 
> 
> s4.5.1, Maintencance Intermediate Point section:
>> A MIP in MPLS-TP identifies OAM packets destined
>>   to it by the value of the TTL field in the OAM packet.
> This is not terribly helpful: Either a reference to where to find out
> what TTL value is needed or some explanation of the required value would
> be a good idea.
> 
> s4.5.1, Up and Down MEPs:
> The term "bridge interface" is IEEE/MPLS-TP jargon and needs defining.
> Might be also worth a note that, unlike prior usage of up/down, this has
> nothing to do with defects (or layabout parliamentarians in
> Brussels). ;-)
> 
> s4.5.3: Please add a reference for PWE3 ACH and VCCV and a pointer to a
> document where "PW control word" is defined (preferably with section
> numbers.
> 
> s4.5.4.6: s/if there a return path exists/if a return path exists/
> 
> s4.7.3, last para: s/Server accepts the modes./Server accepts the mode./
> 
> s4.7.3, last para: I think there is a bit of interaction missing: (i)
> server tells Session-sender to start sending; (ii) if Control-client
> stops the session, it tells server and server tells Session-sender;
> (iii) when session is finished Session-sender reports to Server which
> recovers data from Session-receiver (or controls Fetch client?) 
> 
> s5.1, Traceroute: Should this mention the Paris traceroute?
> 
> s5.1, OWAMP/TWAMP: For consistency should probably reference RFCs.
> 
> s5.3: s/in as much accuracy/with as much accuracy/
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art