[trill] Mirja Kuehlewind's Discuss on draft-ietf-trill-over-ip-

Donald Eastlake <d3e3e3@gmail.com> Sat, 10 March 2018 23:56 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B796A1271DF; Sat, 10 Mar 2018 15:56:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cXG0l8yBKnFH; Sat, 10 Mar 2018 15:56:52 -0800 (PST)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 BDDA812008A; Sat, 10 Mar 2018 15:56:52 -0800 (PST)
Received: by mail-io0-x242.google.com with SMTP id k21so3533976ioc.2; Sat, 10 Mar 2018 15:56:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=HwLCS0hYyPzbE9jfBEYfi/ew9FqtpdONu/W5khEsyOE=; b=BcmP/1BeUNMxhwUG5npMR+kT6mnhXYYkRN05XpwAv8rxYdVXdwetgias9erc+huCnT xGKFjA07YJQArRbgsEGjxjxTmo2SvUHiOXt3TCCFyEZfrJhTzzQXf3K6oLucIW5nMyAh g0IhMpmoywIHI10IpyIttbDV6A2ymUWtIvHBp3UB9ZhnJWC7bkoCSA3Oi1eAZhkL/C5g GPySCwjLFJE07OyVG9K2riowwTIkM9NoBE35YsA8lk6vPfgdkczfO2FEOxU/8xu0ouLR SsN+TO/c0iFwRiDPm0U7uRIMmOeQlmBYlgb5+7hSNw5FAEMJGWHqG06sBMQWFdvB+Vrj +kEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=HwLCS0hYyPzbE9jfBEYfi/ew9FqtpdONu/W5khEsyOE=; b=ALfPzOc/TzOAaQhAVqgUBLb6owgIwg+jZDqsU+I+zB/Ea4yJDRJ+eQiTgH+MlzvT1a f9oDsFcYjEkAW7TaCYU6xbnmCYxidaKNzz12vr5KSVDcmYCgAmO2gw64sEbNV6N+G3ea 857J+NYWDHz4gIP4bWJPBTCqnfrej6FQlYc0y2D9NxUNNOid57aqyBJn9+Vdu5No45S8 QU0M5JtyDDYE30lt81FglYHOW1uvO5cy3b2gcRiAJUmLbTa9Gb4cxf1VleIUyzT8LRym n23g640AgMxXFA5kRJvqF3xlaewt714Kx58rinxKLzLq6dTNPnN0bGa0G9nOcMyHV0k+ XecQ==
X-Gm-Message-State: AElRT7EoRRIUpeq+772EiYxxrR3EOKCO3omsXvvk8xPUNlmp7G5exQCb ASSJYzoKK0bd3ipEYSIRJw6oK9jnt7q2rHsU3uxTw4wG
X-Google-Smtp-Source: AG47ELsxVQGkFCuvlCa9WJqXeVbhJjpzATI9i+mZavxL7gYx+KRw4mxmsDL1Or3bzZWubpr8DePfaTjGSedXjWEKAwY=
X-Received: by with SMTP id k195mr3694032iok.131.1520726212013; Sat, 10 Mar 2018 15:56:52 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 10 Mar 2018 15:56:36 -0800 (PST)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sat, 10 Mar 2018 18:56:36 -0500
Message-ID: <CAF4+nEHd-WuZTVYukceUGL=_+AyY1FGh6jEbE7PT3DnHd8qLFA@mail.gmail.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-trill-over-ip@ietf.org, trill-chairs@ietf.org, trill IETF mailing list <trill@ietf.org>
Content-Type: multipart/alternative; boundary="001a114041aaaaf3c3056717a993"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/E1G-EjwsT-lgEpryCjJn8UWNvYI>
Subject: [trill] Mirja Kuehlewind's Discuss on draft-ietf-trill-over-ip-
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: Sat, 10 Mar 2018 23:56:55 -0000

Hi Mirja,

I though I would try to respond to your discuss/comments so far to expedite

> -----

> 1) Section 4.3 should also talk about decapsulation as DCSP is often
> overwritten on the path and therefore the DCSP of the inner and
> other IP headers can differe on decapsulation. Please see RFC2983
> for further guidance. You probabably should specify to discard the
> outer DSCP at tunnel egress in your use case.

Yes, I don't think there is anything in the draft even hinting about
copying outer DSCP into inner DSCP and in any case the payload will not
always be IP. Adding something specific saying don't do that is fine.

> 2) Further it is not clear to me if the use of CS7 in appropriate
> for this use case as RFC 4594 says

"   o  CS7 marked packets SHOULD NOT be sent across peering points.
      Exchange of control information across peering points SHOULD be
      done using CS6 DSCP and the Network Control service class."

My question is: Does this 12 year old advice from an Informational RFC
still apply? The mapping to DSCP provisions have been specifically looked
at by
knowledgeable people, including David Black, and no one has mentioned a
prohibition against the use of CS7 before.

> 3) Moreover, if my understanding is correct, the high priority
> classes in TRILL are not exclusively reserved for control data.
> However, CS6 and CS7 is only meant for control and rounting traffic.
> If those classes are used it must be ensure that the traffic sent
> with these DSCP is not overloading the network. I think further
> (security) considertations are needed here.


> Broadcast Link Encapsulation Considerations
> ------
> Not every transport encapsualtion can be used for
> Broadcast/Multicast. TCP cannot be used. This is mention later but
> also be consider in the text in section 5.3


> TCP Encapsulation
> -----

> If my understanding is correct than TRILL does not know that the
> connect of a TRILL data packet is. That means the data could can
> also contain traffic that is runing over TCP, right? Encapsulating
> TCP in TCP should generally avoided if possible and need further
> considerations as loss in the outer control loop that is used on the
> TRILL IP link appears as strongly varying delays to the inner
> control loop and therefore can have very negative effects.

Would it be sufficient to note this problem and say that TCP should only be
used where loss rates are low?

> TCP Connection Establishment (section 5.6.1)
> -----
> This section seem to assume for all configured or discovered tunnel
> endpoints there should be immeditately (at node start up time) and
> permantly a/multiple open TCP connections. I'm in general uncertain
> if this is the right approach. However, even if the connection is
> not closed, it might not be usable after an idle time, as middlebox
> on the path may have removed their state. Therefore to keep a
> connection permanently the endpoint need probaly to send
> keep-alives, or alternative a meachism to detect such a failure
> (quickly) and re-establish the connection such be used. However,

Middleboxes are out of scope for this draft. However, I think we'd be happy
to add a little parenthetical encouraging keep alives. Failures will be
detected, perhaps somewhat slowly, by Hellos not getting through. For more
rapid detection, BFD, which TRILL supports (RFC 7175), should be used.

> Comment (2018-03-08)

> Editorial coments:

> 1) It is really confusing that the whole document is talking about
> ports as tunnel endpoints while it also often talks about transport
> (TCP/UDP) ports. It makes it really hard to read this document.
> Maybe these things can be better distighlished somehow.

I must admit that I'm a little confused about what are the best words to
use in meeting the TRILL Charter goal of specifying "TRILL over IP". I
think the important thing, as usual with IETF protocols, is the bits on the
wire, and just changing the words shouldn't change the bits. The word
"transport" is a very recent addition throughout the draft and could be
removed if that is desired.

Whatever gets packets from a TRILL switch port to another TRILL switch port
is typically thought of as a "link" from the TRILL viewpoint. The base
TRILL protocol RFC specified this for Ethernet and treats an arbitrary
bridged LAN, including the common simple case of a point-to-point Ethernet
wire, as a link. There are RFCs specifying PPP and pseudowire technology
"links" between TRILL switch ports. This draft just treats various IP based
encapsulations as a way to get packets from one TRILL switch port to

> 2) This document should not re-specify the UDP header (5.4). At
> minimum the text should be changed the following way.

> "Where he UDP Header is as follows:"
> "Where he UDP Header is as follows as specified in [RFC0768] :"

OK. Could change to "Where the UDP Header is as specified in [RFC0768]."
and drop the diagram.

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