MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, mpls mailing list <firstname.lastname@example.org>, mpls chair <email@example.com> Subject: Protocol Action: 'MPLS Generic Associated Channel (G-ACh) Advertisement Protocol' to Proposed Standard (draft-ietf-mpls-gach-adv-08.txt) The IESG has approved the following document: - 'MPLS Generic Associated Channel (G-ACh) Advertisement Protocol' (draft-ietf-mpls-gach-adv-08.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-gach-adv/
Technical Summary The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. Working Group Summary There is good support in the working group for this draft. There were no significant controversies in progression of the document. Last call comments were constructive technical comments and the document has been updated accordingly. . Document Quality: For this document we seem to have an chicken and egg problem. We know of intended implementations, it seems that since the implementation delta is rather small the implementers in this case has decided to wait for the allocation of the ACh code point before implementing. The document received extensive (agressive?) review from the responsible AD and has been updated to address all comments raised. Personnel: Loa Andersson (firstname.lastname@example.org) is the document shepherd. Adrian Farrel (email@example.com) is the responsible AD. RFC Editor Note Please update the 2119 boilerplate to include "NOT RECOMMENDED" --- Section 6.1: OLD: "the following values MAY supported" NEW: "the following values MAY be supported"