From nobody Thu Jun 1 07:30:03 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BA6128854 for ; Thu, 1 Jun 2017 07:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 MzKLdpeEjl_c for ; Thu, 1 Jun 2017 07:30:01 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 2F02012741D for ; Thu, 1 Jun 2017 07:30:01 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id n195so34792597wmg.1 for ; Thu, 01 Jun 2017 07:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=PAQ7R6zlxMWNLNSwQiWVnJfTGyfwyiL+4aBvpG3rSa4=; b=euyVxpXIgNyCaRmRC46w8dIeG5B8u7O3HCcE8vQbDgvGoJEokqkaOF7OyNrACHQtZ8 O4MFU9E8JKTQmeb4xIhhfIMY6lGdhIJq4qkmAZNB/qNSiuRdKqXsyvMS+Jk1HEQKh2Oq LBaT18exJ/HJ+B56cnp6wdfo+NAUgTzgMFV6McCk3VER3hEy07q5TlkJXiZOd1BUKgUB TkQWDpJ4RxDy5AUN3OugfogJYQcm2uvmV2ZjPnyy6xwLgYvXdYZ76LB2PDabJzpUBafS OjD9Ca6mDgu73JzO15cqXObWGsV1X45pPwVaVf0+wUgq/EqT4NkaQXdKFp+1v5VRCLJM +nnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=PAQ7R6zlxMWNLNSwQiWVnJfTGyfwyiL+4aBvpG3rSa4=; b=ahFwGbzYwQMBPxBu2cARJj7vbm+VqRzAS8PIKhGmbthxIKuxdXNynlnzNXRSLoMALx zpT6golZWtGBOIUsa9DqsM4jm1hKoSYWl4fKsRpy+wcL9CMXJRm3rhaxvimdwnTzJJNU uF+WOaVBpcba8rNwFFdhAgaZaKY/bCH7raKDHs2d2s+8ArrGbC7ZFaHlh7YfKwymuBOW c5kvvyPQ1nWi9SHNR6eouA/F+iGBmI2zdgFzsTrPHpzSurojPHD3oiV/cyG5kSYw8vzC 89Gxcup5itLjuQ1ImwiXnCdJWwypq7T635QxOSzr56bjmkIqHKjoUYuwqvrrftnN/H1d wfIQ== X-Gm-Message-State: AODbwcBfStlBafVf1C3S+CjPtrIwfK8DX0j75amJvA2eTljmGytRzdH2 kfH9CLKvhmCf/UJN X-Received: by 10.28.38.68 with SMTP id m65mr2102976wmm.25.1496327399439; Thu, 01 Jun 2017 07:29:59 -0700 (PDT) Received: from ?IPv6:2003:74:cf01:9664:c4b5:e7c1:1eaa:26fd? (p20030006117AC464C4B5E7C11EAA26FD.dip0.t-ipconnect.de. [2003:6:117a:c464:c4b5:e7c1:1eaa:26fd]) by smtp.googlemail.com with ESMTPSA id y17sm24914012wrb.39.2017.06.01.07.29.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2017 07:29:58 -0700 (PDT) To: tsv-art@ietf.org From: Martin Stiemerling Message-ID: <577b2020-2661-545b-3615-c99ebefe54d8@gmail.com> Date: Thu, 1 Jun 2017 16:29:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Tsv-art] Review of drafts in queue only by 06/02 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 14:30:03 -0000 Hi all, I can do this weeks review of the drafts for the tsv-art but it will become this Friday (06/02) until I will be doing this. However, my excuse is much better this time: I have helped one of my master students to get TCP-ENO into a test setup across the public net. He implemented this in the FreeBSD kernel. Cheers, Martin From nobody Tue Jun 6 12:35:38 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47761252BA for ; Tue, 6 Jun 2017 12:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZmWkpHzmIKwm for ; Tue, 6 Jun 2017 12:35:35 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 4F321124BE8 for ; Tue, 6 Jun 2017 12:35:35 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id q97so58366984wrb.2 for ; Tue, 06 Jun 2017 12:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=Ys/nDhKOn+v5UFs1RnrdTP123GmrTUvgj/YMqLiYKlc=; b=i9o4mC8YFCD2wiHWta/JTY9BeP42gkEKQdeGohQ/9Ew95fXiy0oJzAL9B5tzVjIedx MVjrYtlvQItp0RNAJ7Q+Xuak5KwS3FjJ5Ob/bZZUX5X8g2pohSQsT0NseM/ayAkA96LP NLwGvr3Wn4lekD8w0hsZgrzLzmTpzBBOzFdWIfx0+Ir8hUhwS/3kpgBq/cgvoyNiEBS2 snZkwytlXxy8p15mlGwjoIU82rzmfNOsuPSNs3xnr790QzwtVjUJWoYo1n93o8U68SpX taVM7sv94YVaWCZ8rdRIgTMU24eX1FAUEe4zzs1MMEd28ZmF7zqykvJCBgL7yKkKVfq9 1j0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Ys/nDhKOn+v5UFs1RnrdTP123GmrTUvgj/YMqLiYKlc=; b=XpBfa/BOg+77HHPcT5WrO9RxJXGY585li7SPLObge1Sx3BCgBny17gwH4hQIb6v0Rx DOV67o6OQlr1ihUWi3rHtKCRF7r/Whq6QN0n18YMuB/ayhzFco3tKrAg7e5JOYG5C9u9 4dzygwpeXdY+xzLB/cz8SeaRWSpcYbmERwUDTUJcsmKzrl9bdThkuB79rkUbW3cHhTSZ whjthTFc3fHrCd7oetJbPY3RROYv4NhmvgL2RLyjo3+CpJ5sn0WLnuvjH73rpMmGz0KU 0uslFrJnKvAEyQKtVemyl7qG7jqOwSbIfAJ3xeNKJw9XQzeJEjqh/skXDmORVsRambTC YSIg== X-Gm-Message-State: AODbwcACG+DcbEtiDKixQgG6K5CkF+zI39L8aic0ExG2s1myZJIFsKrP IpAW3NtvulhFmS9Y X-Received: by 10.223.138.194 with SMTP id z2mr21102463wrz.66.1496777733585; Tue, 06 Jun 2017 12:35:33 -0700 (PDT) Received: from ?IPv6:2003:74:cf63:1335:8494:3384:478b:5d96? (p200300061147E73584943384478B5D96.dip0.t-ipconnect.de. [2003:6:1147:e735:8494:3384:478b:5d96]) by smtp.googlemail.com with ESMTPSA id e73sm14735945wmd.1.2017.06.06.12.35.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 12:35:32 -0700 (PDT) From: Martin Stiemerling To: tsv-art@ietf.org Message-ID: <1b24b1f8-2b3b-6824-e8c4-3ce60a858475@gmail.com> Date: Tue, 6 Jun 2017 21:35:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 06/06 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 19:35:37 -0000 Dear TSVers, I did work through all documents that are in IETF LC, IESG processing or being requested for publication as of 06/06, 09:30 pm CEST. Please find below all documents checked and what to do with these documents. Documents that require TSV attention: draft-ietf-trill-over-ip-10 -- Magnus draft-ietf-bmwg-dcbench-methodology-07 -- Lixia Documents that do not require TSV attention: draft-baeuerle-netnews-cancel-lock-05 draft-ietf-tcpm-dctcp-07 (well it is out of TSV :) draft-ietf-precis-7700bis-07 draft-ietf-pals-p2mp-pw-lsp-ping-03 draft-ietf-mpls-app-aware-tldp-08 draft-ietf-avtext-lrr-05 draft-ietf-bmwg-dcbench-terminology-09 The full summary of all current reviews will be email right after this email. Thank you, Martin From nobody Tue Jun 6 12:36:04 2017 Return-Path: X-Original-To: tsv-art@ietf.org Delivered-To: tsv-art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 989B3129534 for ; Tue, 6 Jun 2017 12:36:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Stiemerling To: X-Test-IDTracker: no X-IETF-IDTracker: 6.53.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: Tsv-triage@ietf.org Message-ID: <149677776353.3917.8679341457049693643.idtracker@ietfa.amsl.com> Date: Tue, 06 Jun 2017 12:36:03 -0700 Archived-At: Subject: [Tsv-art] Open review assignments in tsvart as of 06/06/17 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 19:36:04 -0000 The following reviewers have assignments: Last calls: Reviewer LC end Draft Janardhan Iyengar 2017-06-05 draft-ietf-sacm-requirements-15 Yoshifumi Nishida 2017-04-09 draft-ietf-core-coap-tcp-tls-09 * Lixia Zhang 2017-06-13 draft-ietf-bmwg-dcbench-methodology-07 Early review requests: Reviewer Due Draft Magnus Westerlund 2017-06-15 draft-ietf-trill-over-ip-10 * Other revision previously reviewed ** This revision already reviewed Next in the reviewer rotation: Adrian Farrel Fernando Gont Janardhan Iyengar Allison Mankin Yoshifumi Nishida Joerg Ott Colin Perkins Michael Scharf Martin Stiemerling Joseph Touch From nobody Wed Jun 14 08:36:47 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36F7126DD9; Wed, 14 Jun 2017 08:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 t9Q-3IDpk4L4; Wed, 14 Jun 2017 08:36:43 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 4CC00126D05; Wed, 14 Jun 2017 08:36:43 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id 4so1423918ybl.1; Wed, 14 Jun 2017 08:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SBDNDFuvXa44eVZJQ9CAY0oEqc0JCzum+P6jdLHe7N4=; b=bNbW+x8Gcuh/iWkAbB5Zld5iqNlRxeJZLR14jIUCf7xrCdbLDmB+zABvmuJqKFv4+h Pu3NpL95urDZ6bUSR01NxixD7qyoAYN3IWucBCqmXyxmbmB5sYHLmV2mIxRffq/rJYBm iVk9WgIc6eg/VYh+KGojW6tuj7LwXlgooSAuVopuy6xZ9dd5h7gNbh18p0PNnxJEoFhz baQ6f4xA+YOe+i36xHXZdzdDnt5d+LLHSoYfaN3fsomXvuTTE3UEtr9/WNGGX0vwuWUu Q6MqJ4TA/XtXRRZI3BENkNX/U9QYmjteFfVvPPy9Fz8DedPwljOL0GN5mKvjmJ7yGKqH GZjg== 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; bh=SBDNDFuvXa44eVZJQ9CAY0oEqc0JCzum+P6jdLHe7N4=; b=eR4D0Hs9TRD3j48sXqblWiDTCFeSTlOGY139pHbvdauxT+AkIzR+tfNgY/fb5dNu/N 2RILaE/Ls81xUfeLKerqElOWpjiuf/9InG1ngF95VFiqapgplYH9TH67E51ue3C1+5TJ 4WTT3h6yQvNzqKh2vHarkYchg4GHN0ENKSBDOaQGgS98yzG/gbA3xBM8RsmOe7IA/1xd kuRreb+J8ZfU9MiRHUzUVJ57ui7G+sJqf8Va3XdsX5QG5HKexihB9Rn3EPB5ohXqTaeZ 8iDntDr7pUqU4YrWyhd5S8lYM31saUPt7hPU9xym74LILwYN4UUvCLUO7XiV+HcdfIV0 5MgA== X-Gm-Message-State: AKS2vOzh3nsA+zH4cJnW/bF2hYsAtkzqkBLgoaONo3oefS1NTckSj/zR Q9b1AdMq6jfxPg+JbgFFnqOwFpQ2jCz2 X-Received: by 10.37.13.194 with SMTP id 185mr634397ybn.37.1497454602278; Wed, 14 Jun 2017 08:36:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.216.85 with HTTP; Wed, 14 Jun 2017 08:36:41 -0700 (PDT) From: Spencer Dawkins at IETF Date: Wed, 14 Jun 2017 10:36:41 -0500 Message-ID: To: tsv-art@ietf.org, "tsv-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a11c00f98a2dd340551ed5145" Archived-At: Subject: [Tsv-art] TSV Dinner at IETF 99 in Prague X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 15:36:45 -0000 --001a11c00f98a2dd340551ed5145 Content-Type: text/plain; charset="UTF-8" Dear TSV Chairs and TSV Area Review Team, We will be gathering for our usual TSV Chairs/TSV ART dinner on Monday evening in Prague. Please let us know if you are able to join us, by July 13 (Thursday before IETF week), so we can arrange a suitable venue. The participation poll is at http://doodle.com/poll/qrvm7nqwe2s84uky. Please let us know via poll comments if you have any dietary restrictions we should know about when planning the event. Thanks! Spencer and Mirja --001a11c00f98a2dd340551ed5145 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear TSV Chairs and TSV Area Review Team,

We will = be gathering for our usual TSV Chairs/TSV ART dinner on Monday evening in P= rague.

Please let us know if you are able to join us, by July 13 (Th= ursday before IETF week), so we can arrange a suitable venue.
The participation poll is at http://doodle.com/poll/qrvm7nqwe2s84uky.

Please let us know via poll comments if you have any dieta= ry restrictions we should know about when planning the event.
Thanks!

Spencer and Mirja
--001a11c00f98a2dd340551ed5145-- From nobody Thu Jun 15 10:32:44 2017 Return-Path: X-Original-To: tsv-art@ietf.org Delivered-To: tsv-art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECA11293D8; Thu, 15 Jun 2017 10:32:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund To: Cc: trill@ietf.org, ietf@ietf.org, draft-ietf-trill-over-ip.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149754795560.13109.17521244075940607817@ietfa.amsl.com> Date: Thu, 15 Jun 2017 10:32:35 -0700 Archived-At: Subject: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 17:32:36 -0000 Reviewer: Magnus Westerlund Review result: Not Ready Early review of draft-ietf-trill-over-ip-10 Reviewer: Magnus Westerlund Review result: Not Ready TSV-ART review comments: I have set this to not ready as there are several issues, some significant that could affect the protocol realization significantly. Some may be me missing things in TRILL, I was not that familiar with it before this review and I have only tried looking up things, not reading the whole earlier specifications. So don't hesitate to push back and provide pointers to things that can resolve issues. The authors and the WG clearly have thought about a lot of issues and dealt with much already. Diffserv usage -------------- Section 4.3: TRILL over IP implementations MUST support setting the DSCP value in the outer IP Header of TRILL packets they send by mapping the TRILL priority and DEI to the DSCP. They MAY support, for a TRILL Data packet where the native frame payload is an IP packet, mapping the DSCP in this inner IP packet to the outer IP Header with the default for that mapping being to copy the DSCP without change. I think it is fine to require that implementations are capable of setting DSCP values on the outer IP header. However, I fail to see any discussion of the potential issues with actually setting the DSCP values. It is one thing to do this in an IP back bone use case where one can know and have control over the PHB that the DSCP values maps to. But otherwise, over general internet the behavior is not that predictable. One can easily be subject to policers or remapping. Also as the actual DSCP code point usage is domain specific this is difficult. Priority reversal is likely the least of the problems that this can run into over general Internet. Section 4.3: The default TRILL priority and DEI to DSCP mapping, which may be configured per TRILL over IP port, is an follows. Note that the DEI value does not affect the default mapping and, to provide a potentially lower priority service than the default priority 0, priority 1 is considered lower priority than 0. So the priority sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7. TRILL Priority DEI DSCP Field (Binary/decimal) -------------- --- ----------------------------- 0 0/1 001000 / 8 1 0/1 000000 / 0 2 0/1 010000 / 16 3 0/1 011000 / 24 4 0/1 100000 / 32 5 0/1 101000 / 40 6 0/1 110000 / 48 7 0/1 111000 / 56 This appear to be an problematic mapping. At least for prio 0 and 1. As priority 1 appears to be intended to be higher than priority 0, it is interesting that it is mapped to CS1, which to quote https://datatracker.ietf.org/doc/rfc7657/: CS1 ('001000') was subsequently designated as the recommended codepoint for the Lower Effort (LE) PHB [RFC3662]. So what is proposed can in a network using default mapping, result in that you get priority 0 to be lower priority than 1. Plus that in some networks this can also results in strange remapping that results in a different PHB for CS1 than. MTU and Fragmentation --------------------- I think there are two main issue here. The first one is MTUD discovery of the actual IP path MTU between the ports. That will be needed to prevent a lot of traffic going into MTU black holes. Especially as TRILL requries 1470 byte support which is likey above a lot of paths. Section 8.4: Path MTU discovery [RFC4821] should be useful in determining the IP MTU between a pair of RBridge ports with IP connectivity. The issue with RFC4821 is that it has requirements on the packetization layer. Trill appears to have several components that are useful. However, it will require a specification of the procedure to result in a useful tool. Section 8.4: TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in [RFC7177], can be used to obtain added assurance of the MTU of a link. Yes, that can confirm working MTUs that are at 1470 or above, but appears prevented from working below 1470? Thus, it appears that there is a lack of mechanism here to actually get a valid and functional MTU from TRILL in the cases where the Path MTU is below 1470. If I am wrong good, but I think this is an important piece for how to handle the next main issue. UDP encapsulation and IP fragments. I see it as a big issue that UDP encapsulation is the native one, and that relies on IP fragmentation despite the need for reliable fragmentation. With the setup of having to support 1470 MTU on TRILL level some packets will be fragmented in many environments. That will lead to a lot of losses, and as discussed below a very big problem with middleboxes. The main problem here is that if one tries to rely on IP fragments one will have issues with packets ending up in black holes. And different problems depending on IPv4 or IPv6. IPv6 is lilkely the lesser problem assuming that one have working PMTUD. There are several ways out of this. 1. Detect issues and use TCP encapsulation with correctly set MSS to not get IP fragements 2. Determine MTU and implement an fragmentation mechanism on top of UDP. Zero Checksum: -------------- Section 5.4: UDP Checksum - as specified in [RFC0768] Considering the fast path encapsulation desire, I am surprised to not see any mentioning of use of zero checksum here. Raising the zero checksum and forward reference would be good I think. And then Section 8.5: The requirements for the usage of the zero UDP Checksum in a UDP tunnel protocol are detailed in [RFC6936]. These requirements apply to the UDP based TRILL over IP encapsulations specified herein (native and VXLAN), which are applications of UDP tunnel. If you actually intended to allow zero checksum, then you actually should document that Trill fulfills the requirements that the applicability statement raises. I have not analyzed how well it meets these requirements. Please review Section 6.2 of RFC 8086 for example how that can be done. TCP Encapsulation issue ----------------------- Section 5.6: The TCP encapsulation appear to be missing an delimiter format allowing each individual TRILL packet/payload to be read out of the TCP's byte stream. In other words, a normal implementation has no way of ensuring that the TCP payload starts with the start of a new TRILL payload. Multiple small TRILL payloads may be included in the same TCP payload, and also only parts as TCP is one way of dealing with TRILL packets that are larger than the IP+Encapsulation MTU that actually will work. This comment is based on that there appear to be no length fields included in the TRILL header. The most straight forward delimiter is a 2-byte length field for the TRILL payload to be encapsulated. Section 5.6: TCP endpoint requirements. I do wonder if an application like TRILL actual would need to discuss performance impacting implementation choices or limitations. For example use of NAGLE, the requirements on buffer sizes in relation to Bandwidth delay products, as buffer memory in a RBridge will impact performance. Congestion Control ------------------ First thanks for the effort here. 8.1.2 In Other Environments Where UDP based encapsulation headers are used in TRILL over IP in environments other than those discussed in Section 8.1.1, specific congestion control mechanisms are commonly needed. However, if the traffic being carried by the TRILL over IP link is already congestion controlled and the size and volatility of the TRILL IS-IS link state database is limited, then specific congestion control may not be needed. See [RFC8085] Section 3.1.11 for further guidance. This is correct, however my question is if the RBridges have anyway of knowing which traffic is actually congestion controlled, considering that TRILL provides an layer 2 abstraction. I wonder if there should be any type of white list of the types of layer 2 payloads that can be assumed to be congestion controlled, and thus okay to forward over IP paths? I am worried that without any recommendation to prevent traffic that is not controlled to be forwarded, can lead to congestion issues. The other issue I think may exist is the issue serial unicast emulation of broadcast/multicast creates. As this amplifies the outgoing packet rate with a factor of how many addresses are configured for serial unicast this can be significant traffic expansion. Thus, I think additional considerations are needed here, and maybe rate limiting of the amount of traffic to be multicasted. Flow and ECMP ------------- Section 8.3: For example, for TRILL Data, this entropy field could be based on some hash of the Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL. I would appreciate clearer references to what these fields are. If I understand this correctly, the idea here is to look into the inner layer 2 frames, and use the flow equivalents that exists on that level and hash that into value that maps the flows onto the source port range. I think this text should include a summary of the principle and ensure to note the important requirement that what is considered flows in the inner must not result in being striped over multiple source ports as this may lead to reordering issues due to packets taking different paths. NAT and TRILL over IP: Section 8.5: If one like to use TRILL over IP through a NAT, then there are some very important considerations that are missing. First the need for static binding configurations or the need for determining ones external address(es) and be able to communicate that to the peer RBridges, and in addition ensure that one has keep-alives to that the NAT binding never times out. Next is the issue that there is almost zero chance of getting a IP/UDP encapsulation TRILL payload through the NAT if it results in IP fragmentation, as NATs don't do defragment and refragmented on the internal side, and an IP fragment lacks UDP port and thus can't be matched to binding. Also if you like to run IP/ESP through a NAT, then you most likely need the IP/UDP/ESP encapsulation (https://tools.ietf.org/html/rfc3948). Note that this will restrict the MTU even further and thus ensure that the 1470 requirement cannot be fulfilled even without additional tunnels over an 1500 bytes MTU Ethernet infrastructure. I would note that also firewalls likely have issues with IP fragments for the same reason, they require significant amount of state to be verified if they should be let through. In general I think you should create a configuration that has chance to work through most middleboxes, but I think you should require static bindings. I think that configuration is, and don't laugh now, but IP/UDP/ESP/TCP/TRILL, otherwise you will not be able to have both security and reliable fragmentation of TRILL packets. Cheers Magnus Westerlund From nobody Thu Jun 15 18:45:02 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87A8128B91; Thu, 15 Jun 2017 18:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no 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 NznLSlYVxRF3; Thu, 15 Jun 2017 18:44:58 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 E62831205D3; Thu, 15 Jun 2017 18:44:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.176.217; From: "Susan Hares" To: "'Magnus Westerlund'" , Cc: , , , "'Alia Atlas'" , "'Jon Hudson'" References: <149754795560.13109.17521244075940607817@ietfa.amsl.com> In-Reply-To: <149754795560.13109.17521244075940607817@ietfa.amsl.com> Date: Thu, 15 Jun 2017 21:39:10 -0400 Message-ID: <00a301d2e641$5a6cfb00$0f46f100$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHMe5Py4K7gCbNISswrkrRWdm5LSqIziw8g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 01:45:01 -0000 Magnus:=20 Thank you for the very careful review. Please let me chat with the = authors regarding this document. It make take some time, but each of = your points will be responded to by the authors.=20 Sue Hares=20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Thursday, June 15, 2017 1:33 PM To: tsv-art@ietf.org Cc: trill@ietf.org; ietf@ietf.org; draft-ietf-trill-over-ip.all@ietf.org Subject: Tsvart early review of draft-ietf-trill-over-ip-10 Reviewer: Magnus Westerlund Review result: Not Ready Early review of draft-ietf-trill-over-ip-10 Reviewer: Magnus Westerlund Review result: Not Ready TSV-ART review comments: I have set this to not ready as there are several issues, some = significant that could affect the protocol realization significantly. = Some may be me missing things in TRILL, I was not that familiar with it = before this review and I have only tried looking up things, not reading = the whole earlier specifications. So don't hesitate to push back and = provide pointers to things that can resolve issues. The authors and the = WG clearly have thought about a lot of issues and dealt with much = already. Diffserv usage -------------- Section 4.3: TRILL over IP implementations MUST support setting the DSCP value in the outer IP Header of TRILL packets they send by mapping the TRILL priority and DEI to the DSCP. They MAY support, for a TRILL Data packet where the native frame payload is an IP packet, mapping the DSCP in this inner IP packet to the outer IP Header with the default for that mapping being to copy the DSCP without change. I think it is fine to require that implementations are capable of = setting DSCP values on the outer IP header. However, I fail to see any = discussion of the potential issues with actually setting the DSCP = values. It is one thing to do this in an IP back bone use case where one = can know and have control over the PHB that the DSCP values maps to. But = otherwise, over general internet the behavior is not that predictable. = One can easily be subject to policers or remapping. Also as the actual = DSCP code point usage is domain specific this is difficult. Priority = reversal is likely the least of the problems that this can run into over = general Internet. Section 4.3: The default TRILL priority and DEI to DSCP mapping, which may be configured per TRILL over IP port, is an follows. Note that the DEI value does not affect the default mapping and, to provide a potentially lower priority service than the default priority 0, priority 1 is considered lower priority than 0. So the priority sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7. TRILL Priority DEI DSCP Field (Binary/decimal) -------------- --- ----------------------------- 0 0/1 001000 / 8 1 0/1 000000 / 0 2 0/1 010000 / 16 3 0/1 011000 / 24 4 0/1 100000 / 32 5 0/1 101000 / 40 6 0/1 110000 / 48 7 0/1 111000 / 56 This appear to be an problematic mapping. At least for prio 0 and 1. As = priority 1 appears to be intended to be higher than priority 0, it is = interesting that it is mapped to CS1, which to quote https://datatracker.ietf.org/doc/rfc7657/: CS1 ('001000') was subsequently designated as the recommended codepoint for the Lower Effort (LE) PHB [RFC3662]. So what is proposed can in a network using default mapping, result in = that you get priority 0 to be lower priority than 1. Plus that in some = networks this can also results in strange remapping that results in a = different PHB for CS1 than. MTU and Fragmentation --------------------- I think there are two main issue here. The first one is MTUD discovery = of the actual IP path MTU between the ports. That will be needed to = prevent a lot of traffic going into MTU black holes. Especially as TRILL = requries 1470 byte support which is likey above a lot of paths. Section 8.4: Path MTU discovery [RFC4821] should be useful in determining the IP MTU between a pair of RBridge ports with IP connectivity. The issue with RFC4821 is that it has requirements on the packetization = layer. Trill appears to have several components that are useful. However, it = will require a specification of the procedure to result in a useful = tool. Section 8.4: TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in [RFC7177], can be used to obtain added assurance of the MTU of a link. Yes, that can confirm working MTUs that are at 1470 or above, but = appears prevented from working below 1470? Thus, it appears that there is a lack of mechanism here to actually get = a valid and functional MTU from TRILL in the cases where the Path MTU is = below 1470. If I am wrong good, but I think this is an important piece = for how to handle the next main issue. UDP encapsulation and IP fragments. I see it as a big issue that UDP encapsulation is the native one, and = that relies on IP fragmentation despite the need for reliable = fragmentation. With the setup of having to support 1470 MTU on TRILL = level some packets will be fragmented in many environments. That will = lead to a lot of losses, and as discussed below a very big problem with = middleboxes. The main problem here is that if one tries to rely on IP = fragments one will have issues with packets ending up in black holes. = And different problems depending on IPv4 or IPv6. IPv6 is lilkely the lesser problem assuming that one have working PMTUD. There are several ways out of this. 1. Detect issues and use TCP encapsulation with correctly set MSS to not = get IP fragements 2. Determine MTU and implement an fragmentation = mechanism on top of UDP. Zero Checksum: -------------- Section 5.4: UDP Checksum - as specified in [RFC0768] Considering the fast path encapsulation desire, I am surprised to not = see any mentioning of use of zero checksum here. Raising the zero = checksum and forward reference would be good I think. And then Section 8.5: The requirements for the usage of the zero UDP Checksum in a UDP tunnel protocol are detailed in [RFC6936]. These requirements apply to the UDP based TRILL over IP encapsulations specified herein (native and VXLAN), which are applications of UDP tunnel. If you actually intended to allow zero checksum, then you actually = should document that Trill fulfills the requirements that the = applicability statement raises. I have not analyzed how well it meets = these requirements. Please review Section 6.2 of RFC 8086 for example how that can be done. TCP Encapsulation issue ----------------------- Section 5.6: The TCP encapsulation appear to be missing an delimiter format allowing = each individual TRILL packet/payload to be read out of the TCP's byte = stream. In other words, a normal implementation has no way of ensuring = that the TCP payload starts with the start of a new TRILL payload. = Multiple small TRILL payloads may be included in the same TCP payload, = and also only parts as TCP is one way of dealing with TRILL packets that = are larger than the IP+Encapsulation MTU that actually will work. This comment is based on that there appear to be no length fields = included in the TRILL header. The most straight forward delimiter is a = 2-byte length field for the TRILL payload to be encapsulated. Section 5.6: TCP endpoint requirements. I do wonder if an application like TRILL = actual would need to discuss performance impacting implementation = choices or limitations. For example use of NAGLE, the requirements on = buffer sizes in relation to Bandwidth delay products, as buffer memory = in a RBridge will impact performance. Congestion Control ------------------ First thanks for the effort here. 8.1.2 In Other Environments Where UDP based encapsulation headers are used in TRILL over IP in environments other than those discussed in Section 8.1.1, specific congestion control mechanisms are commonly needed. However, if the traffic being carried by the TRILL over IP link is already congestion controlled and the size and volatility of the TRILL IS-IS link state database is limited, then specific congestion control may not be needed. See [RFC8085] Section 3.1.11 for further guidance. This is correct, however my question is if the RBridges have anyway of = knowing which traffic is actually congestion controlled, considering = that TRILL provides an layer 2 abstraction. I wonder if there should be = any type of white list of the types of layer 2 payloads that can be = assumed to be congestion controlled, and thus okay to forward over IP = paths? I am worried that without any recommendation to prevent traffic = that is not controlled to be forwarded, can lead to congestion issues. The other issue I think may exist is the issue serial unicast emulation = of broadcast/multicast creates. As this amplifies the outgoing packet = rate with a factor of how many addresses are configured for serial = unicast this can be significant traffic expansion. Thus, I think = additional considerations are needed here, and maybe rate limiting of = the amount of traffic to be multicasted. Flow and ECMP ------------- Section 8.3: For example, for TRILL Data, this entropy field could be based on some hash of the Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL. I would appreciate clearer references to what these fields are. If I understand this correctly, the idea here is to look into the inner = layer 2 frames, and use the flow equivalents that exists on that level = and hash that into value that maps the flows onto the source port range. I think this text should include a summary of the principle and ensure = to note the important requirement that what is considered flows in the = inner must not result in being striped over multiple source ports as = this may lead to reordering issues due to packets taking different = paths. NAT and TRILL over IP: Section 8.5: If one like to use TRILL over IP through a NAT, then there are some very = important considerations that are missing. First the need for static = binding configurations or the need for determining ones external = address(es) and be able to communicate that to the peer RBridges, and in = addition ensure that one has keep-alives to that the NAT binding never = times out. Next is the issue that there is almost zero chance of getting a IP/UDP = encapsulation TRILL payload through the NAT if it results in IP = fragmentation, as NATs don't do defragment and refragmented on the = internal side, and an IP fragment lacks UDP port and thus can't be = matched to binding. Also if you like to run IP/ESP through a NAT, then you most likely need = the IP/UDP/ESP encapsulation (https://tools.ietf.org/html/rfc3948). Note = that this will restrict the MTU even further and thus ensure that the = 1470 requirement cannot be fulfilled even without additional tunnels = over an 1500 bytes MTU Ethernet infrastructure. I would note that also firewalls likely have issues with IP fragments = for the same reason, they require significant amount of state to be = verified if they should be let through. In general I think you should create a configuration that has chance to = work through most middleboxes, but I think you should require static = bindings. I think that configuration is, and don't laugh now, but = IP/UDP/ESP/TCP/TRILL, otherwise you will not be able to have both = security and reliable fragmentation of TRILL packets. Cheers Magnus Westerlund From nobody Sun Jun 25 17:07:41 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D25126CC4; Sun, 25 Jun 2017 17:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, URIBL_BLOCKED=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 uxaoUzQECrL6; Sun, 25 Jun 2017 17:07:30 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 90BE4124217; Sun, 25 Jun 2017 17:07:30 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id b205so31637831itg.1; Sun, 25 Jun 2017 17:07:30 -0700 (PDT) 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=VsF13UUI8Adxncjmvg7IEhE9NYx7hp7x9Of78C4O/wk=; b=YUDdjbDup6DWDq2H5HmDhW/A+bI7BEZ2rXQ4ACctQHKlRW2mP1VU2RCjYagQ84nJtX j0j3h/Mv/IuDj7DFzjneLeyZi1ew55NxiLM0Qm5Igsn8DS6/TSFwxOy3O1mC8/81Lz7R 3907/zwSqNrGb1JnAcZbA+On6DgPpqSFW8+pT2X4U8JLySY5rq39+ghFpJU7kh47mqI6 Pdgbi+HxrCRaIAk4Wv3uRyk1oSyqYH2GTFf4sCDFOmGriUsjU0rUiNgmC60PeDncDbFX TXYbB9Fg3KrtWL66vH+967mgUmRp4AkPVKOYZF8dXoxWsTElZ/lPSpv0guaBZbfsHp7C fdYA== 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=VsF13UUI8Adxncjmvg7IEhE9NYx7hp7x9Of78C4O/wk=; b=Ui010ZSJ5F/BF0T0w+7mEY4Ekti8TDfPWg9bMs/EKdAi8o0PyAUiQfH9HCpTn9YwCm 1A8qnanDxW48VXVbsSVl8YrXIWItJSJDiWSXZfyKkX5LJ8tJ5za/rqRAd2A7nkMXL5sj XDnNWNTYqBtB42tRLGvGuKLN+dwFoGKLq+n8aIwMatxp8OVz3QCWNNxlNSvhzRV/D9G+ KS/iMajnZ0XqUt86r2yUHceSEz2IdwvWU0WRTrmBu9zsDFBCIYT2iQDDUAcWUDwBCpTf ylKF22+xH/TYsKHuVySPLJxOYk7MKQ8mdAJce7q3C/6r2HqfNPcZQlExsDeyD2U1mYg7 4iQg== X-Gm-Message-State: AKS2vOy6dcYcUcjZH59F/aNjUSe4YzXDzbS62Axzi8K/39/gaAaaJf3d 73n0WRs01PKhGVe1wTXBzgeLslkWzA== X-Received: by 10.36.20.137 with SMTP id 131mr21713650itg.104.1498435649336; Sun, 25 Jun 2017 17:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.221 with HTTP; Sun, 25 Jun 2017 17:07:13 -0700 (PDT) In-Reply-To: <149754795560.13109.17521244075940607817@ietfa.amsl.com> References: <149754795560.13109.17521244075940607817@ietfa.amsl.com> From: Donald Eastlake Date: Sun, 25 Jun 2017 20:07:13 -0400 Message-ID: To: Magnus Westerlund Cc: tsv-art@ietf.org, "trill@ietf.org" , IETF Discussion , draft-ietf-trill-over-ip.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 00:07:34 -0000 Hi Magnus, Thanks for the extensive review. See my responses below. On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund wrote: > > Reviewer: Magnus Westerlund > Review result: Not Ready > > Early review of draft-ietf-trill-over-ip-10 > Reviewer: Magnus Westerlund > Review result: Not Ready > > TSV-ART review comments: > > I have set this to not ready as there are several issues, some significant that > could affect the protocol realization significantly. Some may be me missing > things in TRILL, I was not that familiar with it before this review and I have > only tried looking up things, not reading the whole earlier specifications. So > don't hesitate to push back and provide pointers to things that can resolve > issues. The authors and the WG clearly have thought about a lot of issues and > dealt with much already. OK. Hopefully we can resolve these one way or the other. > Diffserv usage > -------------- > > Section 4.3: > > TRILL over IP implementations MUST support setting the DSCP value in > the outer IP Header of TRILL packets they send by mapping the TRILL > priority and DEI to the DSCP. They MAY support, for a TRILL Data > packet where the native frame payload is an IP packet, mapping the > DSCP in this inner IP packet to the outer IP Header with the default > for that mapping being to copy the DSCP without change. > > I think it is fine to require that implementations are capable of setting > DSCP values on the outer IP header. However, I fail to see any discussion of > the potential issues with actually setting the DSCP values. It is one thing to > do this in an IP back bone use case where one can know and have control over > the PHB that the DSCP values maps to. But otherwise, over general internet the > behavior is not that predictable. One can easily be subject to policers or > remapping. Also as the actual DSCP code point usage is domain specific this is > difficult. Priority reversal is likely the least of the problems that this can > run into over general Internet. It sounds like appropriate discussion and warnings about these issues would resolve the above comment. > Section 4.3: > > The default TRILL priority and DEI to DSCP mapping, which may be > configured per TRILL over IP port, is an follows. Note that the DEI > value does not affect the default mapping and, to provide a > potentially lower priority service than the default priority 0, > priority 1 is considered lower priority than 0. So the priority > sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7. > > TRILL Priority DEI DSCP Field (Binary/decimal) > -------------- --- ----------------------------- > 0 0/1 001000 / 8 > 1 0/1 000000 / 0 > 2 0/1 010000 / 16 > 3 0/1 011000 / 24 > 4 0/1 100000 / 32 > 5 0/1 101000 / 40 > 6 0/1 110000 / 48 > 7 0/1 111000 / 56 > > This appear to be an problematic mapping. At least for prio 0 and 1. As > priority 1 appears to be intended to be higher than priority 0, it is > interesting that it is mapped to CS1, which to quote > https://datatracker.ietf.org/doc/rfc7657/: > > CS1 ('001000') was subsequently designated as the recommended > codepoint for the Lower Effort (LE) PHB [RFC3662]. > > So what is proposed can in a network using default mapping, result in that you > get priority 0 to be lower priority than 1. Plus that in some networks this can > also results in strange remapping that results in a different PHB for CS1 than. The intent in the draft is to reflect the default relative priority of the different priority code points in IEEE Std 802.1Q where priority 1 is lower than priority 0. At a quick look, it appears to me that RFC 2474 requires that 0x001000 be handled as being of a priority not lower than the priority with which 0x000000 is handled. Yet RFC 3662, which you point to, seems to suggest using 0x001000 as a lower priority code point than 0x000000. Given that 3662 not only does not update 2474 but is only Informational while 2474 is Standards Track, I would say that 2474 dominates and that this draft makes the best assumptions it can about default behavior... > MTU and Fragmentation > --------------------- > > I think there are two main issue here. The first one is MTUD discovery > of the actual IP path MTU between the ports. That will be needed to prevent > a lot of traffic going into MTU black holes. Especially as TRILL requries > 1470 byte support which is likey above a lot of paths. Seems like it would depend on the environments where TRILL was used. For example, I do not think 1470 would be a problem in most Data Center or Internet Exchange point uses, for example. Data Centers sometimes support 9K jumbo frames and the like. In fact, it is probably bad to focus too much on 1470 -- that is a required minimum to be sure that reasonable size link state PDUs can be successfully flooded through the TRILL campus so that routing will work. However, it would commonly be the case that, for the TRILL campus to be useful in a particular case, links need to be able to carry the expected size TRILL Data packets. For example, if there were two parts of a TRILL campus connected by one or a few TRILL over IP links and the end stations in each part were assuming they could use 1500 byte Ethernet packets, then the TRILL over IP links would need to support an MTU based on 1500 + TRILL Header + IP and TRILL over IP encapsulation. And more if security was being used or there were any other reasons for additional headers/encapsulation... > Section 8.4: > > Path MTU discovery [RFC4821] should be useful > in determining the IP MTU between a pair of RBridge ports with IP > connectivity. > > The issue with RFC4821 is that it has requirements on the packetization layer. > Trill appears to have several components that are useful. However, it will > require a specification of the procedure to result in a useful tool. See below. > Section 8.4: > > TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in > [RFC7177], can be used to obtain added assurance of the MTU of a > link. > > Yes, that can confirm working MTUs that are at 1470 or above, but appears > prevented from working below 1470? While there is a minimum size for TRILL IS-IS MTU PDUs, determined by header size, it is well below 1470, probably (depending on whether secuirty is in use, etc.) below 150 bytes. > Thus, it appears that there is a lack of mechanism here to actually get a valid > and functional MTU from TRILL in the cases where the Path MTU is below 1470. If > I am wrong good, but I think this is an important piece for how to handle the > next main issue. How about referencing Section 3 of https://tools.ietf.org/html/draft-ietf-trill-mtu-negotiation-05 which is currently in IETF Last Call? (The wording of that section is probably going to be improved based on an OPS review by Brian Carpenter.) > UDP encapsulation and IP fragments. ---------------------------------- > I see it as a big issue that UDP encapsulation is the native one, and that > relies on IP fragmentation despite the need for reliable fragmentation. With > the setup of having to support 1470 MTU on TRILL level some packets will be > fragmented in many environments. That will lead to a lot of losses, and as > discussed below a very big problem with middleboxes. The main problem here is > that if one tries to rely on IP fragments one will have issues with packets > ending up in black holes. And different problems depending on IPv4 or IPv6. > IPv6 is lilkely the lesser problem assuming that one have working PMTUD. > > There are several ways out of this. > > 1. Detect issues and use TCP encapsulation with correctly set MSS to not get IP > fragements 2. Determine MTU and implement an fragmentation mechanism on top of > UDP. So, I don't see that much problem with UDP being the general default consistent with the TRILL philosophy of defaulting to need zero or minimal configuration. The default should be to use multicast Hellos for discovery of neighbors which sure points at UDP to me. Having to traverse a NAT should be a rare case. Since, in the NAT case, you have to configure things related to the static binding and the IP address(es) of peer(s) anyway you can also configure to use a different encapsulation than UDP, such as TCP, at the same time. I don't see it as much of a problem if, by default, TRILL won't operate through a NAT. If you are using UDP and it fragments and fragments are dropped at a NAT, probably you can't exchange Hellos so you will not form an adjacency and anything on the other side of the NAT will not be visible. > Zero Checksum: > -------------- > > Section 5.4: > > UDP Checksum - as specified in [RFC0768] > > Considering the fast path encapsulation desire, I am surprised to not see any > mentioning of use of zero checksum here. Raising the zero checksum and forward > reference would be good I think. > > And then Section 8.5: > > The requirements for the usage of the zero UDP Checksum in a UDP > tunnel protocol are detailed in [RFC6936]. These requirements apply > to the UDP based TRILL over IP encapsulations specified herein > (native and VXLAN), which are applications of UDP tunnel. > > If you actually intended to allow zero checksum, then you actually should > document that Trill fulfills the requirements that the applicability statement > raises. I have not analyzed how well it meets these requirements. > > Please review Section 6.2 of RFC 8086 for example how that can be done. OK. We'll look into it. > TCP Encapsulation issue > ----------------------- > > Section 5.6: > > The TCP encapsulation appear to be missing an delimiter format allowing each > individual TRILL packet/payload to be read out of the TCP's byte stream. In > other words, a normal implementation has no way of ensuring that the TCP > payload starts with the start of a new TRILL payload. Multiple small TRILL > payloads may be included in the same TCP payload, and also only parts as TCP is > one way of dealing with TRILL packets that are larger than the IP+Encapsulation > MTU that actually will work. > > This comment is based on that there appear to be no length fields included in > the TRILL header. The most straight forward delimiter is a 2-byte length field > for the TRILL payload to be encapsulated. Right. It might also be useful to include some sort of check field, as is done in BGP, to detect if you are out of sync in parsing the TCP stream. Another point is that, while with UDP it seems fine to send packets with assorted QoS, you don't want to encourage re-ordering of TCP packets in a stream. So if TCP encapsulation is being used, you want to use the same DSCP value for the packets in a particular TCP stream. So, generally, you need to have a TCP connection per priority handling category. Mapping the 8 priority levels into a smaller number of handling categories is a normal thing to do so you certainly don't necessarily need 8 TCP connections. Adding material on this should not be too hard. > Section 5.6: > > TCP endpoint requirements. I do wonder if an application like TRILL actual > would need to discuss performance impacting implementation choices or > limitations. For example use of NAGLE, the requirements on buffer sizes in > relation to Bandwidth delay products, as buffer memory in a RBridge will impact > performance. Well, I'm not sure how deeply this document should get into such performance issues. What about just saying something about consideration being given to tuning TCP for performance and pointing to one or a few other RFCs that talk about this? > Congestion Control > ------------------ > First thanks for the effort here. You're welcome. > 8.1.2 In Other Environments > > Where UDP based encapsulation headers are used in TRILL over IP in > environments other than those discussed in Section 8.1.1, specific > congestion control mechanisms are commonly needed. However, if the > traffic being carried by the TRILL over IP link is already congestion > controlled and the size and volatility of the TRILL IS-IS link state > database is limited, then specific congestion control may not be > needed. See [RFC8085] Section 3.1.11 for further guidance. > > This is correct, however my question is if the RBridges have any way of knowing > which traffic is actually congestion controlled, considering that TRILL provides > an layer 2 abstraction. I wonder if there should be any type of white list of > the types of layer 2 payloads that can be assumed to be congestion controlled, > and thus okay to forward over IP paths? I am worried that without any > recommendation to prevent traffic that is not controlled to be forwarded, can > lead to congestion issues. > > The other issue I think may exist is the issue serial unicast emulation of > broadcast/multicast creates. As this amplifies the outgoing packet rate with > a factor of how many addresses are configured for serial unicast this can > be significant traffic expansion. Thus, I think additional considerations are > needed here, and maybe rate limiting of the amount of traffic to be multicasted. OK. We can think about those issues. > Flow and ECMP > ------------- > > Section 8.3: > > For example, for TRILL > Data, this entropy field could be based on some hash of the > Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL. > > I would appreciate clearer references to what these fields are. In a TRILL Data packet, the payload after the TRILL Header looks like an Ethernet frame except that there is always either a VLAN tag or, alternatively, where the VLAN tag would be, a Fine Grained Label [RFC7172]. (The preceding is the view in the TRILL RFCs, but there is an equivalent and equally valid view in which all the fields through and including the VLAN or FGL tag are part of the TRILL Header.) The TRILL base protocol specification focuses on Ethernet as a link technology between TRILL switches, in which case there will be a link header including an Outer.MacDA and Outer.MacSA fields and possibly an Outer.VLAN, all before the TRILL Header. See Figure 1 and Figure 2 in RFC 7172. Some of the above could be added to the draft for clarity. > If I understand this correctly, the idea here is to look into the inner > layer 2 frames, and use the flow equivalents that exists on that level and > hash that into value that maps the flows onto the source port range. Yes. > I think this text should include a summary of the principle and ensure to > note the important requirement that what is considered flows in the inner > must not result in being striped over multiple source ports as this may lead to > reordering issues due to packets taking different paths. Well, we can add some text. But when would the relative ordering matter for two TRILL Data packets where the two inner native payloads have different values for any one or more of these three fields (Inner.MacDA, Inner.MacSA, and inner VLAN/FGL tag) ? If any of those fields are different, you are talking about different streams. > NAT and TRILL over IP: > Section 8.5: > > If one like to use TRILL over IP through a NAT, then there are some very > important considerations that are missing. First the need for static binding > configurations or the need for determining ones external address(es) and be > able to communicate that to the peer RBridges, and in addition ensure that one > has keep-alives to that the NAT binding never times out. I think those are good points. There is an additional problem that TRILL Hellos detect neighbors with which they have 2-way connectivity by indicating, inside the Hellos that are sent, from what neighbors Hellos have been received on that port. If a NAT is involved, these neighbor addresses inside Hellos need to be mapped. > Next is the issue that there is almost zero chance of getting a IP/UDP > encapsulation TRILL payload through the NAT if it results in IP fragmentation, > as NATs don't do defragment and refragmented on the internal side, and an IP > fragment lacks UDP port and thus can't be matched to binding. So perhaps the recommendation should be to configure the port to use TCP if there will be fragmentation. > Also if you like to run IP/ESP through a NAT, then you most likely need the > IP/UDP/ESP encapsulation (https://tools.ietf.org/html/rfc3948). Note that this > will restrict the MTU even further and thus ensure that the 1470 requirement > cannot be fulfilled even without additional tunnels over an 1500 bytes MTU > Ethernet infrastructure. > > I would note that also firewalls likely have issues with IP fragments for the > same reason, they require significant amount of state to be verified if they > should be let through. > > In general I think you should create a configuration that has chance to work > through most middleboxes, but I think you should require static bindings. I > think that configuration is, and don't laugh now, but IP/UDP/ESP/TCP/TRILL, > otherwise you will not be able to have both security and reliable fragmentation > of TRILL packets. OK. Thanks again for this review. It has pointed out a number of problems and in thinking about those, I believe a couple of further problems have come to mind that I mentioned above. We'll work on a revised draft. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Cheers > > Magnus Westerlund From nobody Mon Jun 26 10:16:25 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D4C12EB0C; Mon, 26 Jun 2017 10:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 7L-oEZXtGeLI; Mon, 26 Jun 2017 10:16:12 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 0BDB1129BC4; Mon, 26 Jun 2017 10:16:12 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v5QHFGGQ023397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Jun 2017 10:15:18 -0700 (PDT) To: Donald Eastlake , Magnus Westerlund Cc: tsv-art@ietf.org, draft-ietf-trill-over-ip.all@ietf.org, IETF Discussion , "trill@ietf.org" References: <149754795560.13109.17521244075940607817@ietfa.amsl.com> From: Joe Touch Message-ID: <7cc18878-970a-efbe-8488-a4110b9b24e9@isi.edu> Date: Mon, 26 Jun 2017 10:15:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:16:14 -0000 Hi, Donald, On 6/25/2017 5:07 PM, Donald Eastlake wrote: > Hi Magnus, > > Thanks for the extensive review. See my responses below. > > On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund > wrote: >> Reviewer: Magnus Westerlund >> Review result: Not Ready >> >> Early review of draft-ietf-trill-over-ip-10 >> Reviewer: Magnus Westerlund >> Review result: Not Ready >> >> TSV-ART review comments: >> >> I have set this to not ready as there are several issues, some significant that >> could affect the protocol realization significantly. Some may be me missing >> things in TRILL, I was not that familiar with it before this review and I have >> only tried looking up things, not reading the whole earlier specifications. So >> don't hesitate to push back and provide pointers to things that can resolve >> issues. The authors and the WG clearly have thought about a lot of issues and >> dealt with much already. > OK. Hopefully we can resolve these one way or the other. > > ... >> TCP Encapsulation issue >> ----------------------- >> >> Section 5.6: >> >> The TCP encapsulation appear to be missing an delimiter format allowing each >> individual TRILL packet/payload to be read out of the TCP's byte stream. In >> other words, a normal implementation has no way of ensuring that the TCP >> payload starts with the start of a new TRILL payload. Multiple small TRILL >> payloads may be included in the same TCP payload, and also only parts as TCP is >> one way of dealing with TRILL packets that are larger than the IP+Encapsulation >> MTU that actually will work. >> >> This comment is based on that there appear to be no length fields included in >> the TRILL header. The most straight forward delimiter is a 2-byte length field >> for the TRILL payload to be encapsulated. > Right. It might also be useful to include some sort of check field, as > is done in BGP, to detect if you are out of sync in parsing the TCP > stream. There is nothing in BGP that ever assumes that TCP write boundaries are preserved. BGP uses markers and length fields to create message boundaries in TCP's bytestream. The same is needed here. Note that BGP also never claims to craft TCP packets by 'encapsulating' a BGP message in a TCP segment. That part of this document needs to be removed - it not how TCP is ever used. > Another point is that, while with UDP it seems fine to send packets > with assorted QoS, you don't want to encourage re-ordering of TCP > packets in a stream. So if TCP encapsulation is being used, Again - please, NO. NEVER use this term. > you want > to use the same DSCP value for the packets in a particular TCP stream. Again, this is nonsensical. TCP would set a DSCP for the connection, never in different ways for individual segments of a connection. > So, generally, you need to have a TCP connection per priority handling > category. Mapping the 8 priority levels into a smaller number of > handling categories is a normal thing to do so you certainly don't > necessarily need 8 TCP connections. Adding material on this should not > be too hard. Perhaps, but please - again, please - omit any mention or implication that this occurs via encapsulation. If you want to use TCP, please use it properly. > >> Section 5.6: >> >> TCP endpoint requirements. I do wonder if an application like TRILL actual >> would need to discuss performance impacting implementation choices or >> limitations. For example use of NAGLE, the requirements on buffer sizes in >> relation to Bandwidth delay products, as buffer memory in a RBridge will impact >> performance. > Well, I'm not sure how deeply this document should get into such > performance issues. What about just saying something about > consideration being given to tuning TCP for performance and pointing > to one or a few other RFCs that talk about this? Because your use of TCP (even if changed to describe it correctly) isn't listed in those TCP RFCs. And it's not so simple - NAGLE helps performance for interactive systems that use single-byte messages (e.g., telnet) and reduces the number of outstanding "less than full" segments. When used for encapsulation, turning NAGLE off is the right thing for multibyte messages (e.g., TRILL messages) and can avoid the "gathering" delay (200 ms stalls when there isn't enough source data - i.e., incoming TRILL packets - to keep up with the outgoing segments), but could also generate a large number of small segments (which can interfere with segment-based congestion control, vs. ABC). Unless you want a very poorly performing result, *THIS* is what you need to drill down into. Joe From nobody Mon Jun 26 11:43:11 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E70E129B17; Mon, 26 Jun 2017 11:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 7MvGN6U9DXCD; Mon, 26 Jun 2017 11:42:52 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 3A49E1270AC; Mon, 26 Jun 2017 11:42:52 -0700 (PDT) Received: from [128.9.184.87] ([128.9.184.87]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v5QIgIg6009301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Jun 2017 11:42:18 -0700 (PDT) From: Joe Touch To: Donald Eastlake , Magnus Westerlund Cc: tsv-art@ietf.org, "trill@ietf.org" , IETF Discussion , draft-ietf-trill-over-ip.all@ietf.org References: <149754795560.13109.17521244075940607817@ietfa.amsl.com> <7cc18878-970a-efbe-8488-a4110b9b24e9@isi.edu> Message-ID: Date: Mon, 26 Jun 2017 11:42:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <7cc18878-970a-efbe-8488-a4110b9b24e9@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] [trill] Tsvart early review of draft-ietf-trill-over-ip-10 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 18:42:54 -0000 PS - the idea that TCP segments within a single connection should ever have different DSCPs is a good example of why it's a bad idea to even 'think' of TRILL over TCP as direct encapsulation. I.e., that concept is inherently hazardous and should be avoided. Joe On 6/26/2017 10:15 AM, Joe Touch wrote: > Hi, Donald, > > > On 6/25/2017 5:07 PM, Donald Eastlake wrote: >> Hi Magnus, >> >> Thanks for the extensive review. See my responses below. >> >> On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund >> wrote: >>> Reviewer: Magnus Westerlund >>> Review result: Not Ready >>> >>> Early review of draft-ietf-trill-over-ip-10 >>> Reviewer: Magnus Westerlund >>> Review result: Not Ready >>> >>> TSV-ART review comments: >>> >>> I have set this to not ready as there are several issues, some significant that >>> could affect the protocol realization significantly. Some may be me missing >>> things in TRILL, I was not that familiar with it before this review and I have >>> only tried looking up things, not reading the whole earlier specifications. So >>> don't hesitate to push back and provide pointers to things that can resolve >>> issues. The authors and the WG clearly have thought about a lot of issues and >>> dealt with much already. >> OK. Hopefully we can resolve these one way or the other. >> >> ... >>> TCP Encapsulation issue >>> ----------------------- >>> >>> Section 5.6: >>> >>> The TCP encapsulation appear to be missing an delimiter format allowing each >>> individual TRILL packet/payload to be read out of the TCP's byte stream. In >>> other words, a normal implementation has no way of ensuring that the TCP >>> payload starts with the start of a new TRILL payload. Multiple small TRILL >>> payloads may be included in the same TCP payload, and also only parts as TCP is >>> one way of dealing with TRILL packets that are larger than the IP+Encapsulation >>> MTU that actually will work. >>> >>> This comment is based on that there appear to be no length fields included in >>> the TRILL header. The most straight forward delimiter is a 2-byte length field >>> for the TRILL payload to be encapsulated. >> Right. It might also be useful to include some sort of check field, as >> is done in BGP, to detect if you are out of sync in parsing the TCP >> stream. > There is nothing in BGP that ever assumes that TCP write boundaries are > preserved. BGP uses markers and length fields to create message > boundaries in TCP's bytestream. The same is needed here. > > Note that BGP also never claims to craft TCP packets by 'encapsulating' > a BGP message in a TCP segment. That part of this document needs to be > removed - it not how TCP is ever used. > >> Another point is that, while with UDP it seems fine to send packets >> with assorted QoS, you don't want to encourage re-ordering of TCP >> packets in a stream. So if TCP encapsulation is being used, > Again - please, NO. NEVER use this term. > >> you want >> to use the same DSCP value for the packets in a particular TCP stream. > Again, this is nonsensical. TCP would set a DSCP for the connection, > never in different ways for individual segments of a connection. > > >> So, generally, you need to have a TCP connection per priority handling >> category. Mapping the 8 priority levels into a smaller number of >> handling categories is a normal thing to do so you certainly don't >> necessarily need 8 TCP connections. Adding material on this should not >> be too hard. > Perhaps, but please - again, please - omit any mention or implication > that this occurs via encapsulation. > > If you want to use TCP, please use it properly. > >>> Section 5.6: >>> >>> TCP endpoint requirements. I do wonder if an application like TRILL actual >>> would need to discuss performance impacting implementation choices or >>> limitations. For example use of NAGLE, the requirements on buffer sizes in >>> relation to Bandwidth delay products, as buffer memory in a RBridge will impact >>> performance. >> Well, I'm not sure how deeply this document should get into such >> performance issues. What about just saying something about >> consideration being given to tuning TCP for performance and pointing >> to one or a few other RFCs that talk about this? > Because your use of TCP (even if changed to describe it correctly) isn't > listed in those TCP RFCs. > > And it's not so simple - NAGLE helps performance for interactive systems > that use single-byte messages (e.g., telnet) and reduces the number of > outstanding "less than full" segments. When used for encapsulation, > turning NAGLE off is the right thing for multibyte messages (e.g., TRILL > messages) and can avoid the "gathering" delay (200 ms stalls when there > isn't enough source data - i.e., incoming TRILL packets - to keep up > with the outgoing segments), but could also generate a large number of > small segments (which can interfere with segment-based congestion > control, vs. ABC). > > Unless you want a very poorly performing result, *THIS* is what you need > to drill down into. > > Joe > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From nobody Mon Jun 26 12:04:35 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8C112EB4E; Mon, 26 Jun 2017 12:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=AD7Fxyvr; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=FF2f19Ti 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 m4Op5HaFwkEn; Mon, 26 Jun 2017 12:04:21 -0700 (PDT) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B24512EB49; Mon, 26 Jun 2017 12:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1498503366; x=1530039366; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=7bmGUcIENJgAQDkTWPpxmp8xiAPCp4TMP1NJbeM6UJc=; b=AD7Fxyvrh2yR3CukEi/prueBDU/aTOv7GDaNgsswj/K5/hJkdKHjMTjR NXeuMFxA4adPXt2GCj/zsUTG6qgz1idXJ3x6dfKOOtboQeWrHOcyex3d7 7O9mJWC9+5B5QtuY1UZqEt6zgI7ApD/hS7x/ulTE4qYwpwrVYPSmoWrc3 8=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2017 13:56:05 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 00:58:23 +0600 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5QJ4Eha028332 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jun 2017 15:04:16 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v5QJ4Eha028332 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1498503857; bh=/mK0Pk3Pm349kX4HfoBi5jS0hoQ=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=FF2f19Ti1xflbQL+i+1RtceV/iWfJ4WizRAgHxFtCVqjwA75/w30WkAF305E28D5M /KQ9WHRqXS57qlSSPo4pUtbGtrZbhjm/H8sPneSQG5zg2ri84sfk+F1mjd1oPQtbJs jEkSqRSHPsjFQuOpV1QYdmfPFqUK1NWYqSbTQQxY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v5QJ4Eha028332 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd56.lss.emc.com (RSA Interceptor); Mon, 26 Jun 2017 15:03:47 -0400 Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5QJ41AM001658 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 26 Jun 2017 15:04:02 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0352.000; Mon, 26 Jun 2017 15:04:01 -0400 To: Donald Eastlake , Magnus Westerlund CC: "tsv-art@ietf.org" , "draft-ietf-trill-over-ip.all@ietf.org" , IETF Discussion , "trill@ietf.org" Thread-Topic: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations Thread-Index: AdLurvO3SYOqL32fRKuavuJggYEWYw== Date: Mon, 26 Jun 2017 19:04:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 19:04:25 -0000 Adding some comments on ECN and DSCP ... > > Section 4.3: > > > > TRILL over IP implementations MUST support setting the DSCP value in > > the outer IP Header of TRILL packets they send by mapping the TRILL > > priority and DEI to the DSCP. They MAY support, for a TRILL Data > > packet where the native frame payload is an IP packet, mapping the > > DSCP in this inner IP packet to the outer IP Header with the default > > for that mapping being to copy the DSCP without change. > > > > I think it is fine to require that implementations are capable of setti= ng > > DSCP values on the outer IP header. However, I fail to see any discussi= on of > > the potential issues with actually setting the DSCP values. It is one t= hing to > > do this in an IP back bone use case where one can know and have control > > over the PHB that the DSCP values maps to. But otherwise, over general > > internet the > > behavior is not that predictable. One can easily be subject to policers= or > > remapping. Also as the actual DSCP code point usage is domain specific = this is > > difficult. Priority reversal is likely the least of the problems that t= his can > > run into over general Internet. >=20 > It sounds like appropriate discussion and warnings about these issues > would resolve the above comment. For ECN, see RFC 6040 and draft-ietf-tsvwg-rfc6040update-shim. In particul= ar, copying the inner ECN codepoint to the outer IP header encapsulation withou= t requiring decapsulation processing as specified in RFC 6040 or the 6040upda= te-shim draft can lose congestion indications from the network and hence is wrong (it's also wrong wrt RFC 3168, but RFC 6040 and the 6040update-shim drafts = are better and more current references). For DSCPs, start with RFC 2983 - thinking about the validity (or likely val= idity) of the outer DSCP at the decapsulator may help in choosing whether to recommend a uniform model (e.g., copy DSCP out at ingress, copy back in at egress) or a pipe model (e.g., do something reasonable for outer DSCP at ingress, ignore it on egress) as the implementation default. -- DSCP mapping to/from TRILL/Ethernet priorities > The intent in the draft is to reflect the default relative priority of > the different priority code points in IEEE Std 802.1Q where priority 1 > is lower than priority 0. At a quick look, it appears to me that RFC > 2474 requires that 0x001000 be handled as being of a priority not > lower than the priority with which 0x000000 is handled. Yet RFC 3662, > which you point to, seems to suggest using 0x001000 as a lower > priority code point than 0x000000. Given that 3662 not only does not > update 2474 but is only Informational while 2474 is Standards Track, I > would say that 2474 dominates and that this draft makes the best > assumptions it can about default behavior... Well ... that's a discussion about text in RFCs that are well over a decade old, and in an area (less-than-best-effort service) where the aspirations of at least RFC 3662 weren't realized ... but that RFC is not safe to ignor= e, either. In practice, the specification of CS1 for less-than-best-effort service has been promulgated by RFC 4594 rather than RFC 3662, and RFC 4594 has had significant "running code" impact on network design and operation. As Magnus mentioned RFC7657, I strongly suggest starting from the RFC 7657 discussion of this topic in order to figure out what to do. I'm not sure what to recommend, but I do think that starting from RFC 7657 (rather than RFC 2474 and RFC 3662) is the better approach. FWIW, the TSVWG WG is in the process of figuring out which DSCP to recommend for less-than-best-effort-service in place of CS1 - that's likely to be an active topic of discussion in Prague.=20 Thanks, --David > -----Original Message----- > From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Donald > Eastlake > Sent: Sunday, June 25, 2017 8:07 PM > To: Magnus Westerlund > Cc: tsv-art@ietf.org; draft-ietf-trill-over-ip.all@ietf.org; IETF Discuss= ion > ; trill@ietf.org > Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 >=20 > Hi Magnus, >=20 > Thanks for the extensive review. See my responses below. >=20 > On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund > wrote: > > > > Reviewer: Magnus Westerlund > > Review result: Not Ready > > > > Early review of draft-ietf-trill-over-ip-10 > > Reviewer: Magnus Westerlund > > Review result: Not Ready > > > > TSV-ART review comments: > > > > I have set this to not ready as there are several issues, some signific= ant that > > could affect the protocol realization significantly. Some may be me mis= sing > > things in TRILL, I was not that familiar with it before this review and= I have > > only tried looking up things, not reading the whole earlier specificati= ons. So > > don't hesitate to push back and provide pointers to things that can res= olve > > issues. The authors and the WG clearly have thought about a lot of issu= es > and > > dealt with much already. >=20 > OK. Hopefully we can resolve these one way or the other. >=20 > > Diffserv usage > > -------------- > > > > Section 4.3: > > > > TRILL over IP implementations MUST support setting the DSCP value in > > the outer IP Header of TRILL packets they send by mapping the TRILL > > priority and DEI to the DSCP. They MAY support, for a TRILL Data > > packet where the native frame payload is an IP packet, mapping the > > DSCP in this inner IP packet to the outer IP Header with the default > > for that mapping being to copy the DSCP without change. > > > > I think it is fine to require that implementations are capable of sett= ing > > DSCP values on the outer IP header. However, I fail to see any discussi= on of > > the potential issues with actually setting the DSCP values. It is one t= hing to > > do this in an IP back bone use case where one can know and have control > over > > the PHB that the DSCP values maps to. But otherwise, over general > internet the > > behavior is not that predictable. One can easily be subject to policers= or > > remapping. Also as the actual DSCP code point usage is domain specific = this > is > > difficult. Priority reversal is likely the least of the problems that t= his can > > run into over general Internet. >=20 > It sounds like appropriate discussion and warnings about these issues > would resolve the above comment. >=20 > > Section 4.3: > > > > The default TRILL priority and DEI to DSCP mapping, which may be > > configured per TRILL over IP port, is an follows. Note that the DEI > > value does not affect the default mapping and, to provide a > > potentially lower priority service than the default priority 0, > > priority 1 is considered lower priority than 0. So the priority > > sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7. > > > > TRILL Priority DEI DSCP Field (Binary/decimal) > > -------------- --- ----------------------------- > > 0 0/1 001000 / 8 > > 1 0/1 000000 / 0 > > 2 0/1 010000 / 16 > > 3 0/1 011000 / 24 > > 4 0/1 100000 / 32 > > 5 0/1 101000 / 40 > > 6 0/1 110000 / 48 > > 7 0/1 111000 / 56 > > > > This appear to be an problematic mapping. At least for prio 0 and 1. As > > priority 1 appears to be intended to be higher than priority 0, it is > > interesting that it is mapped to CS1, which to quote > > https://datatracker.ietf.org/doc/rfc7657/: > > > > CS1 ('001000') was subsequently designated as the recommended > > codepoint for the Lower Effort (LE) PHB [RFC3662]. > > > > So what is proposed can in a network using default mapping, result in t= hat > you > > get priority 0 to be lower priority than 1. Plus that in some networks = this can > > also results in strange remapping that results in a different PHB for C= S1 > than. >=20 > The intent in the draft is to reflect the default relative priority of > the different priority code points in IEEE Std 802.1Q where priority 1 > is lower than priority 0. At a quick look, it appears to me that RFC > 2474 requires that 0x001000 be handled as being of a priority not > lower than the priority with which 0x000000 is handled. Yet RFC 3662, > which you point to, seems to suggest using 0x001000 as a lower > priority code point than 0x000000. Given that 3662 not only does not > update 2474 but is only Informational while 2474 is Standards Track, I > would say that 2474 dominates and that this draft makes the best > assumptions it can about default behavior... >=20 > > MTU and Fragmentation > > --------------------- > > > > I think there are two main issue here. The first one is MTUD discovery > > of the actual IP path MTU between the ports. That will be needed to > prevent > > a lot of traffic going into MTU black holes. Especially as TRILL requri= es > > 1470 byte support which is likey above a lot of paths. >=20 > Seems like it would depend on the environments where TRILL was used. > For example, I do not think 1470 would be a problem in most Data > Center or Internet Exchange point uses, for example. Data Centers > sometimes support 9K jumbo frames and the like. >=20 > In fact, it is probably bad to focus too much on 1470 -- that is a > required minimum to be sure that reasonable size link state PDUs can > be successfully flooded through the TRILL campus so that routing will > work. However, it would commonly be the case that, for the TRILL > campus to be useful in a particular case, links need to be able to > carry the expected size TRILL Data packets. For example, if there were > two parts of a TRILL campus connected by one or a few TRILL over IP > links and the end stations in each part were assuming they could use > 1500 byte Ethernet packets, then the TRILL over IP links would need to > support an MTU based on 1500 + TRILL Header + IP and TRILL over IP > encapsulation. And more if security was being used or there were any > other reasons for additional headers/encapsulation... >=20 > > Section 8.4: > > > > Path MTU discovery [RFC4821] should be useful > > in determining the IP MTU between a pair of RBridge ports with IP > > connectivity. > > > > The issue with RFC4821 is that it has requirements on the packetization > layer. > > Trill appears to have several components that are useful. However, it w= ill > > require a specification of the procedure to result in a useful tool. >=20 > See below. >=20 > > Section 8.4: > > > > TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in > > [RFC7177], can be used to obtain added assurance of the MTU of a > > link. > > > > Yes, that can confirm working MTUs that are at 1470 or above, but appea= rs > > prevented from working below 1470? >=20 > While there is a minimum size for TRILL IS-IS MTU PDUs, determined by > header size, it is well below 1470, probably (depending on whether > secuirty is in use, etc.) below 150 bytes. >=20 > > Thus, it appears that there is a lack of mechanism here to actually get= a valid > > and functional MTU from TRILL in the cases where the Path MTU is below > 1470. If > > I am wrong good, but I think this is an important piece for how to hand= le > the > > next main issue. >=20 > How about referencing Section 3 of > https://tools.ietf.org/html/draft-ietf-trill-mtu-negotiation-05 > which is currently in IETF Last Call? (The wording of that section is > probably going to be improved based on an OPS review by Brian > Carpenter.) >=20 > > UDP encapsulation and IP fragments. > ---------------------------------- > > I see it as a big issue that UDP encapsulation is the native one, and t= hat > > relies on IP fragmentation despite the need for reliable fragmentation. > With > > the setup of having to support 1470 MTU on TRILL level some packets wil= l > be > > fragmented in many environments. That will lead to a lot of losses, and= as > > discussed below a very big problem with middleboxes. The main problem > here is > > that if one tries to rely on IP fragments one will have issues with pac= kets > > ending up in black holes. And different problems depending on IPv4 or > IPv6. > > IPv6 is lilkely the lesser problem assuming that one have working PMTUD= . > > > > There are several ways out of this. > > > > 1. Detect issues and use TCP encapsulation with correctly set MSS to no= t > get IP > > fragements 2. Determine MTU and implement an fragmentation > mechanism on top of > > UDP. >=20 > So, I don't see that much problem with UDP being the general default > consistent with the TRILL philosophy of defaulting to need zero or > minimal configuration. The default should be to use multicast Hellos > for discovery of neighbors which sure points at UDP to me. Having to > traverse a NAT should be a rare case. Since, in the NAT case, you have > to configure things related to the static binding and the IP > address(es) of peer(s) anyway you can also configure to use a > different encapsulation than UDP, such as TCP, at the same time. I > don't see it as much of a problem if, by default, TRILL won't operate > through a NAT. If you are using UDP and it fragments and fragments are > dropped at a NAT, probably you can't exchange Hellos so you will not > form an adjacency and anything on the other side of the NAT will not > be visible. >=20 > > Zero Checksum: > > -------------- > > > > Section 5.4: > > > > UDP Checksum - as specified in [RFC0768] > > > > Considering the fast path encapsulation desire, I am surprised to not s= ee > any > > mentioning of use of zero checksum here. Raising the zero checksum and > forward > > reference would be good I think. > > > > And then Section 8.5: > > > > The requirements for the usage of the zero UDP Checksum in a UDP > > tunnel protocol are detailed in [RFC6936]. These requirements apply > > to the UDP based TRILL over IP encapsulations specified herein > > (native and VXLAN), which are applications of UDP tunnel. > > > > If you actually intended to allow zero checksum, then you actually shou= ld > > document that Trill fulfills the requirements that the applicability st= atement > > raises. I have not analyzed how well it meets these requirements. > > > > Please review Section 6.2 of RFC 8086 for example how that can be done. >=20 > OK. We'll look into it. >=20 > > TCP Encapsulation issue > > ----------------------- > > > > Section 5.6: > > > > The TCP encapsulation appear to be missing an delimiter format allowing > each > > individual TRILL packet/payload to be read out of the TCP's byte stream= . In > > other words, a normal implementation has no way of ensuring that the TC= P > > payload starts with the start of a new TRILL payload. Multiple small TR= ILL > > payloads may be included in the same TCP payload, and also only parts a= s > TCP is > > one way of dealing with TRILL packets that are larger than the > IP+Encapsulation > > MTU that actually will work. > > > > This comment is based on that there appear to be no length fields inclu= ded > in > > the TRILL header. The most straight forward delimiter is a 2-byte lengt= h > field > > for the TRILL payload to be encapsulated. >=20 > Right. It might also be useful to include some sort of check field, as > is done in BGP, to detect if you are out of sync in parsing the TCP > stream. >=20 > Another point is that, while with UDP it seems fine to send packets > with assorted QoS, you don't want to encourage re-ordering of TCP > packets in a stream. So if TCP encapsulation is being used, you want > to use the same DSCP value for the packets in a particular TCP stream. > So, generally, you need to have a TCP connection per priority handling > category. Mapping the 8 priority levels into a smaller number of > handling categories is a normal thing to do so you certainly don't > necessarily need 8 TCP connections. Adding material on this should not > be too hard. >=20 > > Section 5.6: > > > > TCP endpoint requirements. I do wonder if an application like TRILL act= ual > > would need to discuss performance impacting implementation choices or > > limitations. For example use of NAGLE, the requirements on buffer sizes= in > > relation to Bandwidth delay products, as buffer memory in a RBridge wil= l > impact > > performance. >=20 > Well, I'm not sure how deeply this document should get into such > performance issues. What about just saying something about > consideration being given to tuning TCP for performance and pointing > to one or a few other RFCs that talk about this? >=20 > > Congestion Control > > ------------------ > > First thanks for the effort here. >=20 > You're welcome. >=20 > > 8.1.2 In Other Environments > > > > Where UDP based encapsulation headers are used in TRILL over IP in > > environments other than those discussed in Section 8.1.1, specific > > congestion control mechanisms are commonly needed. However, if the > > traffic being carried by the TRILL over IP link is already congestio= n > > controlled and the size and volatility of the TRILL IS-IS link state > > database is limited, then specific congestion control may not be > > needed. See [RFC8085] Section 3.1.11 for further guidance. > > > > This is correct, however my question is if the RBridges have any way of > knowing > > which traffic is actually congestion controlled, considering that TRILL > provides > > an layer 2 abstraction. I wonder if there should be any type of white l= ist of > > the types of layer 2 payloads that can be assumed to be congestion > controlled, > > and thus okay to forward over IP paths? I am worried that without any > > recommendation to prevent traffic that is not controlled to be forwarde= d, > can > > lead to congestion issues. > > > > The other issue I think may exist is the issue serial unicast emulation= of > > broadcast/multicast creates. As this amplifies the outgoing packet rate= with > > a factor of how many addresses are configured for serial unicast this c= an > > be significant traffic expansion. Thus, I think additional consideratio= ns are > > needed here, and maybe rate limiting of the amount of traffic to be > multicasted. >=20 > OK. We can think about those issues. >=20 > > Flow and ECMP > > ------------- > > > > Section 8.3: > > > > For example, for TRILL > > Data, this entropy field could be based on some hash of the > > Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL. > > > > I would appreciate clearer references to what these fields are. >=20 > In a TRILL Data packet, the payload after the TRILL Header looks like > an Ethernet frame except that there is always either a VLAN tag or, > alternatively, where the VLAN tag would be, a Fine Grained Label > [RFC7172]. (The preceding is the view in the TRILL RFCs, but there is > an equivalent and equally valid view in which all the fields through > and including the VLAN or FGL tag are part of the TRILL Header.) The > TRILL base protocol specification focuses on Ethernet as a link > technology between TRILL switches, in which case there will be a link > header including an Outer.MacDA and Outer.MacSA fields and possibly an > Outer.VLAN, all before the TRILL Header. See Figure 1 and Figure 2 in > RFC 7172. >=20 > Some of the above could be added to the draft for clarity. >=20 > > If I understand this correctly, the idea here is to look into the inner > > layer 2 frames, and use the flow equivalents that exists on that level = and > > hash that into value that maps the flows onto the source port range. >=20 > Yes. >=20 > > I think this text should include a summary of the principle and ensure = to > > note the important requirement that what is considered flows in the inn= er > > must not result in being striped over multiple source ports as this may= lead > to > > reordering issues due to packets taking different paths. >=20 > Well, we can add some text. But when would the relative ordering > matter for two TRILL Data packets where the two inner native payloads > have different values for any one or more of these three fields > (Inner.MacDA, Inner.MacSA, and inner VLAN/FGL tag) ? If any of those > fields are different, you are talking about different streams. >=20 > > NAT and TRILL over IP: > > Section 8.5: > > > > If one like to use TRILL over IP through a NAT, then there are some ver= y > > important considerations that are missing. First the need for static bi= nding > > configurations or the need for determining ones external address(es) an= d > be > > able to communicate that to the peer RBridges, and in addition ensure t= hat > one > > has keep-alives to that the NAT binding never times out. >=20 > I think those are good points. There is an additional problem that > TRILL Hellos detect neighbors with which they have 2-way connectivity > by indicating, inside the Hellos that are sent, from what neighbors > Hellos have been received on that port. If a NAT is involved, these > neighbor addresses inside Hellos need to be mapped. >=20 > > Next is the issue that there is almost zero chance of getting a IP/UDP > > encapsulation TRILL payload through the NAT if it results in IP > fragmentation, > > as NATs don't do defragment and refragmented on the internal side, and > an IP > > fragment lacks UDP port and thus can't be matched to binding. >=20 > So perhaps the recommendation should be to configure the port to use > TCP if there will be fragmentation. >=20 > > Also if you like to run IP/ESP through a NAT, then you most likely need= the > > IP/UDP/ESP encapsulation (https://tools.ietf.org/html/rfc3948). Note th= at > this > > will restrict the MTU even further and thus ensure that the 1470 > requirement > > cannot be fulfilled even without additional tunnels over an 1500 bytes = MTU > > Ethernet infrastructure. > > > > I would note that also firewalls likely have issues with IP fragments f= or the > > same reason, they require significant amount of state to be verified if= they > > should be let through. > > > > In general I think you should create a configuration that has chance to= work > > through most middleboxes, but I think you should require static binding= s. I > > think that configuration is, and don't laugh now, but > IP/UDP/ESP/TCP/TRILL, > > otherwise you will not be able to have both security and reliable > fragmentation > > of TRILL packets. >=20 > OK. Thanks again for this review. It has pointed out a number of > problems and in thinking about those, I believe a couple of further > problems have come to mind that I mentioned above. We'll work on a > revised draft. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >=20 > > Cheers > > > > Magnus Westerlund >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Tue Jun 27 10:13:40 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820C812EA53; Tue, 27 Jun 2017 10:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Wz8GK2vFBeYK; Tue, 27 Jun 2017 10:13:14 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0BA012EA67; Tue, 27 Jun 2017 10:13:11 -0700 (PDT) X-AuditID: c1b4fb25-eedff700000016ef-ab-595292257858 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CE.46.05871.52292595; Tue, 27 Jun 2017 19:13:10 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.195]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Tue, 27 Jun 2017 19:13:09 +0200 From: Magnus Westerlund To: Donald Eastlake CC: "tsv-art@ietf.org" , "trill@ietf.org" , IETF Discussion , "draft-ietf-trill-over-ip.all@ietf.org" Thread-Topic: Tsvart early review of draft-ietf-trill-over-ip-10 Thread-Index: AQHS7hA1g07jSLuZY0i4jyhkqH3mRw== Date: Tue, 27 Jun 2017 17:13:09 +0000 Message-ID: <52E4A8FC978E0241AE652516E24CAF0029AC2251@ESESSMB103.ericsson.se> References: <149754795560.13109.17521244075940607817@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_52E4A8FC978E0241AE652516E24CAF0029AC2251ESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2J7uK7apKBIg44mbouD2zUtPn+dxm7x bON8Fov3k7ezWczas4jFgdVj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MrovTiZteBcO3PF y/3VDYwPdjF1MXJySAiYSHTfOApkc3EICRxhlNh9sJ8dwlnCKNGwuJEVpIpNwELi5o9GNhBb REBN4vXyBSwgRcwChxgljqzoBOrg4BAWsJe4skwMosZBYuHadnYIW0+ipX8fG0gJi4CqxJGX ESBhXgFficW/30Et7maUmPxkLdhFjAKyEve/32MBsZkFxCVuPZkPdamAxJI955khbFGJl4// sYLMlBBQkpi2NQ2iPF/i/e5+Joj5ghInZz5hmcAoPAvJpFlIymYhKYOI60gs2P2JDcLWlli2 8DUzjH3mwGMmZPEFjOyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQKj6+CW36o7GC+/cTzE KMDBqMTDu6EtKFKINbGsuDIXGGYczEoivPm9QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8jvsu RAgJpCeWpGanphakFsFkmTg4pRoYU5fo+p9+8ivfbMqGOHvpqMYn/lprbhpNMlkg8nS7mOux NWdnWh9b4C/wZZfn1suLf9xrmRKXOt3oQsa/U94FtutFH2ct8jq3vZTp217vgLMXli8wzu5Y mh48j0mlvE5/Q2Yid1zypxP7jR5zbH1yWk9iq8VEL/aC9CN3unhYTp1x2LvPWfnfciWW4oxE Qy3mouJEAGT7B/mqAgAA Archived-At: Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 17:13:17 -0000 --_000_52E4A8FC978E0241AE652516E24CAF0029AC2251ESESSMB103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Donald, After having read your response I think there is an important question abou= t the applicability of this document that affects several of the issues bel= ow and what solution you need. That is the question of what type of paths o= ne expect to get Trill over IP working over. Because if the target is gener= al Internet and also through middleboxes such as NATs and Firewall (Not int= ending to block) then there are a lot more work to ensure this. If you for = example changes the applicability to require any on path middleboxes to ful= fill certain requirements things can be more easily addressed. Den 2017-06-26 kl. 02:07, skrev Donald Eastlake: Hi Magnus, Thanks for the extensive review. See my responses below. On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund wro= te: Diffserv usage -------------- Section 4.3: TRILL over IP implementations MUST support setting the DSCP value in the outer IP Header of TRILL packets they send by mapping the TRILL priority and DEI to the DSCP. They MAY support, for a TRILL Data packet where the native frame payload is an IP packet, mapping the DSCP in this inner IP packet to the outer IP Header with the default for that mapping being to copy the DSCP without change. I think it is fine to require that implementations are capable of setting DSCP values on the outer IP header. However, I fail to see any discussion o= f the potential issues with actually setting the DSCP values. It is one thing= to do this in an IP back bone use case where one can know and have control ove= r the PHB that the DSCP values maps to. But otherwise, over general internet = the behavior is not that predictable. One can easily be subject to policers or remapping. Also as the actual DSCP code point usage is domain specific this= is difficult. Priority reversal is likely the least of the problems that this = can run into over general Internet. It sounds like appropriate discussion and warnings about these issues would resolve the above comment. I would note that the choice of encapsulation here do becomes important. Yo= ur's and Joe Touch's observation that for TCP, you can only have a single D= SCP marking per TCP connection for example. For others, see the discussion = in Section 5.1 of https://datatracker.ietf.org/doc/rfc7657/ on this issue. David Black also raised an important question if one should treat this as a= tunnel with a single predictable behavior or let the inner networks markin= g show through. Establishing a tunnel with a single PHB has less risk of ru= nning into issues than multiple different markings. Section 4.3: The default TRILL priority and DEI to DSCP mapping, which may be configured per TRILL over IP port, is an follows. Note that the DEI value does not affect the default mapping and, to provide a potentially lower priority service than the default priority 0, priority 1 is considered lower priority than 0. So the priority sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7. TRILL Priority DEI DSCP Field (Binary/decimal) -------------- --- ----------------------------- 0 0/1 001000 / 8 1 0/1 000000 / 0 2 0/1 010000 / 16 3 0/1 011000 / 24 4 0/1 100000 / 32 5 0/1 101000 / 40 6 0/1 110000 / 48 7 0/1 111000 / 56 This appear to be an problematic mapping. At least for prio 0 and 1. As priority 1 appears to be intended to be higher than priority 0, it is interesting that it is mapped to CS1, which to quote https://datatracker.ietf.org/doc/rfc7657/: CS1 ('001000') was subsequently designated as the recommended codepoint for the Lower Effort (LE) PHB [RFC3662]. So what is proposed can in a network using default mapping, result in that = you get priority 0 to be lower priority than 1. Plus that in some networks this= can also results in strange remapping that results in a different PHB for CS1 t= han. The intent in the draft is to reflect the default relative priority of the different priority code points in IEEE Std 802.1Q where priority 1 is lower than priority 0. At a quick look, it appears to me that RFC 2474 requires that 0x001000 be handled as being of a priority not lower than the priority with which 0x000000 is handled. Yet RFC 3662, which you point to, seems to suggest using 0x001000 as a lower priority code point than 0x000000. Given that 3662 not only does not update 2474 but is only Informational while 2474 is Standards Track, I would say that 2474 dominates and that this draft makes the best assumptions it can about default behavior... David Black provide a good answer on this. MTU and Fragmentation --------------------- I think there are two main issue here. The first one is MTUD discovery of the actual IP path MTU between the ports. That will be needed to prevent a lot of traffic going into MTU black holes. Especially as TRILL requries 1470 byte support which is likey above a lot of paths. Seems like it would depend on the environments where TRILL was used. For example, I do not think 1470 would be a problem in most Data Center or Internet Exchange point uses, for example. Data Centers sometimes support 9K jumbo frames and the like. In fact, it is probably bad to focus too much on 1470 -- that is a required minimum to be sure that reasonable size link state PDUs can be successfully flooded through the TRILL campus so that routing will work. However, it would commonly be the case that, for the TRILL campus to be useful in a particular case, links need to be able to carry the expected size TRILL Data packets. For example, if there were two parts of a TRILL campus connected by one or a few TRILL over IP links and the end stations in each part were assuming they could use 1500 byte Ethernet packets, then the TRILL over IP links would need to support an MTU based on 1500 + TRILL Header + IP and TRILL over IP encapsulation. And more if security was being used or there were any other reasons for additional headers/encapsulation... Yes, and over general Internet you should be happy if you get 1500 bytes of= IP MTU, it may easily be lower with a couple of additional tunnel headers.= Thus, what you say is the goal is not feasible without a solution that sup= ports fragmentation and reassembly, enabling one TRILL packet to be sent in= multiple IP packets. The re-assembly do requires buffering and not somethi= ng to easily perform on a router fast path. And attempting to use IP fragme= ntation is likely doomed if you have any type of NAT or Firewall in the way= . This points to a dedicated solution or using a transport protocol that supp= orts carrying arbitrary data sizes, like TCP or SCTP. And you need to use t= he byte-stream API of TCP to achieve this. Section 8.4: Path MTU discovery [RFC4821] should be useful in determining the IP MTU between a pair of RBridge ports with IP connectivity. The issue with RFC4821 is that it has requirements on the packetization lay= er. Trill appears to have several components that are useful. However, it will require a specification of the procedure to result in a useful tool. See below. Section 8.4: TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in [RFC7177], can be used to obtain added assurance of the MTU of a link. Yes, that can confirm working MTUs that are at 1470 or above, but appears prevented from working below 1470? While there is a minimum size for TRILL IS-IS MTU PDUs, determined by header size, it is well below 1470, probably (depending on whether secuirty is in use, etc.) below 150 bytes. Okay, if you say so, it was not obvious from the spec that is was allowed t= o probe for paths with lesser MTUs than 1470. Thus, it appears that there is a lack of mechanism here to actually get a v= alid and functional MTU from TRILL in the cases where the Path MTU is below 1470= . If I am wrong good, but I think this is an important piece for how to handle t= he next main issue. How about referencing Section 3 of https://tools.ietf.org/html/draft-ietf-trill-mtu-negotiation-05 which is currently in IETF Last Call? (The wording of that section is probably going to be improved based on an OPS review by Brian Carpenter.) I looked at this, and it appears to have the same issue, that it can't prob= e for MTU values below 1470. 2) RB1 tries to send an MTU-probe padded to the size 1470. a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello and stop. But, the algorithm clearly performs a binary search for the MTU. If one look at RFC 4821 one will notice that there are some additional conside= rations there how to make the probing better and robuster. But, cleary Trill has so= me other criterias for what is a success. Verification that Sz works appears suffici= ent, and there are no need to probe further upwards. UDP encapsulation and IP fragments. ---------------------------------- I see it as a big issue that UDP encapsulation is the native one, and that relies on IP fragmentation despite the need for reliable fragmentation. Wit= h the setup of having to support 1470 MTU on TRILL level some packets will be fragmented in many environments. That will lead to a lot of losses, and as discussed below a very big problem with middleboxes. The main problem here = is that if one tries to rely on IP fragments one will have issues with packets ending up in black holes. And different problems depending on IPv4 or IPv6. IPv6 is lilkely the lesser problem assuming that one have working PMTUD. There are several ways out of this. 1. Detect issues and use TCP encapsulation with correctly set MSS to not ge= t IP fragements 2. Determine MTU and implement an fragmentation mechanism on top= of UDP. So, I don't see that much problem with UDP being the general default consistent with the TRILL philosophy of defaulting to need zero or minimal configuration. The default should be to use multicast Hellos for discovery of neighbors which sure points at UDP to me. Having to traverse a NAT should be a rare case. Since, in the NAT case, you have to configure things related to the static binding and the IP address(es) of peer(s) anyway you can also configure to use a different encapsulation than UDP, such as TCP, at the same time. I don't see it as much of a problem if, by default, TRILL won't operate through a NAT. If you are using UDP and it fragments and fragments are dropped at a NAT, probably you can't exchange Hellos so you will not form an adjacency and anything on the other side of the NAT will not be visible. Yes, but this is the issue of applicability and documenting that applicabil= ity. I don't know what goals and requirements that exist for Trill. If the = WG are fine with some restrictions, then document them and focus on solving= the issues that must be solved. You can clearly choose to require TCP for cases where the IP MTU is insuffi= cient for carrying the Sz sized trill packets between the RBs using UDP. Zero Checksum: -------------- Section 5.4: UDP Checksum - as specified in [RFC0768] Considering the fast path encapsulation desire, I am surprised to not see a= ny mentioning of use of zero checksum here. Raising the zero checksum and forw= ard reference would be good I think. And then Section 8.5: The requirements for the usage of the zero UDP Checksum in a UDP tunnel protocol are detailed in [RFC6936]. These requirements apply to the UDP based TRILL over IP encapsulations specified herein (native and VXLAN), which are applications of UDP tunnel. If you actually intended to allow zero checksum, then you actually should document that Trill fulfills the requirements that the applicability statem= ent raises. I have not analyzed how well it meets these requirements. Please review Section 6.2 of RFC 8086 for example how that can be done. OK. We'll look into it. TCP Encapsulation issue ----------------------- Section 5.6: The TCP encapsulation appear to be missing an delimiter format allowing eac= h individual TRILL packet/payload to be read out of the TCP's byte stream. In other words, a normal implementation has no way of ensuring that the TCP payload starts with the start of a new TRILL payload. Multiple small TRILL payloads may be included in the same TCP payload, and also only parts as TC= P is one way of dealing with TRILL packets that are larger than the IP+Encapsula= tion MTU that actually will work. This comment is based on that there appear to be no length fields included = in the TRILL header. The most straight forward delimiter is a 2-byte length fi= eld for the TRILL payload to be encapsulated. Right. It might also be useful to include some sort of check field, as is done in BGP, to detect if you are out of sync in parsing the TCP stream. As you need to actually perform re-assembly, the solution is to use the byt= e stream semantics the TCP API provides and have a framing for each packet. Another point is that, while with UDP it seems fine to send packets with assorted QoS, you don't want to encourage re-ordering of TCP packets in a stream. So if TCP encapsulation is being used, you want to use the same DSCP value for the packets in a particular TCP stream. So, generally, you need to have a TCP connection per priority handling category. Mapping the 8 priority levels into a smaller number of handling categories is a normal thing to do so you certainly don't necessarily need 8 TCP connections. Adding material on this should not be too hard. Yes, agreed it is a possibility and points into possible considerations tha= t David raised. Section 5.6: TCP endpoint requirements. I do wonder if an application like TRILL actual would need to discuss performance impacting implementation choices or limitations. For example use of NAGLE, the requirements on buffer sizes in relation to Bandwidth delay products, as buffer memory in a RBridge will im= pact performance. Well, I'm not sure how deeply this document should get into such performance issues. What about just saying something about consideration being given to tuning TCP for performance and pointing to one or a few other RFCs that talk about this? As Joe said, these are important considerations. If your intention is to en= able this to run at substantial fractions of line rates of the interfaces. = Then this do require considerations. Congestion Control ------------------ First thanks for the effort here. You're welcome. 8.1.2 In Other Environments Where UDP based encapsulation headers are used in TRILL over IP in environments other than those discussed in Section 8.1.1, specific congestion control mechanisms are commonly needed. However, if the traffic being carried by the TRILL over IP link is already congestion controlled and the size and volatility of the TRILL IS-IS link state database is limited, then specific congestion control may not be needed. See [RFC8085] Section 3.1.11 for further guidance. This is correct, however my question is if the RBridges have any way of kno= wing which traffic is actually congestion controlled, considering that TRILL pro= vides an layer 2 abstraction. I wonder if there should be any type of white list = of the types of layer 2 payloads that can be assumed to be congestion controll= ed, and thus okay to forward over IP paths? I am worried that without any recommendation to prevent traffic that is not controlled to be forwarded, c= an lead to congestion issues. The other issue I think may exist is the issue serial unicast emulation of broadcast/multicast creates. As this amplifies the outgoing packet rate wit= h a factor of how many addresses are configured for serial unicast this can be significant traffic expansion. Thus, I think additional considerations a= re needed here, and maybe rate limiting of the amount of traffic to be multica= sted. OK. We can think about those issues. Flow and ECMP ------------- Section 8.3: For example, for TRILL Data, this entropy field could be based on some hash of the Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL. I would appreciate clearer references to what these fields are. In a TRILL Data packet, the payload after the TRILL Header looks like an Ethernet frame except that there is always either a VLAN tag or, alternatively, where the VLAN tag would be, a Fine Grained Label [RFC7172]. (The preceding is the view in the TRILL RFCs, but there is an equivalent and equally valid view in which all the fields through and including the VLAN or FGL tag are part of the TRILL Header.) The TRILL base protocol specification focuses on Ethernet as a link technology between TRILL switches, in which case there will be a link header including an Outer.MacDA and Outer.MacSA fields and possibly an Outer.VLAN, all before the TRILL Header. See Figure 1 and Figure 2 in RFC 7172. Some of the above could be added to the draft for clarity. If I understand this correctly, the idea here is to look into the inner layer 2 frames, and use the flow equivalents that exists on that level and hash that into value that maps the flows onto the source port range. Yes. I think this text should include a summary of the principle and ensure to note the important requirement that what is considered flows in the inner must not result in being striped over multiple source ports as this may lea= d to reordering issues due to packets taking different paths. Well, we can add some text. But when would the relative ordering matter for two TRILL Data packets where the two inner native payloads have different values for any one or more of these three fields (Inner.MacDA, Inner.MacSA, and inner VLAN/FGL tag) ? If any of those fields are different, you are talking about different streams. Okay, then this is very straightforward. NAT and TRILL over IP: Section 8.5: If one like to use TRILL over IP through a NAT, then there are some very important considerations that are missing. First the need for static bindin= g configurations or the need for determining ones external address(es) and be able to communicate that to the peer RBridges, and in addition ensure that = one has keep-alives to that the NAT binding never times out. I think those are good points. There is an additional problem that TRILL Hellos detect neighbors with which they have 2-way connectivity by indicating, inside the Hellos that are sent, from what neighbors Hellos have been received on that port. If a NAT is involved, these neighbor addresses inside Hellos need to be mapped. Yes, and the question is how that can be handled, by the receiver of the pa= cket, or if the sender needs to determine what address it uses and provide = that in the HELLOs. If the first is possible that can simplify a lot. Next is the issue that there is almost zero chance of getting a IP/UDP encapsulation TRILL payload through the NAT if it results in IP fragmentati= on, as NATs don't do defragment and refragmented on the internal side, and an I= P fragment lacks UDP port and thus can't be matched to binding. So perhaps the recommendation should be to configure the port to use TCP if there will be fragmentation. Yes, I think that are likely the simplest solution for you. Also if you like to run IP/ESP through a NAT, then you most likely need the IP/UDP/ESP encapsulation (https://tools.ietf.org/html/rfc3948). Note that t= his will restrict the MTU even further and thus ensure that the 1470 requiremen= t cannot be fulfilled even without additional tunnels over an 1500 bytes MTU Ethernet infrastructure. I would note that also firewalls likely have issues with IP fragments for t= he same reason, they require significant amount of state to be verified if the= y should be let through. In general I think you should create a configuration that has chance to wor= k through most middleboxes, but I think you should require static bindings. I think that configuration is, and don't laugh now, but IP/UDP/ESP/TCP/TRILL, otherwise you will not be able to have both security and reliable fragmenta= tion of TRILL packets. OK. Thanks again for this review. It has pointed out a number of problems and in thinking about those, I believe a couple of further problems have come to mind that I mentioned above. We'll work on a revised draft. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_52E4A8FC978E0241AE652516E24CAF0029AC2251ESESSMB103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Donald,

After having read your response I think there is an important question abou= t the applicability of this document that affects several of the issues bel= ow and what solution you need. That is the question of what type of paths o= ne expect to get Trill over IP working over. Because if the target is general Internet and also through middlebox= es such as NATs and Firewall (Not intending to block) then there are a lot = more work to ensure this. If you for example changes the applicability to r= equire any on path middleboxes to fulfill certain requirements things can be more easily addressed.


Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:
Hi Magnus,=0A=
=0A=
Thanks for the extensive review. See my responses below.=0A=
=0A=
On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund=0A=
<magnus.westerlund@ericsson.com> wrote:=0A=


Diffserv usage=0A=
--------------=0A=
=0A=
Section 4.3:=0A=
=0A=
   TRILL over IP implementations MUST support setting the DSCP value in=0A=
   the outer IP Header of TRILL packets they send by mapping the TRILL=0A=
   priority and DEI to the DSCP. They MAY support, for a TRILL Data=0A=
   packet where the native frame payload is an IP packet, mapping the=0A=
   DSCP in this inner IP packet to the outer IP Header with the default=0A=
   for that mapping being to copy the DSCP without change.=0A=
=0A=
I think it is fine to require that implementations are capable  of setting=
=0A=
DSCP values on the outer IP header. However, I fail to see any discussion o=
f=0A=
the potential issues with actually setting the DSCP values. It is one thing=
 to=0A=
do this in an IP back bone use case where one can know and have control ove=
r=0A=
the PHB that the DSCP values maps to. But otherwise, over general internet =
the=0A=
behavior is not that predictable. One can easily be subject to policers or=
=0A=
remapping. Also as the actual DSCP code point usage is domain specific this=
 is=0A=
difficult. Priority reversal is likely the least of the problems that this =
can=0A=
run into over general Internet.=0A=

=0A=
It sounds like appropriate discussion and warnings about these issues=0A=
would resolve the above comment.

I would note that the choice of encapsulation here do becomes important. Yo= ur's and Joe Touch's observation that for TCP, you can only have a single D= SCP marking per TCP connection for example. For others, see the discussion = in Section 5.1 of https://datatracker.ietf.org/doc/rfc7657/ on this issue.

David Black also raised an important question if one should treat this as a= tunnel with a single predictable behavior or let the inner networks markin= g show through. Establishing a tunnel with a single PHB has less risk of ru= nning into issues than multiple different markings. 


=0A=
=0A=

Section 4.3:=0A=
=0A=
   The default TRILL priority and DEI to DSCP mapping, which may be=0A=
   configured per TRILL over IP port, is an follows. Note that the DEI=0A=
   value does not affect the default mapping and, to provide a=0A=
   potentially lower priority service than the default priority 0,=0A=
   priority 1 is considered lower priority than 0. So the priority=0A=
   sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7.=0A=
=0A=
      TRILL Priority  DEI  DSCP Field (Binary/decimal)=0A=
      --------------  ---  -----------------------------=0A=
                  0   0/1  001000 / 8=0A=
                  1   0/1  000000 / 0=0A=
                  2   0/1  010000 / 16=0A=
                  3   0/1  011000 / 24=0A=
                  4   0/1  100000 / 32=0A=
                  5   0/1  101000 / 40=0A=
                  6   0/1  110000 / 48=0A=
                  7   0/1  111000 / 56=0A=
=0A=
This appear to be an problematic mapping. At least for prio 0 and 1. As=0A=
priority 1 appears to be intended to be higher than priority 0, it is=0A=
interesting that it is mapped to CS1, which to quote=0A=
https://datatracker.ietf.org/doc/rfc7657/:=0A=
=0A=
CS1 ('001000') was subsequently designated as the recommended=0A=
      codepoint for the Lower Effort (LE) PHB [RFC3662].=0A=
=0A=
So what is proposed can in a network using default mapping, result in that =
you=0A=
get priority 0 to be lower priority than 1. Plus that in some networks this=
 can=0A=
also results in strange remapping that results in a different PHB for CS1 t=
han.=0A=

=0A=
The intent in the draft is to reflect the default relative priority of=0A=
the different priority code points in IEEE Std 802.1Q where priority 1=0A=
is lower than priority 0. At a quick look, it appears to me that RFC=0A=
2474 requires that 0x001000 be handled as being of a priority not=0A=
lower than the priority with which 0x000000 is handled. Yet RFC 3662,=0A=
which you point to, seems to suggest using 0x001000 as a lower=0A=
priority code point than 0x000000. Given that 3662 not only does not=0A=
update 2474 but is only Informational while 2474 is Standards Track, I=0A=
would say that 2474 dominates and that this draft makes the best=0A=
assumptions it can about default behavior...

David Black provide a good answer on this. 

=0A=
=0A=

MTU and Fragmentation=0A=
---------------------=0A=
=0A=
I think there are two main issue here. The first one is MTUD discovery=0A=
of the actual IP path MTU between the ports. That will be needed to prevent=
=0A=
a lot of traffic going into MTU black holes. Especially as TRILL requries=
=0A=
1470 byte support which is likey above a lot of paths.=0A=

=0A=
Seems like it would depend on the environments where TRILL was used.=0A=
For example, I do not think 1470 would be a problem in most Data=0A=
Center or Internet Exchange point uses, for example. Data Centers=0A=
sometimes support 9K jumbo frames and the like.=0A=
=0A=
In fact, it is probably bad to focus too much on 1470 -- that is a=0A=
required minimum to be sure that reasonable size link state PDUs can=0A=
be successfully flooded through the TRILL campus so that routing will=0A=
work. However, it would commonly be the case that, for the TRILL=0A=
campus to be useful in a particular case, links need to be able to=0A=
carry the expected size TRILL Data packets. For example, if there were=0A=
two parts of a TRILL campus connected by one or a few TRILL over IP=0A=
links and the end stations in each part were assuming they could use=0A=
1500 byte Ethernet packets, then the TRILL over IP links would need to=0A=
support an MTU based on 1500 + TRILL Header + IP and TRILL over IP=
=0A=
encapsulation. And more if security was being used or there were any=0A=
other reasons for additional headers/encapsulation...

Yes, and over general Internet you should be happy if you get 1500 bytes of= IP MTU, it may easily be lower with a couple of additional tunnel headers.= Thus, what you say is the goal is not feasible without a solution that sup= ports fragmentation and reassembly, enabling one TRILL packet to be sent in multiple IP packets. The re-assemb= ly do requires buffering and not something to easily perform on a router fa= st path. And attempting to use IP fragmentation is likely doomed if you hav= e any type of NAT or Firewall in the way.

This points to a dedicated solution or using a transport protocol that supp= orts carrying arbitrary data sizes, like TCP or SCTP. And you need to use t= he byte-stream API of TCP to achieve this. 

=0A=
=0A=

Section 8.4:=0A=
=0A=
   Path MTU discovery [RFC4821] should be useful=0A=
   in determining the IP MTU between a pair of RBridge ports with IP=0A=
   connectivity.=0A=
=0A=
The issue with RFC4821 is that it has requirements on the packetization lay=
er.=0A=
Trill appears to have several components that are useful. However, it will=
=0A=
require a specification of the procedure to result in a useful tool.=0A=

=0A=
See below.=0A=
=0A=

Section 8.4:=0A=
=0A=
   TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in=0A=
   [RFC7177], can be used to obtain added assurance of the MTU of a=0A=
   link.=0A=
=0A=
Yes, that can confirm working MTUs that are at 1470 or above, but appears=
=0A=
prevented from working below 1470?=0A=

=0A=
While there is a minimum size for TRILL IS-IS MTU PDUs, determined by=0A=
header size, it is well below 1470, probably (depending on whether=0A=
secuirty is in use, etc.) below 150 bytes.

Okay, if you say so, it was not obvious from the spec that is was allowed t= o probe for paths with lesser MTUs than 1470. 

=0A=
=0A=

Thus, it appears that there is a lack of mechanism here to a=
ctually get a valid=0A=
and functional MTU from TRILL in the cases where the Path MTU is below 1470=
. If=0A=
I am wrong good, but I think this is an important piece for how to handle t=
he=0A=
next main issue.=0A=

=0A=
How about referencing Section 3 of=0A=
https://tools.ietf.org/html/draft-ietf-tri=
ll-mtu-negotiation-05=0A=
which is currently in IETF Last Call? (The wording of that section is=0A=
probably going to be improved based on an OPS review by Brian=0A=
Carpenter.)

I looked at this, and it appears to have the same issue, that it can't prob= e for MTU values below 1470. 

   2) RB1 tries to send an MTU-probe padded to the s=
