Re: RTGWG LC for draft-ietf-rtgwg-bgp-routing-large-dc

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?

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?

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.

Section 4.1, para 2
>>

currently the maturity of the protocol

>>
Did you mean lack of maturity?

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.

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?

Typos and minor editorial
===================

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 <jeff.tantsura@ericsson.com>
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
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>