[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
- [mpls] [Errata Held for Document Update] RFC3031 … RFC Errata System