RE: Two week Last Call on LMP

[Jonathan Lang <jplang@calient.net>]

Robin,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Robin Qiu [mailto:robin_qiu@hotmail.com]
> Sent: Tuesday, November 27, 2001 8:05 AM
> To: kireeti@juniper.net
> Cc: ccamp@ops.ietf.org
> Subject: RE: Two week Last Call on LMP
> 
> 
> 
> Hi,
> 
> A few comments/questions/requests. Appreciate your response:
> 1. In secion 2 "LMP Overview", paragraph 7, it says "however,
>    (for link connectivity verification procedure) the
>    control channel MUST terminate on the same two nodes that the
>    TE link spans". Why is this a requirement? This prevents a
>    "proxy" LMP implementation.
I'm not sure of the application here...

> 2. In section 3.2.1, it says "Once it has both sent and received a
>    Hello message, the control channel moves to the UP state". Should
>    a "valid" (expected RcvSeqNum) Hello be received before moving to
>    UP state?
We will add text to clarify that the received Hello must be "valid" as you
say.

> 3. In section 4 "Link Property Correlation MUST be done before the
>    link is brought up". Is it necessary to be "MUST"? Ramesh S.
>    brought up this issue too and Jonathan answered.
This will be changed to a SHOULD.

> 4. Section 5 "Verify Link Connectivity", paragraph 9 "It is also
>    permissible for the sender to terminate the Test procedure
>    without receiving a TestStatusSuccess or TestStatusFailure
>    message by sending an EndVerify message". This seems misleading
>    that the sender can't terminate the Test procedure in other
>    situations. Can it be more straightforward like this "It is also
>    permissible for the sender to terminate the Test procedure anytime
>    after sending BeginVerify. An EndVerify message SHOULD be sent
>    for this purpose."?
ok.

> 5. In section 7 "Message_Id Usage", can something be added to describe
>    how to identify a message_id value wrapping? Because the message_id
>    is made by the other node, it is impossible to know when it wraps
>    without some common rule. For example, can we dictate that
>    message_id be incremented by 1?
In the draft it states that the Message_Id value is incremental.  We will
change "incremental" to "monotonically increasing".

> 6. In section 8 "Graceful Restart", it doesn't cover the scenario where
>    both ends restart. In this case, both sides must process the
>    LinkSummary process as described in section 4.
Thanks.  We'll update the text.

> 7. In section 12.1 "Control Channel FSM", if a CC is brought down
>    administratively by one side, should it only be brought up by that
>    same side? Based on the current specification, either side can bring
>    it up again.
It seems to me that this is an implementation issue that I don't think needs
to be specified in the protocol spec.

> 8. In section 13, is 140 officially assigned to LMP?
no.  The protocol Id needs to be assigned by IANA.

> 9. In 13.6.5, 13.6.6, can object <VERIFY_ID> be put at the end of the
>    object list for both EndVerifyAck and Test, i.e.
>    <EndVerifyAck>::=<CommonHeader><MESSAGE_ID_ACK><VERIFY_ID>
>    <Test>::=<CommonHeader><LOCAL_INTERFACE_ID><VERIFY_ID>
>    This is consistent with other messages, so that it is easier to
>    comply with the recommendation "The transmission order SHOULD be
>    followed".
ok
> 10. In general, can default values be suggested for various LMP timers?
These are very closely related to the transmission medium for the control
channel, so I'm not sure it is appropriate.

> 11. In section 14.9 "BEGIN_VERIFY Class", what is the expected usage
>     for "Number of Data Links" on the receiving side? The Test process
>     is driven by the sending side until a EndVerify is received. Should
>     receiving side count the number of data links tested and take some
>     action after it exceeds "number of data links"?
After the receive side meets the "number of data links", it no longer has to
look for Test messages for that Verification procedure.

> 12. In section 14.12 "TE_LINK Class", don't know who has the authority
>     to request this, but C-Type=4 should be reserved for OIF, just as
>     in LOCAL_LINK_ID Class (14.3.1).
We will add C-Type=4 for OIF.

> 
> Regards,
> 
> Robin Qiu
> 
> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Monday, November 12, 2001 9:00 PM
> To: ccamp@ops.ietf.org
> Subject: Two week Last Call on LMP
> 
> 
> Hi All,
> 
> This is to announce a two week Last Call on the LMP draft:
> draft-ietf-ccamp-lmp-02.txt.  This Last Call ends COB Wed Nov 28.
> 
> Please send questions, comments and requests for clarifications
> to the CCAMP list.
> 
> Kireeti.
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at 
> http://explorer.msn.com/intl.asp
> 
>