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

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 25 February 2019 17:56 UTC

Return-Path: <adrian@olddog.co.uk>
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 B8603126D00 for <mpls@ietfa.amsl.com>; Mon, 25 Feb 2019 09:56:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 tmtwpPjWWisB for <mpls@ietfa.amsl.com>; Mon, 25 Feb 2019 09:56:02 -0800 (PST)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07DE130F96 for <mpls@ietf.org>; Mon, 25 Feb 2019 09:56:01 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1PHto2j022232; Mon, 25 Feb 2019 17:55:53 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CD58022044; Mon, 25 Feb 2019 17:55:52 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id B613922042; Mon, 25 Feb 2019 17:55:52 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1PHtp0d003532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Feb 2019 17:55:51 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Andrew G. Malis'" <agmalis@gmail.com>, 'RFC Errata System' <rfc-editor@rfc-editor.org>
Cc: 'mpls' <mpls@ietf.org>, markzzzsmith@gmail.com, arun@force10networks.com, 'Ross Callon' <rcallon@juniper.net>, erosen@cisco.com
References: <20190225012311.C02BDB80458@rfc-editor.org> <CAA=duU0Y1uXk0Xej2ka8S3e1d6fh9AFdPRXqyjdgYJLE4mOoew@mail.gmail.com>
In-Reply-To: <CAA=duU0Y1uXk0Xej2ka8S3e1d6fh9AFdPRXqyjdgYJLE4mOoew@mail.gmail.com>
Date: Mon, 25 Feb 2019 17:55:49 -0000
Organization: Old Dog Consulting
Message-ID: <020f01d4cd33$57e13470$07a39d50$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0210_01D4CD33.57E2BB10"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEhmuGpLwxAuTsvFpwZfJXMqOlcDwHWOqFQp0h7GBA=
Content-Language: en-gb
X-Originating-IP: 87.112.237.8
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24456.002
X-TM-AS-Result: No--27.080-10.0-31-10
X-imss-scan-details: No--27.080-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24456.002
X-TMASE-Result: 10--27.079900-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbAArNgt5xpQYIM86Aeo6sYK0Vg+MnSE2GHLu 5dsUmK54ax3Gn44CHApd9WOUcyJ+BKWS/mt9cqrN+z2c4lioPkjFphRdtkn03tilG/maIsZ8YWz +8oXB3KiKQdNLgz0V0r0FsRP+GUXHDpfVsOpEdC8WFB9s82eM27pAJMK7N+JV6h3Xfd5VY/iRGr Qa6VK6LJ/Xz1rC/1g0Tl3cIax9cddByHwYgfuI7umc4/pDEQa2+LidURF+DB2F9m5c2eWD4hJKw XL95d7NYbF7D4Z95WIuj7zbOSWeyTY3tG8cxfkUbMGKOuLn5FWZf5btvM85AfnquioS346p4a8t jcE0lxyYsJvvZx/u9SbtuknoGANV3MzeZlPGOReDaBf8SaPLVFsChor7BLiNlRDMdYEo4UAsX2N vG8rX7RFutGs1bX9ftNB04F+WSPeWHmpvkeKJB82MVs2Rn85UIaLR+2xKRDKY5NBG7YIbVxZMwf jbmc4IVSSiiqZH3chOGs1GGHkHWxPoX8jcWGowkRs1fAcYNHGusS9CiBzL8cnaL1ri/ilXxH1I9 BWhJiA5qDlhAYEFL0mlX2scVfePNuVzoZ6LieX1NV6ZtjddkvwGVtfL479aOoj9DXM40dJb6/Sb nJwGr85B/9LVe+0QGbbQdh/kTL8JG55i6ynXHGOILin78AgWMx981lgKTcNnnK6mXN72m2pHKtk QBynKSQBM7HWranVv16+wngHBFJ9FKCGd++IX2x/FmlC/aoz8Xh935PYSDpd9j+WYn72Gr3Ag3z t3L17dztJjx5lKLsLJ8QWL9W0TGvPKMMIuf6+eAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyKbBVa1r lvjN4QViJlGwPJ1GMBesO78OvHuuFzxTdbEKEZHDD/mqpRC9ahCoy1rFy+uOf62jzUDeg==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/iFRolxM_gKN8bS_JxmGKpyBCAVw>
Subject: Re: [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 17:56:05 -0000

3031 does define “MPLS edge node”, “MPLS egress node”, and “MPLS ingress node”. Of course, it also defines “LSR”.

 

As Andy says, the first mention of LER is in 3811 and it looks like the terminology was produced to solidify the definitions in 3031.

 

I don’t think it is an “error” in 3031 that it doesn’t define LER. Sure, it would be nice to have all the definitions in one place, but adding stuff to documents isn’t what Errata Reports are supposed to be for.

 

Adrian

 

 

 

From: mpls <mpls-bounces@ietf.org> On Behalf Of Andrew G. Malis
Sent: 25 February 2019 15:36
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: mpls <mpls@ietf.org>; markzzzsmith@gmail.com; arun@force10networks.com; Ross Callon <rcallon@juniper.net>; erosen@cisco.com
Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (5643)

 

The submitter does make a good point, LER should probably be defined in the MPLS architecture. I just did a search and the earliest mention of "Label Edge Router" that I could find is in RFC 3811. 

 

That said, I think I prefer the definition text from RFC 4221:

   An LER is an LSR placed at the edge of an MPLS domain, and it passes
   traffic into and out of the MPLS domain.  An ingress LER is
   responsible for classifying data and assigning it to a suitable LSP
   or tunnel.
 
   This classification is done using Forwarding Equivalence Classes
   (FECs) that define the common attributes of data (usually packets)
   that will be treated in the same way.  Once data has been classified,
   it can be handed off to an LSP or tunnel through the Next Hop Label
   Forwarding Entry (NHLFE).

Cheers,

Andy

 

 

On Sun, Feb 24, 2019 at 8:23 PM RFC Errata System <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org> > wrote:

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

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

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

Section: Terminology

Original Text
-------------
<missing>

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. 

Notes
-----
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.

Instructions:
-------------
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

_______________________________________________
mpls mailing list
mpls@ietf.org <mailto:mpls@ietf.org> 
https://www.ietf.org/mailman/listinfo/mpls