ize 1470.=0A=
=0A=
      a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1=0A=
         sets the "failed minimum MTU test" flag for RB2 in RB1's=
 Hello=0A=
         and stop.=0A=
=0A=
=0A=
But, the algorithm clearly performs a binary search for the MTU. If =0A=
one look at RFC 4821 one will notice that there are some additional conside=
rations=0A=
there how to make the probing better and robuster. But, cleary Trill has so=
me other=0A=
criterias for what is a success. Verification that Sz works appears suffici=
ent, =0A=
and there are no need to probe further upwards. =0A=



=0A=
=0A=

UDP encapsulation and IP fragments.=0A=

  ----------------------------------=0A=

I see it as a big issue that UDP encapsulation is the native=
 one, and that=0A=
relies on IP fragmentation despite the need for reliable fragmentation. Wit=
h=0A=
the setup of having to support 1470 MTU on TRILL level some packets will be=
=0A=
fragmented in many environments. That will lead to a lot of losses, and as=
=0A=
discussed below a very big problem with middleboxes. The main problem here =
is=0A=
that if one tries to rely on IP fragments one will have issues with packets=
=0A=
ending up in black holes. And different problems depending on IPv4 or IPv6.=
=0A=
IPv6 is lilkely the lesser problem assuming that one have working PMTUD.=0A=
=0A=
There are several ways out of this.=0A=
=0A=
1. Detect issues and use TCP encapsulation with correctly set MSS to not ge=
t IP=0A=
fragements 2. Determine MTU and implement an fragmentation mechanism on top=
 of=0A=
UDP.=0A=

=0A=
So, I don't see that much problem with UDP being the general default=0A=
consistent with the TRILL philosophy of defaulting to need zero or=0A=
minimal configuration. The default should be to use multicast Hellos=0A=
for discovery of neighbors which sure points at UDP to me. Having to=0A=
traverse a NAT should be a rare case. Since, in the NAT case, you have=0A=
to configure things related to the static binding and the IP=0A=
address(es) of peer(s) anyway you can also configure to use a=0A=
different encapsulation than UDP, such as TCP, at the same time. I=0A=
don't see it as much of a problem if, by default, TRILL won't operate=0A=
through a NAT. If you are using UDP and it fragments and fragments are=0A=
dropped at a NAT, probably you can't exchange Hellos so you will not=0A=
form an adjacency and anything on the other side of the NAT will not=0A=
be visible.

Yes, but this is the issue of applicability and documenting that applicabil= ity. I don't know what goals and requirements that exist for Trill. If the = WG are fine with some restrictions, then document them and focus on solving= the issues that must be solved.

You can clearly choose to require TCP for cases where the IP MTU is insuffi= cient for carrying the Sz sized trill packets between the RBs using UDP. 

=0A=
=0A=

Zero Checksum:=0A=
--------------=0A=
=0A=
Section 5.4:=0A=
=0A=
UDP Checksum - as specified in [RFC0768]=0A=
=0A=
Considering the fast path encapsulation desire, I am surprised to not see a=
ny=0A=
mentioning of use of zero checksum here. Raising the zero checksum and forw=
ard=0A=
reference would be good I think.=0A=
=0A=
And then Section 8.5:=0A=
=0A=
   The requirements for the usage of the zero UDP Checksum in a UDP=0A=
   tunnel protocol are detailed in [RFC6936]. These requirements apply=0A=
   to the UDP based TRILL over IP encapsulations specified herein=0A=
   (native and VXLAN), which are applications of UDP tunnel.=0A=
