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

Tarek Saad <tsaad.net@gmail.com> Thu, 30 July 2020 16:58 UTC

Return-Path: <tsaad.net@gmail.com>
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 1A3553A0E10 for <mpls@ietfa.amsl.com>; Thu, 30 Jul 2020 09:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 RhK32-YCUtcE for <mpls@ietfa.amsl.com>; Thu, 30 Jul 2020 09:58:18 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 B19533A0E2C for <mpls@ietf.org>; Thu, 30 Jul 2020 09:58:12 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id d18so28945911ion.0 for <mpls@ietf.org>; Thu, 30 Jul 2020 09:58:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=qhK+hZUiS9lCqYHIPCxaC45g1uNPlZRwfm4Xlq32GJs=; b=Jzc+hVCwBowelQfelTDzjZrhrBdjsMXr0s9wbllUlg8BhkaJ5PpW31yQ1309M4vvId ol/et5P4OWH0atoV4k4fkyFVuIZWPd2tz3jjGgarj6hyEGrw4PC6GFqtFzizfMckz2B4 4U2+Sq9z2FLwsIYj7YdFQBW5EIRaOBA9LwVFAGkZp4YFq0bm2P08Ngl4+rakzeojplyf r97y0TpANfvfct4aHw7dAg7FsPlYMY3desg35rQf+3+okt7JszKYRf+8RhuheAmq+hpl PcCQQNI6VjyqQZYwMR/Y9lTdbSHZ22C/0ZRuGuF5Bo/odAvlopJAPVxTlZaiYsgzS1o8 RV/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=qhK+hZUiS9lCqYHIPCxaC45g1uNPlZRwfm4Xlq32GJs=; b=TLntykJgDML9KgSoSVx5sasRKCsfqrGQwzDOFOmLVG3mYXN8nVwfrEksO7mmVXKQNY seL+EtpC2z92WM8QRaRXQNj3HsiX32EF30EC6r5/DvFfE85IufsOS8B+ZUHV5Zu/OSD7 mKlwQOxbYVoSQPhlVg4oL8GgLT43UXiYqj3ciTtzQdF1jXNwGyzHatz51mwl+E1Yy29q aOPhAVzLseyEC5QQNRQfqQDjn9xGENhMgYUSr/o1ajtbcbPBGjNqdXtQlpZ1ZL2285xR KnoWNNDbbvOBgFHgWH6Yb7q9eA0iQLEmDWYCCnOFxKw+TofZ46l4/ojcg1quH/NS5IU0 7lXQ==
X-Gm-Message-State: AOAM533D7N5rTEm9nXB+S9QOnGPnaRA5DesTzqklmwP+szil0hvxB+KC Fsh/tqLTczW4EeD3MIcNfys=
X-Google-Smtp-Source: ABdhPJyGLxkNs1hhttdmj6ugwY9IlRdqGbFmc78jGNPUdT05y5k7rjvFWzXecQpG+e0MKY0OVTSzvw==
X-Received: by 2002:a05:6602:15c9:: with SMTP id f9mr39494122iow.35.1596128291963; Thu, 30 Jul 2020 09:58:11 -0700 (PDT)
Received: from DM5PR1901MB2150.namprd19.prod.outlook.com ([2603:1036:4:9e::5]) by smtp.gmail.com with ESMTPSA id y8sm3159166ilq.21.2020.07.30.09.58.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2020 09:58:11 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, "erosen@cisco.com" <erosen@cisco.com>, "arun@force10networks.com" <arun@force10networks.com>, "rcallon@juniper.net" <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" <n.leymann@telekom.de>, "jsharma@ciena.com" <jsharma@ciena.com>, mpls <mpls@ietf.org>
Thread-Topic: [mpls] [Technical Errata Reported] RFC3031 (6240)
Thread-Index: ATVGMjU34sK1uRiPQ1qMLcHihaYx4zUwODRFwJc/CI0=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Thu, 30 Jul 2020 16:58:09 +0000
Message-ID: <DM5PR1901MB215023E32222EED43C104E28FC710@DM5PR1901MB2150.namprd19.prod.outlook.com>
References: <20200727105210.2D087F40755@rfc-editor.org> <D08CE9EE-32FC-4C35-938F-F5F000AC84B5@gmail.com>
In-Reply-To: <D08CE9EE-32FC-4C35-938F-F5F000AC84B5@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/4ahnGNwYgXRVO60_jTf9qATMZsM>
Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (6240)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2020 16:58:25 -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" <stewart.bryant@gmail.com> wrote:

    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