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

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 <mpls-bounces@ietf.org> On Behalf Of Stewart Bryant
Sent: 28 July 2020 09:03
To: erosen@cisco.com; arun@force10networks.com; rcallon@juniper.net; BRUNGARD, DEBORAH A <db3546@att.com>; Alvaro Retana <aretana.ietf@gmail.com>; Martin Vigoureux <martin.vigoureux@nokia.com>; loa Andersson <loa@pi.nu>; n.leymann@telekom.de; Tarek Saad <tsaad.net@gmail.com>; jsharma@ciena.com; mpls <mpls@ietf.org>
Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (6240)

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
>   may be the native IP packet.

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 <rfc-editor@rfc-editor.org> wrote:
> 
> 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 <jsharma@ciena.com>
> 
> 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
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls