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

Sujay Gupta <sujay.gupta@ipinfusion.com> Sun, 28 August 2016 00:49 UTC

Return-Path: <sujay.gupta@ipinfusion.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC36712D504 for <l2vpn@ietfa.amsl.com>; Sat, 27 Aug 2016 17:49:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level:
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: OpenSSL error: bad base64 decode)" header.d=ipinfusion.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 2iH-AK3lLgK1 for <l2vpn@ietfa.amsl.com>; Sat, 27 Aug 2016 17:49:24 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 A36CE12D0CD for <l2vpn@ietf.org>; Sat, 27 Aug 2016 17:49:24 -0700 (PDT)
Received: by mail-pa0-x22d.google.com with SMTP id hb8so38166084pac.2 for <l2vpn@ietf.org>; Sat, 27 Aug 2016 17:49:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipinfusion.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=e/9W6ISsqvMFAYO1q31boq98v0ZGic+7Lo+VDIkSal8=; b=NcCOty7MbVkPMJf2tWWYnNDoEq1IyjFjD7e3asZzojCXA8rLC2BU2eRJWRXAGs6D4O IMuR6JTAv8MKyGJOUPehBKXQujGtl5qO/HcutxEtegIP2LbM7JQazSUikxYDJbFzGrUP E6BqqrRq79Iu3B3ryYm4gp48zePbaNuauUg2k3xshK4K4+ZYsR+guyHfkBLbLMAXKFs3 IszwZLzCm/ua+M4oBjVSOZ8nttFd7dYlj5D2Vx2WtYxIsfxFEnXvwG8dWQNlPTGqyGgT o7xTROogx0koAIPGbggt9gUsD+eQAp5nL9kM4AqRv2oMVXrE73A/udXYnoKB23BuwHqG 7jnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=e/9W6ISsqvMFAYO1q31boq98v0ZGic+7Lo+VDIkSal8=; b=dxLBCUwuYJH3hCiRyDq5lt2/K6bxL8uXtwDwX43JX94A1VIFfogucD1jNfgO43ZlbH vxqo/1ewfoWzOGcaM8LCG9Bdk59bmz50GIf/MwzpKhpxZd/yfSGWuw2o3maJl3iKmowM W6zjbLHc77mQVv6essp96lT2aTuLett87IkhasJ7BOsUW6SSKZCCgJpiTWb0V9n1yNO9 M4lIqbSeHBAyGFoj2pEuqANXxJUMM3S96TAI04ib5yZBnKT06SZTcPS+gx3xXsgAZCzQ cND6NbgynJUFUonY2y6T1j+JarK9UipBI98usC3L34GLC5HviafxYckSTJgnTGi1tOFY VjzQ==
X-Gm-Message-State: AE9vXwM7X1IFvcf5XpFnDzovHM9cWKr3v5I7Hxp0MakdpjIK+QLmqqBoCNPFWAenw1uuuwu8wh6JU4SAI/DrniSazYV0mvZu6bfZx9G6Hy4tbWOJW9ifmmD1/TZW4afEL0UUwxyj6A8PqNaGUC8eWtpvL67JrKyPvLd1QL+nrCEhAiHAh7hVKDZBzGkGDN+UEvOiZIvi4wSF1VsyQL9Z09Sqq/E=
X-Received: by 10.66.52.47 with SMTP id q15mr18883764pao.67.1472345364165; Sat, 27 Aug 2016 17:49:24 -0700 (PDT)
From: Sujay Gupta <sujay.gupta@ipinfusion.com>
References: <CAMF3MVvhvrpfjhhEe1p7xnp24bSk2wFJ4N0g5KKSk=odORvK9w@mail.gmail.com> <43DCF955-141C-4739-A88A-DC76045EAE79@nokia.com>
In-Reply-To: <43DCF955-141C-4739-A88A-DC76045EAE79@nokia.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIALSdn2y4ngFuSBQBPX2VZBkWZxgIin/rHn/AcXPA=
Date: Sat, 27 Aug 2016 17:48:18 -0700
Message-ID: <0e83601b97da2c2298da6afee4b6e45e@mail.gmail.com>
Subject: RE: Clarification required Section 9.2.1 RFC 7432 on BGP MPLS-Based Ethernet VPN
To: "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com>, sujay gupta <sujay.ietf@gmail.com>, giles.heron@gmail.com
Content-Type: multipart/alternative; boundary=bcaec5431b3c6b238e053b171e66
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2vpn/hCky3_DP1dqyKVP4dRWkyGjEPhw>
Cc: l2vpn@ietf.org, BESS <bess-bounces@ietf.org>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Aug 2016 00:49:27 -0000

Thanks Jorge



Regards,

-Sujay



*From:* Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com]
*Sent:* Saturday, August 27, 2016 8:02 AM
*To:* sujay gupta; giles.heron@gmail.com
*Cc:* l2vpn@ietf.org; Sujay Gupta; BESS
*Subject:* Re: Clarification required Section 9.2.1 RFC 7432 on BGP
MPLS-Based Ethernet VPN



Hi Sujay,



You may want to have a look at:



https://tools.ietf.org/html/draft-ietf-bess-evpn-usage-02#section-7



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.

Jorge







On 8/26/16, 10:56 PM, "L2vpn on behalf of sujay gupta" <
l2vpn-bounces@ietf.org on behalf of sujay.ietf@gmail.com>; 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?

TIA,

-Sujay

-- 
.