Hi Anoop,
Thank you for your review. We took all your comments.
Please see in-line how we are resolving them in rev 07.
Thanks.
Jorge
-----Original Message-----
From: BESS <bess-boun...@ietf.org> on behalf of "Satya Mohanty (satyamoh)"
<satya...@cisco.com>
Date: Friday, December 7, 2018 at 6:09 PM
To: Anoop Ghanwani <an...@alumni.duke.edu>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] Last Call:
<draft-ietf-bess-evpn-df-election-framework-06.txt> (Framework for EVPN
Designated Forwarder Election Extensibility) to Proposed Standard
Hi Anoop,
Thank you very much for your editorial comments and review.
We will take care of it.
Best,
--Satya
On 12/7/18, 1:01 AM, "BESS on behalf of Anoop Ghanwani"
<bess-boun...@ietf.org on behalf of an...@alumni.duke.edu> wrote:
I have reviewed the doc and I have mostly editorial comments.
Thanks,
Anoop
==
Throughout
VLAN Bundle, VLAN bundle, VLAN-Bundle, VLAN-bundle -- make consistent
VLAN Aware Bundle, VLAN-aware bundle, VLAN-Aware Bundle -- make
consistent
bridge table, Bridge Table -- make consistent (also add definition to
terminology section)
DF election, DF Election -- make consistent
Default DF Election, default DF Election -- make consistent
non-DF -> NDF
[JORGE] done, thx
Section 1
double Q-in-Q tags -> Q-in-Q tags
double is redundant
[JORGE] done, thx
Section 2.1
Fig 1 is a bit confusing. If the idea of the rectangle is to show a
core, then why have connections between PE1 and PE2, PE3, but not
between PE1 and PE4?
[JORGE] good point, fixed it, thx
Change
>>>
Layer-2 devices are particularly susceptible to forwarding loops
because of the broadcast nature of the Ethernet traffic.
>>>
to
The effect of forwarding loops in a Layer-2 network is particularly
severe because of the broadcast nature of Ethernet traffic and the
lack of a TTL.
[JORGE] done, thanks.
Section 2.2.1
a v4 or v6 peering -> an IPv4 or IPv6 peering
[JORGE] done, thanks.
>>>
>From a forwarding perspective, this is
a churn, as it results in re-programming the PE ports as either
blocking or non-blocking at potentially all PEs when the DF changes.
>>>
Why would the reprogramming change at all PEs? It should change for
at most 2 PEs for each (ES,EVI) being reprogrammed. Maybe authors
were trying to convey something else?
[JORGE] changed to:
***From a forwarding perspective, this is
a churn, as it results in re-programming the PE ports as either
blocking or non-blocking at the PEs where the DF state changes.***
Section 2.3
>>>
DF Election procedure Generally
>>>
Missing a period.
[JORGE] done, thanks.
Section 3
specification in EVPN -> EVPN specification
[JORGE] done, thanks.
Section 3.1
DF WAIT, DF_WAIT -- make consistent
[JORGE] done, thanks.
DF Wait timer -- where is this defined?
[JORGE] This is defined in [RFC7432]. I added a reference.
Ethernet Segment Route -> Ethernet Segment route
stop DF timer -> stop DF wait timer (?)
start DF timer -> start DF wait timer (?)
[JORGE] done, thanks.
Section 4
rather than the state of the server states -> rather than the state of
the server (?)
[JORGE] done, thanks.
Section 4.2
Si is the IP address of server i -> Si is the IP address of PE i
[JORGE] done, thanks.
operator chooses so -> operator so chooses
[JORGE] done, thanks.
Note 0 <= i,j <= Number of PEs -- should this be "< Number of PEs"?
Weight(V, Es, Sk) -> Weight(v, Es, Sk)
Pseudo-random -> pseudo-random
efficient deterministic -> efficient and deterministic
V4 -> IPv4
V6 -> IPv6
[JORGE] all of them changed. Thanks.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
