1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc7026.txt b/doc/rfc/rfc7026.txt
new file mode 100644
index 0000000..7d611bf
--- /dev/null
+++ b/doc/rfc/rfc7026.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Farrel
+Request for Comments: 7026                              Juniper Networks
+Updates: 5586                                                  S. Bryant
+Category: Standards Track                                  Cisco Systems
+ISSN: 2070-1721                                           September 2013
+
+
+            Retiring TLVs from the Associated Channel Header
+                 of the MPLS Generic Associated Channel
+
+Abstract
+
+   The MPLS Generic Associated Channel (G-ACh) is a generalization of
+   the applicability of the pseudowire (PW) Associated Channel Header
+   (ACH).  RFC 5586 defines the concept of TLV constructs that can be
+   carried in messages on the G-ACh by placing them in the ACH between
+   the fixed header fields and the G-ACh message.  These TLVs are called
+   ACH TLVs
+
+   No Associated Channel Type yet defined uses an ACH TLV.  Furthermore,
+   it is believed that handling TLVs in hardware introduces significant
+   problems to the fast path, and since G-ACh messages are intended to
+   be processed substantially in hardware, the use of ACH TLVs is
+   undesirable.
+
+   This document updates RFC 5586 by retiring ACH TLVs and removing the
+   associated registry.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by
+   the Internet Engineering Steering Group (IESG).  Further
+   information on Internet Standards is available in Section 2 of
+   RFC 5741.
+
+   Information about the current status of this document, any
+   errata, and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7026.
+
+
+
+
+
+
+
+
+
+Farrel & Bryant              Standards Track                    [Page 1]
+
+RFC 7026                    Retiring ACH TLVs             September 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+1.  Introduction and Scope
+
+   RFC 4385 [RFC4385] says that if the first nibble of a PW packet
+   carried over an MPLS network has a value of 1, then the packet starts
+   with a specific header format called the Pseudowire Associated
+   Channel Header (PWACH) or more generally known as the ACH.  This
+   mechanism creates an Associated Channel that is a message channel
+   associated with a specific pseudowire (PW).
+
+   The applicability of the ACH is generalized in RFC 5586 [RFC5586] to
+   define the MPLS Generic Associated Channel (G-ACh).  This creates a
+   common encapsulation header for control channel messages associated
+   with MPLS Sections, Label Switching Paths (LSPs), and PWs.
+
+   As part of making the ACH fully generic, RFC 5586 defines ACH TLV
+   constructs.  According to RFC 5586:
+
+     In some applications of the generalized associated control channel,
+     it is necessary to include one or more ACH TLVs to provide
+     additional context information to the G-ACh packet.
+
+   RFC 5586 goes on to say:
+
+     If the G-ACh message MAY be preceded by one or more ACH TLVs, then
+     this MUST be explicitly specified in the definition of an ACH
+     Channel Type.
+
+   However, at the time of writing, of the 18 ACH Channel Types defined,
+   none allows the use of ACH TLVs [IANA-ACH].  At the time of writing,
+   there are no unexpired Internet-Drafts that utilize ACH TLVs.
+
+
+
+
+
+
+Farrel & Bryant              Standards Track                    [Page 2]
+
+RFC 7026                    Retiring ACH TLVs             September 2013
+
+
+   Furthermore, G-ACh packets are intended to be substantially processed
+   in hardware; however, processing TLVs in hardware can be difficult
+   because of the unpredictable formats and lengths that they introduce
+   to the normal ACH format.
+
+   This document states that ACH TLVs, as specified in RFC 5586, are not
+   useful and might be harmful.  It updates RFC 5586 by deprecating the
+   ACH TLV and updating the associated IANA registries as described in
+   Section 4 of this document.  This document makes no comment about the
+   use of TLVs in other places.  In particular, proposals to use TLVs
+   within ACH messages or as an appendage to ACH messages, are not in
+   scope of this document.
+
+1.1.  Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Update to RFC 5586
+
+   Section 3 of RFC 5586 is deleted.
+
+   References to ACH TLVs in Section 4 of RFC 5586 should also be
+   disregarded.  Note that the text in Section 4 currently uses phrases
+   like "ACH TLV(s), if present" so, with the removal of Section 3 that
+   used to define ACH TLVs, they will not be present.
+
+3.  Implication for the ACH
+
+   A G-ACh message MUST NOT be preceded by an ACH TLV.
+
+4.  IANA Considerations
+
+   This document details two changes to the IANA registries.
+
+4.1.  Associated Channel Header TLV Registry
+
+   The "Pseudowire Name Spaces (PWE3)" registry has a subregistry called
+   the "Associated Channel Header TLV Registry".  IANA has entirely
+   deleted this subregistry but has left a tombstone record in the top-
+   level list of registries that says:
+
+     Associated Channel Header TLV Registry (DELETED)
+
+     Reference
+     [RFC5586] [RFC7026]
+
+
+
+
+Farrel & Bryant              Standards Track                    [Page 3]
+
+RFC 7026                    Retiring ACH TLVs             September 2013
+
+
+4.2.  Pseudowire Associated Channel Types Registry
+
+     The "Pseudowire Name Spaces (PWE3)" registry has a subregistry
+     called the "Pseudowire Associated Channel Types" registry.  This
+     subregistry previously included a column marked "TLV Follows".
+     IANA has entirely deleted this column leaving no record.
+
+5.  Manageability Considerations
+
+     This document will have no impact on network or device
+     manageability because there are no ACH Types that allow the use of
+     TLVs.  The document removes a feature that might have been used to
+     enhance management messages, and especially Operations, Management,
+     and Administration (OAM) messages.  However, given the considerable
+     experience in defining MPLS OAM messages in the last few years, it
+     would appear that this feature is not useful.
+
+     It is possible that packet sniffers that have already been
+     implemented will look for ACH TLVs.  The deletion of the construct
+     will not have a negative impact.
+
+6.  Security Considerations
+
+     Deleting the ACH TLV has a marginal positive effect on security
+     because it removes a feature that might have been used as an attack
+     vector to carry false information or to bloat G-ACh messages.
+
+     On the other hand, it had been suggested that the ACH TLV could
+     have been used to carry security parameters to secure the messages
+     on the G-ACh in a generic way.  However, no mechanisms have been
+     proposed at the time of writing, and it has generally been
+     considered that it is the responsibility of the specification that
+     defines G-ACh messages to consider the security requirements of
+     those messages that may be different for the different
+     applications.
+
+     Otherwise, this document has no implications for security.
+
+7.  Acknowledgements
+
+     Thanks to Eric Osborne, Thomas Morin, Lizhong Jin, Greg Mirsky, Jia
+     He, and Pearl Liang for suggestions to improve the text.
+
+
+
+
+
+
+
+
+
+Farrel & Bryant              Standards Track                    [Page 4]
+
+RFC 7026                    Retiring ACH TLVs             September 2013
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4385]   Bryant, S., Swallow, G., Martini, L., and D. McPherson,
+              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
+              Use over an MPLS PSN", RFC 4385, February 2006.
+
+   [RFC5586]   Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
+              "MPLS Generic Associated Channel", RFC 5586, June 2009.
+
+8.2.  Informative References
+
+   [IANA-ACH] "Pseudowire Associated Channel Types", IANA,
+              <http://www.iana.org/assignments/pwe3-parameters>
+
+Authors' Addresses
+
+   Adrian Farrel
+   Juniper Networks
+   EMail: adrian@olddog.co.uk
+
+   Stewart Bryant
+   Cisco Systems
+   EMail: stbryant@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrel & Bryant              Standards Track                    [Page 5]
+