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

From: RFC Errata System <[email-masked]>
Date: Wed, 3 Mar 2021 19:43:11 -0800 (PST)

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 <[email-masked]>

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

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 4 Mar 2021 12:15:55 +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 <[email-masked]> wrote:
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 4 Mar 2021 15:30:34 +0000

> On 4 Mar 2021, at 14:12, Duane Anderson <[email-masked]> wrote:
> 
> Stewart -
> 
> 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. 

That is interesting. I had feared the MPLS was getting to EoL. It is good to see it applied to new applications.

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

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. 

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
> 
> -----Original Message-----
> From: Stewart Bryant <[email-masked]> 
> Sent: March 4, 2021 7:16 AM
> To: RFC Errata System <[email-masked]>
> Cc: Stewart Bryant <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; DEBORAH A BRUNGARD <[email-masked]>; Alvaro Retana <[email-masked]>; Martin Vigoureux <[email-masked]>; loa Andersson <[email-masked]>; [email-masked]; Tarek Saad <[email-masked]>; Duane Anderson <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Re: [mpls] [Technical Errata Reported] RFC3031 (6450)
> 
>> 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
>> 
>> 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.
>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 4 Mar 2021 17:46:05 -0000

Hi,

I looked through this and reread 3031 (if may have been a few years).

While I can agree that there is "potential for confusion" in the use of "L2"
and "L3", I agree with Stewart that not many people have reported being
confused in the last 20 years (happy birthday, RFC 3031!).

Perhaps an easier fix (if a fix is needed at all - I don't believe it is) is
to remove the abbreviations "L2" and "L3". 

For "L2"
2.3 Remove L2
3.23 s/L2/layer 2/ twice

For "L3"
2.2 s/L3/layer 3/ three times
2.3 Remove L3
3.17 s/L3/layer 3/ 
4.15 s/L3/layer 3/
5.1.1.2 s/L3/layer 3/ twice
5.1.2.2 s/L3/layer 3/
5.1.3 s/L3/layer 3/
5.1.4 s/L3/layer 3/
5.1.4.2 s/L3/layer 3/
5.1.5 s/L3/layer 3/ four times
5.1.5.1 s/L3/layer 3/
5.2.2 s/L3/layer 3/

Maybe pop that list of changes in the report, mark it as Editorial, and move
on?

Cheers,
Adrian

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of RFC Errata System
Sent: 04 March 2021 03:43
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [mpls] [Technical Errata Reported] RFC3031 (6450)

Section: GLOBAL

Original Text
-------------

        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

        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

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

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 4 Mar 2021 21:46:21 +0000

Hi,

Thanks Duane for user feedback - much appreciated! As you know, those most familiar with a technology, often do not see the same as someone first-time reading. Usually we rely on our friendly ADs from other IETF Areas or expert RFC editors to do a final scrub during publication - and some are quite scrutinizing! I don't think this would have passed today's IESG😊

But as Stewart notes, given one does have the context of the sentences for the meaning, this is more editorial than technical.

The RFC viewing has much improved and we now can view with verified errata:
https://www.rfc-editor.org/rfc/inline-errata/rfc3031.html

I'd suggest, doing an editorial errata as Adrian suggests. If you are happy with his proposal - and the MPLS chairs agree - I can swap this over to an editorial and verify. As I'll be stepping down as AD next week, if can let me know in the next few days, I'll do immediately. If more time is needed, it will be for Martin to approve. Note - we have Adrian's list (thanks Adrian!) - if more are identified later - can always do another errata.

Duane - Ok? MPLS Chairs - Ok?

Deborah

-----Original Message-----
From: Adrian Farrel <[email-masked]> 
Sent: Thursday, March 4, 2021 12:46 PM
To: [email-masked]
Cc: [email-masked]; BRUNGARD, DEBORAH A <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] [Technical Errata Reported] RFC3031 (6450)

Hi,

For "L2"
2.3 Remove L2
3.23 s/L2/layer 2/ twice

For "L3"

Cheers,
Adrian

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of RFC Errata System
Sent: 04 March 2021 03:43
To: [email-masked]; [email-masked]; [email-masked];

--------------------------------------
You may review the report below and at:
https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6450__;!!BhdT!2-7fS0CMjWs9n-bXsviC8j9-l7nAesqsNNgwryAxWA5laUCob4MKYTYMnuK6s74$ 

Section: GLOBAL

Original Text
-------------

        L2              Layer 2
        L3              Layer 3

Corrected Text
--------------

Notes
-----

Instructions:
-------------

_______________________________________________
mpls mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!BhdT!2-7fS0CMjWs9n-bXsviC8j9-l7nAesqsNNgwryAxWA5laUCob4MKYTYMmj5Y50k$

---

From: Loa Andersson <[email-masked]>
Date: Sat, 6 Mar 2021 14:48:12 +0800

Deborah, ail,

In-line please. 

Sent from my iPad

> On 5 Mar 2021, at 05:47, BRUNGARD, DEBORAH A <[email-masked]> wrote:
> 
> Hi,
> 

I seriously doubt that this necessary. After all this is a question that we never once have had to answer, it seems that the context in every case is clear.

However, as an editorial errata to to be hold for a 3031bis, I guess it is harmless. 

/Loa

---

From: Tarek Saad <[email-masked]>
Date: Sun, 7 Mar 2021 01:14:20 +0000

Hi Deborah,

I also thank Duane for the feedback.
I think the changes suggested by Adrian (thanks to him) will be helpful to the reader, so I don't oppose to making them in an editorial errata.

Regards,
Tarek

On 3/4/21, 4:46 PM, "BRUNGARD, DEBORAH A" <[email-masked]> wrote:

    Hi,

    Deborah

    -----Original Message-----
    From: Adrian Farrel <[email-masked]>
    Sent: Thursday, March 4, 2021 12:46 PM
    To: [email-masked]
    Cc: [email-masked]; BRUNGARD, DEBORAH A <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
    Subject: RE: [mpls] [Technical Errata Reported] RFC3031 (6450)

    Hi,

    For "L2"
    2.3 Remove L2
    3.23 s/L2/layer 2/ twice

    For "L3"

    Cheers,
    Adrian

    -----Original Message-----
    From: mpls <[email-masked]> On Behalf Of RFC Errata System
    Sent: 04 March 2021 03:43
    To: [email-masked]; [email-masked]; [email-masked];
    [email-masked]; [email-masked]; [email-masked];
    [email-masked]; [email-masked]; [email-masked]
    Cc: [email-masked]; [email-masked]; [email-masked]
    Subject: [mpls] [Technical Errata Reported] RFC3031 (6450)

    Section: GLOBAL

    Original Text
    -------------

            L2              Layer 2
            L3              Layer 3

    Corrected Text
    --------------

    Notes
    -----

    Instructions:
    -------------

Juniper Business Use Only