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

Stewart Bryant <stewart.bryant@gmail.com> Thu, 04 March 2021 12:16 UTC

Return-Path: <stewart.bryant@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 7187D3A1A10 for <mpls@ietfa.amsl.com>; Thu, 4 Mar 2021 04:16:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level:
X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ajXANOtHRQX4 for <mpls@ietfa.amsl.com>; Thu, 4 Mar 2021 04:16:01 -0800 (PST)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 AB7363A1A0E for <mpls@ietf.org>; Thu, 4 Mar 2021 04:16:00 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id l12so27391004wry.2 for <mpls@ietf.org>; Thu, 04 Mar 2021 04:16:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1/RZJJgZs25xVQGjQZ+ptFZ38iNDsbH5VmRpGBF37jo=; b=JYYxuLOHLzr7BZMP9/jmv1La9DdJqyUGK/HF2tAGhrOVWic8Ck5gpiXswr2Kh9p7jt ifGtyfZmoTR2xBHDg5MpBzwhgrCeh7gzCUp/pO2H4/Y39FnaOq3vDARx1fNOWSvV1KHv yTBfoBKK93M2hKAyERavQI/JCUr+CACbWivom/jAyolSkBRRdCH2VTkV6nCicWx4bbxm en16BbCgvqyEC7qk+/QuwSuKvgH5kFxCrSXDESyvUZLZIztNQKZNd9jLKPB5sVFxKnkN 1Medgga9VW4DXPolmfoPxfkr/1OpnAstFw0NJK0f0FdG3Zff8z+T8NubQBJg+KNJ/X8Y 99qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1/RZJJgZs25xVQGjQZ+ptFZ38iNDsbH5VmRpGBF37jo=; b=An2JvBA0nILpQySdE/eEcx5TsvYRmPaWWrp3PqrPyY+88UtsvztC5xMoYdd/Uhs0YW ZyQ+pEXascXuWN2TlCgcuc6My7gXl+OZHCTEDeU4Bh5JepTdzdqOh78x8VFFi/xkTvay HC9zepxqc/D7tQcQGdjnKC3k5A+ciJDZHxpF8RfNYJA3oapbiRPdoucrIV1pla3u+E1t QkWYHcXxbT6gNNpexWBmm7s6HvSvK+ODnPcF6Thm8QyTrm+XHkaHjMMHNcG5yNIVPPiO hRx4uwLFDcfx/G6PYBCuxXAuN3L9+59kcdZICot15gH6OfsJVfSTAPeZzcc8BbfaKbJU csKA==
X-Gm-Message-State: AOAM531f/tA0vJ/L2jpRoTM2PmlZ9+79uJrWxn6kLKSbHgitEZLydMJt 22j15FcFEQTeKB/JwDnlwiY=
X-Google-Smtp-Source: ABdhPJyFE3pZaQfDNPQyn100oGC+0nBBbSBP+jolAr8PR9XctXfVLNFEY9JlP5D1+lWpcgrQgr4RGg==
X-Received: by 2002:adf:ebcb:: with SMTP id v11mr3646700wrn.231.1614860157519; Thu, 04 Mar 2021 04:15:57 -0800 (PST)
Received: from [192.168.8.125] ([185.69.145.253]) by smtp.gmail.com with ESMTPSA id b15sm12000413wmd.41.2021.03.04.04.15.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Mar 2021 04:15:57 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <20210304034311.3F0F2F4075A@rfc-editor.org>
Date: Thu, 04 Mar 2021 12:15:55 +0000
Cc: Stewart Bryant <stewart.bryant@gmail.com>, erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net, DEBORAH A BRUNGARD <db3546@att.com>, Alvaro Retana <aretana.ietf@gmail.com>, Martin Vigoureux <martin.vigoureux@nokia.com>, loa Andersson <loa@pi.nu>, n.leymann@telekom.de, Tarek Saad <tsaad.net@gmail.com>, "Duane.Anderson@edgewater.ca" <Duane.Anderson@Edgewater.CA>, mpls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9249AB80-A3E8-49B2-B68D-967B2FDCA651@gmail.com>
References: <20210304034311.3F0F2F4075A@rfc-editor.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/kOR9ji6dQQtAHPJcCKYcDq41XT8>
Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (6450)
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: Thu, 04 Mar 2021 12:16:02 -0000

