Re: [bess] Encoding a 20 bit label in a 24 bit field.

"Ali Sajassi (sajassi)" <> Tue, 16 October 2018 17:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58D00130E01 for <>; Tue, 16 Oct 2018 10:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.565
X-Spam-Status: No, score=-14.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FssV7bMsV26L for <>; Tue, 16 Oct 2018 10:29:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85895130DC7 for <>; Tue, 16 Oct 2018 10:29:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6626; q=dns/txt; s=iport; t=1539710980; x=1540920580; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=peJkZFBc0J77afGfRHirLm/mHEqMWpJOyBIYgCMuWWw=; b=dZfFJGYx2Rcz28OUCChSZJrbr7B+RLVX9WqJer60z7seo+rZxEfOxFda vAn+807usRRZWbfAmS01xJrM6z4Bmz6JMy4b7Uf4E5yOOjlOZZj0uCvc+ sDVYgG/LxhDbvWX9NkM+Y0cmTYI7Q03SXEPp7qqBfJmNvtVfaJZlxNiv2 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.54,389,1534809600"; d="scan'208";a="467342396"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2018 17:29:39 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w9GHTdkI025292 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 16 Oct 2018 17:29:39 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 16 Oct 2018 13:29:38 -0400
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Tue, 16 Oct 2018 13:29:38 -0400
From: "Ali Sajassi (sajassi)" <>
To: "Jakob Heitz (jheitz)" <>, Zhuangshunwan <>, BESS <>
Thread-Topic: [bess] Encoding a 20 bit label in a 24 bit field.
Thread-Index: AQHUZXXQUdZMwhG1nUinrA2l/1QLWw==
Date: Tue, 16 Oct 2018 17:29:38 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.c.0.180410
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [bess] Encoding a 20 bit label in a 24 bit field.
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Oct 2018 17:29:43 -0000

Yes, just the encoding of label value needs to be clear. 


On 10/15/18, 6:24 PM, "BESS on behalf of Jakob Heitz (jheitz)" < on behalf of> wrote:

    How about:
    The lower order 4 bits SHOULD be sent as 0 and ignored on receipt.
    -----Original Message-----
    From: Zhuangshunwan <> 
    Sent: Monday, October 15, 2018 6:02 PM
    To: Jakob Heitz (jheitz) <>; BESS <>
    Subject: RE: Encoding a 20 bit label in a 24 bit field.
    It is good to make this explicit. This ambiguity has led to some unnecessary interworking problems.
    Should we also need to explicitly define the "bottom of stack" bit in the low-order bit of the 3-octet label field?
    -----Original Message-----
    From: BESS [] On Behalf Of Jakob Heitz (jheitz)
    Sent: Tuesday, October 16, 2018 4:21 AM
    To: BESS <>
    Subject: [bess] Encoding a 20 bit label in a 24 bit field.
    We have proposed the following erratum for RFC 7432.
    -----Original Message-----
    From: RFC Errata System <>
    Sent: Friday, October 12, 2018 12:37 PM
    To: Ali Sajassi (sajassi) <>;;;;;;;;;; Giles Heron (giheron) <>;
    Cc: Krishnamoorthy Arumugham (karumugh) <>;;
    Subject: [Technical Errata Reported] RFC7432 (5523)
    The following errata report has been submitted for RFC7432, "BGP MPLS-Based Ethernet VPN".
    You may review the report below and at:
    Type: Technical
    Reported by: Krishnamoorthy Arumugham <>
    Section: 7
    Original Text
    Clarifications to following sub-sections:
    Section 7.1
    Section 7.2
    Section 7.5
    Corrected Text
    Section 7.1:
    Add below text to the section 7.1 regarding the encoding of MPLS label:
    "The value of the 20-bit MPLS label is encoded in the high-order 20 bits of the 3 bytes MPLS Label field."
    Section 7.2:
    Add below text to the section 7.2 regarding the encoding of both the MPLS label fields:
    "The value of the 20-bit MPLS label is encoded in the high-order 20 bits of the 3 bytes MPLS Label field for both MPLS Label1 and MPLS Label2."
    Section 7.5:
    Add below text to the section 7.5 regarding the encoding of ESI Label fields:
    "The value of the 20-bit MPLS label is encoded in the high-order 20 bits of the ESI Label field."
    MPLS label is a 20-bit value and is stored in a 3 bytes field in a packet. The 20-bit MPLS label value is generally stored in higher order 20 bits of the 3 byte label field. The exact encoding to be followed for storing MPLS label values are not explicitly mentioned in the RFC 7432 under section 7.1, 7.2 and 7.5 for different types of EVPN routes. This lead to ambiguity in different implementations. Hence a clarification is required.
    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. 
    RFC7432 (draft-ietf-l2vpn-evpn-11)
    Title               : BGP MPLS-Based Ethernet VPN
    Publication Date    : February 2015
    Author(s)           : A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, W. Henderickx
    Category            : PROPOSED STANDARD
    Source              : Layer 2 Virtual Private Networks
    Area                : Routing
    Stream              : IETF
    Verifying Party     : IESG
    BESS mailing list
    BESS mailing list