[Bier] comments on draft-xu-bier-encapsulation-03

Antoni Przygienda <antoni.przygienda@ericsson.com> Sat, 31 October 2015 11:49 UTC

Return-Path: <antoni.przygienda@ericsson.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D8F1A88E1 for <bier@ietfa.amsl.com>; Sat, 31 Oct 2015 04:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 jqof69vWgAoM for <bier@ietfa.amsl.com>; Sat, 31 Oct 2015 04:49:27 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842201A88DC for <bier@ietf.org>; Sat, 31 Oct 2015 04:49:27 -0700 (PDT)
X-AuditID: c6180641-f792c6d00000686a-e7-56343d8ca5c7
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A9.BC.26730.C8D34365; Sat, 31 Oct 2015 05:03:24 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Sat, 31 Oct 2015 07:49:26 -0400
From: Antoni Przygienda <antoni.przygienda@ericsson.com>
To: "bier@ietf.org" <bier@ietf.org>
Thread-Topic: comments on draft-xu-bier-encapsulation-03
Thread-Index: AdETZjSwwyOw6IJnSfmWkyD7xFNaLg==
Date: Sat, 31 Oct 2015 11:49:25 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F180EAFE883@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.12]
Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F180EAFE883eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPuG6PrUmYwYxtZhZLZ+xhcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsPc5SwFE3UqTv9bw9TAeFKti5GTQ0LAROJHywVGCFtM4sK9 9WxdjFwcQgJHGCWm7vrLDOEsZ5To2f+NFaSKTcBC4vK3p8wgtoiAssT5Q43sILawgLHE7Y7v jBBxC4mlj9+wQ9h6EnN+L2YBsVkEVCWav80Eq+EV8JV4vf8YmM0ItPn7qTVMIDazgLjErSfz mSAuEpBYsuc8M4QtKvHy8T9WCFtJYs7ra0BxDqD6fIk/h/UhRgpKnJz5hGUCo9AsJJNmIVTN QlIFUaIjsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLcxAgM+2MSbI47GBd8 sjzEKMDBqMTDu8HXOEyINbGsuDL3EKMEB7OSCG/nBJMwId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rzzZtwPFRJITyxJzU5NLUgtgskycXBKNTAWPrTctryYYdWlJg1xe+8a4dptk4xX/mc/csjp fOfpHdYLZqUserMzfRfDlVO7Ym0KOyJ3c57b8i3/Qfz6U7ln7D8bdDZHZ72KlFDIm3zYvyLu W9hKp6D2NacXdO6xnXrm0JKGH1dOL7YTCvv5KWnHbfupU75c8zayDgpOji66fKb3LUt+k6K2 EktxRqKhFnNRcSIAgZsLjHcCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/bier/H0KC4OPz-OMAgD-E_HtXuadAv_Y>
Subject: [Bier] comments on draft-xu-bier-encapsulation-03
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Oct 2015 11:49:29 -0000

Re-read and rethought. The key lookup will be pretty wide but if one can afford the TCAMs and would want to build something like this I guess it's feasible.

Architecturally the information carried in this encapsulation is more than necessary (which is NOT good). The architecture clearly indicates that a sub-domain MUST match onto one MT-ID and with that carrying both is superfluous, carrying subdomain is good enough. This also resolves the issue of e.g. driving this encapsulation with idr-extensions which doesn't even carry a multi-topology concept.

As well, why does the encaps carry BFR-id ? is that source/destination/originator ? None of those seem necessary to me ?

I think the suggestion towards the authors has been already extended to read the excellent  dataplane  design draft put out by the according design team recently. I support that. Occam's razor in data plane goes a long way ;-)

thanks

--- tony

"Your work is to discover your work and then with all your heart to give yourself to it." --- Buddha