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

[RFC Errata System <[e-mail]>]

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 <[e-mail]>

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