[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Dan,

	See below for in-line response.  Closed points are replaced with "...".

Lou

On 5/5/2009 4:31 AM, Dan Li wrote:

Hi Lou and all,
Thanks for the comments!
The corresponding changes are made in 03 version.
Please see below.
Thanks,
Dan

    ----- Original Message -----
    *From:* Lou Berger <mailto:lberger@labn.net>
    *To:* Dan Li <mailto:danli@huawei.com> ; Xu Huiying
    <mailto:xuhuiying@huawei.com> ; zhangfatai@huawei.com
    <mailto:zhangfatai@huawei.com> ; Bardalai, Snigdho
    <mailto:Snigdho.Bardalai@us.fujitsu.com> ; MEURIC Julien RD-CORE-LAN
    <mailto:julien.meuric@orange-ftgroup.com> ; Diego Caviglia (GA/ERI)
    <mailto:diego.caviglia@ericsson.com>
    *Cc:* ccamp@ops.ietf.org <mailto:ccamp@ops.ietf.org>
    *Sent:* Friday, May 01, 2009 4:27 AM
    *Subject:* Re: Working group last call:
    draft-ietf-ccamp-confirm-data-channel-status-02


    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.
    [Authors] Two references (RFC2205 and RFC3209) are added.
RFC2205 and RFC3209 don't have "restart processes". They do have "soft state". 


    - 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".
    [Authors] Replaced with following text:
    In transport nodes it is possible to perform certain manual operations
    on a cross-connect such as forced protection switch (refer to [G.841])
    on a protected link. These operations will make it impossible to release
    the cross-connect when an LSP is being deleted.
G.841 uses the terms "Lockout of Protection" and "Forced Switch", it looks like you're combining the two. 


 ...




     > 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.
    [Authors] This statement is repeated in both the abstract and
    introduction.
okay. You might want to move the pasted sentence to the end of the paragraphs to improve flow, but this is your call. 


    - 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.
    [Author] Yes, there are several approaches. If one node doesn't support
    this function, it can simply ignore the new messages defined in this
    document.
humm, well this doesn't really answer my question, i.e. why didn't you use the existing types rather than define new types? 

I'm not asking for a change (at this late date) just some justification.


    - Section 4.1:

 ...




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


yes.


The following text is added
    in section 4.1:
    Nodes processing incoming messages SHOULD check to see if a newly
    received message is out of order and can be ignored. Out-of-order
    messages can be identified by examining the value in the Message_Id
    field. If a message is determined to be out-of-order, that message
    should be silently dropped.
Well, this duplicates text from 4204 and should not be included. I was pointing the subsequent paragraphs on the page and suggesting something along the lines of:
If the message is a Confirm Data Channel Status message, and the Message_Id value is less 
   than the largest Message_Id value previously received from the sender
   for the ????, then the message SHOULD be treated as being out-of-
   order.


    ...




     > 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?
    [Authors] In the case of SDH/SONET, Data Channel ID is the
    timeslot label (32 bits), which is encoded as following:
    0 1 2 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | S | U | K | L | M |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We don't need to do in circles here, but 4204/4209 uses a fundamentally different model, i.e. one based on data channel (interface) IDs and ID groups rather than labels. Your approach is not at all consistent with existing LMP, but we've already established this with the use of new messages so be it. 


    - 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.
    [Authors] DATA LINK class is defined in RFC4204. In DATA LINK class,
    a new
    subobject - Data Channel Status subobject is defined in section 4.2
    of this
    document. In this new subobject, the DATA Channel ID is introduced.
    In the
    case of SDH/SONET, DATA Channel ID is used to identify each timeslot
    of the
    data link. So the reference to RFC4204 section 13.12 will be added
    in this
    section.
Yes. Please add some normative language on ConfirmDataChannelStatusAck message construction. 


     ...




     > 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.
    [Authors] This clause is replaced by the following text:
    If the ConfirmDataChannelStatus message is not recognized by the
    RECEIVER,
    the RECEIVER will not send out an acknowledgment message to the
    SENDER.
    Due to message loss problem, the SENDER may not be able to receive the
    acknowledgment message.
    In the above two cases, 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.
I'm surprised you don't want to leverage LMP's message retransmission procedures. 



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




Lou