Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-multi-topology-05: (with COMMENT)

Donald Eastlake <d3e3e3@gmail.com> Thu, 08 March 2018 17:03 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 D6734127522; Thu, 8 Mar 2018 09:03:21 -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 F2Z33w8tkPKc; Thu, 8 Mar 2018 09:03:19 -0800 (PST)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 A0C8F12751F; Thu, 8 Mar 2018 09:03:19 -0800 (PST)
Received: by mail-io0-x231.google.com with SMTP id v6so404822iog.7; Thu, 08 Mar 2018 09:03:19 -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=blvvoIZOZXBFF1QpiCxP/l/u9r7xxawOE+mrPRyfOXM=; b=ZEKe9XiHaX3u4dAdi2u7eahsRGCjil+M0aKvFIITa8dXVZapT8ZkwdL4C1b4mgLu2y 7yrz7pIZdeAQCL1o4lFRxS8MHX9rUO2Wa6oe5vf5LzW7Djq4P8pvPm/KH+RPntDZr/Ni o6jmUKP5uK3f3xSmCn/w+mDp/KGGWEEj4sREvLh9ZPdvOyCrmZ8gMSoy8v+6MpLBHFQY 8fESK2caMCwD3OXvFh3sr1Fmi3+RShhJCYs0ZnTfQrO9NGhQo8HWk56SeoRMvCiu5UxD RWk4Mv6Lt91YGIJ8YfywhuqdXb+Ns5FS0a9hmVJySi8bVCWJWJTPcmvAesVrtcyomBep ETqQ==
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=blvvoIZOZXBFF1QpiCxP/l/u9r7xxawOE+mrPRyfOXM=; b=FXKc8nuHZ4417FPosVWMWJEaTxJrqH1rk/Nvh8RokjMwujeIJl0k9yh7WCfdf6Znbv a5+iY15Mrw2+iq4aKGNByvgq4noRuhJ8UcbfdojMjigRHXFPYkCTzitfFk7pEnYJA0ix BmNZG+Hh/9od5Jtk2uZiEnyaWEw2Z+Ss8GPhM0MrW5QcSB+JLqgYiHZfe6gGUO51nSDe Yl8iz83Nag1s1hGlE0gwfieP3QZIvOT+w0I5fVJeDUQUXBG4CNUY0+8T6bnj0iGurmDV 1DW7QMIO0WAOQsWujNadJulXU6rokEJz9mpBsc2Uh2qYvwkZnNBjDfNFOn72AfCKBuwW AiOA==
X-Gm-Message-State: APf1xPB7unKQQelBsJhWr8wMqBu9LQ3MMU8alQYuT9T6dLD9UYoX0HqG 6uEKUOzdg/3KCCxKEryhW6vSpKhfqQipdbMjMrE=
X-Google-Smtp-Source: AG47ELv5fTySh/kBOWsNyqbntMFUiKNilDKKUkWnin1ySqjTTKcYZ0s8pgIW5e99M+m9XYravCSdxktOQUWEXSoAT4g=
X-Received: by 10.107.95.23 with SMTP id t23mr31984063iob.14.1520528598748; Thu, 08 Mar 2018 09:03:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.58.193 with HTTP; Thu, 8 Mar 2018 09:03:03 -0800 (PST)
In-Reply-To: <152051790690.14018.12630385210703102002.idtracker@ietfa.amsl.com>
References: <152051790690.14018.12630385210703102002.idtracker@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 8 Mar 2018 12:03:03 -0500
Message-ID: <CAF4+nEECR0r74e8tUxUaN28=Mcz+h5-V=ftY=fdk8MnBdPLYDg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-trill-multi-topology@ietf.org, trill-chairs@ietf.org, Susan Hares <shares@ndzh.com>, trill IETF mailing list <trill@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/knHfpaw2TfVbgpoWQeR5Tt7P_zE>
Subject: Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-multi-topology-05: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
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, 08 Mar 2018 17:03:22 -0000

Hi Eric,

On Thu, Mar 8, 2018 at 9:05 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-multi-topology-05: No Objection
>
> ...
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Review in context: https://mozphab-ietf.devsvcdev.mozaws.net/D3642
>
> A diagram in the introduction would have helped me.
>
>             Grained Label [RFC7172]. By implication, an "FGL TRILL
>             switch" does not support MT.
> You are using MT before expansion here. But I actually don't understand why it
> does not. Can you explain?
>
>             implication, a "VL RBridge" or "VL TRILL switch" does not
>             support FGL or MT.
> My same question here as above. Why can't a VL TRILL switch support MT?

All TRILL implementations support VLANs. See TRILL Base Protocol
specification RFC 6325.

Fine grained labels were added in RFC 7172. There are actually two
levels: (1) FGL safe, which means it can transit fine grained labels
but cannot ingress or egress them, and (2) full FGL support which can
also ingress/egress to/from fine grained labeled TRILL Data packets.
It is really desirable to have RBridges be FGL safe so you can have,
say, a TRILL campus with an island or two of fully FGL capable
RBridges and not have to worry that data packets they produce will get
tossed if they happen to hit an older RBridge. And it's pretty easy to
be FGL safe, you just have to not explicitly check in the inner label
and drop the frame if it isn't an ordinary VLAN.

When Multi-Topology was added, it could have been independent of FGL
so you have a lattice of capabilities but the decision was made to
have a sequence instead to avoid starting on a combinatorial explosion
of combinations of options, simplify testing, etc. So its VL < FGL <
MT with each implying support of the previous.

>    (1) all TRILL switch ports on the link advertise topology T support
>        in their Hellos and
>    (2) if any TRILL switch port on the link requires explicit TRILL Data
> Probably stupid question but how do you know that there aren't TRILL switches
> that you haven't heard from yet that don't support T?

If you haven't heard from then, then you haven't established adjacency
with them (see adjacency establishment mechanism in RFC 7177) and you
will therefore ignore data packets from them and will not attempt to
send data packets to them. The process of adjacency establishment
includes learning about MT support in the exchanged Hellos.

>      V -  The version number of the MT label. This document specifies
>          version zero.
> What do I do if I receive an unknown version?

I think if the label has a non-zero version, it would not be
understood by an RBridge that implements this draft and the packet
must be dropped. Any other behavior seems unsafe. This should probably
be explicitly stated.

>          +  There may be non-zero topologies with no multi-destination
>             traffic or, as descried in [RFC5120], even topologies with
>             no traffic at all. For example, if only known destination
> Nit: described

OK

>             topology, there would be no need for a distribution tree for
>             topology T.  For this reasons, a Number of Trees to Compute
>             of zero in the Trees sub-TLV for the TRILL switch holding
> Nit: "reason"

OK.

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