Lou,
Sorry, I didn't notice your comments in my previous mail.
1) We have accepted all your suggestions on [RFC2119] conformance issue,
especially for section 5 of this draft.
2) For retransmisstion issue, the following text is dropped:
> . 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.
3) For the behavior of ignoring the unknown message, RFC4204 doesn't
describe how to handle the unknown message. RFC3473 also doesn't discuss
this issue. But by default, we think it should be discarded silently.
Any other suggestion?
------
> 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]".
------
Please review the attached draft of the latest version.
Regards,
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:* Wednesday, May 20, 2009 11:38 PM
*Subject:* 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>
<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>
<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