=0A=
If you actually intended to allow zero checksum, then you actually should=
=0A=
document that Trill fulfills the requirements that the applicability statem=
ent=0A=
raises. I have not analyzed how well it meets these requirements.=0A=
=0A=
Please review Section 6.2 of RFC 8086 for example how that can be done.=0A=

=0A=
OK. We'll look into it.=0A=
=0A=

TCP Encapsulation issue=0A=
-----------------------=0A=
=0A=
Section 5.6:=0A=
=0A=
The TCP encapsulation appear to be missing an delimiter format allowing eac=
h=0A=
individual TRILL packet/payload to be read out of the TCP's byte stream. In=
=0A=
other words, a normal implementation has no way of ensuring that the TCP=0A=
payload starts with the start of a new TRILL payload. Multiple small TRILL=
=0A=
payloads may be included in the same TCP payload, and also only parts as TC=
P is=0A=
one way of dealing with TRILL packets that are larger than the IP+Encap=
sulation=0A=
MTU that actually will work.=0A=
=0A=
This comment is based on that there appear to be no length fields included =
in=0A=
the TRILL header. The most straight forward delimiter is a 2-byte length fi=
eld=0A=
for the TRILL payload to be encapsulated.=0A=

=0A=
Right. It might also be useful to include some sort of check field, as=0A=
is done in BGP, to detect if you are out of sync in parsing the TCP=0A=
stream.

As you need to actually perform re-assembly, the solution is to use the byt= e stream semantics the TCP API provides and have a framing for each packet. 

=0A=
=0A=
Another point is that, while with UDP it seems fine to send packets=0A=
with assorted QoS, you don't want to encourage re-ordering of TCP=0A=
packets in a stream. So if TCP encapsulation is being used, you want=0A=
to use the same DSCP value for the packets in a particular TCP stream.=0A=
So, generally, you need to have a TCP connection per priority handling=0A=
category. Mapping the 8 priority levels into a smaller number of=0A=
handling categories is a normal thing to do so you certainly don't=0A=
necessarily need 8 TCP connections. Adding material on this should not=0A=
be too hard.

Yes, agreed it is a possibility and points into possible considerations tha= t David raised. 

=0A=
=0A=

Section 5.6:=0A=
=0A=
TCP endpoint requirements. I do wonder if an application like TRILL actual=
=0A=
would need to discuss performance impacting implementation choices or=0A=
limitations. For example use of NAGLE, the requirements on buffer sizes in=
=0A=
relation to Bandwidth delay products, as buffer memory in a RBridge will im=
pact=0A=
performance.=0A=

=0A=
Well, I'm not sure how deeply this document should get into such=0A=
performance issues. What about just saying something about=0A=
consideration being given to tuning TCP for performance and pointing=0A=
to one or a few other RFCs that talk about this?

As Joe said, these are important considerations. If your intention is to en= able this to run at substantial fractions of line rates of the interfaces. = Then this do require considerations. 

=0A=
=0A=

Congestion Control=0A=
------------------=0A=
First thanks for the effort here.=0A=

=0A=
You're welcome.=0A=
=0A=

8.1.2 In Other Environments=0A=
=0A=
   Where UDP based encapsulation headers are used in TRILL over IP in=0A=
   environments other than those discussed in Section 8.1.1, specific=0A=
   congestion control mechanisms are commonly needed.  However, if the=0A=
   traffic being carried by the TRILL over IP link is already congestion=0A=
   controlled and the size and volatility of the TRILL IS-IS link state=0A=
   database is limited, then specific congestion control may not be=0A=
   needed. See [RFC8085] Section 3.1.11 for further guidance.=0A=
=0A=
This is correct, however my question is if the RBridges have any way of kno=
wing=0A=
which traffic is actually congestion controlled, considering that TRILL pro=
vides=0A=
an layer 2 abstraction. I wonder if there should be any type of white list =
of=0A=
the types of layer 2 payloads that can be assumed to be congestion controll=
ed,=0A=
and thus okay to forward over IP paths? I am worried that without any=0A=
recommendation to prevent traffic that is not controlled to be forwarded, c=
an=0A=
lead to congestion issues.=0A=
=0A=
The other issue I think may exist is the issue serial unicast emulation of=
=0A=
broadcast/multicast creates. As this amplifies the outgoing packet rate wit=
h=0A=
a factor of how many addresses are configured for serial unicast this can=
=0A=
be significant traffic expansion. Thus, I think additional considerations a=
re=0A=
needed here, and maybe rate limiting of the amount of traffic to be multica=
sted.=0A=

=0A=
OK. We can think about those issues.=0A=
=0A=

Flow and ECMP=0A=
-------------=0A=
=0A=
Section 8.3:=0A=
=0A=
For example, for TRILL=0A=
   Data, this entropy field could be based on some hash of the=0A=
   Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL.=0A=
=0A=
I would appreciate clearer references to what these fields are.=0A=

=0A=
In a TRILL Data packet, the payload after the TRILL Header looks like=0A=
an Ethernet frame except that there is always either a VLAN tag or,=0A=
alternatively, where the VLAN tag would be, a Fine Grained Label=0A=
[RFC7172]. (The preceding is the view in the TRILL RFCs, but there is=0A=
an equivalent and equally valid view in which all the fields through=0A=
and including the VLAN or FGL tag are part of the TRILL Header.) The=0A=
TRILL base protocol specification focuses on Ethernet as a link=0A=
technology between TRILL switches, in which case there will be a link=0A=
header including an Outer.MacDA and Outer.MacSA fields and possibly an=0A=
Outer.VLAN, all before the TRILL Header. See Figure 1 and Figure 2 in=0A=
RFC 7172.=0A=
=0A=
Some of the above could be added to the draft for clarity.=0A=
=0A=

If I understand this correctly, the idea here is to look int=
o the inner=0A=
layer 2 frames, and use the flow equivalents that exists on that level and=
=0A=
hash that into value that maps the flows onto the source port range.=0A=

=0A=
Yes.=0A=
=0A=

I think this text should include a summary of the principle =
and ensure to=0A=
note the important requirement that what is considered flows in the inner=
=0A=
must not result in being striped over multiple source ports as this may lea=
d to=0A=
reordering issues due to packets taking different paths.=0A=

=0A=
Well, we can add some text. But when would the relative ordering=0A=
matter for two TRILL Data packets where the two inner native payloads=0A=
have different values for any one or more of these three fields=0A=
(Inner.MacDA, Inner.MacSA, and inner VLAN/FGL tag) ? If any of those=0A=
fields are different, you are talking about different streams.

Okay, then this is very straightforward. 

=0A=
=0A=

NAT and TRILL over IP:=0A=
Section 8.5:=0A=
=0A=
If one like to use TRILL over IP through a NAT, then there are some very=0A=
important considerations that are missing. First the need for static bindin=
g=0A=
configurations or the need for determining ones external address(es) and be=
=0A=
able to communicate that to the peer RBridges, and in addition ensure that =
one=0A=
has keep-alives to that the NAT binding never times out.=0A=

=0A=
I think those are good points. There is an additional problem that=0A=
TRILL Hellos detect neighbors with which they have 2-way connectivity=0A=
by indicating, inside the Hellos that are sent, from what neighbors=0A=
Hellos have been received on that port. If a NAT is involved, these=0A=
neighbor addresses inside Hellos need to be mapped.

Yes, and the question is how that can be handled, by the receiver of the pa= cket, or if the sender needs to determine what address it uses and provide = that in the HELLOs. If the first is possible that can simplify a lot. 

=0A=
=0A=

Next is the issue that there is almost zero chance of gettin=
g a IP/UDP=0A=
encapsulation TRILL payload through the NAT if it results in IP fragmentati=
on,=0A=
as NATs don't do defragment and refragmented on the internal side, and an I=
P=0A=
fragment lacks UDP port and thus can't be matched to binding.=0A=

=0A=
So perhaps the recommendation should be to configure the port to use=0A=
TCP if there will be fragmentation.=0A=

Yes, I think that are likely the simplest solution for you. 

=0A=

