RE: Moving right along ...

[Fugui Wang <fwang@axiowave.com>]

Kireeti,

For LMP, the following questions regrading message format
has not been answered yet.

Regards,
Fugui

> draft-ietf-ccamp-lmp-01.txt has been posted.  The thought was
> raised that this draft is close to ready for WG Last Call.  Please
> review it, and let us know if you disagree.

A couple of questions regarding the messages in the new
LMP draft:

(1) BeginVerifyAck message: 
Since REMOTE_LINK_ID is optional in the BeginVerify
message, how could LOCAL_LINK_ID be a required object
in the BeginVerifyAck message? When you compose the 
BeginVerifyAck message, you may not know the 
LOCAL_LINK_ID if it is not specified as REMOTE_LINK_ID
in the BeginVerify message.

REMOTE_LINK_ID object should be within the 
BeginVerifyAck message. Otherwise when receiving
BeginVerifyAck, the node won't know for which 
TE link the BeginVerifyAck is for.

So maybe we should change the BeginVerifyAck message to:
<BeginVerifyAck Message> ::= <Common Heade>
                             [<LOCAL_LINK_ID>]
                             <REMOTE_LINK_ID>
                             <MESSAGE_ID_ACK>
                             <BEGIN_VERIFY_ACK>
                             <VERIFY_ID>
Actually, I think LOCAL_LINK_ID could also be removed
because it won't be useful for the receiver side 
except providing a redundant check.

(2) LinkSummaryAck:
Again, REMOTE_LINK_ID object should be there. 
Otherwise, the remote node won't know for which
TE link the LinkSummaryAck is for. Using 
MESSAGE_ID_ACK to identify that is difficult
since that will require the MESSAGE_ID to be
unique over the node and we also need to use
the MESSAGE_ID as an index to locate the TE link
efficiently. (In the old LMP draft, I did see that 
"When combined with the Local TE Link Id ..., the 
MessageId field uniquely identifies a message.")
Changing the message to the following
format will make life much easier:
<LinkSummaryAck Message> ::= <Common Header>
                             <MESSAGE_ID_ACK>
                             <REMOTE_LINK_ID>

It would also be nice if we can add the REMOTE_LINK_ID
object to LinkSummaryNack message.

Thanks,
Fugui