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 <[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
