RE: Moving right along ...

[Jonathan Lang <jplang@calient.net>]

Fugui,
  Sorry for missing this one.  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Fugui Wang [mailto:fwang@axiowave.com]
> Sent: Wednesday, October 17, 2001 9:22 AM
> To: 'Kireeti Kompella'
> Cc: 'ccamp@ops.ietf.org'
> Subject: RE: Moving right along ...
> 
> 
> 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.
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).

> 
> 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.

> 
> 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
>