Anoop - Thanks, helpful comments, please see [JM] inline. We will address these in a version that covers comments post-WGLC.
-Jon > On Aug 5, 2015, at 9:04 PM, Anoop Ghanwani <[email protected]> wrote: > > Support. I have mostly minor comments included below. > > Anoop > > ====== > > > Section 2.3 > I had trouble understanding this statement: > >>> > Operating large-scale infrastructure could be expensive, provided > that a larger amount of elements will statistically fail more often. > >>> > Is it just trying to say that with a larger number of elements, likelihood of > seeing failures goes up? Or is it saying something else? [JM] That's it, will simplify the wording in next revision. > > Section 3.2.4 > >> > If a data center network size is small, it is possible to reduce the > number of switches in Tier-1 or Tier-2 of Clos topology by a power of > two. > >> > Should this say factor of 2? [JM] Yes, good catch! 16->8, not 16->4. > > Section 4.1 > >> > The major downside of this > approach is the proprietary nature of such extensions. > >> > The bigger issue is probably limited scalability because of the need for > synchronization between switches at a given tier level where the protocol is > implemented. Also wastage of ports to implement the inter-chassis link. I > say that because a standard for this now exists -- 802.1AX DRNI, so > technically, the proprietary nature is no longer a limiting factor. > [JM] I believe 802.1ax-rev is not technically completed the standards process but I will discuss state and inability to scale such implementations past a 1+1 model in a sentence or two in next rev. > Section 4.1, para 2 > >> > currently the maturity of the protocol > >> > Did you mean lack of maturity? [JM] Yes, will fix. > > Section 4.3 > >>> > Application providers and network operators continue > to also develop new solutions to meet some of the requirements that > previously have driven large Layer 2 domains. > >>> > Would be good to add a reference. [JM] Rather than add 5 or 6 I think we can clarify that we are referring to various overlay/tunneling techniques. > > Section 5.2.1 > >>> > A unique ASN is allocated per each group of Tier-2 devices. > >>> > By group, do you mean all of the switches in a cluster (cluster being a term > previously defined)? Or is group something else? [JM] Yes, we will clarify to mean cluster. > > > Typos and minor editorial > =================== [JM] Will address all below in next rev. > > Section 2.4, line 6 > situation -> situations (or a situation) > > Section 4.1, line 11 > larger topologies many of the fundamentals -> > larger topologies, many of the fundamentals > > Section 4.2, last bullet > Layer-2 -> Layer 2 > Layer-3 -> Layer 3 > (Only instance where hyphens are used :)) > > Section 5.1, bullet 6 > >> > It is worth mentioning that all widely deployed > link-state IGPs also feature periodic refreshes of routing > information, while BGP does not expire routing state, even if this > rarely causes significant impact to modern router control planes. > >> > would read better as > >> > It is worth mentioning that all widely deployed > link-state IGPs also feature periodic refreshes of routing > information even if this > rarely causes significant impact to modern router control planes, > while BGP does not expire routing state. > >> > > Section 5.1, last bullet > NRLI -> NLRI > > Section 5.2.3 > The section Section 8.2 -> Section 8.2 > > Section 5.2.5 > iBGP -> IBGP > > Section 5.2.5, 2nd bullet > >> > device with the other devices in the Clos > >> > change to > >> > device compared with the other devices in the Clos > >> > > Section 6.1, 3rd para, 2nd line > step (e) Section -> step (e) in Section > > Section 6.4, line 1 > used to ECMP -> used for ECMP > > Section 6.4, line 2 > minimizing -> minimize > > Section 7.1, 3rd para, 1st line > Ethernet technologies -> Ethernet links (or platforms) > > Section 7.1, 2nd line from bottom > it's -> its > > Section 7.4, 1st para after bullets, line 2 from bottom > only store -> only stores > > Section 7.5, line 4 from bottom > server IP address subnet -> server IP address subnets > > Section 8.1, 1st para, last line > iBGP -> IBGP > > Section 8.2, 2nd para, line 2 from bottom > Tiers -> tiers > > Section 8.2.2, line 9 > there is no failures -> there are no failures > > > >> On Sun, Aug 2, 2015 at 8:31 PM, Jeff Tantsura <[email protected]> >> wrote: >> Hi RTGWG, >> >> This email is to start 2 weeks RTGWG LC for >> draft-ietf-rtgwg-bgp-routing-large-dc-05 >> Authors have addressed all the comments. >> >> Please indicate support or no-support as well as your comments by August >> 18, 2015. >> >> If you are listed as a document author or contributor please respond to >> this email stating of whether or not you are aware of any relevant IPR. >> The response needs to be sent to the RTGWG mailing list. The document will >> not advance to the next stage until a response has been received from each >> author and each individual that has contributed to the document. >> >> Thanks, >> >> Jeff & Chris >> >> _______________________________________________ >> rtgwg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/rtgwg >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
