Re: [bess] About draft-brissette-bess-evpn-mh-pa-02

Krzysztof Szarkowicz <> Sat, 20 April 2019 08:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 385A112009E; Sat, 20 Apr 2019 01:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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] 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 hbCViklj63jT; Sat, 20 Apr 2019 01:35:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD368120073; Sat, 20 Apr 2019 01:35:37 -0700 (PDT)
Received: by with SMTP id 85so3644817pgc.3; Sat, 20 Apr 2019 01:35:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4VW/UlIo26ao3hoEdKXA2SEevVoEthI4o9GNAgfPgB0=; b=C7jLBG4gsynIks+idjLDMzd7A2V4pEdEjT3GA+zsNyR9Q+wELBBvHYdcUnBpEKsVIK RI2TlZirthv3W9DdwvgmHFMjS2+VPMvAGFaFw2hqCG/DLFONfnlcqdPH6Efx9MEu4Le2 P7/lP2znVah9OZWTmz0QCihm9RTqNAMyxHCTu78Gc/BigzuMgMKgmOpioUm7Nsd5kpee pmVXYibapCQo9lKptoMkNZqKWX+kmfv11OUQJ/36JD/QgkT+k8ClmLYsdGzAr4r4/8vx 410FPG5YfnlTGoKKMR4xx5HiT9ocSVNObJAyjyjBPHWnXChDCy1zKVYYm1oPL57gU349 3/xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4VW/UlIo26ao3hoEdKXA2SEevVoEthI4o9GNAgfPgB0=; b=OaVYjK0u6038aupP0QH0ChrhkOmiX4z1oeP220nLWNuLLtJzW8aU1dJKVlmFxl6R9C +/IXVEQODWINPkeN5NNVMJG7nWS4OHhpmwJwrbxdgiR4la9zCRxQn2bonpOhJylfYZdX tXJIG8lXZrx9+oufIbAij63IAuSt+zc9xfOcAAy223/3X9869mbxGaMca4XvVpm2LqK6 5lzRXtr8mpOhoNbqU4769OD9ni+hIkr04P8WwZX/WRZIC0b/TwG540kNFee0xfGQ3o9/ ZLrnIua1WdDOt7koyJmps40aBFCaXWSVxBx291Zb7c+/TYIUJgsHXWMgIoNNU7b8433o R2wQ==
X-Gm-Message-State: APjAAAXnNdScuKMq4565OtW/9UwyVmqDUpHg1cZMxX1Eq5hY/uq5v3Le jNOSusgbD6HQv3apO4ZkKoYBg/A3
X-Google-Smtp-Source: APXvYqzkUkHGFdkoeGSX9JLU7uzC0MFCAMWiHlDF/iSagKW669ICQUmI8Xd5JWfC5cOJvkUL/QZgUg==
X-Received: by 2002:a63:d84a:: with SMTP id k10mr8100444pgj.441.1555749336903; Sat, 20 Apr 2019 01:35:36 -0700 (PDT)
Received: from ( []) by with ESMTPSA id k9sm8667779pga.22.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Apr 2019 01:35:35 -0700 (PDT)
From: Krzysztof Szarkowicz <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2085CE70-74DF-43AC-8BFA-866873C09A0F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Sat, 20 Apr 2019 10:35:09 +0200
In-Reply-To: <>
Cc: "" <>
To: "" <>
References: <>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <>
Subject: Re: [bess] About draft-brissette-bess-evpn-mh-pa-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Apr 2019 08:35:43 -0000


Would like to add as well one comment, regarding section 4, which says:

For Modulo calculation, byte 10 of the ESI is used.

This is too restrictive, since in essence it means, to achieve the desired diversity, operator would need to use ESI byte 10 for ESI differentiation. Given the fact, ES-Import RT community inherits from ESI only byte 1-7, many deployments differentiate ESI within these bytes only. So, byte 10 stays the same in many deployments (typically ’00’). 

Therefore, modulo calculation should take into account entire ESI (bytes 2-10, omitting byte 1, which defines ESI type). Or, some sort of hash/CRC function should be calculated over ESI bytes 2-10, quasi compressing 9 bytes to 1 byte (= result of hash/CRC), and this 1 byte should be taken as input for modulo calculations.


> On 2018-Nov-05, at 10:44, Rabadan, Jorge (Nokia - US/Mountain View) <> wrote:
> Hi all,
> I think I already made similar comments when the first revision of the draft in the subject was presented, but since I see no changes in the last revision, please let me throw the comments to the list for discussion:
> 1) section 3
> "Peering PEs MAY exchange only Ethernet-Segment route (Route Type-4)"
> Note that the AD per-ES route is REQUIRED in RFC7432. Please don't make this solution non-backwards compatible. Besides, mass withdrawal is important in this solution.
> 2) section 4
> The document only talks about the default Alg and HRW Alg, but other Algs such as Preference make a lot of sense here too.
> Also, shouldn't you request a new capability in the DF Election EC capability registry? If so, IMO this could be done:
> - the ES routes are advertised with existing DF Algs, e.g., default, HRW, Pref
> - when the new capability "port-based" is signaled, the Alg should be modified to consider the port only and not the Ethernet Tags.
> - the "port-based" capability should be compatible with the 'DP' capability (for non-revertive) and you should make sure that the AC-DF bit is zero so that an AC going down does not influence the DF Election.
> 3) I assume the ES associated to the port is defined as single-active mode. Also, as in RFC7432, the ESI-label based split-horizon procedures should be used to avoid transient echo'ed packets.
> 4) section 5 - Port-active over Integrated Routing-Bridging Interface
> In this section you assume that the entire port belongs to a single BD, and there are no other ACs in the BD. Without this assumption you cannot drive the IRB state out of the ES state. Please let me know if I am missing something, otherwise please, make this explicit.
> Thank you.
> Jorge
> _______________________________________________
> BESS mailing list