Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS)

Donald Eastlake <d3e3e3@gmail.com> Thu, 19 January 2017 04:44 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 003601288B8; Wed, 18 Jan 2017 20:44:08 -0800 (PST)
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 AO5QxEZW8mru; Wed, 18 Jan 2017 20:44:07 -0800 (PST)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 77B8B127058; Wed, 18 Jan 2017 20:44:07 -0800 (PST)
Received: by mail-io0-x236.google.com with SMTP id j18so29282742ioe.2; Wed, 18 Jan 2017 20:44:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=so6rTVCtXEhI6ABM4BEk+w10qfjgOnYvj6SqK6fr7/o=; b=HAcvbOmIDLonw7ZHIQBvhsTLe4DYisHf2UY+kMBuDUkAZbbbJzv62xjY2MKv8y48Yi UJDM5fH7zDtzkEXCR4+N2f+gtJkGIZsyn1eRAiKXcUtSHbzJY1onK4xADD0hUrbzG99i LGfct28E70KX6dGOrIOy1eUhORJT7MFdf/tZLn9RI2V6cVrkW3nJSIoKyVDbG0qk9GDw ZQP4aqc6o9kpJ7HDkKNRzw6fcbUzPdKTcEM7zXeHdQXiiyPqbzaN85YWSTFDNuv/FETt ikURGoYW13IAMI13eBvUg1lc8Z2slyL9JuLuf8Uu/KSLV0t4pDD5iDWTzzTerGquLCAb R5HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=so6rTVCtXEhI6ABM4BEk+w10qfjgOnYvj6SqK6fr7/o=; b=iPYqXyD28AookNrpIN5loGbWfsFmEPJV/cnIuBe5/F4EMuspZf9bHOopTe5Qp7QAPo 66qGNcTlvKnSDl1gICzKy6G6mc6Vwfg2Fxyx8MZon7mFZ8vGz2FN0SIhFw+7iQp1ry+X D3iBiI+Sc5LrPJOk5il9tT+Hahi3VPexgptfzxNTLc3RdZkbEAbpb8i+8j/7T4FyewVf PJWwNYiHoT9n07Hq0+UX78zKpvjmKgKYTCdHeCDMq2U0itgJbW6lv71SfFVwPmZvRmCh LUkirA664gQBGD6IY5qRBARlCz1we7L9nk0SE2HolQapW7ULiX/am8/5V3MY7Otv0S4L +cHQ==
X-Gm-Message-State: AIkVDXLE3PlZDcoPcj2Yl2oebR+AnFzXJohkrsXvVdPNph8SFybuQSUpboSUBFUgz3f8QGdYQHN+0JNFBQYrpw==
X-Received: by 10.107.175.93 with SMTP id y90mr6450353ioe.12.1484801046758; Wed, 18 Jan 2017 20:44:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.41.72 with HTTP; Wed, 18 Jan 2017 20:43:51 -0800 (PST)
In-Reply-To: <148477153647.2298.16876633792182475280.idtracker@ietfa.amsl.com>
References: <148477153647.2298.16876633792182475280.idtracker@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 18 Jan 2017 23:43:51 -0500
Message-ID: <CAF4+nEE21nqqZZZbhvuPztaNSp0uHoZWPpirr2X9QfgQv9my6w@mail.gmail.com>
To: Alvaro Retana <aretana@cisco.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/d5_rvtVPmUpbE_0D91d4kKGyAvM>
Cc: "trill-chairs@ietf.org" <trill-chairs@ietf.org>, "trill@ietf.org" <trill@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-trill-rfc6439bis@ietf.org, Susan Hares <shares@ndzh.com>
Subject: Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS)
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: Thu, 19 Jan 2017 04:44:09 -0000

Hi Alvaro,

On Wed, Jan 18, 2017 at 3:32 PM, Alvaro Retana <aretana@cisco.com>; wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-rfc6439bis-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Section 2.4 (Overload and Appointed Forwarders) talks about potential
> Appointed Forwarders which are overloaded.  In IS-IS, a node with the
> overload bit set "shall not" (ISO 10589) be considered for transit.
> However, the use of "SHOULD NOT appoint an RBridge in overload" and
> "SHOULD re-assign VLANs from the overloaded RBridge" leaves a potential
> hole in the proper forwarding of TRILL data packers.  Why aren't MUST
> NOT/MUST used?  Is there something in the specific use of IS-IS by TRILL
> that I am missing?

The Appointed Forwarder function has to do with accepting frames from
end stations for ingress and egressing frames to end stations. It does
not have anything to do with TRILL Data packet transit routing.

Consider the following case: two TRILL switches (RBridges) RB1 and RB2
are connected by a link L1 that also has end stations on it. The end
stations are all in VLAN X. There are other end stations in VLAN X in
the TRILL campus not on L1 but all of these other end stations are
directly connected to RB2. RB2 is in overload.

Under these circumstances, RB2 should be the Appointed Forwarder for
VLAN X as that way traffic between all of the VLAN X end stations can
be forwarded by RB2 without any IS-IS routing at all. RB2 will just
be, in effect, forwarding native frames between RB2 ports (although,
for consistency, the TRILL specifications say that RB2 ingresses this
VLAN X traffic by encapsulating it into a TRILL Data frame, and then
notices it is destined for an end station on a local port, immediately
decapsulates it, and sends it out that port).

> I think this should be an easy DISCUSS to clear; either point to the
> piece I'm missing, or don't use an overloaded node.

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