Subject: [mpls] [Technical Errata Reported] RFC6425 (3306)

From: RFC Errata System <[email-masked]>
Date: Wed, 1 Aug 2012 12:15:28 -0700 (PDT)

The following errata report has been submitted for RFC6425,
"Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6425&eid=3306

--------------------------------------
Type: Technical
Reported by: Mustapha Aissaoui <[email-masked]>

Section: 3.1.1

Original Text
-------------
3.1.1 Identifying a P2MP MPLS TE LSP

   [RFC4379] defines how an MPLS TE LSP under test may be identified in
   an echo request.  A Target FEC Stack TLV is used to carry either an
   RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV.

   In order to identify the P2MP MPLS TE LSP under test, the echo
   request message MUST carry a Target FEC Stack TLV, and this MUST
   carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4
   Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV.  These sub-TLVs
   carry fields from the RSVP-TE P2MP SESSION and SENDER_TEMPLATE
   objects [RFC4875] and so provide sufficient information to uniquely
   identify the LSP.

   The new sub-TLVs are assigned Sub-Type identifiers as follows, and
   are described in the following sections.

      Sub-Type #       Length              Value Field
      ----------       ------              -----------
              17         20                RSVP P2MP IPv4 Session
              18         56                RSVP P2MP IPv6 Session

Corrected Text
--------------
3.1.1. Identifying a P2MP MPLS TE LSP

   [RFC4379] defines how an MPLS TE LSP under test may be identified in
   an echo request.  A Target FEC Stack TLV is used to carry either an
   RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV.

   In order to identify the P2MP MPLS TE LSP under test, the echo
   request message MUST carry a Target FEC Stack TLV, and this MUST
   carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4
   Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV.  These sub-TLVs
   carry fields from the RSVP-TE P2MP SESSION and SENDER_TEMPLATE
   objects [RFC4875] and so provide sufficient information to uniquely
   identify the LSP.

   The new sub-TLVs are assigned Sub-Type identifiers as follows, and
   are described in the following sections.

      Sub-Type #       Length              Value Field
      ----------       ------              -----------
              17         20                RSVP P2MP IPv4 Session
              18         44                RSVP P2MP IPv6 Session

Notes
-----
Dear authors of RFC 6425,
I believe the length of the "RSVP P2MP IPv6 Session Sub-TLV" in Section 3.1.1 should be 44 bytes and not 56 bytes to match the format shown in Section 3.1.1.2. 

It may be the 56 byte figure was copied over from RFC 4379 which uses a 16-byte "IPv6 tunnel end point address" as the top field in the sub-TLV in the case of an IPv6 P2P RSVP session. With an IPv6 P2MP RSVP session that field is replaced with the P2MP-ID which is a 4-byte field only.

Mustapha.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6425 (draft-ietf-mpls-p2mp-lsp-ping-18)
--------------------------------------
Title               : Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping
Publication Date    : November 2011
Author(s)           : S. Saxena, Ed., G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, T. Nadeau
Category            : PROPOSED STANDARD
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG