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

Eric Rescorla <ekr@rtfm.com> Thu, 08 March 2018 17:07 UTC

Return-Path: <ekr@rtfm.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 D97DB127698 for <trill@ietfa.amsl.com>; Thu, 8 Mar 2018 09:07:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 8_wq6O-M3B_a for <trill@ietfa.amsl.com>; Thu, 8 Mar 2018 09:07:45 -0800 (PST)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 1B28212711B for <trill@ietf.org>; Thu, 8 Mar 2018 09:07:43 -0800 (PST)
Received: by mail-qt0-x229.google.com with SMTP id v90so7496232qte.12 for <trill@ietf.org>; Thu, 08 Mar 2018 09:07:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wh5CqUbYVpn8253qYmScOdHzGOtqcZEHDp48tkB9FI0=; b=w9pGPND39OYzf5i9fc0Qwd2H8VeWQl9qVpbPcbi2AC+xtQBaD/uStkFD3owmxUBkAs mNoakTB7+Kwk5L4Zj/DKZGoOFvLGoeETZ5Aeh752Au0hYOi08AS78FFNkvAefzrmEv9b Xuv3JpSrWrrwy2d8xeCrJpBgpHsMa6O0mSHzSi9+rv2SIOsWja1/oAYiKPQg/XzyNaNz EgaD6rX4024cDmH8FjSOkiMm4xDPXAz5QyiVbRZbxsYQAWA9LIKJi11Mea/3ZxZAMVBK oThSkI1Nzb2cGUvqo6SphreJ8MHmVzoS3FCr2Ne7hfkTjC7m/pBd0U+ixxBdMTMr6zVv 6R1g==
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=wh5CqUbYVpn8253qYmScOdHzGOtqcZEHDp48tkB9FI0=; b=T/vEENTDHAF5fAS/vcLoU46vtssnFXeUXnjd9yAtmh5YVMuYI/BfmvESjGttlF0cJU 55vo+56vOwuZ544N25u48lrAcN+qvRuxALVTMGvpmWAgvOdOnsNKveuO6My79egVwmb9 lAFKfLobViZcyuZlGjrHbWmtPnCsKKMDWAf4jJT3ydzi6fcuUbbsiFYmcfeXqW5X+vot 0YY8zDMDrEMeIVE2gQFX3WFlpSBKqurZxA59j/QEq6dgoWcQojbJo3y6soQq0ySSeryJ SdLwYmUw2rWfuQ66++cnEiZEIefOQ48LFfLIrw0WzCw8xSubvUIr+wcMY1h1424YxnlD DtnA==
X-Gm-Message-State: AElRT7FLOLqM05fgba/J3+eqD2nI4xmJwxXffTOhRUn3HENMM2BchVT/ DK7YrF/GpwMS0FMzfRGzzbj3o6j40GWyZDnGxU/3XQ==
X-Google-Smtp-Source: AG47ELshQNLsprwtU43XeOrNbD3B6L6VuLrfwlSHjsyALVk20hZSuJwZCB5lJm+7xIWVR2prjW2DTDEQHxmghMVWwzA=
X-Received: by 10.237.32.135 with SMTP id 7mr40562130qtb.287.1520528862109; Thu, 08 Mar 2018 09:07:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Thu, 8 Mar 2018 09:07:01 -0800 (PST)
In-Reply-To: <CAF4+nEECR0r74e8tUxUaN28=Mcz+h5-V=ftY=fdk8MnBdPLYDg@mail.gmail.com>
References: <152051790690.14018.12630385210703102002.idtracker@ietfa.amsl.com> <CAF4+nEECR0r74e8tUxUaN28=Mcz+h5-V=ftY=fdk8MnBdPLYDg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 8 Mar 2018 09:07:01 -0800
Message-ID: <CABcZeBN6SHTjEdWUBVAqVWiG9Wnj=EqRVZiFiJV540z2dGMa4w@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.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: multipart/alternative; boundary="94eb2c114ed0b280f80566e9b68e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/umXNLIEIsJ-eax50PWTfPOitUtw>
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:07:47 -0000

Thanks. I think it might help to just expand a bit of your above
explanation about FGL into the doc, if that's not too much trouble.

-ekr


On Thu, Mar 8, 2018 at 9:03 AM, Donald Eastlake <d3e3e3@gmail.com> wrote:

> 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
>