Eric,
Thank you for the comments.
Please see in-line.
-----Original Message-----
From: Eric C Rosen <ero...@juniper.net>
Date: Monday, April 30, 2018 at 7:46 AM
To: "Satya Mohanty (satyamoh)" <satya...@cisco.com>,
"stephane.litkow...@orange.com" <stephane.litkow...@orange.com>,
"bess@ietf.org" <bess@ietf.org>,
"draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org"
<draft-ietf-bess-evpn-df-election-framework.auth...@ietf.org>
Subject: Re: [bess] Shepherd's review of draft-ietf-bess-df-election-framework
Resent-From: <alias-boun...@ietf.org>
Resent-To: <jorge.raba...@nokia.com>, <satya...@cisco.com>,
<saja...@cisco.com>, <jdr...@juniper.com>, <kiran.naga...@nokia.com>,
<senthil.sathap...@nokia.com>
Resent-Date: Monday, April 30, 2018 at 7:46 AM
Let me add a couple of minor comments:
- The draft should state the action to be taken when receiving a route
that has more than one DF Election Extended Community. I think the two
possible options are "treat the route as if it did not have any DF
Election Extended Community", and "treat-as-withdraw" (defined in RFC
7606).
[JORGE] we are fixing that in the next rev. Satya can comment too, but we
should treat this in the same way we are treating inconsistencies among the PEs
in the ES, i.e. fall back to default DF Election. So that matches your "treat
the route as if it did not have any DF Election Extended Community".
- The draft should state the action to be taken when receiving a route
whose DF Election Extended Community has more than one DF Type bit set.
I think the procedures in the draft assume that at most one DF Type bit
is set, and may not work properly if multiple DF Type bits are set.
[JORGE] I assume you mean "more than one bit in the Bitmap set". The DF Type is
a single 0-255 value. This draft sets up the registry and defines only one bit
in the Bitmap. For that one we say it can be set or not. As far as this draft
is concerned, the other bits have no meaning. New specs with different types of
capabilities should clearly state if the new defined bit can be set along with
existing capabilities and/or types. Stephane also made a comment similar to
this and suggested something like this, that we are adding:
o For any new capability defined in the future, the
applicability/compatibility of this new capability to the existing
DF types must be assessed on a per case by case basis.
o Likewise, for any new DF type defined in future, its
applicability/compatibility to the existing capabilities must be
assessed on a per case by case basis.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
