[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,
No problem. Can you address the comments in my message included below?
I've also included a some issues that are not resolved in the latest
document at the end of the mail. If you can address these too that
would be great.
Lou
On 5/19/2009 8:14 PM, Dan Li wrote:
Lou,
Sorry, I attached the wrong version. Here is the latest one.
Thanks,
Dan
----- Original Message -----
*From:* Lou Berger <mailto:lberger@labn.net>
*To:* Dan Li <mailto:danli@huawei.com>
*Cc:* Deborah A. Brungard <mailto:dbrungard@att.com> ;
ccamp@ops.ietf.org <mailto:ccamp@ops.ietf.org> ; Diego Caviglia
(GA/ERI) <mailto:diego.caviglia@ericsson.com> ; MEURIC Julien
RD-CORE-LAN <mailto:julien.meuric@orange-ftgroup.com> ; Bardalai,
Snigdho <mailto:Snigdho.Bardalai@us.fujitsu.com> ;
zhangfatai@huawei.com <mailto:zhangfatai@huawei.com> ; Xu Huiying
<mailto:xuhuiying@huawei.com>
*Sent:* Tuesday, May 19, 2009 9:23 PM
*Subject:* Re: Working group last call:
draft-ietf-ccamp-confirm-data-channel-status-02
Dan,
It looks like the rev attached to your email was an older version,
i.e., it doesn't have all the updates discussed in this and earlier
e-mails. Do you have an more current rev?
I'll wait to comment on the attachment until you have a fully updated
rev so we don't re-discuss closed topics.
On 5/18/2009 10:50 PM, Dan Li wrote:
> Hi all,
> Issues from previous email exchange are listed below:
> 1) Soft State - combined with the suggestions from Lou and Julien:
>
> In [RFC2205] and [RFC3209], a soft state mechanism was defined to
> prevent state discrepancies between LSRs.
I suggest dropping the following clause:
> With RSVP-TE uses moving to "firm states",
(end drop)
> RSVP-TE restart processes ([RFC3473], [RFC5063])
> have been defined: adjacent LSRs may resynchronize their control
> plane state to reinstate information about LSPs that have persisted
> in the data plane. Both mechanisms aim at keeping state consistency
> among nodes and allow LSRs to detect mismatched data plane states.
> The data plane handling of such mismatched state can be treated as a
> local policy decision. Some deployments may decide to automatically
> clean up the data plane state so it matches the control plane state,
> but others may choose to raise an alert to the management plane and
> leave the data plane untouched just in case it is in use.
>
> 2) Section 2.3 - the last sentence caused the confusion.
> Since the scenario described in section 2.3 is not very typical, and
> keeps causing confusion, so this section is removed.
> 3) Section 4.3 - use RFC2119 language for any required protocol
behavior.
>
>
> 4.3. Message Construction
>
> Data_Link Class is included in ConfirmDataChannelStatus and
> ConfirmDataChannelStatusAck messages, which is defined in section
13.12
> in [RFC4204].
>
> The status of the TE link end SHOULD be carried by the Data Channel
> Status subobject which is defined in section 4.2 of this
document. The
> new subobject SHOULD be part of Data_Link Class.
>
Why SHOULD vs MUST?
> In the case of SDH/SONET, DATA Channel ID in the new subobject
SHOULD be
> used to identify each timeslot of the data link.
>
> 4) At the end of section 5 - take the proposed text from Lou:
> ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable
> transmission mechanisms. If after the retry limit is reached, a
> ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack
> message is not received by the SENDER, the SENDER SHOULD
terminate the
> data channel confirmation procedure.
> Please let us know if you have more comments.
Once we have the revision with all discussed updates I'll let you know
if I think anything got missed/dropped.
Thanks,
Lou
> Thanks,
> Dan
additional comments on -04 rev:
Section 5 is still fairly weak on it usage of [RFC2119] conformance
language. I've made some suggestions below. Feel free to change the
directives listed below to whichever
key word you feel is appropriate.
> 5. Procedures
>
> The data channel status confirmation related LMP messages are sent
I think you mean "MAY be" rather than "are".
> between adjacent nodes periodically or driven by some events to
> confirm the channel status for the data links.
Is this timer triggered? If so, please state so. Is the sending of
ConfirmDataChannelStatus messages purely a local policy
matter/decision? If so, please state so. If the trigger is something
else, please say so.
> The procedure is
> described below:
>
> . The SENDER constructs a ConfirmDataChannelStatus message which
> contains one or more DATA_LINK objects. DATA_LINK object is
replace "contains" with "MUST contain".
> defined in [RFC4204]. Each DATA_LINK object contains one or more
replace "contains" with "MUST contain".
> Data Channel Status subobject. The Data Channel ID field in the
replace "subobject" with "subobjects".
> Data Channel Status subobject indicates which data channel needs
replace "indicates" with "MUST indicate"
> to be confirmed, and reports the data channel status at the
SENDER.
replace "reports" with "MUST report"
> The ConfirmDataChannelStatus message is sent to the RECEIVER.
>
> . The RECEIVER extracts the data channel statuses from the
replace "extracts" with "MUST extract"
> ConfirmDataChannelStatus message, and compares these with its data
replace "compares" with "SHOULD compare "
> channel statuses for the reported data channels. If a data channel
> status mismatch is found, the mismatch result SHOULD be reported
> to the management plane for further action. The RECEIVER also
> sends the ConfirmDataChannelStatusAck message which carries all
replace "sends" with "SHOULD send "
replace "carries" with "MUST carry"
> the local end statuses of the requested data channels to the
> SENDER.
>
> . If the RECEIVER is not able to support or to begin the
> confirmation procedure, the ConfirmDataChannelStatusNack message
> MUST be responded with the ERROR_CODE which indicates the reason
> of rejection.
>
> . The SENDER receives the response ConfirmDataChannelStatusAck
Insert "When" before "the SENDER".
> message, and compares the received data channel statuses at the
replace "compares" with "MUST compare"
> remote end with the data channel statuses at the local end. If a
> data channel status mismatch is found, the mismatch result SHOULD
> be reported to the management plane for further action.
>
Retransmission is now distributed over two places in this section.
Either combine or drop the following:
> . The ConfirmDataChannelStatus message SHOULD be resent, if the
> ConfirmDataChannelStatusNack message is received or no response
> message is received in the configured time by the SENDER.
(end drop)
>
> The data channel status mismatch issue identified by LMP may be
> automatically resolved by RSVP restart. For example, the restarting
> node may also have damaged its data plane. This leaves the data
> channels mismatched. But RSVP restart will re-install the data plane
> state in the restarting node. The issue may also be resolved via RSVP
> soft state timeout.
>
> If the ConfirmDataChannelStatus message is not recognized by the
> RECEIVER, the RECEIVER ignores this message, and will not send out an
> acknowledgment message to the SENDER.
Please provide a reference to where this behavior is define, e.g. "Per
[RFCxyz]".
>
> Due to message loss problem, the SENDER may not be able to receive
> the acknowledgment message.
>
The following is the second part of Retransmission in this section. As
mentioned above, either combine or drop previous text.
> ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable
> transmission mechanisms. If after the retry limit is reached, a
> ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack
> message is not received by the SENDER, the SENDER SHOULD terminate
> the data channel confirmation procedure.
That's it,
Lou