Re: [mpls] [Technical Errata Reported] RFC3031 (5643)
"Andrew G. Malis" <agmalis@gmail.com> Mon, 25 February 2019 15:36 UTC
Return-Path: <agmalis@gmail.com>
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 71D98130EE3 for <mpls@ietfa.amsl.com>; Mon, 25 Feb 2019 07:36:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ky-dBwdeSUXz for <mpls@ietfa.amsl.com>; Mon, 25 Feb 2019 07:36:41 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37DDB1292F1 for <mpls@ietf.org>; Mon, 25 Feb 2019 07:36:41 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id j36so10921917qta.7 for <mpls@ietf.org>; Mon, 25 Feb 2019 07:36:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dHl5Q3N3VTt17UQz/AxLZab+J+z9u8+tXUZg79bYOhA=; b=r1wGm4oVr+Nc1cNCvzUlPKvRUgIcEnDv//UMaj2ArKbOzP1RiODnreE7pSfnuo8mg6 JDWGaAjk0b94qs3i8ouIsikHQNHWJuouY1c/k9A737ahlHbtwLvobMliU2iizlrSdBqU XrGYCLW2hB+ULVBht1lr64hH4K3ljbaonHI4+6D5JefJaRY7Nz/NRsITkV9B+VVTniFa QQVgqVM+gfmt03u+TBjZqLzXj+YBGYhrvII8/Mw0qDdoaT33DfXk7dWImJ3kVt+9Ei2Z gKwffOn/9ymJ5sII05HZiTSO1ST1UL8wsRXjx1tXyZ9gaFtItXsJr0pdGRQX17QlXp/p k/QQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dHl5Q3N3VTt17UQz/AxLZab+J+z9u8+tXUZg79bYOhA=; b=b48SNhxSxLOhWrI7aSFqvQUFO2TBJDDVbmAixYFNz/mP+uKyjPWdyVJVthW4+bu1Uz TbuTyXBuBTJO8IZzzd6t2sOMVDnKZnL0dSK/gzWpmrfcYqXtMRYMeYaUb6AkVnN5N5wd qPZaofwMoPR4gxjdavcYnUnpIYLZHfv6OXEbdPb9jC+Z2NOjQr+QAYPcUyIrru9H+Vxv q+VcDpIrsHScUUMjNjpmvqgH10eMXs9xtnZN5qrvKAt3IdVcRYqQTScRVhQnYfKRGE6+ N94f4qsYOwEHt1Z+7O+vfjnORcx540vdXKZxRDBMYIy5AxC+lWuyNxsP2nqTdZo5UcYt qTcg==
X-Gm-Message-State: AHQUAubDrkn0J2NOuoZs/pWyzPvnGEU06I4HLrqcJ1iw9d+ZccwL/5sA 5xCbl/FqFR1csSQ8vC1Y/wZQ5KnaidTGNda8DsA=
X-Google-Smtp-Source: AHgI3IbllZ1IcfKd5moO6lhhs5gTZBJSWuyejZ3AbkI0NDEQEaa6dSys1A2s8SVvHTUi7RkP55ZWpzmz8byw8lQHVck=
X-Received: by 2002:a0c:941b:: with SMTP id h27mr14114232qvh.8.1551109000146; Mon, 25 Feb 2019 07:36:40 -0800 (PST)
MIME-Version: 1.0
References: <20190225012311.C02BDB80458@rfc-editor.org>
In-Reply-To: <20190225012311.C02BDB80458@rfc-editor.org>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Mon, 25 Feb 2019 10:36:28 -0500
Message-ID: <CAA=duU0Y1uXk0Xej2ka8S3e1d6fh9AFdPRXqyjdgYJLE4mOoew@mail.gmail.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: erosen@cisco.com, arun@force10networks.com, Ross Callon <rcallon@juniper.net>, "BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com>, Alvaro Retana <aretana.ietf@gmail.com>, Martin Vigoureux <martin.vigoureux@nokia.com>, Loa Andersson <loa@pi.nu>, Nicolai Leymann <n.leymann@telekom.de>, mpls <mpls@ietf.org>, markzzzsmith@gmail.com
Content-Type: multipart/alternative; boundary="000000000000f634280582b9b455"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ZaCRde2uu6mYvmoiad83D1KP4rE>
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 15:36:43 -0000
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> 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> > > 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 > https://www.ietf.org/mailman/listinfo/mpls >
- [mpls] [Technical Errata Reported] RFC3031 (5643) RFC Errata System
- Re: [mpls] [Technical Errata Reported] RFC3031 (5… Andrew G. Malis
- Re: [mpls] [Technical Errata Reported] RFC3031 (5… Adrian Farrel
- Re: [mpls] [Technical Errata Reported] RFC3031 (5… Acee Lindem (acee)