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

From: RFC Errata System <[email-masked]>
Date: Mon, 27 Jul 2020 03:52:10 -0700 (PDT)

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/eid6240

--------------------------------------
Type: Technical
Reported by: Jitendra Kumar Sharma <[email-masked]>

Section: 3.10

Original Text
-------------
3.10. The Next Hop Label Forwarding Entry (NHLFE)

   The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding
   a labeled packet.  It contains the following information:

   1. the packet's next hop

   2. the operation to perform on the packet's label stack; this is one
      of the following operations:

      a) replace the label at the top of the label stack with a
         specified new label

      b) pop the label stack

      c) replace the label at the top of the label stack with a
         specified new label, and then push one or more specified new
         labels onto the label stack.

   It may also contain:

      d) the data link encapsulation to use when transmitting the packet

      e) the way to encode the label stack when transmitting the packet

      f) any other information needed in order to properly dispose of
         the packet.

   Note that at a given LSR, the packet's "next hop" might be that LSR
   itself.  In this case, the LSR would need to pop the top level label,
   and then "forward" the resulting packet to itself.  It would then
   make another forwarding decision, based on what remains after the
   label stacked is popped.  This may still be a labeled packet, or it
   may be the native IP packet.

   This implies that in some cases the LSR may need to operate on the IP
   header in order to forward the packet.

   If the packet's "next hop" is the current LSR, then the label stack
   operation MUST be to "pop the stack".

Corrected Text
--------------
3.10. The Next Hop Label Forwarding Entry (NHLFE)

   The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding
   a labeled packet on an LSR or an unlabeled packet on an Ingress MPLS router. It 
   contains the following information:

   1. the packet's next hop

   2. the operation to perform on the packet's label stack; this is one
      of the following operations:

      a) replace the label at the top of the label stack with a
         specified new label

      b) pop the label stack

      c) replace the label at the top of the label stack with a
         specified new label, and then push one or more specified new
         labels onto the label stack.

      d) push a new label on an unlabeled packet

   It may also contain:

      e) the data link encapsulation to use when transmitting the packet

      f) the way to encode the label stack when transmitting the packet

      g) any other information needed in order to properly dispose of
         the packet.

   Note that at a given LSR, the packet's "next hop" might be that LSR
   itself.  In this case, the LSR would need to pop the top level label,
   and then "forward" the resulting packet to itself.  It would then
   make another forwarding decision, based on what remains after the
   label stacked is popped.  This may still be a labeled packet, or it
   may be the native IP packet.

   This implies that in some cases the LSR may need to operate on the IP
   header in order to forward the packet.

   If the packet's "next hop" is the current LSR, then the label stack
   operation MUST be to "pop the stack".

Notes
-----
Section 3.10 defines NHLFE, and it sounds from the definition that this piece of information is used by an MPLS router only when packet is already labeled. Now, when section 3.12 (FTN) defines the relationship between FEC and NHLFE, the definition of NHLFE in section 3.10 does not align with FTN definition.

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: Tue, 28 Jul 2020 09:02:49 +0100

As the reporter notes, RFC3031 does not provide a complete description of the procedure to use when labelling an unlabelled  packet at ingress.

However, as far as I am aware this has not caused any interoperability issues in the 20 years since its publication.

In any case the text      "d) push a new label on an unlabeled packet” should be      "d) push a first label on an unlabeled packet”

In both the old and new text 

> This may still be a labeled packet, or it

Whilst technically correct through the use of “may” does not tell the full story since the remnant may be a PW packet and we did not update RFC3031 when we published the PW series.

We could safety accept the errata, but I am worried that it is only part of the set of changes needed to cover the case.

In many ways, given the existence proof that people are able to correctly implement MPLS I am inclined to leave the document alone and note this for consideration during an update.

Stewart 

> On 27 Jul 2020, at 11:52, RFC Errata System <[email-masked]> wrote:
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Tarek Saad <[email-masked]>
Date: Thu, 30 Jul 2020 16:58:09 +0000

I see the forwarding of "unlabeled packets" is discussed in RFC3031 in context of the FTN. For example, in Section 3.13:
"
   In order to forward an unlabeled packet, a LSR analyzes the network
   layer header, to determine the packet's FEC.  It then uses the FTN to
   map this to an NHLFE.  Using the information in the NHLFE, it
   determines where to forward the packet, and performs an operation on
   the packet's label stack. "

So, adding "d) push a first label on an unlabeled packet" to the set of operations seems reasonable.
I agree with Stewart, RFC3031 sometimes alludes to incoming unlabeled packets as IP - by now it's clear MPLS can carry other types of payloads.

Regards,
Tarek

On 7/28/20, 4:02 AM, "Stewart Bryant" <[email-masked]> wrote:

    Stewart

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 30 Jul 2020 23:09:52 +0100

Except, of course, that the operation on an unlabelled packet is "push one or more labels".

The lawyer in me (who has not been fed this week) thinks that is it possible to stretch bullet c) to cover the case of an unlabelled packet by saying that if there is no label then replacing it with another no label is simple.

I tell the lawyer that it's a stretch, and he replies that he's only a lawyer.

Best,
Adrian

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Stewart Bryant
Sent: 28 July 2020 09:03
To: [email-masked]; [email-masked]; [email-masked]; BRUNGARD, DEBORAH A <[email-masked]>; Alvaro Retana <[email-masked]>; Martin Vigoureux <[email-masked]>; loa Andersson <[email-masked]>; [email-masked]; Tarek Saad <[email-masked]>; [email-masked]; mpls <[email-masked]>
Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (6240)

Stewart