Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.

["Philip Crocker" <[e-mail]>]

Hi all,

I have some comments / questions on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.

1)  Section 3.  If out-of-band verification is in use, and the passive LMP node receives an out-of-band test message with a trace pattern that does not correlate to any trace pattern of any data link configured on the node, the draft does not specify what should happen and it seems to me that there are two possibilities.

	a) The passive node sends a TestStatusFailure message back to the active node to fail verification.

	b) The passive node discards the received test message.  The active node will continue to retransmit the test message.  Either a subsequent test message leads to a successful verification, or the passive node eventually times out the verification process of this data link.

Note that this is a new situation occurring only in the out-of-band verification procedure, and therefore I believe should be addressed in the draft (in the standard link verification procedure an incoming in-band test message can always, necessarily, be correlated to the data link it was received on).  

In my opinion, if it is possible for a trace pattern used on a data link to be changed and for the change not to be noticed immediately by the passive node, then it is more robust if the test message is retransmitted as in b) above allowing multiple opportunities for the verification to succeed.  

However, for other implementations this possibility may not exist and so option a) would be preferable.  My preference is therefore for this to be left as an implementation decision, but for the draft to mention that both options are equally valid.  Would anyone care to comment on this?

2)  Section 4.1.9 (InsertTrace Message) specifies that the use of this message 'assumes that the remote [node] knows the mapping between the local and remote interface_Ids before fulfilling such [a] request'.  Isn't this same assumption also true for the TraceMonitor and TraceReq messages defined in sections 4.1.1 and 4.1.6 respectively?  If so, I suggest copying the text above from section 4.1.9 to the introductory paragraphs of sections 4.1.1 and 4.1.6 also.

3)  Section 4.  Is there a good reason why both the TraceMonitor and TraceReq (and associated) messages are required?  It seems to me that the function of a TraceMonitor message can be replicated by using a TraceReq message, then comparing the observed trace pattern to the expected pattern.  I realize that the TraceMismatch message is allowed to contain information about multiple mismatches at once, and a similar function is not available in the TraceReport message, but is this the only functional difference between the two sets of messages?

Thanks,

Phil