Also if you like to run IP/ESP through a NAT, then you most =
likely need the=0A=
IP/UDP/ESP encapsulation (https://tools.ietf.org/html/rfc3948). No=
te that this=0A=
will restrict the MTU even further and thus ensure that the 1470 requiremen=
t=0A=
cannot be fulfilled even without additional tunnels over an 1500 bytes MTU=
=0A=
Ethernet infrastructure.=0A=
=0A=
I would note that also firewalls likely have issues with IP fragments for t=
he=0A=
same reason, they require significant amount of state to be verified if the=
y=0A=
should be let through.=0A=
=0A=
In general I think you should create a configuration that has chance to wor=
k=0A=
through most middleboxes, but I think you should require static bindings. I=
=0A=
think that configuration is, and don't laugh now, but IP/UDP/ESP/TCP/TRILL,=
=0A=
otherwise you will not be able to have both security and reliable fragmenta=
tion=0A=
of TRILL packets.=0A=

=0A=
OK. Thanks again for this review. It has pointed out a number of=0A=
problems and in thinking about those, I believe a couple of further=0A=
problems have come to mind that I mentioned above. We'll work on a=0A=
revised draft.=0A=
=0A=
=0A=

=0A=
Cheers =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Media Technologies, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_52E4A8FC978E0241AE652516E24CAF0029AC2251ESESSMB103erics_--


From nobody Thu Jun 29 19:17:49 2017
Return-Path: 
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9686C129B74; Thu, 29 Jun 2017 19:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 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_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 B6RkVZ3UiUKa; Thu, 29 Jun 2017 19:17:28 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 192E4129A9C; Thu, 29 Jun 2017 19:17:28 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id h64so17142728iod.0; Thu, 29 Jun 2017 19:17:28 -0700 (PDT)
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=9HzTNkMcvS4yzHxXwMLFDr5N1hX/InMnh6UtABvknZQ=; b=cU9RcUu81fqYMMvQm2x3a351VexCv6V57sGeWcEoRYJBaOkVcNQkJ4/vzCtswoSpAm KnsLeunRxq35kOVy94kCTSxU8vCdGlhzr1LR03jh9SNVZUmvxHp/IPoBNp1sxIG7S2zJ dIqv+c9yivSThgBpsmlwuCu99U6ZwychrTq8uHVies20ZqQU6LvALSoQmgUkeX/c0ESp 9n/nNsJ/CLrsOKfbP/uUkPNFsAQ4wLx+LiANlP8HDpMfSMj3p4I886WWm052DIjUNm32 ndyl3K+hV4N08cDo+z46mC31xHdgd4szz7mEI397TeHo7gsxGu+b30nGcF2jRvRBcHA2 aYgg==
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=9HzTNkMcvS4yzHxXwMLFDr5N1hX/InMnh6UtABvknZQ=; b=YH3tOH0M7TYV6QYYuCKlIhOaRIFjFVoYbhSTU3eB5HphECY9VRCJoDUWVvFRDJlu25 nOLgROR81AELoyXAwTnG0mmAk/XHF2sr+JhidtVmQtC6gHmutId+FUk0l+PEljUTFDrd Pk0N/w7NOxADwbvCZV/PkvYz1IKB7nY0QS7+0/EmoNP+uItjyOQfAhThXAao/bJQLInP kxAscNA3jHDY5tiAUuOid6+i0HYvsMVVXTmbbd9yz+JJhpgvbN3NLtbR120qvsA4TvJ2 /qMKw7BFM77lFimQkKf6cy+PnpjNulRdDo/M2Zwqkqngg1dFhGgyJHIhmJ2kyC+/a6+S fsfA==
X-Gm-Message-State: AKS2vOzXjnKvZYeCUqn1jE1EHkMjQClbddNVhIqncF0v0b3a0rhw1F64 v07e1vpZARpuNqJ5AR2WKM2FgVIKiQ==
X-Received: by 10.107.156.83 with SMTP id f80mr20165783ioe.9.1498789047319; Thu, 29 Jun 2017 19:17:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.221 with HTTP; Thu, 29 Jun 2017 19:17:11 -0700 (PDT)
In-Reply-To: <52E4A8FC978E0241AE652516E24CAF0029AC2251@ESESSMB103.ericsson.se>
References: <149754795560.13109.17521244075940607817@ietfa.amsl.com>  <52E4A8FC978E0241AE652516E24CAF0029AC2251@ESESSMB103.ericsson.se>
From: Donald Eastlake 
Date: Thu, 29 Jun 2017 22:17:11 -0400
Message-ID: 
To: Magnus Westerlund 
Cc: "tsv-art@ietf.org" , "trill@ietf.org" ,  IETF Discussion , "draft-ietf-trill-over-ip.all@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1141bcbec246930553240434"
Archived-At: 
Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 02:17:32 -0000

--001a1141bcbec246930553240434
Content-Type: text/plain; charset="UTF-8"

HI Magnus,

On Tue, Jun 27, 2017 at 1:13 PM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> Hi Donald,
>
> After having read your response I think there is an important question
> about the applicability of this document that affects several of the issues
> below and what solution you need. That is the question of what type of
> paths one expect to get Trill over IP working over. Because if the target
> is general Internet and also through middleboxes such as NATs and Firewall
> (Not intending to block) then there are a lot more work to ensure this. If
> you for example changes the applicability to require any on path
> middleboxes to fulfill certain requirements things can be more easily
> addressed.
>

The use cases in the document support communication over the general
Internet in the brach office case but that does not necessarily imply
NATs/Firewalls.

Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:
>
> Hi Magnus,
>
> Thanks for the extensive review. See my responses below.
>
> On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund  wrote:
>
>
> Diffserv usage
> --------------
>
> Section 4.3:
>
>    TRILL over IP implementations MUST support setting the DSCP value in
>    the outer IP Header of TRILL packets they send by mapping the TRILL
>    priority and DEI to the DSCP. They MAY support, for a TRILL Data
>    packet where the native frame payload is an IP packet, mapping the
>    DSCP in this inner IP packet to the outer IP Header with the default
>    for that mapping being to copy the DSCP without change.
>
> I think it is fine to require that implementations are capable  of setting
> DSCP values on the outer IP header. However, I fail to see any discussion of
> the potential issues with actually setting the DSCP values. It is one thing to
> do this in an IP back bone use case where one can know and have control over
> the PHB that the DSCP values maps to. But otherwise, over general internet the
> behavior is not that predictable. One can easily be subject to policers or
> remapping. Also as the actual DSCP code point usage is domain specific this is
> difficult. Priority reversal is likely the least of the problems that this can
> run into over general Internet.
>
> It sounds like appropriate discussion and warnings about these issues
> would resolve the above comment.
>
> I would note that the choice of encapsulation here do becomes important.
> Your's and Joe Touch's observation that for TCP, you can only have a single
> DSCP marking per TCP connection for example. For others, see the discussion
> in Section 5.1 of https://datatracker.ietf.org/doc/rfc7657/ on this
> issue.
>

Well, if a TRILL over IP implementation using TCP transport wants to have
more than one priority category for traffic where there might be one or
more intervening IP routers, which would be the normal case, it would just
need a TCP connection per priority category. Mapping the 8 priority levels
into a smaller number of categories is a routine thing to do. Note that the
base TRILL protocol specification (RFC 6325) says:

   RBridges are not required to implement any
   particular number of distinct priority levels but may treat one or

   more adjacent priority levels in the same fashion.


> David Black also raised an important question if one should treat this as
> a tunnel with a single predictable behavior or let the inner networks
> marking show through. Establishing a tunnel with a single PHB has less risk
> of running into issues than multiple different markings.
>

It is an implementation choice whether to have a single PHB or eight, one
per priority level, or something in between.

> Section 4.3:
>
>    The default TRILL priority and DEI to DSCP mapping, which may be
>    configured per TRILL over IP port, is an follows. Note that the DEI
>    value does not affect the default mapping and, to provide a
>    potentially lower priority service than the default priority 0,
>    priority 1 is considered lower priority than 0. So the priority
>    sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7.
>
>       TRILL Priority  DEI  DSCP Field (Binary/decimal)
>       --------------  ---  -----------------------------
>                   0   0/1  001000 / 8
>                   1   0/1  000000 / 0
>                   2   0/1  010000 / 16
>                   3   0/1  011000 / 24
>                   4   0/1  100000 / 32
>                   5   0/1  101000 / 40
>                   6   0/1  110000 / 48
>                   7   0/1  111000 / 56
>
> This appear to be an problematic mapping. At least for prio 0 and 1. As
> priority 1 appears to be intended to be higher than priority 0, it is
> interesting that it is mapped to CS1, which to quotehttps://datatracker.ietf.org/doc/rfc7657/:
>
> CS1 ('001000') was subsequently designated as the recommended
>       codepoint for the Lower Effort (LE) PHB [RFC3662].
>
> So what is proposed can in a network using default mapping, result in that you
> get priority 0 to be lower priority than 1. Plus that in some networks this can
> also results in strange remapping that results in a different PHB for CS1 than.
>
> The intent in the draft is to reflect the default relative priority of
> the different priority code points in IEEE Std 802.1Q where priority 1
> is lower than priority 0. At a quick look, it appears to me that RFC
> 2474 requires that 0x001000 be handled as being of a priority not
> lower than the priority with which 0x000000 is handled. Yet RFC 3662,
> which you point to, seems to suggest using 0x001000 as a lower
> priority code point than 0x000000. Given that 3662 not only does not
> update 2474 but is only Informational while 2474 is Standards Track, I
> would say that 2474 dominates and that this draft makes the best
> assumptions it can about default behavior...
>
>
> David Black provide a good answer on this.
>

I'll reply to him.

> MTU and Fragmentation
> ---------------------
>
> I think there are two main issue here. The first one is MTUD discovery
> of the actual IP path MTU between the ports. That will be needed to prevent
> a lot of traffic going into MTU black holes. Especially as TRILL requries
> 1470 byte support which is likey above a lot of paths.
>
> Seems like it would depend on the environments where TRILL was used.
> For example, I do not think 1470 would be a problem in most Data
> Center or Internet Exchange point uses, for example. Data Centers
> sometimes support 9K jumbo frames and the like.
>
> In fact, it is probably bad to focus too much on 1470 -- that is a
> required minimum to be sure that reasonable size link state PDUs can
> be successfully flooded through the TRILL campus so that routing will
> work. However, it would commonly be the case that, for the TRILL
> campus to be useful in a particular case, links need to be able to
> carry the expected size TRILL Data packets. For example, if there were
> two parts of a TRILL campus connected by one or a few TRILL over IP
> links and the end stations in each part were assuming they could use
> 1500 byte Ethernet packets, then the TRILL over IP links would need to
> support an MTU based on 1500 + TRILL Header + IP and TRILL over IP
> encapsulation. And more if security was being used or there were any
> other reasons for additional headers/encapsulation...
>
>
> Yes, and over general Internet you should be happy if you get 1500 bytes
> of IP MTU, it may easily be lower with a couple of additional tunnel
> headers. Thus, what you say is the goal is not feasible without a solution
> that supports fragmentation and reassembly, enabling one TRILL packet to be
> sent in multiple IP packets. The re-assembly do requires buffering and not
> something to easily perform on a router fast path. And attempting to use IP
> fragmentation is likely doomed if you have any type of NAT or Firewall in
> the way.
>
> This points to a dedicated solution or using a transport protocol that
> supports carrying arbitrary data sizes, like TCP or SCTP. And you need to
> use the byte-stream API of TCP to achieve this.
>

OK.

> Section 8.4:
>
>    Path MTU discovery [RFC4821] should be useful
>    in determining the IP MTU between a pair of RBridge ports with IP
>    connectivity.
>
> The issue with RFC4821 is that it has requirements on the packetization layer.
> Trill appears to have several components that are useful. However, it will
> require a specification of the procedure to result in a useful tool.
>
> See below.
>
>
> Section 8.4:
>
>    TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in
>    [RFC7177], can be used to obtain added assurance of the MTU of a
>    link.
>
> Yes, that can confirm working MTUs that are at 1470 or above, but appears
> prevented from working below 1470?
>
> While there is a minimum size for TRILL IS-IS MTU PDUs, determined by
> header size, it is well below 1470, probably (depending on whether
> secuirty is in use, etc.) below 150 bytes.
>
>
> Okay, if you say so, it was not obvious from the spec that is was allowed
> to probe for paths with lesser MTUs than 1470.
>
> Thus, it appears that there is a lack of mechanism here to actually get a valid
> and functional MTU from TRILL in the cases where the Path MTU is below 1470. If
> I am wrong good, but I think this is an important piece for how to handle the
> next main issue.
>
> How about referencing Section 3 ofhttps://tools.ietf.org/html/draft-ietf-trill-mtu-negotiation-05
> which is currently in IETF Last Call? (The wording of that section is
> probably going to be improved based on an OPS review by Brian
> Carpenter.)
>
> I looked at this, and it appears to have the same issue, that it can't
> probe for MTU values below 1470.
>

I think the thing was that, before TRILL over IP, it would not have been
useful to determine an MTU below 1470. But there is no particular problem
in constructing a smaller MTU-probe PDUs and an RBridge receiving such a
PDU is generally required to respond with an equal length MTU-ack.

>    2) RB1 tries to send an MTU-probe padded to the size 1470.
>
>       a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1
>          sets the "failed minimum MTU test" flag for RB2 in RB1's Hello
>          and stop.
>
>
> But, the algorithm clearly performs a binary search for the MTU. If
> one look at RFC 4821 one will notice that there are some additional considerations
> there how to make the probing better and robuster. But, cleary Trill has some other
> criterias for what is a success. Verification that Sz works appears sufficient,
> and there are no need to probe further upwards.
>
> UDP encapsulation and IP fragments.
>
>   ----------------------------------
>
> I see it as a big issue that UDP encapsulation is the native one, and that
> relies on IP fragmentation despite the need for reliable fragmentation. With
> the setup of having to support 1470 MTU on TRILL level some packets will be
> fragmented in many environments. That will lead to a lot of losses, and as
> discussed below a very big problem with middleboxes. The main problem here is
> that if one tries to rely on IP fragments one will have issues with packets
> ending up in black holes. And different problems depending on IPv4 or IPv6.
> IPv6 is lilkely the lesser problem assuming that one have working PMTUD.
>
> There are several ways out of this.
>
> 1. Detect issues and use TCP encapsulation with correctly set MSS to not get IP
> fragements 2. Determine MTU and implement an fragmentation mechanism on top of
> UDP.
>
> So, I don't see that much problem with UDP being the general default
> consistent with the TRILL philosophy of defaulting to need zero or
> minimal configuration. The default should be to use multicast Hellos
> for discovery of neighbors which sure points at UDP to me. Having to
> traverse a NAT should be a rare case. Since, in the NAT case, you have
> to configure things related to the static binding and the IP
> address(es) of peer(s) anyway you can also configure to use a
> different encapsulation than UDP, such as TCP, at the same time. I
> don't see it as much of a problem if, by default, TRILL won't operate
> through a NAT. If you are using UDP and it fragments and fragments are
> dropped at a NAT, probably you can't exchange Hellos so you will not
> form an adjacency and anything on the other side of the NAT will not
> be visible.
>
>
> Yes, but this is the issue of applicability and documenting that
> applicability. I don't know what goals and requirements that exist for
> Trill. If the WG are fine with some restrictions, then document them and
> focus on solving the issues that must be solved.
>
> You can clearly choose to require TCP for cases where the IP MTU is
> insufficient for carrying the Sz sized trill packets between the RBs using
> UDP.
>

OK.

> Zero Checksum:
> --------------
>
> Section 5.4:
>
> UDP Checksum - as specified in [RFC0768]
>
> Considering the fast path encapsulation desire, I am surprised to not see any
> mentioning of use of zero checksum here. Raising the zero checksum and forward
> reference would be good I think.
>
> And then Section 8.5:
>
>    The requirements for the usage of the zero UDP Checksum in a UDP
>    tunnel protocol are detailed in [RFC6936]. These requirements apply
>    to the UDP based TRILL over IP encapsulations specified herein
>    (native and VXLAN), which are applications of UDP tunnel.
>
> If you actually intended to allow zero checksum, then you actually should
> document that Trill fulfills the requirements that the applicability statement
> raises. I have not analyzed how well it meets these requirements.
>
> Please review Section 6.2 of RFC 8086 for example how that can be done.
>
> OK. We'll look into it.
>
>
> TCP Encapsulation issue
> -----------------------
>
> Section 5.6:
>
> The TCP encapsulation appear to be missing an delimiter format allowing each
> individual TRILL packet/payload to be read out of the TCP's byte stream. In
> other words, a normal implementation has no way of ensuring that the TCP
> payload starts with the start of a new TRILL payload. Multiple small TRILL
> payloads may be included in the same TCP payload, and also only parts as TCP is
> one way of dealing with TRILL packets that are larger than the IP+Encapsulation
> MTU that actually will work.
>
> This comment is based on that there appear to be no length fields included in
> the TRILL header. The most straight forward delimiter is a 2-byte length field
> for the TRILL payload to be encapsulated.
>
> Right. It might also be useful to include some sort of check field, as
> is done in BGP, to detect if you are out of sync in parsing the TCP
> stream.
>
> As you need to actually perform re-assembly, the solution is to use the
> byte stream semantics the TCP API provides and have a framing for each
> packet.
>

Of course.

My point was that the framing might usefully have some sort of flag field,
like the BGP framing has, so that there was a good chance of detecting if
the parsing of the byte stream into frames has gotten out of synch.

> Another point is that, while with UDP it seems fine to send packets
> with assorted QoS, you don't want to encourage re-ordering of TCP
> packets in a stream. So if TCP encapsulation is being used, you want
> to use the same DSCP value for the packets in a particular TCP stream.
> So, generally, you need to have a TCP connection per priority handling
> category. Mapping the 8 priority levels into a smaller number of
> handling categories is a normal thing to do so you certainly don't
> necessarily need 8 TCP connections. Adding material on this should not
> be too hard.
>
>
> Yes, agreed it is a possibility and points into possible considerations
> that David raised.
>
> Section 5.6:
>
> TCP endpoint requirements. I do wonder if an application like TRILL actual
> would need to discuss performance impacting implementation choices or
> limitations. For example use of NAGLE, the requirements on buffer sizes in
> relation to Bandwidth delay products, as buffer memory in a RBridge will impact
> performance.
>
> Well, I'm not sure how deeply this document should get into such
> performance issues. What about just saying something about
> consideration being given to tuning TCP for performance and pointing
> to one or a few other RFCs that talk about this?
>
>
> As Joe said, these are important considerations. If your intention is to
> enable this to run at substantial fractions of line rates of the
> interfaces. Then this do require considerations.
>

I see.

> Congestion Control
> ------------------
> First thanks for the effort here.
>
> You're welcome.
>
>
> 8.1.2 In Other Environments
>
>    Where UDP based encapsulation headers are used in TRILL over IP in
>    environments other than those discussed in Section 8.1.1, specific
>    congestion control mechanisms are commonly needed.  However, if the
>    traffic being carried by the TRILL over IP link is already congestion
>    controlled and the size and volatility of the TRILL IS-IS link state
>    database is limited, then specific congestion control may not be
>    needed. See [RFC8085] Section 3.1.11 for further guidance.
>
> This is correct, however my question is if the RBridges have any way of knowing
> which traffic is actually congestion controlled, considering that TRILL provides
> an layer 2 abstraction. I wonder if there should be any type of white list of
> the types of layer 2 payloads that can be assumed to be congestion controlled,
> and thus okay to forward over IP paths? I am worried that without any
> recommendation to prevent traffic that is not controlled to be forwarded, can
> lead to congestion issues.
>
> The other issue I think may exist is the issue serial unicast emulation of
> broadcast/multicast creates. As this amplifies the outgoing packet rate with
> a factor of how many addresses are configured for serial unicast this can
> be significant traffic expansion. Thus, I think additional considerations are
> needed here, and maybe rate limiting of the amount of traffic to be multicasted.
>
> OK. We can think about those issues.
>
>
> Flow and ECMP
> -------------
>
> Section 8.3:
>
> For example, for TRILL
>    Data, this entropy field could be based on some hash of the
>    Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL.
>
> I would appreciate clearer references to what these fields are.
>
> In a TRILL Data packet, the payload after the TRILL Header looks like
> an Ethernet frame except that there is always either a VLAN tag or,
> alternatively, where the VLAN tag would be, a Fine Grained Label
> [RFC7172]. (The preceding is the view in the TRILL RFCs, but there is
> an equivalent and equally valid view in which all the fields through
> and including the VLAN or FGL tag are part of the TRILL Header.) The
> TRILL base protocol specification focuses on Ethernet as a link
> technology between TRILL switches, in which case there will be a link
> header including an Outer.MacDA and Outer.MacSA fields and possibly an
> Outer.VLAN, all before the TRILL Header. See Figure 1 and Figure 2 in
> RFC 7172.
>
> Some of the above could be added to the draft for clarity.
>
>
> If I understand this correctly, the idea here is to look into the inner
> layer 2 frames, and use the flow equivalents that exists on that level and
> hash that into value that maps the flows onto the source port range.
>
> Yes.
>
>
> I think this text should include a summary of the principle and ensure to
> note the important requirement that what is considered flows in the inner
> must not result in being striped over multiple source ports as this may lead to
> reordering issues due to packets taking different paths.
>
> Well, we can add some text. But when would the relative ordering
> matter for two TRILL Data packets where the two inner native payloads
> have different values for any one or more of these three fields
> (Inner.MacDA, Inner.MacSA, and inner VLAN/FGL tag) ? If any of those
> fields are different, you are talking about different streams.
>
>
> Okay, then this is very straightforward.
>
> NAT and TRILL over IP:
> Section 8.5:
>
> If one like to use TRILL over IP through a NAT, then there are some very
> important considerations that are missing. First the need for static binding
> configurations or the need for determining ones external address(es) and be
> able to communicate that to the peer RBridges, and in addition ensure that one
> has keep-alives to that the NAT binding never times out.
>
> I think those are good points. There is an additional problem that
> TRILL Hellos detect neighbors with which they have 2-way connectivity
> by indicating, inside the Hellos that are sent, from what neighbors
> Hellos have been received on that port. If a NAT is involved, these
> neighbor addresses inside Hellos need to be mapped.
>
> Yes, and the question is how that can be handled, by the receiver of the
> packet, or if the sender needs to determine what address it uses and
> provide that in the HELLOs. If the first is possible that can simplify a
> lot.
>

I'm not sure. this would require a little detailed design work.

> Next is the issue that there is almost zero chance of getting a IP/UDP
> encapsulation TRILL payload through the NAT if it results in IP fragmentation,
> as NATs don't do defragment and refragmented on the internal side, and an IP
> fragment lacks UDP port and thus can't be matched to binding.
>
> So perhaps the recommendation should be to configure the port to use
> TCP if there will be fragmentation.
>
> Yes, I think that are likely the simplest solution for you.
>

OK

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

Also if you like to run IP/ESP through a NAT, then you most likely need the
> IP/UDP/ESP encapsulation (https://tools.ietf.org/html/rfc3948). Note that this
> will restrict the MTU even further and thus ensure that the 1470 requirement
> cannot be fulfilled even without additional tunnels over an 1500 bytes MTU
> Ethernet infrastructure.
>
> I would note that also firewalls likely have issues with IP fragments for the
> same reason, they require significant amount of state to be verified if they
> should be let through.
>
> In general I think you should create a configuration that has chance to work
> through most middleboxes, but I think you should require static bindings. I
> think that configuration is, and don't laugh now, but IP/UDP/ESP/TCP/TRILL,
> otherwise you will not be able to have both security and reliable fragmentation
> of TRILL packets.
>
> OK. Thanks again for this review. It has pointed out a number of
> problems and in thinking about those, I believe a couple of further
> problems have come to mind that I mentioned above. We'll work on a
> revised draft.
>
>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287 <+46%2010%20714%2082%2087>
> Torshamnsgatan 23           | Mobile +46 73 0949079 <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>

--001a1141bcbec246930553240434
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


HI Magnus,

On Tue, Jun 27, 2017 at 1:13 PM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:







Hi Donald,



After having read your response I think there is an important question abou=
t the applicability of this document that affects several of the issues bel=
ow and what solution you need. That is the question of what type of paths o=
ne expect to get Trill over IP working
 over. Because if the target is general Internet and also through middlebox=
es such as NATs and Firewall (Not intending to block) then there are a lot =
more work to ensure this. If you for example changes the applicability to r=
equire any on path middleboxes to
 fulfill certain requirements things can be more easily addressed. 

The use cases in the document support =
communication over the general Internet in the brach office case but that d=
oes not necessarily imply NATs/Firewalls.

<=
span class=3D"gmail-m_-2274122840677479759gmail-">
Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:






Hi Magnus,

Thanks for the extensive review. See my responses below.

On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund
<magnus.westerlund@ericsson.com> wrote:







Diffserv usage
--------------

Section 4.3:

   TRILL over IP implementations MUST support setting the DSCP value in
   the outer IP Header of TRILL packets they send by mapping the TRILL
   priority and DEI to the DSCP. They MAY support, for a TRILL Data
   packet where the native frame payload is an IP packet, mapping the
   DSCP in this inner IP packet to the outer IP Header with the default
   for that mapping being to copy the DSCP without change.

I think it is fine to require that implementations are capable  of setting
DSCP values on the outer IP header. However, I fail to see any discussion o=
f
the potential issues with actually setting the DSCP values. It is one thing=
 to
do this in an IP back bone use case where one can know and have control ove=
r
the PHB that the DSCP values maps to. But otherwise, over general internet =
the
behavior is not that predictable. One can easily be subject to policers or
remapping. Also as the actual DSCP code point usage is domain specific this=
 is
difficult. Priority reversal is likely the least of the problems that this =
can
run into over general Internet.





It sounds like appropriate discussion and warnings about these issues
would resolve the above comment.

I would note that the choice of encapsulation here do becomes important. Yo=
ur's and Joe Touch's observation that for TCP, you can only have a =
single DSCP marking per TCP connection for example. For others, see the dis=
cussion in Section 5.1 of

https://datatracker.ietf.org/doc/rfc7657/ on this issue. 

Well, if a TRILL over IP implementation u=
sing TCP transport wants to have more than one priority category for traffi=
c where there might be one or more intervening IP routers, which would be t=
he normal case, it would just need a TCP connection per priority category. =
Mapping the 8 priority levels into a smaller number of categories is a rout=
ine thing to do. Note that the base TRILL protocol specification (RFC 6325)=
 says:

   RBridges are not required to implement any
   particular number of distinct priority levels but may treat one or=C2=A0=

=C2=A0 =C2=A0more adjacent priority levels in the=
 same fashion.
=C2=A0

David Black also raised an important question if one should treat this as a=
 tunnel with a single predictable behavior or let the inner networks markin=
g show through. Establishing a tunnel with a single PHB has less risk of ru=
nning into issues than multiple
 different markings.=C2=A0

It is an i=
mplementation choice whether to have a single PHB or eight, one per priorit=
y level, or something in between.=C2=A0








Section 4.3:

   The default TRILL priority and DEI to DSCP mapping, which may be
   configured per TRILL over IP port, is an follows. Note that the DEI
   value does not affect the default mapping and, to provide a
   potentially lower priority service than the default priority 0,
   priority 1 is considered lower priority than 0. So the priority
   sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7.

      TRILL Priority  DEI  DSCP Field (Binary/decimal)
      --------------  ---  -----------------------------
                  0   0/1  001000 / 8
                  1   0/1  000000 / 0
                  2   0/1  010000 / 16
                  3   0/1  011000 / 24
                  4   0/1  100000 / 32
                  5   0/1  101000 / 40
                  6   0/1  110000 / 48
                  7   0/1  111000 / 56

This appear to be an problematic mapping. At least for prio 0 and 1. As
priority 1 appears to be intended to be higher than priority 0, it is
interesting that it is mapped to CS1, which to quote
https://datatracker.ietf.org/doc/rfc7657/:

CS1 ('001000') was subsequently designated as the recommended
      codepoint for the Lower Effort (LE) PHB [RFC3662].

So what is proposed can in a network using default mapping, result in that =
you
get priority 0 to be lower priority than 1. Plus that in some networks this=
 can
also results in strange remapping that results in a different PHB for CS1 t=
han.





The intent in the draft is to reflect the default relative priority of
the different priority code points in IEEE Std 802.1Q where priority 1
is lower than priority 0. At a quick look, it appears to me that RFC
2474 requires that 0x001000 be handled as being of a priority not
lower than the priority with which 0x000000 is handled. Yet RFC 3662,
which you point to, seems to suggest using 0x001000 as a lower
priority code point than 0x000000. Given that 3662 not only does not
update 2474 but is only Informational while 2474 is Standards Track, I
would say that 2474 dominates and that this draft makes the best
assumptions it can about default behavior...





David Black provide a good answer on this. 
=C2=A0
I'll reply to him.








MTU and Fragmentation
---------------------

I think there are two main issue here. The first one is MTUD discovery
of the actual IP path MTU between the ports. That will be needed to prevent
a lot of traffic going into MTU black holes. Especially as TRILL requries
1470 byte support which is likey above a lot of paths.





Seems like it would depend on the environments where TRILL was used.
For example, I do not think 1470 would be a problem in most Data
Center or Internet Exchange point uses, for example. Data Centers
sometimes support 9K jumbo frames and the like.

In fact, it is probably bad to focus too much on 1470 -- that is a
required minimum to be sure that reasonable size link state PDUs can
be successfully flooded through the TRILL campus so that routing will
work. However, it would commonly be the case that, for the TRILL
campus to be useful in a particular case, links need to be able to
carry the expected size TRILL Data packets. For example, if there were
two parts of a TRILL campus connected by one or a few TRILL over IP
links and the end stations in each part were assuming they could use
1500 byte Ethernet packets, then the TRILL over IP links would need to
support an MTU based on 1500 + TRILL Header + IP and TRILL over IP
encapsulation. And more if security was being used or there were any
other reasons for additional headers/encapsulation...





Yes, and over general Internet you should be happy if you get 1500 bytes of=
 IP MTU, it may easily be lower with a couple of additional tunnel headers.=
 Thus, what you say is the goal is not feasible without a solution that sup=
ports fragmentation and reassembly,
 enabling one TRILL packet to be sent in multiple IP packets. The re-assemb=
ly do requires buffering and not something to easily perform on a router fa=
st path. And attempting to use IP fragmentation is likely doomed if you hav=
e any type of NAT or Firewall in
 the way. 



This points to a dedicated solution or using a transport protocol that supp=
orts carrying arbitrary data sizes, like TCP or SCTP. And you need to use t=
he byte-stream API of TCP to achieve this.

=C2=A0
OK.








Section 8.4:

   Path MTU discovery [RFC4821] should be useful
   in determining the IP MTU between a pair of RBridge ports with IP
   connectivity.

The issue with RFC4821 is that it has requirements on the packetization lay=
er.
Trill appears to have several components that are useful. However, it will
require a specification of the procedure to result in a useful tool.





See below.






Section 8.4:

   TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in
   [RFC7177], can be used to obtain added assurance of the MTU of a
   link.

Yes, that can confirm working MTUs that are at 1470 or above, but appears
prevented from working below 1470?





While there is a minimum size for TRILL IS-IS MTU PDUs, determined by
header size, it is well below 1470, probably (depending on whether
secuirty is in use, etc.) below 150 bytes.





Okay, if you say so, it was not obvious from the spec that is was allowed t=
o probe for paths with lesser MTUs than 1470.









Thus, it appears that there is a lack of mechanism here to actually ge=
t a valid
and functional MTU from TRILL in the cases where the Path MTU is below 1470=
. If
I am wrong good, but I think this is an important piece for how to handle t=
he
next main issue.





How about referencing Section 3 of
https://tools.ietf.org/html/draft-ietf=
-trill-mtu-negotiation-05
which is currently in IETF Last Call? (The wording of that section is
probably going to be improved based on an OPS review by Brian
Carpenter.)

I looked at this, and it appears to have the same issue, that it can't =
probe for MTU values below 1470.


I think the thing was that, befo=
re TRILL over IP, it would not have been useful to determine an MTU below 1=
470. But there is no particular problem in constructing a smaller MTU-probe=
 PDUs and an RBridge receiving such a PDU is generally required to respond =
with an equal length MTU-ack.=C2=A0


   2) RB1 tries to send an MTU-probe padded to the size 1470.

      a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1
         sets the "failed minimum MTU test" flag for RB2 in RB1&#=
39;s Hello
         and stop.


But, the algorithm clearly performs a binary search for the MTU. If=20
one look at RFC 4821 one will notice that there are some additional conside=
rations
there how to make the probing better and robuster. But, cleary Trill has so=
me other
criterias for what is a success. Verification that Sz works appears suffici=
ent,=20
and there are no need to probe further upwards. 








UDP encapsulation and IP fragments.





  ----------------------------------





I see it as a big issue that UDP encapsulation is the native one, and =
that
relies on IP fragmentation despite the need for reliable fragmentation. Wit=
h
the setup of having to support 1470 MTU on TRILL level some packets will be
fragmented in many environments. That will lead to a lot of losses, and as
discussed below a very big problem with middleboxes. The main problem here =
is
that if one tries to rely on IP fragments one will have issues with packets
ending up in black holes. And different problems depending on IPv4 or IPv6.
IPv6 is lilkely the lesser problem assuming that one have working PMTUD.

There are several ways out of this.

1. Detect issues and use TCP encapsulation with correctly set MSS to not ge=
t IP
fragements 2. Determine MTU and implement an fragmentation mechanism on top=
 of
UDP.





So, I don't see that much problem with UDP being the general defau=
lt
consistent with the TRILL philosophy of defaulting to need zero or
minimal configuration. The default should be to use multicast Hellos
for discovery of neighbors which sure points at UDP to me. Having to
traverse a NAT should be a rare case. Since, in the NAT case, you have
to configure things related to the static binding and the IP
address(es) of peer(s) anyway you can also configure to use a
different encapsulation than UDP, such as TCP, at the same time. I
don't see it as much of a problem if, by default, TRILL won't opera=
te
through a NAT. If you are using UDP and it fragments and fragments are
dropped at a NAT, probably you can't exchange Hellos so you will not
form an adjacency and anything on the other side of the NAT will not
be visible.





Yes, but this is the issue of applicability and documenting that applicabil=
ity. I don't know what goals and requirements that exist for Trill. If =
the WG are fine with some restrictions, then document them and focus on sol=
ving the issues that must be solved.




You can clearly choose to require TCP for cases where the IP MTU is insuffi=
cient for carrying the Sz sized trill packets between the RBs using UDP.=C2=
=A0
=C2=A0
OK.








Zero Checksum:
--------------

Section 5.4:

UDP Checksum - as specified in [RFC0768]

Considering the fast path encapsulation desire, I am surprised to not see a=
ny
mentioning of use of zero checksum here. Raising the zero checksum and forw=
ard
reference would be good I think.

And then Section 8.5:

   The requirements for the usage of the zero UDP Checksum in a UDP
   tunnel protocol are detailed in [RFC6936]. These requirements apply
   to the UDP based TRILL over IP encapsulations specified herein
   (native and VXLAN), which are applications of UDP tunnel.

If you actually intended to allow zero checksum, then you actually should
document that Trill fulfills the requirements that the applicability statem=
ent
raises. I have not analyzed how well it meets these requirements.

Please review Section 6.2 of RFC 8086 for example how that can be done.





OK. We'll look into it.






TCP Encapsulation issue
-----------------------

Section 5.6:

The TCP encapsulation appear to be missing an delimiter format allowing eac=
h
individual TRILL packet/payload to be read out of the TCP's byte stream=
. In
other words, a normal implementation has no way of ensuring that the TCP
payload starts with the start of a new TRILL payload. Multiple small TRILL
payloads may be included in the same TCP payload, and also only parts as TC=
P is
one way of dealing with TRILL packets that are larger than the IP+Encapsula=
tion
MTU that actually will work.

This comment is based on that there appear to be no length fields included =
in
the TRILL header. The most straight forward delimiter is a 2-byte length fi=
eld
for the TRILL payload to be encapsulated.





Right. It might also be useful to include some sort of check field, as
is done in BGP, to detect if you are out of sync in parsing the TCP
stream.

As you need to actually perform re-assembly, the solution is to use the byt=
e stream semantics the TCP API provides and have a framing for each packet.

=C2=A0
Of course.

My point was that the framing might usefully have some sort of flag field=
, like the BGP framing has, so that there was a good chance of detecting if=
 the parsing of the byte stream into frames has gotten out of synch.
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
<=
span class=3D"gmail-m_-2274122840677479759gmail-">



Another point is that, while with UDP it seems fine to send packets
with assorted QoS, you don't want to encourage re-ordering of TCP
packets in a stream. So if TCP encapsulation is being used, you want
to use the same DSCP value for the packets in a particular TCP stream.
So, generally, you need to have a TCP connection per priority handling
category. Mapping the 8 priority levels into a smaller number of
handling categories is a normal thing to do so you certainly don't
necessarily need 8 TCP connections. Adding material on this should not
be too hard.





Yes, agreed it is a possibility and points into possible considerations tha=
t David raised.











Section 5.6:

TCP endpoint requirements. I do wonder if an application like TRILL actual
would need to discuss performance impacting implementation choices or
limitations. For example use of NAGLE, the requirements on buffer sizes in
relation to Bandwidth delay products, as buffer memory in a RBridge will im=
pact
performance.





Well, I'm not sure how deeply this document should get into such
performance issues. What about just saying something about
consideration being given to tuning TCP for performance and pointing
to one or a few other RFCs that talk about this?





As Joe said, these are important considerations. If your intention is to en=
able this to run at substantial fractions of line rates of the interfaces. =
Then this do require considerations.=C2=A0

I see.=C2=A0
<=
div bgcolor=3D"#FFFFFF">








Congestion Control
------------------
First thanks for the effort here.





You're welcome.






8.1.2 In Other Environments

   Where UDP based encapsulation headers are used in TRILL over IP in
   environments other than those discussed in Section 8.1.1, specific
   congestion control mechanisms are commonly needed.  However, if the
   traffic being carried by the TRILL over IP link is already congestion
   controlled and the size and volatility of the TRILL IS-IS link state
   database is limited, then specific congestion control may not be
   needed. See [RFC8085] Section 3.1.11 for further guidance.

This is correct, however my question is if the RBridges have any way of kno=
wing
which traffic is actually congestion controlled, considering that TRILL pro=
vides
an layer 2 abstraction. I wonder if there should be any type of white list =
of
the types of layer 2 payloads that can be assumed to be congestion controll=
ed,
and thus okay to forward over IP paths? I am worried that without any
recommendation to prevent traffic that is not controlled to be forwarded, c=
an
lead to congestion issues.

The other issue I think may exist is the issue serial unicast emulation of
broadcast/multicast creates. As this amplifies the outgoing packet rate wit=
h
a factor of how many addresses are configured for serial unicast this can
be significant traffic expansion. Thus, I think additional considerations a=
re
needed here, and maybe rate limiting of the amount of traffic to be multica=
sted.





OK. We can think about those issues.






Flow and ECMP
-------------

Section 8.3:

For example, for TRILL
   Data, this entropy field could be based on some hash of the
   Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL.

I would appreciate clearer references to what these fields are.





In a TRILL Data packet, the payload after the TRILL Header looks like
an Ethernet frame except that there is always either a VLAN tag or,
alternatively, where the VLAN tag would be, a Fine Grained Label
[RFC7172]. (The preceding is the view in the TRILL RFCs, but there is
an equivalent and equally valid view in which all the fields through
and including the VLAN or FGL tag are part of the TRILL Header.) The
TRILL base protocol specification focuses on Ethernet as a link
technology between TRILL switches, in which case there will be a link
header including an Outer.MacDA and Outer.MacSA fields and possibly an
Outer.VLAN, all before the TRILL Header. See Figure 1 and Figure 2 in
RFC 7172.

Some of the above could be added to the draft for clarity.






If I understand this correctly, the idea here is to look into the inne=
r
layer 2 frames, and use the flow equivalents that exists on that level and
hash that into value that maps the flows onto the source port range.





Yes.






I think this text should include a summary of the principle and ensure=
 to
note the important requirement that what is considered flows in the inner
must not result in being striped over multiple source ports as this may lea=
d to
reordering issues due to packets taking different paths.





Well, we can add some text. But when would the relative ordering
matter for two TRILL Data packets where the two inner native payloads
have different values for any one or more of these three fields
(Inner.MacDA, Inner.MacSA, and inner VLAN/FGL tag) ? If any of those
fields are different, you are talking about different streams.





Okay, then this is very straightforward. 










NAT and TRILL over IP:
Section 8.5:

If one like to use TRILL over IP through a NAT, then there are some very
important considerations that are missing. First the need for static bindin=
g
configurations or the need for determining ones external address(es) and be
able to communicate that to the peer RBridges, and in addition ensure that =
one
has keep-alives to that the NAT binding never times out.





I think those are good points. There is an additional problem that
TRILL Hellos detect neighbors with which they have 2-way connectivity
by indicating, inside the Hellos that are sent, from what neighbors
Hellos have been received on that port. If a NAT is involved, these
neighbor addresses inside Hellos need to be mapped.

Yes, and the question is how that can be handled, by the receiver of the pa=
cket, or if the sender needs to determine what address it uses and provide =
that in the HELLOs. If the first is possible that can simplify a lot.

=C2=A0
I'm not sure. this would requi=
re a little detailed design work.








Next is the issue that there is almost zero chance of getting a IP/UDP
encapsulation TRILL payload through the NAT if it results in IP fragmentati=
on,
as NATs don't do defragment and refragmented on the internal side, and =
an IP
fragment lacks UDP port and thus can't be matched to binding.





So perhaps the recommendation should be to configure the port to use
TCP if there will be fragmentation.

Yes, I think that are likely the simplest solution for you. 

OK=C2=A0

Thanks,<=
/div>
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake =
3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milfor=
d, MA 01757 USA

Al=
so if you like to run IP/ESP through a NAT, then you most likely need the
IP/UDP/ESP encapsulation (https://tools.ietf.org/html/rfc3948)=
. Note that this
will restrict the MTU even further and thus ensure that the 1470 requiremen=
t
cannot be fulfilled even without additional tunnels over an 1500 bytes MTU
Ethernet infrastructure.

I would note that also firewalls likely have issues with IP fragments for t=
he
same reason, they require significant amount of state to be verified if the=
y
should be let through.

In general I think you should create a configuration that has chance to wor=
k
through most middleboxes, but I think you should require static bindings. I
think that configuration is, and don't laugh now, but IP/UDP/ESP/TCP/TR=
ILL,
otherwise you will not be able to have both security and reliable fragmenta=
tion
of TRILL packets.





OK. Thanks again for this review. It has pointed out a number of
problems and in thinking about those, I believe a couple of further
problems have come to mind that I mentioned above. We'll work on a
revised draft.







Cheers=20

Magnus Westerlund=20

-----------------------------------------------------------------=
-----
Media Technologies, Ericsson Research
-----------------------------------------------------------------=
-----
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.c=
om
-----------------------------------------------------------------=
-----








--001a1141bcbec246930553240434--


From nobody Fri Jun 30 03:47:26 2017
Return-Path: 
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1CE12EB99 for ; Fri, 30 Jun 2017 03:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wgnlbVlDmRDv for ; Fri, 30 Jun 2017 03:47:22 -0700 (PDT)
Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 51AB912EAF7 for ; Fri, 30 Jun 2017 03:47:22 -0700 (PDT)
Received: by mail-wr0-x235.google.com with SMTP id k67so201709583wrc.2 for ; Fri, 30 Jun 2017 03:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=IjI2ere6e6XTLF2o5K8WHRyJCUwqB8mLJfXz5K/URAk=; b=W81g88BP3/ezhS8JqnvPasplc0ljpM0UUctZFvRzDXp2ntji1YnhZpctv85E/rBF6A H155V96DYPCMKGGPhyEx9q14LAif5HT8htyLMtt3Ps5yeHvMkX6xfS6BCqlZk97ZoVNV POxF4+ycNu4h1l9IZDqamCs0IgqtI7TMm7KfvMfFaDeALR+Kfc4D/Wp2g7l/g+5kTyoq Te77zmaDsLyZ4iyYeg6ULX5M5a9GeKG+zdNDYwEj1G0YnhPH+I/y+P8rEPrMzUG5NmLG vqzQaS/53luaxyd+mowHkx7yyQEsdnB93nRmBAuFnjfD0gEqFD88puFXAisW9+RZoXEi uqwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=IjI2ere6e6XTLF2o5K8WHRyJCUwqB8mLJfXz5K/URAk=; b=X57FWiRhapu0MA/tTHJAmHSBHYBdMgyrwZvL1LFNerSm/74+RWpnrILJV1QTNFn5q0 BP/i/Abehfex8zf1R/Kw2elH7WBOGsryTsLLwFnb3t5qDPegQDEzjVwEtBOv1c7b1aqD h5bcsx0IHQqhOBgTN1IBfUTHV9FZq8NVmCCu9cmO4oxeupcvGGU5u4p70ZAxBpsJWfnR 5uzQ+6P/JW4yqnU35tcLd1KACDQKRQslnybkVW8n9e1pzzOIV/gvnggHsiErdps1lezm l2Q56oE3ajdgitul2vnhVhIKsPYbwck6bQJehg2lCExwAXNB06racEenfbIUMOsp+AAs EZfg==
X-Gm-Message-State: AKS2vOwzlzvIbKDl6LlSEW0soQZ2Eu0mZLRRL9a0DxGi9sFw++7bpgru 3l81gLWKU8KSbMxA
X-Received: by 10.223.135.42 with SMTP id a39mr23866258wra.78.1498819640507; Fri, 30 Jun 2017 03:47:20 -0700 (PDT)
Received: from fbipool-clients-45-95.fbi.h-da.de ([2001:41b8:9bf:fda2:1d83:365:9749:ce70]) by smtp.googlemail.com with ESMTPSA id r142sm4418445wmg.24.2017.06.30.03.47.18 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jun 2017 03:47:19 -0700 (PDT)
From: Martin Stiemerling 
To: tsv-art@ietf.org
Message-ID: <39a837d5-bb20-7479-7fd8-0023a65fd247@gmail.com>
Date: Fri, 30 Jun 2017 12:47:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 06/30
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 10:47:24 -0000

Dear TSVers,

I did work through all documents that are in IETF LC, IESG processing or 
being requested for publication as of 06/30, 12:45 am CEST.

Please find below all documents checked and what to do with these 
documents.

Documents that require TSV attention:
draft-ietf-teas-gmpls-lsp-fastreroute-09 -- Adrian
draft-ietf-trill-mtu-negotiation-06 -- Need Volunteer


Documents that do not require TSV attention:
draft-bormann-hybi-ws-wk-00
draft-weis-gdoi-rekey-ack-05
draft-ietf-teas-gmpls-scsi-03
draft-ietf-mpls-rfc3107bis-02
draft-ietf-httpbis-early-hints-03
draft-ietf-trill-rbridge-multilevel-06
draft-ietf-sipcore-content-id-07
draft-ietf-precis-7613bis-08
draft-ietf-dnsop-sutld-ps-06
draft-ietf-spring-oam-usecase-06
draft-ietf-pce-pceps-14
draft-ietf-manet-rfc5444-usage-06
draft-ietf-bier-architecture-07
draft-ietf-trill-arp-optimization-08

Cheers,

   Martin


From nobody Fri Jun 30 03:47:36 2017
Return-Path: 
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA84F12EC0C for ; Fri, 30 Jun 2017 03:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 6FlMe3I0UEaM for ; Fri, 30 Jun 2017 03:47:24 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 2934612EAF7 for ; Fri, 30 Jun 2017 03:47:24 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id 62so106520255wmw.1 for ; Fri, 30 Jun 2017 03:47:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=XsbcBJjRQ22J5vRJ10qdIP6SVbIsGjb8TtdtoS5+xTg=; b=AVmXeytcHLP83DNL3z+ZQmGs8ZC9mtjf4An958zqK35kkvWNYbMzCUITXzscAAPmcA k5jEKZ/kSx07avFzYJb+wsS9eW3Zzk8DmxVIn7fplRHbZBTFhOU4rIR+bsbE/Rkg5pya CNb00avPMcRuKc5xDyPOGctQs84/V3+7kJk06h7jSBpEBsHpfiinKxbCJREvEFrME1jh Wxzeh2DWK62bPGHyiQU3Mmqi5sUyFOoQTrw6rRW3CQgatY1KgDfbjvZrAs67GCavRSHU a7LiDHo0jZXkNsCwVnENqLeL+mVfjxkh05+I1UoXouCxmPJ4fHq5boKzE8UDCgbfGmnY RxcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=XsbcBJjRQ22J5vRJ10qdIP6SVbIsGjb8TtdtoS5+xTg=; b=rT2H9hMBd58L0/t+P+Dvap5Yf1w9go9D4AYf9Q57ySN6Ev/wTzuMpORiUwaAXZzect hCxRveA0BF/DHkYpuntjlKvnAARUXMiEUM6zKbYjfhH088Cl5HdX/Z/dXfSf8bMpxYrj ePustyo60q+rOiuS3urZzBNCr2g7WhE1wHtUIaHP1xwSlGScwnJXZmjOTtV+PyO3cw4j 3vFln975kUKWt0t3BuKzCX57vv79C71rYbsjgJIejF3M9RWEqNfGNqKbcYHAjtcV8vrs uz+Ptc4O4Aga27Cg7a3hrq2V+i9tsbmJOMIrUZl8RD/m8iVDGpZyA9AKEQ4spXBVCCIv 2Rpw==
X-Gm-Message-State: AKS2vOwxRR8Y5CWRUxxs+1czX0dxw2fj58xZgVY0H1DsMH80ailm0/z8 bmqwF9nEkEOcoDOv
X-Received: by 10.28.6.208 with SMTP id 199mr14274555wmg.45.1498819642467; Fri, 30 Jun 2017 03:47:22 -0700 (PDT)
Received: from fbipool-clients-45-95.fbi.h-da.de ([2001:41b8:9bf:fda2:1d83:365:9749:ce70]) by smtp.googlemail.com with ESMTPSA id c27sm7049050wrb.44.2017.06.30.03.47.21 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jun 2017 03:47:21 -0700 (PDT)
To: tsv-art@ietf.org
From: Martin Stiemerling 
Message-ID: <30013f8c-47bd-b753-17ed-41dfb53d49c8@gmail.com>
Date: Fri, 30 Jun 2017 12:47:21 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 10:47:26 -0000

Hi,

I wonder who could and would volunteer to do the tsv-art review for 
draft-ietf-trill-mtu-negotiation-06 ?

Thanks,

   Martin


From nobody Fri Jun 30 09:04:50 2017
Return-Path: 
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DEE12FEE1 for ; Fri, 30 Jun 2017 09:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 R9Jv-y_AjTGo for ; Fri, 30 Jun 2017 09:04:48 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 F28DF12778E for ; Fri, 30 Jun 2017 09:04:47 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v5UG3pie025367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 Jun 2017 09:03:53 -0700 (PDT)
To: Martin Stiemerling , tsv-art@ietf.org
References: <30013f8c-47bd-b753-17ed-41dfb53d49c8@gmail.com>
From: Joe Touch 
Message-ID: <81eb8115-23cc-f9af-5e6f-de63508c8406@isi.edu>
Date: Fri, 30 Jun 2017 09:03:50 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <30013f8c-47bd-b753-17ed-41dfb53d49c8@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Subject: Re: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 16:04:50 -0000

Hi, all,

I'm familiar with both TRILL and MTU issues ;-)

However, I'm out for the next two weeks; the soonest I could do this
would likely be as the IETF begins...

Joe


On 6/30/2017 3:47 AM, Martin Stiemerling wrote:
> Hi,
>
> I wonder who could and would volunteer to do the tsv-art review for
> draft-ietf-trill-mtu-negotiation-06 ?
>
> Thanks,
>
>   Martin
>
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art


From nobody Fri Jun 30 13:14:18 2017
Return-Path: 
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDFF1314A4 for ; Fri, 30 Jun 2017 13:14:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 V5muQZE3orE1 for ; Fri, 30 Jun 2017 13:14:15 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D682212E957 for ; Fri, 30 Jun 2017 13:14:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=Gq42Zpf/YzQ0QvEmWfDQ5fqCa+dE+p3SAfb6lO9sYGw7nRCroSpGcr+0jGDIdHiGzNUEAiwpPwbIXSbYIlA/i/0TiTbBEgsTB/uVIn4+ZN/AMQVeLf9QJesq2gRLOZJKpz7q7HYFafX6ZCjPMY8LNCnv6ZE8b91E7JwRXUfP6ao=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 1589 invoked from network); 30 Jun 2017 22:14:12 +0200
Received: from pd9e11f21.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.31.33) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 30 Jun 2017 22:14:12 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <81eb8115-23cc-f9af-5e6f-de63508c8406@isi.edu>
Date: Fri, 30 Jun 2017 22:14:11 +0200
Cc: Martin Stiemerling , tsv-art@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <30013f8c-47bd-b753-17ed-41dfb53d49c8@gmail.com> <81eb8115-23cc-f9af-5e6f-de63508c8406@isi.edu>
To: Joe Touch 
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20170630201412.1583.31701@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
Subject: Re: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 20:14:17 -0000

The document is on the telechat agenda for next Thursday, so in two =
weeks is too late. I read the doc already and didn=E2=80=99t see any =
issue. So a short check might be enough=E2=80=A6

Mirja


> Am 30.06.2017 um 18:03 schrieb Joe Touch :
>=20
> Hi, all,
>=20
> I'm familiar with both TRILL and MTU issues ;-)
>=20
> However, I'm out for the next two weeks; the soonest I could do this
> would likely be as the IETF begins...
>=20
> Joe
>=20
>=20
> On 6/30/2017 3:47 AM, Martin Stiemerling wrote:
>> Hi,
>>=20
>> I wonder who could and would volunteer to do the tsv-art review for
>> draft-ietf-trill-mtu-negotiation-06 ?
>>=20
>> Thanks,
>>=20
>>  Martin
>>=20
>> _______________________________________________
>> Tsv-art mailing list
>> Tsv-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/tsv-art
>=20
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art


From nobody Fri Jun 30 14:00:35 2017
Return-Path: 
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A1212741D for ; Fri, 30 Jun 2017 14:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 XVjel_lCgQBk for ; Fri, 30 Jun 2017 14:00:31 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 C702D127137 for ; Fri, 30 Jun 2017 14:00:31 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v5UKxbE9002267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 Jun 2017 13:59:38 -0700 (PDT)
To: "Mirja Kuehlewind (IETF)" 
Cc: Martin Stiemerling , tsv-art@ietf.org
References: <30013f8c-47bd-b753-17ed-41dfb53d49c8@gmail.com> <81eb8115-23cc-f9af-5e6f-de63508c8406@isi.edu> 
From: Joe Touch 
Message-ID: <1f121338-a249-fca1-bfef-c16a571b1652@isi.edu>
Date: Fri, 30 Jun 2017 13:59:36 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Subject: Re: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 21:00:33 -0000

I can do a short check next Wed, if that helps. It wouldn't hurt to ask
Fred to check it too.

Joe


On 6/30/2017 1:14 PM, Mirja Kuehlewind (IETF) wrote:
> The document is on the telechat agenda for next Thursday, so in two weeks is too late. I read the doc already and didn’t see any issue. So a short check might be enough…
>
> Mirja
>
>
>> Am 30.06.2017 um 18:03 schrieb Joe Touch :
>>
>> Hi, all,
>>
>> I'm familiar with both TRILL and MTU issues ;-)
>>
>> However, I'm out for the next two weeks; the soonest I could do this
>> would likely be as the IETF begins...
>>
>> Joe
>>
>>
>> On 6/30/2017 3:47 AM, Martin Stiemerling wrote:
>>> Hi,
>>>
>>> I wonder who could and would volunteer to do the tsv-art review for
>>> draft-ietf-trill-mtu-negotiation-06 ?
>>>
>>> Thanks,
>>>
>>>  Martin
>>>
>>> _______________________________________________
>>> Tsv-art mailing list
>>> Tsv-art@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tsv-art
>> _______________________________________________
>> Tsv-art mailing list
>> Tsv-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/tsv-art


From nobody Fri Jun 30 18:43:48 2017
Return-Path: 
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADE012EC5C; Fri, 30 Jun 2017 18:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 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, URIBL_BLOCKED=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 eTvYNoVfK8wD; Fri, 30 Jun 2017 18:43:31 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 EE95512EABA; Fri, 30 Jun 2017 18:43:30 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id r36so32633421ioi.1; Fri, 30 Jun 2017 18:43:30 -0700 (PDT)
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=QgV41TXIZD7Vk5O6hFiAunE+DHtrdZuP08ULzeYh1Nk=; b=mY/uoT/MQLktf5kK42lyLAPk6UexxqDAuE6kufCOUSfUFrOR2DkqXLVcHgpK5phQDZ ygRDioA3PnCQ5X8TsCQaJqilQ/XJgMOPt4GC0Yaz0m/rp9c5sVeI/N0HNLNYyTBEWbWQ iPhieu5dBFmV1m/NaUcvflcbvtmRW1dJt/bllGT9qy3I0scxamL+L2q89CXXuXntVa/c 2nvm7pm3IpxbCsLJ4VGq569bP3VerCTsssAcIAn7DNYbdHLOyYhf4hrvtqV5EN/yTcGv PGaElgH+sHIzPfkzRQaeTJEWDAZrIzoulU2sKtotkj57iJNuD8pMO6KTi4FfFlsJQlv7 XaYg==
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=QgV41TXIZD7Vk5O6hFiAunE+DHtrdZuP08ULzeYh1Nk=; b=FloA/PSF+3c5n3Ke5DTqpuHKpNVs7SZZ85pREe+9cW+lGr0P3OfvAOwJvJtQflQHlr UsIZZjorojjls9NYm7PlAXET4vhltPu9T7PoDZ5h+5XO4+cqb/4yLtumVPycGTXAnpq1 EqUbWt5JHrdxfqB8+nQ5ITs92gtiY09ZmaNSvWsZUH/QbNXrGcj3JU8MeBG9gyUloAm4 RzQylW0ZWhe6uQ5AOIynOgm4+8UP9zOfktayOPrqBHN437V2YH9N33wLU7x1jqXhwJW0 glKaqbiaFr1PptggNoCcrppnE/DI/5efy0UKDI7A4p2e/kcMcZLWLFhqCtQeWfgnt3M9 bXjQ==
X-Gm-Message-State: AKS2vOy4DKCSO0528qbab4hmP2UqDYpAVx5fVh+2jZz0eZAayWkt8Veg 4XOKErF5v5FpcWwO05uCTHXGZkxtXKo5
X-Received: by 10.107.156.83 with SMTP id f80mr25274248ioe.9.1498873410069; Fri, 30 Jun 2017 18:43:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.221 with HTTP; Fri, 30 Jun 2017 18:43:13 -0700 (PDT)
In-Reply-To: 
References: 
From: Donald Eastlake 
Date: Fri, 30 Jun 2017 21:43:13 -0400
Message-ID: 
To: "Black, David" 
Cc: Magnus Westerlund , "tsv-art@ietf.org" ,  "draft-ietf-trill-over-ip.all@ietf.org" , IETF Discussion ,  "trill@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Jul 2017 01:43:35 -0000

Hi David,

On Mon, Jun 26, 2017 at 3:04 PM, Black, David  wrote:
> Adding some comments on ECN and DSCP ...
>
>> > Section 4.3:
>> >
>> >    TRILL over IP implementations MUST support setting the DSCP value in
>> >    the outer IP Header of TRILL packets they send by mapping the TRILL
>> >    priority and DEI to the DSCP. They MAY support, for a TRILL Data
>> >    packet where the native frame payload is an IP packet, mapping the
>> >    DSCP in this inner IP packet to the outer IP Header with the default
>> >    for that mapping being to copy the DSCP without change.
>> >
>> > I think it is fine to require that implementations are capable of setting
>> > DSCP values on the outer IP header. However, I fail to see any discussion of
>> > the potential issues with actually setting the DSCP values. It is one thing to
>> > do this in an IP back bone use case where one can know and have control
>> > over the PHB that the DSCP values maps to. But otherwise, over general
>> > internet the
>> > behavior is not that predictable. One can easily be subject to policers or
>> > remapping. Also as the actual DSCP code point usage is domain specific this is
>> > difficult. Priority reversal is likely the least of the problems that this can
>> > run into over general Internet.
>>
>> It sounds like appropriate discussion and warnings about these issues
>> would resolve the above comment.
>
> For ECN, see RFC 6040 and draft-ietf-tsvwg-rfc6040update-shim.  In particular,
> copying the inner ECN codepoint to the outer IP header encapsulation without
> requiring decapsulation processing as specified in RFC 6040 or the 6040update-shim
> draft can lose congestion indications from the network and hence is wrong
> (it's also wrong wrt RFC 3168, but RFC 6040 and the 6040update-shim drafts are
> better and more current references).

That's a good point.

> For DSCPs, start with RFC 2983 - thinking about the validity (or likely validity)
> of the outer DSCP at the decapsulator may help in choosing whether to
> recommend a uniform model (e.g., copy DSCP out at ingress, copy back in at
> egress) or a pipe model (e.g., do something reasonable for outer DSCP at
> ingress, ignore it on egress) as the implementation default.

I believe the default behavior in the current draft is the best
default. That sets DSCP based on the same TRILL Header indicia that
controls default QoS on non-IP links.

> -- DSCP mapping to/from TRILL/Ethernet priorities
>
>> The intent in the draft is to reflect the default relative priority of
>> the different priority code points in IEEE Std 802.1Q where priority 1
>> is lower than priority 0. At a quick look, it appears to me that RFC
>> 2474 requires that 0x001000 be handled as being of a priority not
>> lower than the priority with which 0x000000 is handled. Yet RFC 3662,
>> which you point to, seems to suggest using 0x001000 as a lower
>> priority code point than 0x000000. Given that 3662 not only does not
>> update 2474 but is only Informational while 2474 is Standards Track, I
>> would say that 2474 dominates and that this draft makes the best
>> assumptions it can about default behavior...
>
> Well ... that's a discussion about text in RFCs that are well over a decade
> old, and in an area (less-than-best-effort service) where the aspirations
> of at least RFC 3662 weren't realized ... but that RFC is not safe to ignore,
> either.
>
> In practice, the specification of CS1 for less-than-best-effort service has
> been promulgated by RFC 4594 rather than RFC 3662, and RFC 4594 has
> had significant "running code" impact on network design and operation.
>
> As Magnus mentioned RFC7657, I strongly suggest starting from the
> RFC 7657 discussion of this topic in order to figure out what to do.  I'm
> not sure what to recommend, but I do think that starting from
> RFC 7657 (rather than RFC 2474 and RFC 3662) is the better approach.

OK.

> FWIW, the TSVWG WG is in the process of figuring out which DSCP
> to recommend for less-than-best-effort-service in place of CS1 - that's
> likely to be an active topic of discussion in Prague.

I'll try to attend that session.

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

> Thanks, --David
>
>> -----Original Message-----
>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Donald
>> Eastlake
>> Sent: Sunday, June 25, 2017 8:07 PM
>> To: Magnus Westerlund 
>> Cc: tsv-art@ietf.org; draft-ietf-trill-over-ip.all@ietf.org; IETF Discussion
>> ; trill@ietf.org
>> Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10
>>
>> Hi Magnus,
>>
>> Thanks for the extensive review. See my responses below.
>>
>> On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund
>>  wrote:
>> >
>> > Reviewer: Magnus Westerlund
>> > Review result: Not Ready
>> >
>> > Early review of draft-ietf-trill-over-ip-10
>> > Reviewer: Magnus Westerlund
>> > Review result: Not Ready
>> >
>> > TSV-ART review comments:
>> >
>> > I have set this to not ready as there are several issues, some significant that
>> > could affect the protocol realization significantly. Some may be me missing
>> > things in TRILL, I was not that familiar with it before this review and I have
>> > only tried looking up things, not reading the whole earlier specifications. So
>> > don't hesitate to push back and provide pointers to things that can resolve
>> > issues. The authors and the WG clearly have thought about a lot of issues
>> and
>> > dealt with much already.
>>
>> OK. Hopefully we can resolve these one way or the other.
>>
>> > Diffserv usage
>> > --------------
>> >
>> > Section 4.3:
>> >
>> >    TRILL over IP implementations MUST support setting the DSCP value in
>> >    the outer IP Header of TRILL packets they send by mapping the TRILL
>> >    priority and DEI to the DSCP. They MAY support, for a TRILL Data
>> >    packet where the native frame payload is an IP packet, mapping the
>> >    DSCP in this inner IP packet to the outer IP Header with the default
>> >    for that mapping being to copy the DSCP without change.
>> >
>> > I think it is fine to require that implementations are capable  of setting
>> > DSCP values on the outer IP header. However, I fail to see any discussion of
>> > the potential issues with actually setting the DSCP values. It is one thing to
>> > do this in an IP back bone use case where one can know and have control
>> over
>> > the PHB that the DSCP values maps to. But otherwise, over general
>> internet the
>> > behavior is not that predictable. One can easily be subject to policers or
>> > remapping. Also as the actual DSCP code point usage is domain specific this
>> is
>> > difficult. Priority reversal is likely the least of the problems that this can
>> > run into over general Internet.
>>
>> It sounds like appropriate discussion and warnings about these issues
>> would resolve the above comment.
>>
>> > Section 4.3:
>> >
>> >    The default TRILL priority and DEI to DSCP mapping, which may be
>> >    configured per TRILL over IP port, is an follows. Note that the DEI
>> >    value does not affect the default mapping and, to provide a
>> >    potentially lower priority service than the default priority 0,
>> >    priority 1 is considered lower priority than 0. So the priority
>> >    sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7.
>> >
>> >       TRILL Priority  DEI  DSCP Field (Binary/decimal)
>> >       --------------  ---  -----------------------------
>> >                   0   0/1  001000 / 8
>> >                   1   0/1  000000 / 0
>> >                   2   0/1  010000 / 16
>> >                   3   0/1  011000 / 24
>> >                   4   0/1  100000 / 32
>> >                   5   0/1  101000 / 40
>> >                   6   0/1  110000 / 48
>> >                   7   0/1  111000 / 56
>> >
>> > This appear to be an problematic mapping. At least for prio 0 and 1. As
>> > priority 1 appears to be intended to be higher than priority 0, it is
>> > interesting that it is mapped to CS1, which to quote
>> > https://datatracker.ietf.org/doc/rfc7657/:
>> >
>> > CS1 ('001000') was subsequently designated as the recommended
>> >       codepoint for the Lower Effort (LE) PHB [RFC3662].
>> >
>> > So what is proposed can in a network using default mapping, result in that
>> you
>> > get priority 0 to be lower priority than 1. Plus that in some networks this can
>> > also results in strange remapping that results in a different PHB for CS1
>> than.
>>
>> The intent in the draft is to reflect the default relative priority of
>> the different priority code points in IEEE Std 802.1Q where priority 1
>> is lower than priority 0. At a quick look, it appears to me that RFC
>> 2474 requires that 0x001000 be handled as being of a priority not
>> lower than the priority with which 0x000000 is handled. Yet RFC 3662,
>> which you point to, seems to suggest using 0x001000 as a lower
>> priority code point than 0x000000. Given that 3662 not only does not
>> update 2474 but is only Informational while 2474 is Standards Track, I
>> would say that 2474 dominates and that this draft makes the best
>> assumptions it can about default behavior...
>>
>> > MTU and Fragmentation
>> > ---------------------
>> >
>> > I think there are two main issue here. The first one is MTUD discovery
>> > of the actual IP path MTU between the ports. That will be needed to
>> prevent
>> > a lot of traffic going into MTU black holes. Especially as TRILL requries
>> > 1470 byte support which is likey above a lot of paths.
>>
>> Seems like it would depend on the environments where TRILL was used.
>> For example, I do not think 1470 would be a problem in most Data
>> Center or Internet Exchange point uses, for example. Data Centers
>> sometimes support 9K jumbo frames and the like.
>>
>> In fact, it is probably bad to focus too much on 1470 -- that is a
>> required minimum to be sure that reasonable size link state PDUs can
>> be successfully flooded through the TRILL campus so that routing will
>> work. However, it would commonly be the case that, for the TRILL
>> campus to be useful in a particular case, links need to be able to
>> carry the expected size TRILL Data packets. For example, if there were
>> two parts of a TRILL campus connected by one or a few TRILL over IP
>> links and the end stations in each part were assuming they could use
>> 1500 byte Ethernet packets, then the TRILL over IP links would need to
>> support an MTU based on 1500 + TRILL Header + IP and TRILL over IP
>> encapsulation. And more if security was being used or there were any
>> other reasons for additional headers/encapsulation...
>>
>> > Section 8.4:
>> >
>> >    Path MTU discovery [RFC4821] should be useful
>> >    in determining the IP MTU between a pair of RBridge ports with IP
>> >    connectivity.
>> >
>> > The issue with RFC4821 is that it has requirements on the packetization
>> layer.
>> > Trill appears to have several components that are useful. However, it will
>> > require a specification of the procedure to result in a useful tool.
>>
>> See below.
>>
>> > Section 8.4:
>> >
>> >    TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in
>> >    [RFC7177], can be used to obtain added assurance of the MTU of a
>> >    link.
>> >
>> > Yes, that can confirm working MTUs that are at 1470 or above, but appears
>> > prevented from working below 1470?
>>
>> While there is a minimum size for TRILL IS-IS MTU PDUs, determined by
>> header size, it is well below 1470, probably (depending on whether
>> secuirty is in use, etc.) below 150 bytes.
>>
>> > Thus, it appears that there is a lack of mechanism here to actually get a valid
>> > and functional MTU from TRILL in the cases where the Path MTU is below
>> 1470. If
>> > I am wrong good, but I think this is an important piece for how to handle
>> the
>> > next main issue.
>>
>> How about referencing Section 3 of
>> https://tools.ietf.org/html/draft-ietf-trill-mtu-negotiation-05
>> which is currently in IETF Last Call? (The wording of that section is
>> probably going to be improved based on an OPS review by Brian
>> Carpenter.)
>>
>> > UDP encapsulation and IP fragments.
>>   ----------------------------------
>> > I see it as a big issue that UDP encapsulation is the native one, and that
>> > relies on IP fragmentation despite the need for reliable fragmentation.
>> With
>> > the setup of having to support 1470 MTU on TRILL level some packets will
>> be
>> > fragmented in many environments. That will lead to a lot of losses, and as
>> > discussed below a very big problem with middleboxes. The main problem
>> here is
>> > that if one tries to rely on IP fragments one will have issues with packets
>> > ending up in black holes. And different problems depending on IPv4 or
>> IPv6.
>> > IPv6 is lilkely the lesser problem assuming that one have working PMTUD.
>> >
>> > There are several ways out of this.
>> >
>> > 1. Detect issues and use TCP encapsulation with correctly set MSS to not
>> get IP
>> > fragements 2. Determine MTU and implement an fragmentation
>> mechanism on top of
>> > UDP.
>>
>> So, I don't see that much problem with UDP being the general default
>> consistent with the TRILL philosophy of defaulting to need zero or
>> minimal configuration. The default should be to use multicast Hellos
>> for discovery of neighbors which sure points at UDP to me. Having to
>> traverse a NAT should be a rare case. Since, in the NAT case, you have
>> to configure things related to the static binding and the IP
>> address(es) of peer(s) anyway you can also configure to use a
>> different encapsulation than UDP, such as TCP, at the same time. I
>> don't see it as much of a problem if, by default, TRILL won't operate
>> through a NAT. If you are using UDP and it fragments and fragments are
>> dropped at a NAT, probably you can't exchange Hellos so you will not
>> form an adjacency and anything on the other side of the NAT will not
>> be visible.
>>
>> > Zero Checksum:
>> > --------------
>> >
>> > Section 5.4:
>> >
>> > UDP Checksum - as specified in [RFC0768]
>> >
>> > Considering the fast path encapsulation desire, I am surprised to not see
>> any
>> > mentioning of use of zero checksum here. Raising the zero checksum and
>> forward
>> > reference would be good I think.
>> >
>> > And then Section 8.5:
>> >
>> >    The requirements for the usage of the zero UDP Checksum in a UDP
>> >    tunnel protocol are detailed in [RFC6936]. These requirements apply
>> >    to the UDP based TRILL over IP encapsulations specified herein
>> >    (native and VXLAN), which are applications of UDP tunnel.
>> >
>> > If you actually intended to allow zero checksum, then you actually should
>> > document that Trill fulfills the requirements that the applicability statement
>> > raises. I have not analyzed how well it meets these requirements.
>> >
>> > Please review Section 6.2 of RFC 8086 for example how that can be done.
>>
>> OK. We'll look into it.
>>
>> > TCP Encapsulation issue
>> > -----------------------
>> >
>> > Section 5.6:
>> >
>> > The TCP encapsulation appear to be missing an delimiter format allowing
>> each
>> > individual TRILL packet/payload to be read out of the TCP's byte stream. In
>> > other words, a normal implementation has no way of ensuring that the TCP
>> > payload starts with the start of a new TRILL payload. Multiple small TRILL
>> > payloads may be included in the same TCP payload, and also only parts as
>> TCP is
>> > one way of dealing with TRILL packets that are larger than the
>> IP+Encapsulation
>> > MTU that actually will work.
>> >
>> > This comment is based on that there appear to be no length fields included
>> in
>> > the TRILL header. The most straight forward delimiter is a 2-byte length
>> field
>> > for the TRILL payload to be encapsulated.
>>
>> Right. It might also be useful to include some sort of check field, as
>> is done in BGP, to detect if you are out of sync in parsing the TCP
>> stream.
>>
>> Another point is that, while with UDP it seems fine to send packets
>> with assorted QoS, you don't want to encourage re-ordering of TCP
>> packets in a stream. So if TCP encapsulation is being used, you want
>> to use the same DSCP value for the packets in a particular TCP stream.
>> So, generally, you need to have a TCP connection per priority handling
>> category. Mapping the 8 priority levels into a smaller number of
>> handling categories is a normal thing to do so you certainly don't
>> necessarily need 8 TCP connections. Adding material on this should not
>> be too hard.
>>
>> > Section 5.6:
>> >
>> > TCP endpoint requirements. I do wonder if an application like TRILL actual
>> > would need to discuss performance impacting implementation choices or
>> > limitations. For example use of NAGLE, the requirements on buffer sizes in
>> > relation to Bandwidth delay products, as buffer memory in a RBridge will
>> impact
>> > performance.
>>
>> Well, I'm not sure how deeply this document should get into such
>> performance issues. What about just saying something about
>> consideration being given to tuning TCP for performance and pointing
>> to one or a few other RFCs that talk about this?
>>
>> > Congestion Control
>> > ------------------
>> > First thanks for the effort here.
>>
>> You're welcome.
>>
>> > 8.1.2 In Other Environments
>> >
>> >    Where UDP based encapsulation headers are used in TRILL over IP in
>> >    environments other than those discussed in Section 8.1.1, specific
>> >    congestion control mechanisms are commonly needed.  However, if the
>> >    traffic being carried by the TRILL over IP link is already congestion
>> >    controlled and the size and volatility of the TRILL IS-IS link state
>> >    database is limited, then specific congestion control may not be
>> >    needed. See [RFC8085] Section 3.1.11 for further guidance.
>> >
>> > This is correct, however my question is if the RBridges have any way of
>> knowing
>> > which traffic is actually congestion controlled, considering that TRILL
>> provides
>> > an layer 2 abstraction. I wonder if there should be any type of white list of
>> > the types of layer 2 payloads that can be assumed to be congestion
>> controlled,
>> > and thus okay to forward over IP paths? I am worried that without any
>> > recommendation to prevent traffic that is not controlled to be forwarded,
>> can
>> > lead to congestion issues.
>> >
>> > The other issue I think may exist is the issue serial unicast emulation of
>> > broadcast/multicast creates. As this amplifies the outgoing packet rate with
>> > a factor of how many addresses are configured for serial unicast this can
>> > be significant traffic expansion. Thus, I think additional considerations are
>> > needed here, and maybe rate limiting of the amount of traffic to be
>> multicasted.
>>
>> OK. We can think about those issues.
>>
>> > Flow and ECMP
>> > -------------
>> >
>> > Section 8.3:
>> >
>> > For example, for TRILL
>> >    Data, this entropy field could be based on some hash of the
>> >    Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL.
>> >
>> > I would appreciate clearer references to what these fields are.
>>
>> In a TRILL Data packet, the payload after the TRILL Header looks like
>> an Ethernet frame except that there is always either a VLAN tag or,
>> alternatively, where the VLAN tag would be, a Fine Grained Label
>> [RFC7172]. (The preceding is the view in the TRILL RFCs, but there is
>> an equivalent and equally valid view in which all the fields through
>> and including the VLAN or FGL tag are part of the TRILL Header.) The
>> TRILL base protocol specification focuses on Ethernet as a link
>> technology between TRILL switches, in which case there will be a link
>> header including an Outer.MacDA and Outer.MacSA fields and possibly an
>> Outer.VLAN, all before the TRILL Header. See Figure 1 and Figure 2 in
>> RFC 7172.
>>
>> Some of the above could be added to the draft for clarity.
>>
>> > If I understand this correctly, the idea here is to look into the inner
>> > layer 2 frames, and use the flow equivalents that exists on that level and
>> > hash that into value that maps the flows onto the source port range.
>>
>> Yes.
>>
>> > I think this text should include a summary of the principle and ensure to
>> > note the important requirement that what is considered flows in the inner
>> > must not result in being striped over multiple source ports as this may lead
>> to
>> > reordering issues due to packets taking different paths.
>>
>> Well, we can add some text. But when would the relative ordering
>> matter for two TRILL Data packets where the two inner native payloads
>> have different values for any one or more of these three fields
>> (Inner.MacDA, Inner.MacSA, and inner VLAN/FGL tag) ? If any of those
>> fields are different, you are talking about different streams.
>>
>> > NAT and TRILL over IP:
>> > Section 8.5:
>> >
>> > If one like to use TRILL over IP through a NAT, then there are some very
>> > important considerations that are missing. First the need for static binding
>> > configurations or the need for determining ones external address(es) and
>> be
>> > able to communicate that to the peer RBridges, and in addition ensure that
>> one
>> > has keep-alives to that the NAT binding never times out.
>>
>> I think those are good points. There is an additional problem that
>> TRILL Hellos detect neighbors with which they have 2-way connectivity
>> by indicating, inside the Hellos that are sent, from what neighbors
>> Hellos have been received on that port. If a NAT is involved, these
>> neighbor addresses inside Hellos need to be mapped.
>>
>> > Next is the issue that there is almost zero chance of getting a IP/UDP
>> > encapsulation TRILL payload through the NAT if it results in IP
>> fragmentation,
>> > as NATs don't do defragment and refragmented on the internal side, and
>> an IP
>> > fragment lacks UDP port and thus can't be matched to binding.
>>
>> So perhaps the recommendation should be to configure the port to use
>> TCP if there will be fragmentation.
>>
>> > Also if you like to run IP/ESP through a NAT, then you most likely need the
>> > IP/UDP/ESP encapsulation (https://tools.ietf.org/html/rfc3948). Note that
>> this
>> > will restrict the MTU even further and thus ensure that the 1470
>> requirement
>> > cannot be fulfilled even without additional tunnels over an 1500 bytes MTU
>> > Ethernet infrastructure.
>> >
>> > I would note that also firewalls likely have issues with IP fragments for the
>> > same reason, they require significant amount of state to be verified if they
>> > should be let through.
>> >
>> > In general I think you should create a configuration that has chance to work
>> > through most middleboxes, but I think you should require static bindings. I
>> > think that configuration is, and don't laugh now, but
>> IP/UDP/ESP/TCP/TRILL,
>> > otherwise you will not be able to have both security and reliable
>> fragmentation
>> > of TRILL packets.
>>
>> OK. Thanks again for this review. It has pointed out a number of
>> problems and in thinking about those, I believe a couple of further
>> problems have come to mind that I mentioned above. We'll work on a
>> revised draft.
>>
>> Thanks,
>> Donald
>> ===============================
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  d3e3e3@gmail.com
>>
>> > Cheers
>> >
>> > Magnus Westerlund
>>
>> _______________________________________________
>> Tsv-art mailing list
>> Tsv-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/tsv-art