[mpls] [Technical Errata Reported] RFC3031 (5643)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 25 February 2019 01:23 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E0AFE130E86 for <mpls@ietfa.amsl.com>; Sun, 24 Feb 2019 17:23:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id R_0b_1alw0ZT for <mpls@ietfa.amsl.com>; Sun, 24 Feb 2019 17:23:30 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D7B12DD85 for <mpls@ietf.org>; Sun, 24 Feb 2019 17:23:29 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id C02BDB80458; Sun, 24 Feb 2019 17:23:11 -0800 (PST)
To: erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, loa@pi.nu, n.leymann@telekom.de
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: markzzzsmith@gmail.com, mpls@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20190225012311.C02BDB80458@rfc-editor.org>
Date: Sun, 24 Feb 2019 17:23:11 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/R8aa17K8MZiDlWVu2thIz71cviY>
Subject: [mpls] [Technical Errata Reported] RFC3031 (5643)
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: Mon, 25 Feb 2019 01:23:32 -0000

The following errata report has been submitted for RFC3031,
"Multiprotocol Label Switching Architecture".

You may review the report below and at:

Type: Technical
Reported by: Mark Smith <markzzzsmith@gmail.com>

Section: Terminology

Original Text

Corrected Text
label edge router - a router capable of accepting an unlabelled packet,
and through MPLS processing, may MPLS encapsulate the packet by adding
 a label stack. 

I am doing some MPLS review.

The book I'm using said an LER was an (RFC3031) MPLS edge node. I believed it was any router that could take unlabelled packets and label them, regardless of where the router was within the MPLS domain. (In other words, an MPLS router was not an LER if it would not MPLS label unlabelled packets and forward them.)

I decided to check RFC3031 for a definition, and discovered there isn't a definition at all for "label edge router", or a match on any text that matches "label edge" or "LER".

RFC6178 clarifies LER processing of IPv4 packets, and the general description of processing matches my understanding of what an LER is. 

However, it doesn't formally define an "label edge router" either, and I think an update to RFC3031 should be where "label edge router" is formally defined.

This erratum 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  
can log in to change the status and edit the report, if necessary. 

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