Clarification required Section 9.2.1 RFC 7432 on BGP MPLS-Based Ethernet VPN

sujay gupta <> Sat, 27 August 2016 05:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9351C12B04A for <>; Fri, 26 Aug 2016 22:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fhfbZ6zxzFkx for <>; Fri, 26 Aug 2016 22:56:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AB4312B024 for <>; Fri, 26 Aug 2016 22:56:24 -0700 (PDT)
Received: by with SMTP id h186so34927545pfg.3 for <>; Fri, 26 Aug 2016 22:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=ryBmL9CpBuC/YCgXjihClgqxWgIXla/ObiKislgWrZA=; b=TeZkzgm8d5aq/s9rByqaIpm58XOj/lfl9Gx87fX7Ppp+pLY9CqlMOhmEk5FywG9EVr IIeJSjsmVdQ8MsvIud8b+fJ9rr+Kcd9sAkKF5GrUI6C2KruAVzQuqkG4C/JuxyGkB1uK dHyQf2gQNBs/UMvqY0Z2GKnVI0K+0qaHY1KRXnsySZf27CrcNi9B4vNdXT8GbYBOKgKf 4A1PHfNoeWI8P4PXQSluJ0xZ3VmZLE1FoZikUSFgQvCfcMQc601R++5VwzpqgEmOJTLH z0jR3SE9MPRy2s/le3fZxLMNShUtSMMs1jMoC3Y0kUx1cUh0PeAXnAyLlvmI4V1trOIO PCGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ryBmL9CpBuC/YCgXjihClgqxWgIXla/ObiKislgWrZA=; b=GCxlAvK+PknTqG7mEVxHtFNo3h5KU+SalA8JsWor09dpxjcYdE358u5SLa7Jz5Ho8M CMuNHRxAzGIOXjXtX3jqhPqwBd2jmSbfUnpAcRIZj0oyU0XvPX3zo9qOa8d3Ne9Refyl 7J7GbagejsQgF5XGkoR8xiWPZlIftH9pIIH+PWMfwyPfdLTWcLhXORqVNAJ0KdKCui78 uuwHPHLC8Ae6LkHTl2vvaCivkMb4uOK/DKBivIclH3BN1WrViv/h6N1Miqw24e11bJa3 EQK1c3mKzNI3rb3Px60Lxc3Eo2dFQrqa6xRkBA6TdGDYKiCtMw8FIXywz7lCJ6DC5nvL YhIQ==
X-Gm-Message-State: AE9vXwNojBKy2TazSbEI7zZDEA+64xsp6ULy1mCANPZBV1aAxYqXzzaYuiKhspe0m+GLYAreDG9R8XQbO4T/NQ==
X-Received: by with SMTP id k24mr12489453pfa.100.1472277384011; Fri, 26 Aug 2016 22:56:24 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 26 Aug 2016 22:56:23 -0700 (PDT)
From: sujay gupta <>
Date: Fri, 26 Aug 2016 22:56:23 -0700
Message-ID: <>
Subject: Clarification required Section 9.2.1 RFC 7432 on BGP MPLS-Based Ethernet VPN
Content-Type: multipart/alternative; boundary=94eb2c112fba7c24c9053b074af9
Archived-At: <>
Cc:, Sujay Gupta <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Layer 2 Virtual Private Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 27 Aug 2016 05:56:25 -0000

Dear Authors,

In section 9.2.1, on "Constructing MAC/IP Advertisement"

The question or rather confirmation I have a question around is the below

The MPLS Label1 field is encoded as 3 octets, where the high-order
   20 bits contain the label value.  The MPLS Label1 MUST be downstream
   assigned, and it is associated with the MAC address being advertised
   by the advertising PE.

While this statement is correct and indeed should be the way.

The following paragraph "recommends" 4 different ways of implementing it;

1) Single Label for the entire MAC-VRF

2) Per MAC-VRF and Ethernet Tag combination

3) Per ESI and Ethernet Tag combination

4) One Label per MAC address.

The question is;

As my implementation can assign Labels per Attachment circuit; i.e per
ESI and sometimes only on

an Ethernet Tag basis as well sometimes in per ESI and Ethernet Tag combination.

But the implementation CANNOT do a EVPN Label per MAC-VRF.

I am of the belief that this is purely a local choice and does not
effect in any way

the protocol behavior.  The interpretation of the label is finally a
responsibility of the

advertising PE as long as the forwarding is taken care correctly.

Whereas for BUM and unknown traffic indeed, the inner Label should
have the entire domain level

applicability and advertised as per PMSI attributes depending upon
P-tree methods.

Is this understanding correct?