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