Re: [bess] Alvaro Retana's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)

Alvaro Retana <> Wed, 16 January 2019 22:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0651F1311DB; Wed, 16 Jan 2019 14:49:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.737
X-Spam-Status: No, score=-1.737 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 3RCW3VUCZOEs; Wed, 16 Jan 2019 14:49:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1720131200; Wed, 16 Jan 2019 14:49:10 -0800 (PST)
Received: by with SMTP id s13so9371638otq.4; Wed, 16 Jan 2019 14:49:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=mzTFkNmu9FW/XvQqpMuiscFa1p0f4NxwMLGxxpX8fbw=; b=VcKLvnI55SR7BbMgHyiwAXTrgsociiL2XPIiNtjGdK8JBy+JaUpX7n5UbPh3vWoMV8 5xn2kwBBQ9mPqNd/4ExhpRieJJbA+bB/bnfI1s+iPwh1weTABeOiv5Ze+yXElXzJ8iPy JjFLGy03yl69ljy50wETFRIgEFteygs59ANuUtQkYtK1Z4YwTVHRjaT1BTZ5aPYKidD8 sxrR9gS3WobmsXw/V37fcSfcFGi4AagGLAD2oieiHvgKKadpHbjlYSaCjqULxmqufEsB cWye/g2aFx93ZGKAzKXxkJ48PTC+Ocl5yAKL7YV+93Ma28QrUTHWKuI2rHpoSqVgP+br 50ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=mzTFkNmu9FW/XvQqpMuiscFa1p0f4NxwMLGxxpX8fbw=; b=TLUMFm5hSMHFyLR+H3+VnqBzvftXbrNyBlmkLadEwjuNrFk8JRodFOf4X+HTqAShHQ h/hNQhT2arRqkvQohWqTFtVswSPxZ/w3Ci3eZ6YwLmCTjFv4AePv8a7NOAv16m5pO3Ks 2J4OmVTm36hDxb000pxAZX+g1EInRatdh56ANV2PxUt/MM7d9fTGkU48EvltytjIlywy gUuUDO6pK8d4i6qvkT/Xhz24iLMgzrmHgCkbGCfwiCHeeRq6ff6I4FxUpwWDMwZ8S6kA LChsA7XhrXYTuqBIDcWshcmLi98TScqSYmy++mbvvqUliHpJrZm1ECZWrA16i2A618dG Ww6Q==
X-Gm-Message-State: AJcUukedE3ORfGl14daR6qtZYWRXNUzSTDtbNP1K0OMzWguyZmRzZWHz oZbuhLoyrYsT7+RgMXjbH/mXWipB36Ia//fFp/ZEBg==
X-Google-Smtp-Source: ALg8bN4Aw0ML1GH0ZPyDx/zwfBqhehFiWteOP3xo2QlOxG3lx6+9ImfBELXxpOAZTULZMZGpIJ0EMQc3V6CBYu+bF9g=
X-Received: by 2002:a9d:282:: with SMTP id 2mr7011802otl.287.1547678949327; Wed, 16 Jan 2019 14:49:09 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 16 Jan 2019 14:49:08 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Wed, 16 Jan 2019 14:49:08 -0800
Message-ID: <>
To: The IESG <>, "Rabadan, Jorge (Nokia - US/Mountain View)" <>
Cc: "" <>, "" <>, "" <>, Stephane Litkowski <>
Content-Type: multipart/alternative; boundary="000000000000004a15057f9b164f"
Archived-At: <>
Subject: Re: [bess] Alvaro Retana's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)
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: Wed, 16 Jan 2019 22:49:13 -0000

On January 15, 2019 at 7:49:53 AM, Rabadan, Jorge (Nokia - US/Mountain
View) ( wrote:




(b) Form that text, what I get is that a new algorithm can define the
of the bits. Is that correct? If so, (1) s/a specific DF Alg MAY determine
the use/a specific DF Alg MUST/SHOULD determine the use ...and... (2) for DF

Algs 0 and 1, what happens if any of the other bits are set?
[JORGE] the use of the reserved bits for any future DF Alg is optional, so,
a MAY should be fine? I changed the text to:

The use of the bits is optional, yes.  But because each DF Alg may use the
bits in a different way, I think that each DF Arg MUST specify how the bits
are used.  If there’s no use for the bits, then a future DF Alg should
still specify how they are used: ignored when received.

"- In general, a specific DF Alg MAY determine the use of the
reserved bits in the Extended Community, which may be used in a
different way for a different DF Alg. In particular, for DF Algs
0 and 1, the reserved bits are not set by the advertising PE and
SHOULD be ignored by the receiving PE."

Maybe if you changed the “In particular…” text to apply to every DF Alg
(unless specifically specified in the future) then I think we could be ok
with a MAY above.

BTW, why only SHOULD and not MUST?

(5) §3.2: "if even a single advertisement for the type-4 route is not
with the locally configured DF Alg and capability, the Default DF Election
algorithm (modulus) algorithm MUST be used" Given that the PEs advertise
their preferred algorithm/capability, it is possible that it also supports
other algorithm/capability combinations, which may have been advertised. I
assume that it is up to the implementation if they want to update their
advertisement. Do you want to say anything about this? Are there potential
downsides to an implementation changing their preferred combination?
[JORGE] If the advertised ext community is not consistent across all the
PEs in the Ethernet Segment, the DF Alg falls back to the default DF Alg.
This is added in this section and also in the security section. Besides
these two bullets have been modified for clarity and completeness. Let us
know if you are not ok with it.
"- Otherwise if even a single advertisement for the type-4 route is
received without the locally configured DF Alg and capability, the Default
DF Election algorithm (modulus) algorithm MUST be used as in [RFC7432].
This procedure handles the case where participating PEs in the ES disagree
about the DF algorithm and capability to apply.
- The absence of the DF Election Extended Community or the presence of
multiple DF Election Extended Communities (in the same route) MUST be
interpreted by a receiving PE as an indication of the Default DF Election
algorithm on the sending PE, that is, DF Alg 0 and no DF Election

Yes, that text is fine with me.

The comment I tried to make above is different.  Let me try to give an
example — let’s assume that 3 algorithms have been defined: the default and
2 more (A1 and A2).  Let’s assume that all PEs support all the algorithms,
and that all, except 1 prefer A1 — the other router (R2) prefers A2.  In
this scenario neither A1 nor A2 will be used…  My question above was along
the lines of: if R2 prefers A2, then A1 and then the default…then it can
advertise A1 once it sees that all other PEs prefer that…resulting in
something better than the default.

(6) The HRW1999 reference must be Normative.
[JORGE] please check out the discussion with Adrian and Satya related to
this, where Adrian recommended to move it to informative references.

I don’t think that was Adrian’s intent when he said: "HRW1999 is provided
as a normative reference, and from the text I can see why.”

In any case, I think the reference has to be Normative because HRW "must be
read to...implement the technology in the new RFC”.