Subject: Re: [bess] DF election rule in EVPN MH, for untagged interface - reg
From: Muthu Arul Mozhi Perumal <[email-masked]>
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Cc: Jaikumar Somasundaram <[email-masked]>, "[email-masked]" <[email-masked]>, P Muthu Arul Mozhi <[email-masked]>
Date: Tue, 9 Apr 2019 11:40:45 +0530
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>

Hi Jorge,

Okay, thanks for the clarification..

Regards,
Muthu

On Tue, Apr 9, 2019 at 11:17 AM Rabadan, Jorge (Nokia - US/Mountain View) <
[email-masked]> wrote:

> Hi,
>
>
>
> I think the definition of Ethernet Tag in the framework draft should be
> clear enough.
>
> There are implementations using configured IDs.
>
> Jorge
>
>
>
>
>
> *From: *Muthu Arul Mozhi Perumal <[email-masked]>
> *Date: *Tuesday, April 9, 2019 at 2:54 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]
> >
> *Cc: *Jaikumar Somasundaram <[email-masked]>, "
> [email-masked]" <[email-masked]>, P Muthu Arul Mozhi <
> [email-masked]>
> *Subject: *Re: [bess] DF election rule in EVPN MH, for untagged interface
> - reg
>
>
>
> 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) <
> [email-masked]> 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 <[email-masked]>
> *Date: *Friday, April 5, 2019 at 5:10 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]
> >
> *Cc: *Jaikumar Somasundaram <[email-masked]>, "
> [email-masked]" <[email-masked]>, P Muthu Arul Mozhi <
> [email-masked]>
> *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) <
> [email-masked]> 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 <[email-masked]> on behalf of Jaikumar Somasundaram <
> [email-masked]>
> *Date: *Friday, April 5, 2019 at 6:15 AM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *P Muthu Arul Mozhi <[email-masked]>
> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
>