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

Jon Mitchell <jrmitche@puck.nether.net> Mon, 10 August 2015 14:38 UTC

Return-Path: <jrmitche@puck.nether.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B081B363A; Mon, 10 Aug 2015 07:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.39
X-Spam-Level:
X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxgBli6Srb9N; Mon, 10 Aug 2015 07:38:21 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id A95431B3637; Mon, 10 Aug 2015 07:38:21 -0700 (PDT)
Received: from [100.113.49.137] (220.sub-70-194-106.myvzw.com [70.194.106.220]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 43E5C540715; Mon, 10 Aug 2015 10:38:18 -0400 (EDT)
References: <D1E42E95.A10A4%jeff.tantsura@ericsson.com> <CA+-tSzxO9UG2JZ_-TO7yz0YaUKQWfYDzYhY4-yPboWrULp00-A@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CA+-tSzxO9UG2JZ_-TO7yz0YaUKQWfYDzYhY4-yPboWrULp00-A@mail.gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-8BD56439-27C9-4233-9B3A-83B265D96821
Content-Transfer-Encoding: 7bit
Message-Id: <03BEACC6-BEE0-4808-9F0E-5B27E38C495B@puck.nether.net>
X-Mailer: iPhone Mail (12H143)
From: Jon Mitchell <jrmitche@puck.nether.net>
Subject: Re: RTGWG LC for draft-ietf-rtgwg-bgp-routing-large-dc
Date: Mon, 10 Aug 2015 09:38:16 -0500
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/_mABqbPYfRQlvoHWkHb09w0K7ls>
Cc: "draft-ietf-rtgwg-bgp-routing-large-dc@tools.ietf.org" <draft-ietf-rtgwg-bgp-routing-large-dc@tools.ietf.org>, rtgwg-chairs <rtgwg-chairs@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2015 14:38:24 -0000

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 <anoop@alumni.duke.edu>; 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 <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
>