RFC 5960, "MPLS Transport Profile Data Plane Architecture", August 2010

Note: This RFC has been updated by RFC 7274

Errata ID: 2533
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Italo Busi
Date Reported: 2010-09-29
Verifier Name: Adrian Farrel
Date Verified: 2010-11-10

Section 3.2 says:

   A section MUST provide a means of identifying the type of payload it
   carries.  If the section is a data-link, link-specific mechanisms
   such as a protocol type indication in the data-link header MAY be
   used.  If the section is an LSP, this information MAY be implied by
   the LSP label or, if the LSP payload is MPLS-labeled, by the setting
   of the S bit.  Additional labels MAY also be used if necessary to
   distinguish different payload types; see [RFC5921] for examples and
   further discussion.

It should say:

   A section MUST provide a means of identifying the type of payload it
   carries. This mechanism may be used to facilitate multiplexing MPLS
   with other protocols on the section if that function is supported by
   the section. Support or non-support of multiplexing on sections is
   out-of-scope for this document.

   If the section is a data-link, link-specific mechanisms
   such as a protocol type indication in the data-link header MAY be
   used.  If the section is an LSP, this information MAY be implied by
   the LSP label or, if the LSP payload is MPLS-labeled, by the setting
   of the S bit.  Additional labels MAY also be used if necessary to
   distinguish different payload types; see [RFC5921] for examples and
   further discussion.

Notes:

This change clarifies the requirement to support payload identification, the way it is used, and the use to which it is put. Furthermore, it clarifies the standing of protocol multiplexing onto underlying sections.

This issue was first raised in a liaison from the ITU-T
See https://datatracker.ietf.org/liaison/916/

Report New Errata