Re: [trill] Review of draft-ietf-trill-over-ip-08

Donald Eastlake <> Thu, 05 January 2017 01:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 875EC1294C6; Wed, 4 Jan 2017 17:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XjKLHSYD72R7; Wed, 4 Jan 2017 17:43:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25882129421; Wed, 4 Jan 2017 17:43:26 -0800 (PST)
Received: by with SMTP id d9so468246069ioe.0; Wed, 04 Jan 2017 17:43:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=shYu8Lzejr0kqXrUueN31nYnZk9TQtaMo+crB2KPSWM=; b=QjfzUT3pGYyOscfjfq2vLi5Z8LZ8ACRyO/0R6BxUmrP+3HKSy1YLxFEKP1CFaeE4OA zLXZKS7hJZeCG17WBcsdMzNbzq8Vt886gI2I+RLfYbYAr9rMiVr12aHBAs/nTVhO3SOR y88+LilYYyvBUeLV0cMfmcGLkzi73VyvRyUERg2v9W3Jf5xvGgXYk90L4JQJ8GBxrDtz 8DjsbvGTbWqw5fKh+sw46yniHzOTj6huxbXm4rPtL2v+536myZR6vNsREAne0aejUS3D /Ub4N8dyak4ZzAsJ3ognkvQ62+Sy++p+ekDRAVFYrPZqEtmKgJ0INap1Utsmmvf8nqBC 0Btg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=shYu8Lzejr0kqXrUueN31nYnZk9TQtaMo+crB2KPSWM=; b=rctzrY0VOw/1LJ1cueja/EbSlseSUz/eVG/sbgUUQJGVjkheBMfBeV4AN1ydeqU1FL VNFGOzQs7i0VtXRAiet6O94IA3PEK1ZBqVofiNbXvaVBK7/s1zrKdjao4rOYYcTTepts 5lAM8O6Ubs/N113snaXKexJAh5sfCeYsl7hmiM6Nkwng3lZQY8a7Aqkd71GZOiToycg6 egu326SiGu/iTP+R4JmWiMsqaLxHeAweFUS2e5CN+LVogWNgrCqa3dbY+xxll0QCYa71 x1sKNiSwu/EdTXOZ6g4qU433FYmd6hyWI2lLdqXlf6BB7NDjv0ZtFXlgpuZCOy3v5Vwb shtg==
X-Gm-Message-State: AIkVDXKt1CgGvefTozN9XlJ/CXfATB8SYR1/YOmrOX/B9/9ukwdO2fkqbU91rEmFeDHeNa4hMR+VpztWgiifOw==
X-Received: by with SMTP id y77mr50675142ioe.12.1483580606237; Wed, 04 Jan 2017 17:43:26 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 4 Jan 2017 17:43:10 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Wed, 4 Jan 2017 20:43:10 -0500
Message-ID: <>
To: Joe Touch <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>, "" <>, IETF Discussion <>,
Subject: Re: [trill] Review of draft-ietf-trill-over-ip-08
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jan 2017 01:43:28 -0000

Hi Joe,

Thanks for the comments.

On Tue, Jan 3, 2017 at 1:56 PM, Joe Touch <> wrote:
> Some observations:
> - the title is misleading; this is TRILL over UDP, not trill over IP.

Humm... The two encapsulations specified do use UDP and it seems
implausible that TCP would be used. But it is possible someone would
want to use SCTP or some other non-UDP IP encapsulation. That would
presumably be via some future document. So I guess, on balance it
would be better to change the title as you suggest.

> - the use of two different ports invites some potentially unintended
> problems, e.g., selective blocking of the control vs. data plane. IMO,
> given that TRILL's purpose is to extend Ethernet (not IP), this service
> would be better served using a single port and differentiated
> encapsulated traffic by whatever method TRILL nodes use internally.
> Otherwise, this spec needs to include specific description of unexpected
> behavior, e.g., data frames on the IS-IS port and IS-IS frames on the
> data port.

I guess I don't see this.

As for selective blocking, if someone can control the passing of
traffic through links connecting TRILL switches, they can always block
a subset of traffic based on whatever criteria they want. I don't
think it makes significant difference what header field they look at.

Similarly, if someone can modify traffic passing through links between
TRILL switches, if the traffic is IP they could swap around port
numbers, but they could also swap around other header fields.
Presumably it is a policy decision for network managers based on their
threat model whether or not to use facilities by TRILL or otherwise to
provided to secure control traffic and/or use link security to protect
all traffic over a link. (Similarly, it is a matter for end system
users/managers to decide whether to use end-to-end security.)

I suppose we could throw in a few sentences saying that if security is
not being used and data or control is mislabeled as the other and it
happens to be parseable as the other, you will get junk in the data
stream or screwed up control information. But I don't think the
mislabeling of control and data as the other by TRILL code is a
realistic problem. It would be detected by the crudest of testing.

> - regardless of whether one or two ports are requested, this doc should
> provide the needed information for IANA (e.g., a service name and
> description compliant with RFC6335).


> - the section on MTU handling might benefit from informationally citing
> intarea-tunnels, and consider using the recommendations there. In
> particular, it's not sufficient to assume IPv4 supports 576 byte MTUs
> (that's the minimum receiver reassembly MTU, not the transit MTU). That
> section should also address issues of PMTUD and PLMTUD.

I'll take a look at that draft in this context.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

> Joe