From nobody Thu Mar 4 04:16:03 2021 Return-Path: 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 ; 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 ; 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 ; Thu, 4 Mar 2021 04:16:00 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id l12so27391004wry.2 for ; 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 In-Reply-To: <20210304034311.3F0F2F4075A@rfc-editor.org> Date: Thu, 4 Mar 2021 12:15:55 +0000 Cc: Stewart Bryant , erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net, DEBORAH A BRUNGARD , Alvaro Retana , Martin Vigoureux , loa Andersson , n.leymann@telekom.de, Tarek Saad , "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 X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = wrote: >=20 > The following errata report has been submitted for RFC3031, > "Multiprotocol Label Switching Architecture". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6450 >=20 > -------------------------------------- > Type: Technical > Reported by: Duane L. Anderson >=20 > Section: GLOBAL >=20 > Original Text > ------------- > 2.2. Terminology defines the terms >=20 > Layer 2 layer 2 the protocol layer under layer 3=20 > (which therefore offers the services used by = layer 3) > Layer 3 the protocol layer at which IP and its = associated=20 > routing protocols operate >=20 > 2.3. Acronyms and Abbreviations defines=20 >=20 > L2 Layer 2 > L3 Layer 3 >=20 > 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.=20 >=20 > 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.=20 >=20 > 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).=20 >=20 > 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.=20 >=20 > 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 >=20 > * L is used as a name for a certain label attached to packet, and=20 >=20 > * L is used as a arbitrary value assigned to a label attached to a = packet >=20 >=20 > 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.=20 >=20 > 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.=20 >=20 > 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.=20 >=20 > 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.=20 >=20 > 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.=20 >=20 > 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. >=20 > 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 =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > 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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls