Re: [trill] Mirja Kühlewind's No Objection on draft-ietf-trill-irb-13: (with COMMENT)

Donald Eastlake <d3e3e3@gmail.com> Tue, 05 July 2016 13:36 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F5112D567; Tue, 5 Jul 2016 06:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 kMqcAEHpyW1X; Tue, 5 Jul 2016 06:36:07 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F64812B050; Tue, 5 Jul 2016 06:36:07 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id s66so228986386oif.1; Tue, 05 Jul 2016 06:36:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=969UUSDbl7dnot3uGawEvJJcFKu4fqiaGSQFpOPA4N4=; b=bDqCag2LLAhogjjMlV+FXJGSNw+3esx53TzZVqSWbVvtAnqXDlfyokCWFJ/fr+dIZ0 15Cihaw8rmZvB/QcXUfsJZPYFOFqZArGrrmVn+PtUVP9YH8NtTq/Y1RN5YjduH790LYJ 3e3W/PIExiFiojBxXkb9iYKMQ/4EdbBDKzY00GLQtDeu6qyPQc2/zvQtgQdNSiChJmY5 Rc1RzXxr8FJp6k6j1vKgeSPnylw7xpBUXNxYL2z3JPFoirFLImNh19jiruUsYrLmk/8w 5qLVDn+gTjhD5MKoN0xi5Jv5AL8+3WgEFGmgGpcZwAZHlv8KsYUMAzX7Dz4DNEbJVee0 JI4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=969UUSDbl7dnot3uGawEvJJcFKu4fqiaGSQFpOPA4N4=; b=B4lpRVwZBnTZiu6dLA5pSI3LzwL04c9heucYLNfJ7GLTGAb0VJRCKt/nWbO17DZDr6 xPD9yrVDkKShwEJBMHP1VLVKywDj6+FT1VhQTDLwXg4i/lSw0h7UFc9KZgO2otIg+Ck/ U4HHrr1Ieng+oOiSOS9lJ+vChCkndefIMWvZyM7pEDtVj1piaVZO1T9EvYSNKlz7gbjT mIpa//zSCn7cnFnoknARCuMZ/f3Kd4uqG24bwlMQ5jZ/rtcl3cVFud1JUVDRkiItCDtw vM0xRvX+c/TIxofHIUAZ5HdBlABkMo1yKuXWtg0hLXssGloCX/7OL6Q+QJOuEoddBd/5 uTFA==
X-Gm-Message-State: ALyK8tJF644XVpDF6MUhs31umhqW/GXeRdjDEF/x0EsOCWajSFHUzStCUuPJ1x+nrzDYyetZcSFs3YuSBxrfgg==
X-Received: by 10.202.229.66 with SMTP id c63mr9968337oih.81.1467725766570; Tue, 05 Jul 2016 06:36:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.52.242 with HTTP; Tue, 5 Jul 2016 06:35:52 -0700 (PDT)
In-Reply-To: <CAF4+nEECEqNqmEwNHggAjcxF=nYfhF5rTvN=taEAptVtXy6NKQ@mail.gmail.com>
References: <20160629221311.30384.53041.idtracker@ietfa.amsl.com> <CAF4+nEECEqNqmEwNHggAjcxF=nYfhF5rTvN=taEAptVtXy6NKQ@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 5 Jul 2016 09:35:52 -0400
Message-ID: <CAF4+nEFRZj543L+2krRj6jf0S1sSsu6d7UzgR48c=0CJtJoWHg@mail.gmail.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/wsmdYaLCHGaZK0S_nOagi5N9wOE>
Cc: "trill-chairs@ietf.org" <trill-chairs@ietf.org>, The IESG <iesg@ietf.org>, "trill@ietf.org" <trill@ietf.org>, draft-ietf-trill-irb@ietf.org
Subject: Re: [trill] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-trill-irb-13=3A_=28with_COMMENT=29?=
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jul 2016 13:36:10 -0000

Hi Mirja,

A -14 version has been uploaded that is intended to resolve your comment.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Wed, Jun 29, 2016 at 9:49 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
> Hi Mirja,
>
> Thanks for your comments. See below.
>
> On Wed, Jun 29, 2016 at 6:13 PM, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-trill-irb-13: No Objection
>>
>> ...
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Two minor comments:
>>
>> 1) There are only a few SHOULDs and MUSTs in this whole document
>>    and where they are used it is often not very clear what the action
>>    is that should follow and how it should be implemented
>>   (e.g. "The network operator MUST ensure the consistency of the
>>    tenant ID on each edge RBridge for each routing domain.").
>>   And maybe there are actually more case where normative
>>   language should be used?
>>   Please double-check the use of normative language in this document!
>
> OK.
>
>>  2) A similar question on the following part:
>>   „If a tenant is deleted on an edge RBridge RB1, RB1 SHOULD re-
>>    advertise the local tenant Data Label, tenant gateway MAC, and
>>    related IP prefixes information of the rest tenants to other edge
>>    RBridges. […] Therefore the transient routes consistency won't
>>   cause issues other than wasting some network bandwidth.“
>>   Wasting network resources actually can be an issue.
>>   So why is this not an MUST?
>
> Wasting bandwidth can be an issue but is not necessarily an issue,
> particularly if it occurs only during a brief transient period. TRILL
> does not make it mandatory to implement with the maximum link
> utilization efficiency. For example, TRILL multi-destination traffic
> is send over a distribution tree. If there are no devices interested
> in traffic in a particular VLAN further down a branch of the tree, it
> is recommended that traffic heading down that branch be pruned. But
> this is not mandatory. The TRILL campus will operate "correctly"
> without such pruning and if someone wants to make a very simple, low
> end implementation without pruning, so be it. (As far as I know, all
> existing TRILL implementation do prune distribution trees.)
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com