[mpls] [Errata Held for Document Update] RFC3031 (6240)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 26 February 2021 21:59 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DA83A0C62; Fri, 26 Feb 2021 13:59:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAqDsp6M7kjC; Fri, 26 Feb 2021 13:59:25 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02BC13A0C3D; Fri, 26 Feb 2021 13:59:24 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 96F04F40755; Fri, 26 Feb 2021 13:59:13 -0800 (PST)
To: jsharma@ciena.com, erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: db3546@att.com, iesg@ietf.org, mpls@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20210226215913.96F04F40755@rfc-editor.org>
Date: Fri, 26 Feb 2021 13:59:13 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/AxaLWwYnBBOWstJcj4C_Od78PTw>
Subject: [mpls] [Errata Held for Document Update] RFC3031 (6240)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2021 21:59:27 -0000

The following errata report has been held for document update 
for RFC3031, "Multiprotocol Label Switching Architecture". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6240

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Jitendra Kumar Sharma <jsharma@ciena.com>
Date Reported: 2020-07-27
Held by: Deborah Brungard (IESG)

Section: 3.10

Original Text
-------------
3.10. The Next Hop Label Forwarding Entry (NHLFE)

   The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding
   a labeled packet.  It contains the following information:

   1. the packet's next hop

   2. the operation to perform on the packet's label stack; this is one
      of the following operations:

      a) replace the label at the top of the label stack with a
         specified new label

      b) pop the label stack

      c) replace the label at the top of the label stack with a
         specified new label, and then push one or more specified new
         labels onto the label stack.

   It may also contain:

      d) the data link encapsulation to use when transmitting the packet

      e) the way to encode the label stack when transmitting the packet

      f) any other information needed in order to properly dispose of
         the packet.

   Note that at a given LSR, the packet's "next hop" might be that LSR
   itself.  In this case, the LSR would need to pop the top level label,
   and then "forward" the resulting packet to itself.  It would then
   make another forwarding decision, based on what remains after the
   label stacked is popped.  This may still be a labeled packet, or it
   may be the native IP packet.

   This implies that in some cases the LSR may need to operate on the IP
   header in order to forward the packet.

   If the packet's "next hop" is the current LSR, then the label stack
   operation MUST be to "pop the stack".

Corrected Text
--------------
3.10. The Next Hop Label Forwarding Entry (NHLFE)

   The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding
   a labeled packet on an LSR or an unlabeled packet on an Ingress MPLS router. It 
   contains the following information:

   1. the packet's next hop

   2. the operation to perform on the packet's label stack; this is one
      of the following operations:

      a) replace the label at the top of the label stack with a
         specified new label

      b) pop the label stack

      c) replace the label at the top of the label stack with a
         specified new label, and then push one or more specified new
         labels onto the label stack.

      d) push a new label on an unlabeled packet


   It may also contain:

      e) the data link encapsulation to use when transmitting the packet

      f) the way to encode the label stack when transmitting the packet

      g) any other information needed in order to properly dispose of
         the packet.

   Note that at a given LSR, the packet's "next hop" might be that LSR
   itself.  In this case, the LSR would need to pop the top level label,
   and then "forward" the resulting packet to itself.  It would then
   make another forwarding decision, based on what remains after the
   label stacked is popped.  This may still be a labeled packet, or it
   may be the native IP packet.

   This implies that in some cases the LSR may need to operate on the IP
   header in order to forward the packet.

   If the packet's "next hop" is the current LSR, then the label stack
   operation MUST be to "pop the stack".

Notes
-----
Section 3.10 defines NHLFE, and it sounds from the definition that this piece of information is used by an MPLS router only when packet is already labeled. Now, when section 3.12 (FTN) defines the relationship between FEC and NHLFE, the definition of NHLFE in section 3.10 does not align with FTN definition.

--------------------------------------
RFC3031 (draft-ietf-mpls-arch-06)
--------------------------------------
Title               : Multiprotocol Label Switching Architecture
Publication Date    : January 2001
Author(s)           : E. Rosen, A. Viswanathan, R. Callon
Category            : PROPOSED STANDARD
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG