Routing in the DC - Next Steps

"Alvaro Retana (aretana)" <> Thu, 27 July 2017 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B44D131CAF; Thu, 27 Jul 2017 07:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9flvZmnJ7vVk; Thu, 27 Jul 2017 07:55:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABC7F131B79; Thu, 27 Jul 2017 07:55:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=12018; q=dns/txt; s=iport; t=1501167334; x=1502376934; h=from:to:cc:subject:date:message-id:mime-version; bh=o4ZvXxXBjUsgB+L34FYIcmCZ0TgLUzkef52xdVr+A8U=; b=aAgVqU7aLGMDihGUNubxDzz6k2m8pNHKKjnRvpbG4BmJFq+i9SmaXIJT QPxLAAQbH3kDUebkTpAqPNdCja3J8LcN8npzKISv1m0AAcNP00iVH6epW BCTUx2KUOobeMHX3b6GxWQGiLlGwnGON/yYAuHrV3xA28VpFn9FwbPgVz 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AABu/nlZ/49dJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9rZG0nB44GojyFL4ISLoQ1ZByDSz8YAQIBAQEBAQEBayiFQksLEgF?= =?us-ascii?q?KAgQwJwQBDRkHiTBkEK9zgiYnixoBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyiDT?= =?us-ascii?q?YFhK4YfhGAwgjEFiWqNcogKAoFmhWeMVoJjgRKOR5VxAQ8QOIEKdxVJEgGHBne?= =?us-ascii?q?IcYEOAQEB?=
X-IronPort-AV: E=Sophos;i="5.40,419,1496102400"; d="scan'208,217";a="273158705"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 14:55:33 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v6REtXHh020544 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2017 14:55:33 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 09:55:33 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 09:55:32 -0500
From: "Alvaro Retana (aretana)" <>
To: "" <>, "" <>
CC: "" <>
Subject: Routing in the DC - Next Steps
Thread-Topic: Routing in the DC - Next Steps
Thread-Index: AQHTBuhlO8jlpLakoECLslHbAbQDfw==
Date: Thu, 27 Jul 2017 14:55:32 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.22.0.170515
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_AAA19B9732AA488E89D7106B30B30415ciscocom_"
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area General mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Jul 2017 14:55:37 -0000


At last week’s rtgwg meeting in Prague [1], I outlined what I think should be the next steps related to potential new IETF work for Routing in the DC.  This message presents the same points for discussion “on the list”.

Data Centers, because of their topologies (traditional and emerging), traffic patterns, need for fast restoration and low human intervention, among other things, are driving a set of routing solutions specific to them.  Some of these solutions are incremental in nature, but others have resulted in new proposals.  I believe that the requirements coming from the DC will most likely result in several solutions – in this case, one size probably doesn’t fit all.

In consultation with the rtgwg Chairs and Alia (who is the responsible AD for rtgwg), we have agreed to hold a non-WG-Forming BOF at IETF 100 (Singapore) [*].  The intent of this BOF is to discuss the special circumstances that surround Routing in the DC (what is the problem?), and potential new solutions.  The objective is *not* to hold a popularity contest and find a winning solution – but to determine whether there is interest and energy in the community to work on them.  If there is significant interest and energy (beyond the proponents) around a specific new solution (or solutions), then we can consider chartering an effort around it – but let’s cross that bridge when we get to it.

Jeff Tantsura has volunteered to help coordinate the proponents of this BOF, i.e. people interested in discussing and describing the problem, requirements, etc.  While I would like to see documents describing the special circumstances in the DC, at this point I don’t expect them to be published as RFCs.

I will be setting up a mailing list in the next couple of days so that we can focus the discussion there.  I will also be announcing BOF chairs – they will run the meeting, coordinate the agenda and would be the ones who should be contacted if anyone wants time to present a potential new solution.  I will be the responsible AD.

The focus of this effort is on new potential solutions: ones that may require a standalone effort (WG) – I don’t expect work/discussions on related incremental enhancements in an existing WG to be delayed or deferred.



[*] Pending discussion with the IESG/IAB, of course.