I think that there is an existence proof that this is not causing implementation difficulty.

- Stewart


> On 4 Mar 2021, at 03:43, 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:
> https://www.rfc-editor.org/errata/eid6450
> 
> --------------------------------------
> Type: Technical
> Reported by: Duane L. Anderson <Duane.Anderson@Edgewater.CA>
> 
> Section: GLOBAL
> 
> Original Text
> -------------
> 2.2. Terminology defines the terms
> 
>        Layer 2         layer 2 the protocol layer under layer 3 
>                        (which therefore offers the services used by layer 3)
>        Layer 3         the protocol layer at which IP and its associated 
>                        routing protocols operate
> 
> 2.3. Acronyms and Abbreviations defines 
> 
>        L2              Layer 2
>        L3              Layer 3
> 
> However, in 3.14. Scope and Uniqueness of Labels, 4.3. Label Stacks and Implicit Peering, 4.5. LSP Trees as Multipoint-to-Point Entities, and 4.6. LSP Tunneling between BGP Border Routers, L1, L2 and L3 are used as differentiating names for certain labels attached to packets. 
> 
> Of course, in 3.23. Time-to-Live (TTL), L2 is used to refer to layer 2 frame header and to a layer 2 switch, which is correct. 
> 
> However, in 4.3. Label Stacks and Implicit Peering, the term level 1 is used to refer to the LIFO (stack) ordinal number of a label then named L1 and given a protocol layer 2 protocol of layer 2 (L2). Furthermore, labels named L2 and then L1 are pushed onto the stack of labels prefixed to the packet. To top it all off the packet's stack attribute as protocol level 2 (L2). 
> 
> Of course, in 3.17. LSP Next Hop, 4.1.5. The Implicit NULL Label, 5.1.1.2. PushConditional, 5.1.1.4. PulledConditional, 5.1.2.2. RequestWhenNeeded, 5.1.3. Upstream LSR: NotAvailable Procedure, 5.1.4. Upstream LSR: Release Procedure, 5.1.4.2. NoReleaseOnChange, 5.1.5. Upstream LSR: labelUse Procedure, 5.2.2. Schemes for LSRs that do not Support Label Merging, refer to L3 meaning level 3, which is correct. 
> 
> Furthermore, in 3.1. Labels, 3.2. Upstream and Downstream LSRs, 3.4. Label Assignment and Distribution, 3.5. Attributes of a Label Binding, 3.14. Scope and Uniqueness of Labels, 4.1.2.2. Distributing Labels, 5.1.5. Upstream LSR: labelUse Procedure, 5.1.5.2. UseIfLoopNotDetected, 5.1.6. Downstream LSR: Withdraw Procedure
> 
> * L is used as a name for a certain label attached to packet, and 
> 
> * L is used as a arbitrary value assigned to a label attached to a packet
> 
> 
> Corrected Text
> --------------
> I have not provided any corrected text as I've literally "highlighted" 44 places in a pdf format file of RFC 3031 that are ambiguous. 
> 
> As there is no facility to attach a file to this Report Errata for RFC3031 form, i will send the file commented pdf file upon request. 
> 
> Notes
> -----
> My rational for highlighting (no pun intended) these problems is that the overloading of the L2, L3 abbreviations layer 2 and layer 3, with the names L1, L2, L3 and L for labels, plus the use of L1 and L2 as indexed names for the ordinal position of a label prefixed to a payload, then to use L2 and L3 as to actually mean layer 2 and layer is uh ... sloppy. 
> 
> Honestly, I can't understand how RFC 3031 has been posted for twenty years and that it is on the Standards Track and no one has found these problems. 
> 
> Its similar to when someone publishes a mathematical treatise and use the same set of variable names {x, y, z, t} over and over again in different contexts spread throughout the paper. Its intractable and practically gibberish. 
> 
> I apologize if my criticism is harsh regarding this problem but I spent a considerable amount of my time reading this document trying to make sense of it before I realized that the fault is not mine but it is of the document.
> 
> 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