IETF Logo Mail Archive

Re: [Dcrouting] DC Routing requirements draft

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Wed, 24 January 2018 00:19 UTC

Return-Path: <jheitz@cisco.com>
X-Original-To: dcrouting@ietfa.amsl.com
Delivered-To: dcrouting@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4221F12D7F6 for <dcrouting@ietfa.amsl.com>; Tue, 23 Jan 2018 16:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 Uoeg9SNe2g6C for <dcrouting@ietfa.amsl.com>; Tue, 23 Jan 2018 16:19:26 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C674612D574 for <dcrouting@ietf.org>; Tue, 23 Jan 2018 16:19:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18860; q=dns/txt; s=iport; t=1516753165; x=1517962765; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J9E3bmSjznZ+xag0VbSVd0RvbVr6aDy9xzZYRtvPuLY=; b=M1616AJutZuUBb91wa1rwhM75LxxpecaO6S3Yz70DQoMDgY2Mt16b2Qn GWSAb7WG9T6Gx8k4tC9i/753IN/tfTzYyp13vj2GFXnbbH1WZd7SnPO+t gWZqbrFT/iOhgUy1wFfa/DdWzvWFAWPGUyT70SqVUMl3A5ADDc99mdJul M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B8AwDGz2da/5RdJa1eGQEBAQEBAQEBAQEBAQcBAQEBAYJKRzFmdCcHg1aZCYICiQ+IW4VUghcKGAEKhElPAhqEXFYWAQEBAQEBAQECayiFIwEBAQQBASEKQQsQAgEIEQQBASgDAgICHwYLFAkIAgQOBQiJSUwDFRCzM4Inh0MNgwUBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYRLghWBV4Fogy6Ca0QBAQKCJYJhgmUFi2OXXj0CkFaEfJQsjhqJCQIRGQGBOwEmBS0/gRFwFT2CKgmETniNA4EXAQEB
X-IronPort-AV: E=Sophos;i="5.46,404,1511827200"; d="scan'208,217";a="129012896"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 00:19:24 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w0O0JO9k001080 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jan 2018 00:19:24 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 23 Jan 2018 18:19:24 -0600
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Tue, 23 Jan 2018 18:19:24 -0600
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Tony Przygienda <tonysietf@gmail.com>
CC: "dcrouting@ietf.org" <dcrouting@ietf.org>
Thread-Topic: [Dcrouting] DC Routing requirements draft
Thread-Index: AQHTlKgJ7bHCAkVu5UmqDxkZ80WB/6OCJzFQ
Date: Wed, 24 Jan 2018 00:19:24 +0000
Message-ID: <1ab7acef55f34c4588b19c516a4c919a@XCH-ALN-014.cisco.com>
References: <00db7d5f09b5415ebb42c73e42d2baf6@XCH-ALN-014.cisco.com> <CA+wi2hOmPN811qQe2idGW7f8zxdPbqBt1mV8cyMNRqKimkTMKg@mail.gmail.com>
In-Reply-To: <CA+wi2hOmPN811qQe2idGW7f8zxdPbqBt1mV8cyMNRqKimkTMKg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.32.198.47]
Content-Type: multipart/alternative; boundary="_000_1ab7acef55f34c4588b19c516a4c919aXCHALN014ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrouting/lQkwZ4hVn_UreeZUYMTVe-PZiYY>
Subject: Re: [Dcrouting] DC Routing requirements draft
X-BeenThere: dcrouting@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Routing in the Data Center: discussions about problems, requirements and potential solutions." <dcrouting.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dcrouting>, <mailto:dcrouting-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dcrouting/>
List-Post: <mailto:dcrouting@ietf.org>
List-Help: <mailto:dcrouting-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dcrouting>, <mailto:dcrouting-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2018 00:19:28 -0000

The likelihood of a perturbation in one part of the network shaking something distant is one reason I added that a device should only know about distant devices in the aggregate. You could make it more explicit: The blast radius of a failure should be small. It's a bit difficult to specify exactly how small.

Thanks,
Jakob

From: Tony Przygienda [mailto:tonysietf@gmail.com]
Sent: Tuesday, January 23, 2018 4:12 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: dcrouting@ietf.org
Subject: Re: [Dcrouting] DC Routing requirements draft

Largely agreed. One observation only.

Trying to extend a single ZTP over a very large area like DCI IMO is a perilous idea due to the lack of separation of the fabrics (i.e. if that implies that one device flap could shake another DC fabric that way) ... DCI ZTP is probably a different problem than DC fabric ZTP due to the fact that fabrics internally are ideally run on private addressing or even no addressing at all (or only local addressing if must be). DCI is more of a public address problem IMO but one could argue against that as well if the DCIs extend over LSPs or some kind of overlay ...
thanks
--- tony

On Tue, Jan 23, 2018 at 3:58 PM, Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:
Comments on draft-dt-rtgwg-dcrouting-requirements

I'd like to expand on the ZTP requirement.
It is ok to pre-configure devices with items such as a unique identifier, capabilities, port types and so on.
It is not ok to require any of the configured items to depend upon the location of the device in the topology.
In other words, it should be possible to remove a device from any part of the network and put it into another part of the network without any manual configuration. The auto-configuration protocol should recognize the move and reconfigure a moved device.

It should be possible to have multiple networks that are individually auto-configured to be connected to each other in such a way that the auto-configuration of one network does not interfere with the auto-configuration of an adjoining network.

The DC routing protocol should be able to auto-configure and route multiple CLOS networks that are interconnected with a loose data-center-interconnect (DCI) network. The auto-configuration protocol should be able to discover and configure all the datacenters in a DCI as a single network.

The auto-configuration protocol should not require a dedicated (out-of-band) network.

Each device should not be required to know the topology outside of its immediate neighbors. It should be sufficient for a device to know about distant devices in the aggregate. Specific knowledge of certain distant devices should be for special cases only. For example, a network controller is expected to know precise topology information about its domain of control. In particular, each device must not store a complete link state database of the whole network or IP addresses of every leaf in the datacenter.

Thanks,
Jakob


_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<mailto:Dcrouting@ietf.org>
https://www.ietf.org/mailman/listinfo/dcrouting

v2.23.0 | Report a Bug | By Email