Subject: [CCAMP] [resend] Summary of the changes on draft-ietf-ccamp-confirm-data-channel-status

From: Dan Li <[email-masked]>
Date: Tue, 30 Jun 2009 15:12:46 +0800

Hi All,

After the WG LC on draft-ietf-ccamp-confirm-data-channel-status-02.txt, we got many comments. With the discussion on the CCAMP mailing list, and also got lots of help from CCAMP co-chairs Lou and Deborah, we have addressed all the comments on this draft. The following is the summary about the changes between 05 version (latest version) and 02 version (WG LC version).

The latest version can be found at: http://tools.ietf.org/html/draft-ietf-ccamp-confirm-data-channel-status-05

- Section 1:
Added text to define the scope of use/applicability of this document.
OLD:
   This document defines simple additions to the Link Management 
   Protocol (LMP) [RFC4204] to provide a control plane tool that can 
   assist in the location of stranded resources by allowing adjacent 
   LSRs to confirm data channel statuses, and provides triggers for 
   notifying the management plane if any discrepancies are found. 
NEW:
   This document defines simple additions to the Link Management 
   Protocol (LMP) [RFC4204] to provide a control plane tool that can 
   assist in the location of stranded resources by allowing adjacent 
   LSRs to confirm data channel statuses, and provides triggers for 
   notifying the management plane if any discrepancies are found. As LMP 
   is already used to verify data plane connectivity, it is considered 
   to be an appropriate candidate to support this feature. 

- Section 2.2
Clarified the Soft state issue:
OLD:
   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 mechanisms allow LSRs to detect mismatched data plane 
   state after the expiry of the Recovery Timer. It is a local policy 
   decision how this mismatched state is handled. 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.
NEW:
   In [RFC2205] and [RFC3209], a soft state mechanism was defined to 
   prevent state discrepancies between LSRs. 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. 

- Removed Section 2.3 (Manual Change of the Cross-Connection State) in version 02.

- Section 2.4 in 02 version (section 2.3 in 05 version)
Editorial Change:
"From the upstream's point of view" 
         ^^^^^^^^^^upstream node's

- Section 3:
Editorial Change:
"The protocol extensions are intended..." Change to:
"The protocol extensions defined in this document are intended..."

- Section 4.1:
Clarifications:
OLD:
   Extensions to LMP to confirm a data channel status are described 
   below. In order to confirm a data channel status, the new LMP 
   messages are sent between adjacent nodes periodically or driven by 
   some event (such as an operator command, a configurable timer, or the 
   rejection of an LSP setup message because of an unavailable resource). 

   Three new messages are defined to check data channel status. Message 
   Type numbers are found in Section 7.1. 
NEW:
   Extensions to LMP to confirm a data channel status are described 
   below. In order to confirm a data channel status, the new LMP 
   messages are sent between adjacent nodes periodically or driven by 
   some event (such as an operator command, a configurable timer, or the 
   rejection of an LSP setup message because of an unavailable resource). 
   The new LMP messages run over the control channel, encapsulated in 
   UDP with an LMP port number and IP addressing as defined in Link 
   Management Protocol (LMP) [RFC4204]. 

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

   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 specified TE link, then the message 
   SHOULD be treated as being out-of-order. 

- Section 4.1.1
Editorial Change:
   "is found, this mismatch result SHOULD be reported to" change to: 
   "is found, this mismatch result is expected to be reported to"

- Section 4.1.2
Editorial Change:
   "status mismatch is found, the mismatch result SHOULD be reported to" change to:
   "status mismatch is found, the mismatch result is expected to be reported to"

- Section 4.2
Change the definition to cover when the channel / resource is unavailable due to being missing, removed, administratively off-line, failed scenarios.
OLD:
   0x0000 : The channel is available/free. 
   0x0001 : The channel is cross-connected/allocated. 
NEW:
   0x0000 : The channel is available/free. 
   0x0001 : The channel is unavailable/in-use. 

- Added new section 4.3 "Message Construction"

- Added new section 4.4 "Backward Compatibility"

- Section 5
Fixed the issue of "Section 5 is still fairly weak on it usage of [RFC2119] conformance language." 
1) "The data channel status confirmation related LMP messages are sent"
replace "are" with "MAY be"
2) "The SENDER constructs a ConfirmDataChannelStatus message which contains one or more DATA_LINK objects."
replace "contains" with "MUST contain"
3) "defined in [RFC4204]. Each DATA_LINK object contains one or more"
replace "contains" with "MUST contain"
4) "Data Channel Status subobject. The Data Channel ID field in the"
replace "subobject" with "subobjects"
5) "Data Channel Status subobject indicates which data channel needs"
replace "indicates" with "MUST indicate"
6) "to be confirmed, and reports the data channel status at the SENDER."
replace "reports" with "MUST report"
7) "The RECEIVER extracts the data channel statuses from the"
replace "extracts" with "MUST extract"
8) "ConfirmDataChannelStatus message, and compares these with its data"
replace "compares" with "SHOULD compare "
9) "The RECEIVER also sends the ConfirmDataChannelStatusAck message which carries all"
replace "sends" with "SHOULD send "
replace "carries" with "MUST carry"
10) "The SENDER receives the response ConfirmDataChannelStatusAck"
Insert "When" before "the SENDER"
11) "message, and compares the received data channel statuses at the"
replace "compares" with "MUST compare"

- Section 5
Added the following text to describe the re-transmission mechanism:
   Due to message loss problem, the SENDER may not be able to receive 
   the acknowledgment message. 

   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. 

- Section 9.2
Added two references: RFC 2205, RFC 2309.

- Section 11, 12, 13
Changed to new template of IETF draft.

Thanks,

Dan and co-authors