Re: [Isis-wg] Comments on draft-xu-isis-flooding-reduction-in-msdc-00

Xuxiaohu <> Tue, 25 April 2017 08:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3807512946D for <>; Tue, 25 Apr 2017 01:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eH_YzusCFngv for <>; Tue, 25 Apr 2017 01:46:34 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C29812945E for <>; Tue, 25 Apr 2017 01:46:34 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DFL90626; Tue, 25 Apr 2017 08:46:29 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 25 Apr 2017 09:46:15 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Tue, 25 Apr 2017 16:46:06 +0800
From: Xuxiaohu <>
To: Erik Auerswald <>, "" <>
Thread-Topic: Comments on draft-xu-isis-flooding-reduction-in-msdc-00
Thread-Index: AQHSuHnYzJsNpeyNDUGF7bgutVKvpaHVvfNQ
Date: Tue, 25 Apr 2017 08:46:06 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58FF0CE6.00DF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: fa8fd101fe8ce40e3da3c7579532418e
Archived-At: <>
Subject: Re: [Isis-wg] Comments on draft-xu-isis-flooding-reduction-in-msdc-00
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Apr 2017 08:46:36 -0000

Hi Erik,

Thanks a lot for your valuable comments. Please see my response inline.

> -----邮件原件-----
> 发件人: Erik Auerswald []
> 发送时间: 2017年4月19日 3:27
> 收件人: Xuxiaohu;
> 主题: Comments on draft-xu-isis-flooding-reduction-in-msdc-00
> Hi,
> after reading the openfabric draft I looked at other data center related IS-IS
> drafts. I would like to comment on draft-xu-isis-flooding-reduction-in-msdc-00.
> I like the idea of using what the draft calls "controllers" to regulate link-state
> information dissemination. This architecture shows similarities to using route
> reflectors for BGP (RFC 4456) and to Google's Firepath routing solution (see
> Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google's
> Datacenter Network,

Your observation is absolutely correct. It could be looked as an IETF standards compliant alternative to the Firepath to some extent.

> This idea can be realized using existing implementations, with additional
> possible optimizations via IS-IS extensions. In fact I built a lab today to play with
> the idea, using a couple of switches, one of which was used as controller, and
> the others as fabric switches.

It would be great if you could share more information about your experiment:)

> To prevent the "management network" of the draft to be used for data
> forwarding, high link costs on these interfaces, both on controller and fabric (i.e.
> non-controller) switches, suffices. This can and should be symmetrical, there is
> no need for asymmetrical link costs as proposed by e.g. openfabric. Another
> possibility is to set the overload bit for the controllers.

Right, another way to achieve the above goal is to use the overload bit. I will add it in the next version.

> RFC 2973, IS-IS Mesh Groups, can be used to prevent flooding on the data path
> links.

Could you explain more about how to apply the ISIS mesh group in the CLOS topology?

> The management network as described by the draft should not be interpreted
> as a virtual router or VRF. Thus the (often single) management port found on
> data center switches cannot be used for this purpose. Front ports need to be
> used instead. The Dell Z9100-ON switch, for example, provides two 1G/10G
> ports (in addition to 32 100G ports) that could be used for redundant controller
> connections.

Your understanding of the management network is correct. Thanks a lot for sharing the valuable information.

> The controllers can be implemented using switches, or using x86 servers
> running a routing daemon (e.g. BIRD, Quagga, ...). Small data center networks
> could use two switches as controllers with a direct connection from each data
> plane switch to each controller switch. If the fabric comprises more switches
> than can be connected to a single controller switch, two separate Ethernet
> networks comprised of standard switches can be used to connect two servers
> acting as controllers. Each controller and fabric switch could be connected to
> two independent Ethernet networks in a resiliency model similar to Fibre
> Channel networks (SAN A & SAN B).

Yes, the controller here plays the similar role as a BGP route server. Hence, it could be implemented on servers or switches.

> These simple Ethernet networks would not even need to rely on STP to provide
> redundant controller connections. Each fabric switch would use one VLAN to
> connect to management Ethernet one, and a different VLAN to connect to
> management Ethernet two. If each management Ethernet is comprised of just
> one controller switch connecting to all fabric switches, one VLAN per controller
> switch suffices. The two controller switches would not be connected. If two
> servers are used as controllers, each could connect one routed port to each of
> the two management Ethernets.
> The basic architecture of sending link-state information via controller lends itself
> to further optimizations, e.g. suppressing link-state if and only if a default or
> summary route pointing towards all connected spines suffices. This would open
> the doors for traffic engineering via controllers as well.

Exactly. In fact, we have been considering applying Fibbing ( into our approach for traffic-engineering purpose.

> I'd say draft-xu-isis-flooding-reduction-in-msdc-00 shows a lot of potential. It
> even allows experimentation today using readily available parts (switches and
> open source routing daemons).

Thanks again for your valuable comments.

Best regards,

> Thanks,
> Erik
> --
> Dipl.-Inform. Erik Auerswald
> T:+49-631-4149988-0 M:+49-176-64228513
> Gesellschaft für Fundamental Generic Networking mbH
> Geschäftsführung: Volker Bauer, Jörg Mayer
> Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630