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

"Rabadan, Jorge (Nokia - US)" <> Sat, 27 August 2016 15:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0649112D0B9; Sat, 27 Aug 2016 08:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TqEAact9c1EA; Sat, 27 Aug 2016 08:01:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2183612B04B; Sat, 27 Aug 2016 08:01:44 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 5CC68ED970E32; Sat, 27 Aug 2016 15:01:39 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id u7RF1fce001569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Aug 2016 15:01:41 GMT
Received: from ( []) by (GMO) with ESMTP id u7RF1fNZ020838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Aug 2016 17:01:41 +0200
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Sat, 27 Aug 2016 17:01:40 +0200
From: "Rabadan, Jorge (Nokia - US)" <>
To: sujay gupta <>, "" <>
Subject: Re: Clarification required Section 9.2.1 RFC 7432 on BGP MPLS-Based Ethernet VPN
Thread-Topic: Clarification required Section 9.2.1 RFC 7432 on BGP MPLS-Based Ethernet VPN
Thread-Index: AQHSACfFFiBK8WVQ+Uy57Y1q3B5t8qBcUKGA
Date: Sat, 27 Aug 2016 15:01:40 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.19.0.160817
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_43DCF955141C4739A88ADC76045EAE79nokiacom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, Sujay Gupta <>, BESS <>
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 15:01:46 -0000

Hi Sujay,

You may want to have a look at:

This draft is relevant to your discussion below. The label allocation is a local implementation matter; most of the implementations I’m aware of, use a label per MAC-VRF.

My 2 cents.

On 8/26/16, 10:56 PM, "L2vpn on behalf of sujay gupta" <<> on behalf of<>> wrote:

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 statement;

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?