The IESG has approved the following document: - 'Data Channel Status Confirmation Extensions for the Link Management Protocol ' <draft-ietf-ccamp-confirm-data-channel-status-09.txt> as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-confirm-data-channel-status-09.txt Technical Summary This document defines an extention to the Link Management Protocol (LMP) 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. Working Group Summary This document received adequate attention and discussion in the working group in its early revisions. The document has been laregly stable for quite some time, mainly needing revisions as part of the publication process. Document Quality There have been no public statements related to intent to implement, but it is expected that some/all of the primary Authors plan to implement. Private comment to the AD reveal the existence of two implementations. Personnel Lou Berger (lberger@labn.net) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. RFC Editor Note Section 4.1.3 ADD to the end of the section The ERROR_CODE object in this message has a new Class Type (see Section 7.3), but is formed as the ERROR_CODE object defined in [RFC4204]. The following Error Codes are defined: 0x01 = Channel Status Confirmation Procedure not supported 0x02 = Unwilling to Confirm END --- Section 4.4 OLD Some nodes running in the network may only support the LMP Message Types, which are already defined in [RFC4204]. The three new types of LMP message defined in this document can not be recognized by these nodes. The unknown message behavior is not being specified in [RFC4204], it's suggested to discard the unknown message silently. The mechanism defined in this document presumes a certain non- standard behavior of existing/non-document supporting nodes. To use this mechanism all nodes MUST have the extensions described in this document for compatibility. NEW Some nodes running in the network might only support the LMP Message Types which are already defined in [RFC4204]. The three new types of LMP message defined in this document can not be recognized by these nodes. The behavior of an LMP node that receives an unknown message is not specified in [RFC4204] and will be clarified in a separate document. Since the behavior of legacy nodes must be assumed to be unknown, this document assumes that a deployment intended to support the function described in this document will consist completely of nodes that support the protocol extensions described in this document. In future, it may be the case that LMP will be extended to allow function-support to be detected. In that case, it may become possible to deploy this function in a mixed environment. END --- Section 5 s/local police/local policy/ --- Section 5 OLD 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. NEW 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 and SHOULD raise an alert to the management plane. END --- Section 6 OLD The operation of the procedures described in this document does not of themselves constitute a security risk since they do not cause any change in network state. It would be possible, if the messages were intercepted or spoofed to cause bogus alerts in the management plane and so the use of the LMP security measures are RECOMMENDED. NEW The operation of the procedures described in this document does not of themselves constitute a security risk since they do not cause any change in network state. It would be possible, if the messages were intercepted or spoofed to cause bogus alerts in the management plane and so the use of the LMP security measures described in [RFC4204] are RECOMMENDED. END --- NEW 7.3. NEW LMP Error_Code Class Type IANA maintains the "Link Management Protocol (LMP)" registry which has a subregistry called "LMP Object Class name space and Class type (C-Type)". This subregistry has an entry for the ERROR_CODE object. IANA is requested to allocate a new value for an ERROR_CODE class type as follows. C-Type Description Reference ------ ------------------------ --------- 4 ConfirmDataChannelStatusNack [This-ID] END _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
