Re: [bess] DF election rule in EVPN MH, for untagged interface - reg

Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Tue, 09 April 2019 00:54 UTC

Return-Path: <muthu.arul@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D17812018E for <bess@ietfa.amsl.com>; Mon, 8 Apr 2019 17:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 Pl375fX0Qlvg for <bess@ietfa.amsl.com>; Mon, 8 Apr 2019 17:54:01 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 9A7121201A1 for <bess@ietf.org>; Mon, 8 Apr 2019 17:54:00 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id f18so12883566lja.10 for <bess@ietf.org>; Mon, 08 Apr 2019 17:54:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=As7wLe42haNT2K4IW+BvBf28me9haNPHkw1z+P3aNeI=; b=ovRyGAi79xSYnTQpdNxfVDDFQwMDSa2rtmBhh/pSP2LjCs+uXllKay9km8OPcrGvUN dGQx1ZCmjeMqf62vsqeta+d7IhM/28k4bbVlYB7QQdZUxMbw5T1s/CmAJjyh5YAZHxxU wzPwhtE1fsh7t4KwSvbIK78pFGn67VXoCHFtiGfq8l+cHLOWAq2qjyw9LWDX4DbOiOwT 1K8uSbR10pk6vFRQ/Q8XebhRcy46PgRlNQkCtUBICnbRIHlrVZWgXUeOznYkrgLdzl18 NHxfa6lBWcDQkVOf3LN/lFY22oCeq2XvqJDLlMkPVeXSJS5rN+3L18lrbHG8gx+ZbQ9y cIgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=As7wLe42haNT2K4IW+BvBf28me9haNPHkw1z+P3aNeI=; b=m/ScSRrN0DJwJKCBEiyVDvNxBuCd/KVu4gnNKraDsA9hmHnbt363K8pEXHJOkfvKF5 yj1c7EJiwIA480hMO6JWenAdS3+cp/ki9ecvQSiOboY4McqtWBCyVAh3/dcW7M+fa2r0 taN1v7PC52gDz9zKLYhJjEGB48wFyuZhQV5hK6KH9GoNMK8X+7fgiAJr37AOEwzQhwf5 /seHQlR5FZ1EukOTht8J6a7Ry3ChiW8nJvam3zbfW/nEpufxsHyhL2dm+HJNJPevj0LV 7cKzKiA5D3KYeXph0seRL+OMdof6OhhBlzSlQRlbjAiQkX5d3Eo7FNSKskn+f6Ecgy3p BFfw==
X-Gm-Message-State: APjAAAVbUEcbDlsUMpsVjHJJcheH7jue9w5NMC7jpSWG+9Ktha0IT2Of vydlIXJ6fkPdliNui8411BVTEzdotpfjcUzl/0A=
X-Google-Smtp-Source: APXvYqwbvzLbZlD1eBYrYyHdGy4jRD44aXdIeddPxOhANK694spI0MvX3aIYoo7kmsi3keqaCOW5Qr+qiqOUU5Cb8ZM=
X-Received: by 2002:a2e:81da:: with SMTP id s26mr18676989ljg.86.1554771238833; Mon, 08 Apr 2019 17:53:58 -0700 (PDT)
MIME-Version: 1.0
References: <09CBA32C-C703-408F-9F73-9F26D8FD1C25@nokia.com> <CAKz0y8zUim0pJ56T317LchQMyaQyn8Ba9S5BYVs4NrgTVn+DXQ@mail.gmail.com> <7076E872-08AF-4665-9187-0E5BA2140370@nokia.com>
In-Reply-To: <7076E872-08AF-4665-9187-0E5BA2140370@nokia.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Date: Tue, 09 Apr 2019 06:23:43 +0530
Message-ID: <CAKz0y8y1j1-BcPvFsO6GSb+w3dQHngPzx6V77fXrCgrdMUwKPw@mail.gmail.com>
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
Cc: Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com>, "bess@ietf.org" <bess@ietf.org>, P Muthu Arul Mozhi <p.muthu.arul.mozhi@ericsson.com>
Content-Type: multipart/alternative; boundary="00000000000065d3d305860e639c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/bOwZMTLGx4ufq8xPQihhL0CEFhA>
Subject: Re: [bess] DF election rule in EVPN MH, for untagged interface - reg
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2019 00:54:05 -0000

Hi Jorge,

