Hi, ccampers
I found a mismatch description between the procedure and the message format in LMP.
The LMP document that I have read is draft-ietf-ccamp-lmp-10.txt.
The procedure is of the link connectivity verification.
If you see the section 5.1, "Example of Link Connectivity Verification", the section is now describing as follows:
****************************************************************************************
In the section, 5.1,
o A sends a BeginVerify message over the control channel to B
indicating it will begin verifying the ports that form the TE
link. The LOCAL_LINK_ID object carried in the BeginVerify
message carries the identifier (IP address or interface index)
that A assigns to the link.
o Upon receipt of the BeginVerify message, B creates a Verify_Id
and binds it to the TE Link from A. This binding is used later
when B receives the Test messages from A, and these messages
carry the Verify_Id. B discovers the identifier (IP address or
interface index) that A assigns to the TE link by examining the
LOCAL_LINK_ID object carried in the received BeginVerify
message. (If the data ports are not yet assigned to the TE
Link, the binding is limited to the Node_Id of A.) In response
to the BeginVerify message, B sends to A the BeginVerifyAck
message. The LOCAL_LINK_ID object carried in the BeginVerifyAck
message is used to carry the identifier (IP address or
interface index) that B assigns to the TE link. The
REMOTE_LINK_ID object carried in the BeginVerifyAck message is
used to bind the Link_Ids assigned by both A and B. The
Verify_Id is returned to A in the BeginVerifyAck message over
the control channel.
In the section, 12.5.1,
<BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> [<REMOTE_LINK_ID>]
<BEGIN_VERIFY>
The above transmission order SHOULD be followed.
To limit the scope of Link Verification to a particular TE Link, the
Link_Id field of the LOCAL_LINK_ID object MUST be non-zero. If this
field is zero, the data links can span multiple TE links and/or they
may comprise a TE link that is yet to be configured. In the special
case where the local Link_Id field is zero, the "Verify all Links"
flag of the BEGIN_VERIFY object is used to distinguish between data
links that span multiple TE links and those that have not yet been
assigned to a TE link (see Section 5).
The REMOTE_LINK_ID object may be included if the local/remote
Link_Id mapping is known.
The Link_Id field of the REMOTE_LINK_ID object MUST be non-zero if
included.
In the section, 12.5.2,
<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
The LOCAL_LINK_ID object may be included if the local/remote Link_Id
mapping is known or learned through the BeginVerify message.
****************************************************************************************
There is a discrepancy about the remote Link_id between the text and the format.
In the text, the remote Link_id has been included in the BeginVerifyAck message.
But, in the format, the remote Link_id has been included in the BeginVerify message, not in BeginVerifyAck message.
I think that the text is correct, and the format is not correct.
I'm not sure that I would be reading an old document of LMP.
What do you think of this?
Thanks,
Young.