RE: Moving right along ...

[Fugui Wang <fwang@axiowave.com>]

Jonathan,

Thanks for the answer. But still have questions regarding your
answer. Please see in line.

Fugui

>> 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.
>Assuming you don't receive the REMOTE_LINK_ID in BeginVerify message:
>If you have locally assigned the Interface to a TE Link, then you will
>know
>the LOCAL_LINK_ID.  If the Interface has not been assigned a TE link, >then
>you put a value of zero in the LOCAL_LINK_ID (same rule as BeginVerify
>message).

But if the node which received the BeginVerify message has multiple
TE links to the sender, how does it know which one to pick?

>> 
>> 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.
>The Message_ID_ACK object is sufficient to know which TE link the
>BeginVerifyAck is for.
Well, theoretically I agree with you. But doesn't that mean that
in the sender side, all TE links need to pick Message_ID from 
a global place? Also, in order to tell the TE link from the
Message_ID_ACK, the sender side need to buffer all of the 
unacknowledged message_ID <==> TE link mapping info. 
This would be an additional requirement for the send side.
Even if you decide to do so, you still need more sophisticated
schemes to discard those lost messages from the mapping info
list. 
However,if we simply add the REMOTE_LINK_ID in the 
BeginVerifyAck message, it would be much easier for the 
sender side to implement. Same problem also exists for 
the remaining two questions below.


>> 
>> 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.")
>The MESSAGE_ID_ACK is unique within the scope of the LMP adjacency and >is
>sufficient to identify the LinkSummaryAck 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
>>