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

Donald Eastlake <d3e3e3@gmail.com> Tue, 21 February 2017 19:33 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 EEF88129489; Tue, 21 Feb 2017 11:33:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 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, URIBL_BLOCKED=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 K92aZRqQnJ7H; Tue, 21 Feb 2017 11:33:24 -0800 (PST)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 D1082129442; Tue, 21 Feb 2017 11:33:23 -0800 (PST)
Received: by mail-it0-x22c.google.com with SMTP id y135so66132420itc.1; Tue, 21 Feb 2017 11:33:23 -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:content-transfer-encoding; bh=OHOyXDegnHjhjsb+NCpPhcXRm3lelPJEoj9HltTXaq0=; b=hnk6VW2lcnaYSZ4KpzgxOhICHS6RoIMR/ni7b/+jQQLbkm3wkrxHYbNPHjnlKRVMAu wkeb2FMNuDBOeMI9shn9IRVOCkWaJQgZaElPJqqF9SAHnaSjuXjjt9bH+hIg79BR/O5j ulLVSNSmEEFtPlqZnnIvO7wPAY+3ksEV95xkYwT7tv+4Ku9dxsl+z3wQNXUqfpakrZJA An3fNE5ePLle5H8JmJxW71JSXX7ygqvsp/HjIiQNKay1mIWkJLytl96cXBfX+9Ad8l2p GF6AjHAoGVcM67G2oTD11r7cTwXqFf1UpOF0FmsytVt0DdCyFG0S/Nm00332/wNqzZft Nicw==
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:content-transfer-encoding; bh=OHOyXDegnHjhjsb+NCpPhcXRm3lelPJEoj9HltTXaq0=; b=InC+g6rzvhMyai8pFYO8Q8XhwUVavKRTg1kG1/MSS5daTzAYV/oRpPXBOL1Nwu5ZZ8 WrL7brPIubFvsEaLYcTYwEJbb4lqNzw4PYs48Bm00pA33IiccAU4jKKB6ZY8GrWQAQqI 9PXi0ocm0a7LRmZwzlYH0HtY+n1lOIHRNQnhTCE2DdstWs9hP/IKNhAtSHnyvWx5u5JI I+AhWBHMw2Wc0BX9tsMY+JA8TDojSdqsHRpqsTrtQPOjUJAzUnpepBdBlCE5MBPQEbfZ VysHsIndEfzPFI0H/CY/+xfoVz7lb84o3B5hlMGeaoXRrhZ6yjZyBZCFWqtmxpZ7/vaw c/EQ==
X-Gm-Message-State: AMke39kAcjHHivYD475UQg3VVldH8lhs4TmqSVLMWFjbdczK1ne6bwurCZbLQ83Ilg8yNd1/XEFiDHq4ipSmWA==
X-Received: by 10.36.47.213 with SMTP id j204mr28439571itj.7.1487705603161; Tue, 21 Feb 2017 11:33:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.32.148 with HTTP; Tue, 21 Feb 2017 11:33:07 -0800 (PST)
In-Reply-To: <FDF0EF47-D4FE-4A62-96B3-FB3559287AC4@cisco.com>
References: <148477153647.2298.16876633792182475280.idtracker@ietfa.amsl.com> <CAF4+nEE21nqqZZZbhvuPztaNSp0uHoZWPpirr2X9QfgQv9my6w@mail.gmail.com> <FDF0EF47-D4FE-4A62-96B3-FB3559287AC4@cisco.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 21 Feb 2017 14:33:07 -0500
Message-ID: <CAF4+nEE4kDGcY_h1ZsE1pP+=h+zShnsepnhq68fS0J++B1j4zw@mail.gmail.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/wjudrCtkwx_dqcmPNBOBE0K2Qgg>
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" <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: Tue, 21 Feb 2017 19:33:25 -0000

Hi Alvaro,

On Thu, Jan 19, 2017 at 9:18 AM, Alvaro Retana (aretana)
<aretana@cisco.com>; wrote:
> Donald:
>
> Hi!
>
> I am not concerned about the case you described below: where the source and
> destination are attached to the same switch.  Nor am I concerned about
> transit TRILL data packets.

OK. I guess I was mislead by your reference to the IS-IS standard that
a router in overload "shall not" be considered for transit. I thought
that your comment had to do with building shortest cost paths which is
not particularly relevant here.

> I am concerned about the case where the other end stations are not attached
> to any of the local switches, but are somewhere else in the campus (or the
> mixed case where some of the other end stations are attached to an
> overloaded switch, but others are elsewhere).  In that case, if I am not
> missing anything, the appointed forwarder for the local link will accept the
> native frame and will have to send a TRILL Data Packet across the campus –
> the information to do that may not be available if the switch is overloaded.

Yes. The case you cite is one where the designated router really, as
the draft says, SHOULD NOT appoint the router in overload as appointed
forwarder. (Note that if it violates this "SHOULD NOT" the appointed
forwarder becomes, as far as IS-IS routing is concerned, a source and
sink, not a transit node.) But, in any case, it may be that the
designated router on the link is the only router on the link and is in
overload or it may be that all the routers on the link are in
overloaded or it may be the case I cite where the best routed to
appointer forwarder for VLAN-x is one that is in overload because all
the end stations in VLAN-x are attached to that router. So there are
plenty of cases where either it is a good idea or is unavoidable to
appoint a router in overload as the appointed forwarder for some VLAN.
You ask for the reason the draft says "SHOULD NOT" rather than "MUST
NOT" and that's the reason.

I can make some changes to Section 2.4 to try to clarify this.

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

> Thanks!
> Alvaro.
>
>
>
> On 1/18/17, 11:43 PM, "Donald Eastlake" <d3e3e3@gmail.com>; wrote:
>
>
>
> 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
>
>