Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip

Joe Touch <> Fri, 01 May 2015 19:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 160B81A8AB1 for <>; Fri, 1 May 2015 12:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JXL-EDj71bor for <>; Fri, 1 May 2015 12:48:53 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45A381ACE1C for <>; Fri, 1 May 2015 12:48:53 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t41Jm1C6006831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 1 May 2015 12:48:19 -0700 (PDT)
Message-ID: <>
Date: Fri, 01 May 2015 12:48:00 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Donald Eastlake <>, "" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 May 2015 19:48:55 -0000

Hi, all,

Have you considered GUE as an encapsulation layer?

Encapsulating anything in UDP directly has a number of hazards,
including support for at-rate fragmentation, IPv4 ID generation, etc.,
that GUE is intended to address.


On 5/1/2015 9:58 AM, Donald Eastlake wrote:
> Forwarded with permission.
> Thanks,
> Donald
> ---------- Forwarded message ----------
> From: *Donald Eastlake* < <>>
> Date: Tue, Apr 28, 2015 at 9:26 AM
> Subject: Re: Mail regarding draft-ietf-trill-over-ip
> To: Mingui Zhang < <>>
> Hi Mingui,
> Thanks for these comments! See below.
> On Tue, Apr 28, 2015 at 4:27 AM, Mingui Zhang <
> <>> wrote:
>> Hi,
>> I read the document. It's comprehensive and well written. Below, several comments for your information.
>> 1.      It's not clear how the ports IPs are associated with the ports? Maybe, we can add some words to explain that they can be got from DHCP or manual configuration? Or we just say it is out the scope of this document.
> Yes, they need to be configured. Could be DHCP or manual or maybe some
> sort of orchestration thing... Seems reasonable to mention this in the
> draft.
>> 2.      Is it helpful to add a reference topology? Terminologies, such as IP tunnel, port IPs, RBridges can be put onto this figure. A walk-through example based on this reference topology can be used to explain how the IP tunnel is set up, how does a TRILL Data packet get encapsulated/decapsulated and transported in the IP tunnel. I think this would be educational.
> A few more network diagrams would probably be helpful. If you look at
> the minutes from the Dallas TRILL WG meeting, the suggestion of having
> a couple of example packets was supported...
>> 3.      Both IP and TRILL have specified BFD. Since TRILL is dependent on IP in TRILL-over-IP, it's unnecessary to have both TRILL and IP interact with BFD. It's best to assert TRILL-over-IP will have the IP interact with BFD. Please refer to
> Well, if you are only going to use one then I agree with the section
> you reference in RFC 5882 and you should do BFD over IP. But that
> doesn't check the TRILL stack, just the IP and lower stacks. So we
> could recommend just using IP BFD but I don't think we should try to
> prohibit people from also using BFD over TRILL on the link.
>> 4.      Is the IP link in this document "a single link (physical, or a secure tunnel such as IPsec)"? Then, we can require the TTL "MUST be set to the maximum on transmit, and checked to be equal to the maximum value on reception (and the packet dropped if this is not the case)." See also RFC 5880 Section 9.
> I don't think so. There is nothing wrong with the communication
> between two TRILL IP ports being multiple IP hops. Even if IPsec is in
> use, it could be integrated with the TRILL over IP port at one end but
> at the other end, the IPsec implementation could be integrated with a
> firewall a couple of hops from the RBridge...
>> 5.      There are six tiny typos marked in the attached doc.
> OK. We'll fix this up in the next version.
> Maybe you should post these comments, or some of them, to the TRILL WG
> mailing list. It would be good if there was more discussion of drafts
> there. Or if it OK with you, I could just forward your comments and my
> responses to the list...
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 <tel:%2B1-508-333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA
> <>
>> Thanks,
>> Mingui
> _______________________________________________
> trill mailing list