From nobody Thu Mar 4 07:30:43 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 C1DF83A0D81 for ; Thu, 4 Mar 2021 07:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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_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 qnj-fRmxBfX2 for ; Thu, 4 Mar 2021 07:30:40 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 6FD033A0D7E for ; Thu, 4 Mar 2021 07:30:40 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id w203-20020a1c49d40000b029010c706d0642so4700563wma.0 for ; Thu, 04 Mar 2021 07:30:40 -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=joeyEplJijibe6E64GpaB5oKt6I9IXqPJmcLoov8flc=; b=tM2tdKsHtG107FrG9y3D+E6ezEVCy4O98KDNwmOhcmps4eA0w7bHGe21Sm82UA9HuQ 3LlT8HzJQ+C2NCWlSXn0Unq+PZp4dluK0umkbQ5Dl3fi4uAjbhPY2mitynazhlP2KgTK BQ5EAC2tfaBpDAX0cWT1A1fRjMRxq0DN4RvPcBXNlpFj9NL/RM7b6vgNexbLevaUjDOQ fEKTl7O6yB/+drJWEJlx3f49gJLZgMaakrVtEIHJBlYttb5eB7VLIpqeEkiMKlFW+GPi ioxOii9AdP0e2pdqqkhfy9FS8Gs6EDxK2lToXu6ypibbSbkccMUek0WOoJlLdn/1TT8h QLYA== 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=joeyEplJijibe6E64GpaB5oKt6I9IXqPJmcLoov8flc=; b=cNMQ7afBjn1WXtWhoI9K2KhlVgwAJGf4nsRsIS5SQiDykEziCnux6UFp1dSeXRhvs/ TEDY3/qjtX+r12xVmyoTKwXvZwnEFl0Bb2YNonBc23xkIqUSbviWYjMRhLcfuI7M34hn aair/VUKT7SZw0oW0tRlg6ooh9KaywVdMobvYUtsPfXpV3M/dxcaT3KQMsx5T+LvfP7C HOBWNlX0JFm5eZcSUtApno8qXUrrCI8bYDa/J9DdUYLfA0VTTmPvMq5GFsx/eRwqkjFB aFin1pj+nvMqzx+Y5+KXoTgt+SDC+JojRGrtCPwGYxIob+oazqigBu+m1WD8RYXTOO4J wrbg== X-Gm-Message-State: AOAM532UECSSuMyrWXejwvbFfzwzsefHT09QJdosBQjmPwKjnxP+F6Cq 0CLr055jBDSzUowc52aYAwU= X-Google-Smtp-Source: ABdhPJyZyYzAUkJZobrzoQa/tyk/jLPel0u6CBg0X2Xjv0WBAHP+rLE4G7cmHQAFE1UrM7CSjE9FyQ== X-Received: by 2002:a7b:cb99:: with SMTP id m25mr4603020wmi.64.1614871837858; Thu, 04 Mar 2021 07:30:37 -0800 (PST) Received: from [192.168.8.125] ([185.69.145.253]) by smtp.gmail.com with ESMTPSA id i11sm16574648wro.53.2021.03.04.07.30.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Mar 2021 07:30:37 -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 X-Priority: 1 In-Reply-To: Date: Thu, 4 Mar 2021 15:30:34 +0000 Cc: Stewart Bryant , RFC Errata System , "erosen@cisco.com" , "arun@force10networks.com" , "rcallon@juniper.net" , DEBORAH A BRUNGARD , Alvaro Retana , Martin Vigoureux , loa Andersson , "n.leymann@telekom.de" , Tarek Saad , "mpls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <255777D3-B604-43FA-B76E-23BCE5F1F0A5@gmail.com> References: <20210304034311.3F0F2F4075A@rfc-editor.org> <9249AB80-A3E8-49B2-B68D-967B2FDCA651@gmail.com> To: Duane Anderson X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [mpls] [EXTERNAL] [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 15:30:43 -0000 > On 4 Mar 2021, at 14:12, Duane Anderson wrote: >=20 > Stewart - >=20 > I work in the military/aerospace sector. I know for a fact that MPLS = likely will be implemented into new component designs by any number of = manufacturers of safety-critical systems (e.g., aircraft, spacecraft, = automobiles, trains, etc.). This will go on for years to come.=20 That is interesting. I had feared the MPLS was getting to EoL. It is = good to see it applied to new applications. >=20 > I have no doubt that there is little perceived implementation = difficulty. However, given the magnitude of the errata in RFC3031, I = think there's a existence proof that statistically someday, sometime in = the future, people will be hurt and likely will die.=20 >=20 An existence proof would require that someone had already been hurt not = a statistical possibility that it might happen at some time in the = future. In any case MPLS is so simple in the data plane that any competent = tester should be able to force a new implantation to experience all the = corner cases.=20 What is more likely to happen is an MPLS application error, or a = hardware error, than a misunderstanding of the MPLS data plane itself. - Stewart > - Duane >=20 > -----Original Message----- > From: Stewart Bryant =20 > Sent: March 4, 2021 7:16 AM > To: RFC Errata System > 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 = ; mpls@ietf.org > Subject: [EXTERNAL] Re: [mpls] [Technical Errata Reported] RFC3031 = (6450) >=20 > I think that there is an existence proof that this is not causing = implementation difficulty. >=20 > - Stewart >=20 >=20 >> On 4 Mar 2021, at 03:43, RFC Errata System = wrote: >>=20 >> The following errata report has been submitted for RFC3031,=20 >> "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 >> 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.=20= >> Label Assignment and Distribution, 3.5. Attributes of a Label = Binding,=20 >> 3.14. Scope and Uniqueness of Labels, 4.1.2.2. Distributing Labels,=20= >> 5.1.5. Upstream LSR: labelUse Procedure, 5.1.5.2.=20 >> UseIfLoopNotDetected, 5.1.6. Downstream LSR: Withdraw Procedure >>=20 >> * L is used as a name for a certain label attached to packet, and >>=20 >> * L is used as a arbitrary value assigned to a label attached to a=20 >> 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=20= >> use "Reply All" to discuss whether it should be verified or rejected.=20= >> When a decision is reached, the verifying party can log in to change=20= >> the status and edit the report, if necessary. >>=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