For EVPN VPWS, I understand that service instance identifies are used as
Ethernet Tags in the DF election. However, for EVPN VPLS is it common to
configure anything other than the VLAN ID (VID) as the Ethernet Tag? Do we
have vendor implementations providing such an Ethernet Tag configuration
different from the VID for EVPN VPLS?

Regards,
Muthu

On Fri, Apr 5, 2019 at 9:49 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.rabadan@nokia.com> wrote:

> The Ethernet Tag that you use for DF Election does not even need to match
> what you have in the data path.
>
> Note that the definition says even “configured IDs”.
>
>
>
> As long as you use the same ID for the BD on all the PEs attached to the
> ES, you are fine.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
> *Date: *Friday, April 5, 2019 at 5:10 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com
> >
> *Cc: *Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com>, "
> bess@ietf.org" <bess@ietf.org>, P Muthu Arul Mozhi <
> p.muthu.arul.mozhi@ericsson.com>
> *Subject: *Re: [bess] DF election rule in EVPN MH, for untagged interface
> - reg
>
>
>
> Thanks, Jorge. It is clear that the Ethernet Tag needs to be different
> from 0 for the purpose of DF election..
>
>
>
> One of the options a provider has for supporting untagged frames in EVPN
> VPLS multihoming in VID translation...a rule to match untagged frames and
> impose a VID at the ingress and another rule to match that VID and dispose
> it at the egress.
>
>
>
> Are there any other options that can interop well?
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Fri, Apr 5, 2019 at 11:11 AM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.rabadan@nokia.com> wrote:
>
> Hi,
>
>
>
> I think you should check out
> https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-09
>
>
>
> This draft updates RFC7432 in certain aspects of the DF Election, and it
> is already at the RFC editor.
>
>
>
> Check out the use of Ethernet Tag in the document.
>
>
>
>    o Ethernet Tag - used to represent a Broadcast Domain that is
>
>      configured on a given ES for the purpose of DF election. Note that
>
>      any of the following may be used to represent a Broadcast Domain:
>
>      VIDs (including Q-in-Q tags), configured IDs, VNI (VXLAN Network
>
>      Identifiers), normalized VID, I-SIDs (Service Instance
>
>      Identifiers), etc., as long as the representation of the broadcast
>
>      domains is configured consistently across the multi-homed PEs
>
>      attached to that ES. The Ethernet Tag value MUST be different from
>
>      zero.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *BESS <bess-bounces@ietf.org> on behalf of Jaikumar Somasundaram <
> jaikumar.somasundaram@ericsson.com>
> *Date: *Friday, April 5, 2019 at 6:15 AM
> *To: *"bess@ietf.org" <bess@ietf.org>
> *Cc: *P Muthu Arul Mozhi <p.muthu.arul.mozhi@ericsson.com>
> *Subject: *[bess] DF election rule in EVPN MH, for untagged interface -
> reg
>
>
>
> Hi All,
>
>
>
> RFC7432, section 8.5, talks about DF election algorithm (service carving
> algorithm)
>
> only for <ES, VLAN> for VLAN-based service or <ES, VLAN bundle> for VLAN-(aware)
>
> bundle service.
>
>
>
> But there wont be any vlan id for untagged interface and so I wonder
>
> how the service carving algorithm can be applied to elect the DF.
>
> Also, should I use the lower VLAN ID even in the case of VLAN-bundle
>
> service, for electing the DF?
>
>
>
> Could some one help me to understand this please?
>
>
>
> ==========<snip from RFC 7432, section 8.5>===============
> 8.5 <https://tools.ietf.org/html/rfc7432#section-8.5>.  Designated
> Forwarder Election
>
> …
>
>    The default procedure for DF election at the granularity of <ES,
>
>    VLAN> for VLAN-based service or <ES, VLAN bundle> for VLAN-(aware)
>
>    bundle service is referred to as "service carving".
>
> …
>
>       Assuming a redundancy group of N PE nodes, for VLAN-based service,
>
>       the PE with ordinal i is the DF for an <ES, VLAN V> when (V mod N)
>
>       = i.  In the case of VLAN-(aware) bundle service, then the
>
>       numerically lowest VLAN value in that bundle on that ES MUST be
>
>       used in the modulo function.
>
> …
>
> =========<snip end>======================================
>
>
>
> Thanks & Regards
>
> Jaikumar S
>
>
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
>