Re: Working group last call: draft-ietf-ccamp-confirm-data-channel-status-02

[Lou Berger <lberger@labn.net>]

Authors,

Here are some LC comments:

- Section 2.2:

>   RSVP-TE restart processes [RFC3473], [RFC5063] define mechanisms
>   where adjacent LSRs may resynchronize their control plane state to
>   reinstate information about LSPs that have persisted in the data
>   plane.

    The same can be said for RFC2205's (and consequently RFC3209's) soft
    state mechanisms.


- Section 2.3:
>   operations on a cross-connect such as forced protection switch,
>   red-line,

    Please provide references or definitions of "forced protection
    switch" and "red-line".

- Section 2.4:
>   ... From the upstream's
>   point of view ...

    Presumably you mean "upstream node's" point of view, i.e. "node" is
    missing.

- Section 3:
>   The protocol extensions are intended

    Do you mean "The protocol extensions *defined in this document*"?

>   the major factor to deal with.

    I don't understand this, do you mean "the major source of errors" or
    something else?

>   As LMP is already used to verify data plane connectivity, it is
>   considered to be an appropriate candidate to support this feature.

    This is a fairly major point as it defines the scope of
    use/applicability of this document.  I suggest that you repeat this
    point in both the abstract and introduction.

- Section 4.1:

>   Three new messages are defined to check data channel status. Message
>   Type numbers are found in Section 7.1.

    So why define new message types?  It seems that the same effect
    could have been obtained using new Channel_Status values in
    channelstatus messages.

- Section 4.1:

    How are the new messages to be encapsulated and sent?  Presumably
    the same as non-test messages, i.e., "run over the control channel,
    encapsulated in UDP with an LMP port number and IP addressing as
    defined in RFC4202".

    Also, don't you also need to specify out of order processing for the
    new messages? see the top of Page 24 in RFC4202.

- Section 4.1.1.:
>    is found, this mismatch result SHOULD be reported to the management

   This "SHOULD" duplicates a requirement in section 5.  For many
   reasons it's not good practice to define the same requirement in two
   places and it's therefore typically avoided.  I suggest replacing
   "SHOULD be" with something like "is typically" or "is expected to
   be".

- Section 4.1.2.:
>   status mismatch is found, the mismatch result SHOULD be reported to

   Same comment as Section 4.1.1.

- Section 4.2:

>   0x0000 : The channel is available/free.
>   0x0001 : The channel is cross-connected/allocated.

    What about when the channel / resource is unavailable due to being
    missing, removed, administratively off-line, failed, etc.?  Are
    different "unavailable" values warranted?  If not, perhaps
    "unavailable/in-use" is a better description than
    "cross-connected/allocated".

>  Data Channel ID

   Isn't this field redundant with the DATA_LINK object's interface_ids?
   Please keep in mind that LMP already has a notion of data channels
   that are represented in the 4204/4209 CHANNEL_STATUS objects.  Am I
   missing something?

- Section 5:
>  ... The RECEIVER also
>      sends the ConfirmDataChannelStatusAck message which carries all
>      the local end statuses of the requested data channels to the
>      SENDER.

    If the DATA Channel ID remains, you'll need to define how it's used
    in this message.

>   ..., and this
>   information MAY be queried in the future.

    It seems that this clause is referring to behavior of (1) a
    management entity that is querying for mismatch state and (2) the
    node's support for this management entity.  As this document doesn't
    cover management considerations *at all* this clause should either be
    moved to a more complete "Management Considerations" section or be
    removed.

>   The data channel status mismatch issue warned about by LMP may be
    I think you mean "identified" ---------^^^^^^^^^^^^
>   automatically resolved by RSVP restart.

    The issue may also be resolved via RSVP soft state timeout.

>   If the ConfirmDataChannelStatus message is not recognized by the
>   RECEIVER, the RECEIVER will not send out an acknowledgement message

    spelling: "acknowledgment" -----------------^^^^^^^^^^^^^^^

>   to the SENDER. In this case, if the ConfirmDataChannelStatusAck or
>   ConfirmDataChannelStatusNack message is not received by the SENDER
>   within the configured time, the SENDER SHOULD terminate the data
>   channel confirmation procedure. A default value of 1 minutes is
>   suggested for this timer.

    It might be worth identifying this "compatibility" case separately
    from the case where no ConfirmDataChannelStatusAck is received due
    to message loss.

Lou

On 4/17/2009 12:25 PM, Lou Berger wrote:
>
> This email begins a two week working group last call on
> draft-ietf-ccamp-confirm-data-channel-status-02.txt
>
> 
http://tools.ietf.org/html/draft-ietf-ccamp-confirm-data-channel-status-02
>
> Please send your comments to the list or the authors before the last
> call closes on May 1, 2009.
>