From nobody Wed Jan 11 13:53:01 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 59F96129591 for ; Wed, 11 Jan 2017 13:52:59 -0800 (PST) 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 qV55me68p1_S for ; Wed, 11 Jan 2017 13:52:58 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c: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 B920D1294F1 for ; Wed, 11 Jan 2017 13:52:57 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id r126so24881660wmr.0 for ; Wed, 11 Jan 2017 13:52:57 -0800 (PST) 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=lxCZmO6Kbe8TDpJXSAPE57QFmzCHd2p93mzSb5W46fM=; b=Z4gdzJR8oXrKmu8e5tNnVDl7d9LIXEr+tFOCsEheuw1GvNeFd10ZOf93mMldpLt9sk NTx3VAekAAOJOPl+GbS1A8l9scXaBE7Y+aWU4tCaN0zDpUkRtU5DqsDTiHQqFr85hVpf im7c5PhfzWIMYpDgnvQHCtHmtQyEQuR7H+mcVWOp/6VVJZ3cegN+uFZYpnhEcPic3Zde bAeYMOsiEdZDDqCqAZuTVMFEL998HXj0nDM8YP4jMTom93hvxzjEAT0w2bt+vGMYIol+ 2+KD01w9qhVONC4ISdH5ruocFmbDmVDuzFguHzuqyAiqA+rF5kxiM0HiAuGq3Qhk206m 2jww== 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=lxCZmO6Kbe8TDpJXSAPE57QFmzCHd2p93mzSb5W46fM=; b=mC0ngpECXwQwjiYRUOoT2OREtPL2X3v60hY3SRHwnO6wMQMkDmgcLXrYhHKfVz0ee/ 8faQ2YuTdbrergM5u8IA/odGdmicdhSGqXg1Ku9Kcu0Ci7EB1WuYBiNxx9bI8SYv4mBO 2pq3HswUq4lRFRbfyaYB7CRFmZ5c+D8E9YE4jV+PdC3cOqM0Te12bc3fjQfUaih034mU gZuAo+THuGs6TZ0T1N7PPTpwHXt9T4cYIUY9gXgG181ryUPipe//SG32kwsDcVlztfkq DVj58IFPC7clMqbIEMnXdVfbOhKAY8DqM12tw0bxowJlLVxHYY+hD9v3WFNM70/H1j2d xcHg== X-Gm-Message-State: AIkVDXL5d5embSw6cGyjUnEQs5PLD2wZ9e7hJHKR1bTZbLbYQdH7KdWRCdrsWLVdeay4qQ== X-Received: by 10.28.99.69 with SMTP id x66mr4371271wmb.91.1484171575983; Wed, 11 Jan 2017 13:52:55 -0800 (PST) Received: from ?IPv6:2003:74:cf7b:5953:f802:b0c2:1a02:ebe9? (p200300063350F753F802B0C21A02EBE9.dip0.t-ipconnect.de. [2003:6:3350:f753:f802:b0c2:1a02:ebe9]) by smtp.googlemail.com with ESMTPSA id l187sm4592wml.6.2017.01.11.13.52.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 13:52:55 -0800 (PST) From: Martin Stiemerling To: tsv-art@ietf.org Message-ID: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> Date: Wed, 11 Jan 2017 22:52:54 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 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 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 21:52:59 -0000 Dear TSVers, First of all, a happy new (western) year! :) I did work through all documents that are in IETF LC, IESG processing or being requested for publication as of 01/11, 09:00 pm UTC. Please find below all documents checked and what to do with these documents. Documents that require TSV attention: none. Documents that do not require TSV attention: draft-ietf-oauth-jwsreq-09 draft-ietf-ipsecme-rfc4307bis-15 draft-ietf-geojson-text-sequence-03 draft-ietf-dime-agent-overload-08 draft-ietf-bmwg-ipv6-nd-04 draft-ietf-intarea-hostname-practice-03 draft-mohali-dispatch-cause-for-service-number-12 draft-ietf-trill-rfc6439bis-04 draft-ietf-trill-directory-assist-mechanisms-10 draft-ietf-teas-p2mp-loose-path-reopt-08 draft-ietf-teas-gmpls-resource-sharing-proc-06 draft-ietf-sidr-rpki-oob-setup-06 draft-ietf-sidr-publication-10 draft-ietf-sidr-adverse-actions-03 draft-ietf-rtgwg-rlfa-node-protection-10 draft-ietf-mpls-residence-time-12 draft-ietf-lisp-type-iana-04 draft-ietf-ecrit-ecall-22 draft-ietf-ecrit-car-crash-21 draft-ietf-bfcpbis-bfcp-websocket-13 draft-ietf-6man-rdnss-rfc6106bis-14 draft-holmberg-dispatch-mcptt-rp-namespace-04 draft-murchison-webdav-prefer-13 draft-ietf-dnsop-edns-key-tag-03 draft-ietf-payload-melpe-04 draft-ietf-insipid-logme-reqs-11 draft-ietf-softwire-multicast-prefix-option-11 draft-ietf-clue-rtp-mapping-10 draft-ietf-bfcpbis-sdp-ws-uri-07 draft-ietf-dhc-dhcpv6-failover-protocol-03 draft-ietf-nvo3-use-case-15 draft-ietf-softwire-dslite-multicast-14 Thanks, Martin From nobody Thu Jan 12 09:38: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 00AC31294D2 for ; Thu, 12 Jan 2017 09:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 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, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IOVGENtAzUw for ; Thu, 12 Jan 2017 09:38:32 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 080441294BD for ; Thu, 12 Jan 2017 09:38:32 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id l19so16354755ywc.2 for ; Thu, 12 Jan 2017 09:38:31 -0800 (PST) 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=vdKsz8gNYh4X/3DJVrZkX5/C6AsoKuBkezIjkfGeSE0=; b=rY8QOA/YhqXocU745Amt5TPdIej9kbgum2PJ8Nj49M/3g8zKtNnqcBkwpbMw+N5/UU PcYED5hIsMDXmnl2y7/fYOUP5jNTcy3cPlPdfJifUbV/hMV9b7BDCRNoqjJ6pu4wUvh8 O74dCptxrAgEBMKUWYd/elCBWedEU8U50pcZAjT30+ZMif+fDS6u0CFeldPNpt0vg8Ql Do5uOkXfF2JzRemSrBJXRzyDCBHRLNGUFIsJ91YA8A9Yro105C8KYXzzetDY5rFgWsm8 Xl6PE7bQ2F+EN9YhPAFgHWBvaAqxzsyFCze4E9mVGFEs7aa8aUe5AbwH5X9mMtfzMPhF upSw== 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=vdKsz8gNYh4X/3DJVrZkX5/C6AsoKuBkezIjkfGeSE0=; b=csjRZd2aUzE2j7Od9OYmYydcAXIV2J3kvytVhPGb9ZjZTFTTMrLbHUvOP0++yE2Ij9 CaaUhhd5GEilZPN2wKH5iElKym7ABGLD1o7xSNzC7ewYKwOzdWzElX/Q3OlYnEo/WOQG 9hv0VFYYnV9gY7AOsCEih/Mis+u7l6SFWsGLCautvsZp2Fph5Y86deqAsRSLSglYJsuh xbLIoTHfj8+6gK9TOx+VlHkHnozRdB4YfzZvJqJDHeLS2XFMbob4xPv4YjofGG+hcZxY NKgEHtZIVvFTRNbEkvEJJBmFs5LLoJtNZUx3Cw/UV52TbkD5ac7lI3gJRGK32Pa+Njo2 Xf2g== X-Gm-Message-State: AIkVDXJ6fNltZduw/8fThFF121PNRIqm4+QqkoOOBrK5VJHNecGPAD+aIkNdioB7KjYGw8Rn3eMYN2aTbW6n9A== X-Received: by 10.129.174.3 with SMTP id m3mr11846637ywh.152.1484242711282; Thu, 12 Jan 2017 09:38:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.221.195 with HTTP; Thu, 12 Jan 2017 09:38:30 -0800 (PST) In-Reply-To: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> From: Spencer Dawkins at IETF Date: Thu, 12 Jan 2017 11:38:30 -0600 Message-ID: To: Martin Stiemerling Content-Type: multipart/alternative; boundary=f403045e62a29128ab0545e92f13 Archived-At: Cc: "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:38:34 -0000 --f403045e62a29128ab0545e92f13 Content-Type: text/plain; charset=UTF-8 Thank you, Martin! On Wednesday, January 11, 2017, Martin Stiemerling wrote: > Dear TSVers, > > First of all, a happy new (western) year! :) > > I did work through all documents that are in IETF LC, IESG processing or > being requested for publication as of 01/11, 09:00 pm UTC. > > Please find below all documents checked and what to do with these > documents. > > > Documents that require TSV attention: > none. > > > Documents that do not require TSV attention: > draft-ietf-oauth-jwsreq-09 > draft-ietf-ipsecme-rfc4307bis-15 > draft-ietf-geojson-text-sequence-03 > draft-ietf-dime-agent-overload-08 > draft-ietf-bmwg-ipv6-nd-04 > draft-ietf-intarea-hostname-practice-03 > draft-mohali-dispatch-cause-for-service-number-12 > draft-ietf-trill-rfc6439bis-04 > draft-ietf-trill-directory-assist-mechanisms-10 > draft-ietf-teas-p2mp-loose-path-reopt-08 > draft-ietf-teas-gmpls-resource-sharing-proc-06 > draft-ietf-sidr-rpki-oob-setup-06 > draft-ietf-sidr-publication-10 > draft-ietf-sidr-adverse-actions-03 > draft-ietf-rtgwg-rlfa-node-protection-10 > draft-ietf-mpls-residence-time-12 > draft-ietf-lisp-type-iana-04 > draft-ietf-ecrit-ecall-22 > draft-ietf-ecrit-car-crash-21 > draft-ietf-bfcpbis-bfcp-websocket-13 > draft-ietf-6man-rdnss-rfc6106bis-14 > draft-holmberg-dispatch-mcptt-rp-namespace-04 > draft-murchison-webdav-prefer-13 > draft-ietf-dnsop-edns-key-tag-03 > draft-ietf-payload-melpe-04 > draft-ietf-insipid-logme-reqs-11 > draft-ietf-softwire-multicast-prefix-option-11 > draft-ietf-clue-rtp-mapping-10 > draft-ietf-bfcpbis-sdp-ws-uri-07 > draft-ietf-dhc-dhcpv6-failover-protocol-03 > draft-ietf-nvo3-use-case-15 > draft-ietf-softwire-dslite-multicast-14 > > Thanks, > > Martin > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > --f403045e62a29128ab0545e92f13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you, Martin!

On Wednesday, January 11, 2017, Martin Stiemerlin= g <mls.ietf@gmail.com> wrot= e:
Dear TSVers,

First of all, a happy new (western) year! :)

I did work through all documents that are in IETF LC, IESG processing or be= ing requested for publication as of 01/11, 09:00 pm UTC.

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


Documents that require TSV attention:
none.


Documents that do not require TSV attention:
draft-ietf-oauth-jwsreq-09
draft-ietf-ipsecme-rfc4307bis-15
draft-ietf-geojson-text-sequence-03
draft-ietf-dime-agent-overload-08
draft-ietf-bmwg-ipv6-nd-04
draft-ietf-intarea-hostname-practice-03
draft-mohali-dispatch-cause-for-service-number-12
draft-ietf-trill-rfc6439bis-04
draft-ietf-trill-directory-assist-mechanisms-10
draft-ietf-teas-p2mp-loose-path-reopt-08
draft-ietf-teas-gmpls-resource-sharing-proc-06
draft-ietf-sidr-rpki-oob-setup-06
draft-ietf-sidr-publication-10
draft-ietf-sidr-adverse-actions-03
draft-ietf-rtgwg-rlfa-node-protection-10
draft-ietf-mpls-residence-time-12
draft-ietf-lisp-type-iana-04
draft-ietf-ecrit-ecall-22
draft-ietf-ecrit-car-crash-21
draft-ietf-bfcpbis-bfcp-websocket-13
draft-ietf-6man-rdnss-rfc6106bis-14
draft-holmberg-dispatch-mcptt-rp-namespace-04
draft-murchison-webdav-prefer-13
draft-ietf-dnsop-edns-key-tag-03
draft-ietf-payload-melpe-04
draft-ietf-insipid-logme-reqs-11
draft-ietf-softwire-multicast-prefix-option-11
draft-ietf-clue-rtp-mapping-10
draft-ietf-bfcpbis-sdp-ws-uri-07
draft-ietf-dhc-dhcpv6-failover-protocol-03
draft-ietf-nvo3-use-case-15
draft-ietf-softwire-dslite-multicast-14

Thanks,

=C2=A0 Martin

_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art
--f403045e62a29128ab0545e92f13-- From nobody Fri Jan 13 14:10: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 EC230129499 for ; Fri, 13 Jan 2017 14:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] 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 LNZpftX4KgOU for ; Fri, 13 Jan 2017 14:09:59 -0800 (PST) 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 BDCD91289B0 for ; Fri, 13 Jan 2017 14:09:59 -0800 (PST) Received: from [128.9.184.156] ([128.9.184.156]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0DM9ee2020126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 13 Jan 2017 14:09:41 -0800 (PST) To: Martin Stiemerling , tsv-art@ietf.org References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> From: Joe Touch Message-ID: <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> Date: Fri, 13 Jan 2017 14:09:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:10:02 -0000 Hi Martin, I've been tracking this one for a while: draft-ietf-nvo3-use-case-15 It does have significant transport issues, but it's already being watched ;-) Joe On 1/11/2017 1:52 PM, Martin Stiemerling wrote: > Dear TSVers, > > First of all, a happy new (western) year! :) > > I did work through all documents that are in IETF LC, IESG processing > or being requested for publication as of 01/11, 09:00 pm UTC. > > Please find below all documents checked and what to do with these > documents. > > > Documents that require TSV attention: > none. > > > Documents that do not require TSV attention: > draft-ietf-oauth-jwsreq-09 > draft-ietf-ipsecme-rfc4307bis-15 > draft-ietf-geojson-text-sequence-03 > draft-ietf-dime-agent-overload-08 > draft-ietf-bmwg-ipv6-nd-04 > draft-ietf-intarea-hostname-practice-03 > draft-mohali-dispatch-cause-for-service-number-12 > draft-ietf-trill-rfc6439bis-04 > draft-ietf-trill-directory-assist-mechanisms-10 > draft-ietf-teas-p2mp-loose-path-reopt-08 > draft-ietf-teas-gmpls-resource-sharing-proc-06 > draft-ietf-sidr-rpki-oob-setup-06 > draft-ietf-sidr-publication-10 > draft-ietf-sidr-adverse-actions-03 > draft-ietf-rtgwg-rlfa-node-protection-10 > draft-ietf-mpls-residence-time-12 > draft-ietf-lisp-type-iana-04 > draft-ietf-ecrit-ecall-22 > draft-ietf-ecrit-car-crash-21 > draft-ietf-bfcpbis-bfcp-websocket-13 > draft-ietf-6man-rdnss-rfc6106bis-14 > draft-holmberg-dispatch-mcptt-rp-namespace-04 > draft-murchison-webdav-prefer-13 > draft-ietf-dnsop-edns-key-tag-03 > draft-ietf-payload-melpe-04 > draft-ietf-insipid-logme-reqs-11 > draft-ietf-softwire-multicast-prefix-option-11 > draft-ietf-clue-rtp-mapping-10 > draft-ietf-bfcpbis-sdp-ws-uri-07 > draft-ietf-dhc-dhcpv6-failover-protocol-03 > draft-ietf-nvo3-use-case-15 > draft-ietf-softwire-dslite-multicast-14 > > Thanks, > > Martin > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Sat Jan 14 03:48:56 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 484371294DD for ; Sat, 14 Jan 2017 03:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 x7_7DTkjnQu1 for ; Sat, 14 Jan 2017 03:48:52 -0800 (PST) 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 D209A1294C8 for ; Sat, 14 Jan 2017 03:48:51 -0800 (PST) Received: (qmail 29980 invoked from network); 14 Jan 2017 12:48:49 +0100 Received: from p5dec26aa.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.38.170) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 14 Jan 2017 12:48:49 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> Date: Sat, 14 Jan 2017 12:48:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Martin Stiemerling , tsv-art@ietf.org Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 11:48:54 -0000 Hi Joe, I also thought that this could potentially have a transport review. If = you=E2=80=99d be able to send one that be great, please do so. Or what = do you meant by it=E2=80=99s already being watched? Mirja > Am 13.01.2017 um 23:09 schrieb Joe Touch : >=20 > Hi Martin, >=20 > I've been tracking this one for a while: >=20 > draft-ietf-nvo3-use-case-15 >=20 > It does have significant transport issues, but it's already being > watched ;-) >=20 > Joe >=20 >=20 > On 1/11/2017 1:52 PM, Martin Stiemerling wrote: >> Dear TSVers, >>=20 >> First of all, a happy new (western) year! :) >>=20 >> I did work through all documents that are in IETF LC, IESG processing >> or being requested for publication as of 01/11, 09:00 pm UTC. >>=20 >> Please find below all documents checked and what to do with these >> documents. >>=20 >>=20 >> Documents that require TSV attention: >> none. >>=20 >>=20 >> Documents that do not require TSV attention: >> draft-ietf-oauth-jwsreq-09 >> draft-ietf-ipsecme-rfc4307bis-15 >> draft-ietf-geojson-text-sequence-03 >> draft-ietf-dime-agent-overload-08 >> draft-ietf-bmwg-ipv6-nd-04 >> draft-ietf-intarea-hostname-practice-03 >> draft-mohali-dispatch-cause-for-service-number-12 >> draft-ietf-trill-rfc6439bis-04 >> draft-ietf-trill-directory-assist-mechanisms-10 >> draft-ietf-teas-p2mp-loose-path-reopt-08 >> draft-ietf-teas-gmpls-resource-sharing-proc-06 >> draft-ietf-sidr-rpki-oob-setup-06 >> draft-ietf-sidr-publication-10 >> draft-ietf-sidr-adverse-actions-03 >> draft-ietf-rtgwg-rlfa-node-protection-10 >> draft-ietf-mpls-residence-time-12 >> draft-ietf-lisp-type-iana-04 >> draft-ietf-ecrit-ecall-22 >> draft-ietf-ecrit-car-crash-21 >> draft-ietf-bfcpbis-bfcp-websocket-13 >> draft-ietf-6man-rdnss-rfc6106bis-14 >> draft-holmberg-dispatch-mcptt-rp-namespace-04 >> draft-murchison-webdav-prefer-13 >> draft-ietf-dnsop-edns-key-tag-03 >> draft-ietf-payload-melpe-04 >> draft-ietf-insipid-logme-reqs-11 >> draft-ietf-softwire-multicast-prefix-option-11 >> draft-ietf-clue-rtp-mapping-10 >> draft-ietf-bfcpbis-sdp-ws-uri-07 >> draft-ietf-dhc-dhcpv6-failover-protocol-03 >> draft-ietf-nvo3-use-case-15 >> draft-ietf-softwire-dslite-multicast-14 >>=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 Sat Jan 14 07:07: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 23B6A129C28 for ; Sat, 14 Jan 2017 07:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.857 X-Spam-Level: X-Spam-Status: No, score=-3.857 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_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=ZPQUMpg4; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=syC5LgxM 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 LIOQaDRFMJd8 for ; Sat, 14 Jan 2017 07:07:46 -0800 (PST) Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (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 315BB129C33 for ; Sat, 14 Jan 2017 07:07:42 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=Hbf+qjYPQJY1CmmNOBBm6aEs0j7wjiv/0gOnBUuxMblf+j9aJUNpsENM GdtR35C2IJJKyz0dQVoSPNn2V9oaAqDpoCVp1St+ZTYT57ZAJN5g4IlqR nKizTzwLv4tvmUCUCSTBVC5w4pxFLilwag/cgn0FZmefon4mrOMeVfUl9 Q=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1484405978; x=1515941978; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qRMiquw4yc7A7PwZVAEiXf3UirjVQslGZDH9k0NvgN4=; b=ZPQUMpg4pRTwDPUhv1MzUs/qtRU4PZDlsNyh08z3hqVe7IXPA0al6RWu iMA2WUfHNXceHn5AXgHwzeTBLXhv0j4thG16RvYARxqSXMFYfD0ENz+tL U0QAK9qcF9P9mjGjVYs1C96zpFZjhZlsdc9c7pZYlV0E9ZoBpOjOSPxaW E=; Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2017 08:59:37 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2017 21:05:29 +0600 Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0EF7cKS010736 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 14 Jan 2017 10:07:40 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com v0EF7cKS010736 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1484406460; bh=zklw1GSfkPcURiwdbb4ST0FT/RM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=syC5LgxMxPhuFXOLYE/gGUgV6zU8FSDlgI5p/8mVgr+0pzWYqVZJXiRL6ignv1qDP 6KRib0eRFZQoit51ZpPlCfgYI+tHpoZulI7MPRTslhIHISIb/I2aqqGhBYcHDl4GcW Aj7AzLOmsO6aB8/+gpM001W/u2IG+XG2HIuhfWUI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com v0EF7cKS010736 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd52.lss.emc.com (RSA Interceptor); Sat, 14 Jan 2017 10:06:32 -0500 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0EF7Ojs005025 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sat, 14 Jan 2017 10:07:24 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0266.001; Sat, 14 Jan 2017 10:07:23 -0500 To: "Mirja Kuehlewind (IETF)" , Joe Touch Thread-Topic: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 Thread-Index: AQHSblwz9r9Rf9MGakCAK7/VS8noa6E4EOTA Date: Sat, 14 Jan 2017 15:07:22 +0000 Message-ID: References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Martin Stiemerling , "Black, David" , "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 15:07:48 -0000 QXMgb25lIG9mIHRoZSBhdXRob3JzIG9mIHRoZSBOVk8zIGFyY2hpdGVjdHVyZSBSRkMsIFJGQyA4 MDE0LCBJJ2QgYmUgd2lsbGluZyB0byBoZWxwIHdpdGggYSBUcmFuc3BvcnQgcmV2aWV3IG9mIHRo aXMgTlZPMyB1c2UgY2FzZSBkcmFmdC4gIFRoYXQnbGwgaGF2ZSB0byBoYXBwZW4gcXVpY2tseSwg YXMgaXQgbG9va3MgbGlrZSBJRVRGIExDIGVuZGVkIG9uIFdlZG5lc2RheSwgYW5kIHRoZSBkcmFm dCdzIG9uIHRoaXMgd2VlaydzIHRlbGVjaGF0IGFnZW5kYS4NCg0KSm9lPw0KDQpUaGFua3MsIC0t RGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUc3YtYXJ0IFtt YWlsdG86dHN2LWFydC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlyamEgS3VlaGxl d2luZA0KPiAoSUVURikNCj4gU2VudDogU2F0dXJkYXksIEphbnVhcnkgMTQsIDIwMTcgNjo0OSBB TQ0KPiBUbzogSm9lIFRvdWNoDQo+IENjOiBNYXJ0aW4gU3RpZW1lcmxpbmc7IHRzdi1hcnRAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtUc3YtYXJ0XSBUU1YgVHJpYWdlIHRlYW06IFJldmlldyBv ZiBJRVRGIExDIGRvY3VtZW50cyBhcyBvZiAwMS8xMQ0KPiANCj4gSGkgSm9lLA0KPiANCj4gSSBh bHNvIHRob3VnaHQgdGhhdCB0aGlzIGNvdWxkIHBvdGVudGlhbGx5IGhhdmUgYSB0cmFuc3BvcnQg cmV2aWV3LiBJZiB5b3XigJlkIGJlIGFibGUNCj4gdG8gc2VuZCBvbmUgdGhhdCBiZSBncmVhdCwg cGxlYXNlIGRvIHNvLiBPciB3aGF0IGRvIHlvdSBtZWFudCBieSBpdOKAmXMgYWxyZWFkeQ0KPiBi ZWluZyB3YXRjaGVkPw0KPiANCj4gTWlyamENCj4gDQo+IA0KPiA+IEFtIDEzLjAxLjIwMTcgdW0g MjM6MDkgc2NocmllYiBKb2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU+Og0KPiA+DQo+ID4gSGkgTWFy dGluLA0KPiA+DQo+ID4gSSd2ZSBiZWVuIHRyYWNraW5nIHRoaXMgb25lIGZvciBhIHdoaWxlOg0K PiA+DQo+ID4gZHJhZnQtaWV0Zi1udm8zLXVzZS1jYXNlLTE1DQo+ID4NCj4gPiBJdCBkb2VzIGhh dmUgc2lnbmlmaWNhbnQgdHJhbnNwb3J0IGlzc3VlcywgYnV0IGl0J3MgYWxyZWFkeSBiZWluZw0K PiA+IHdhdGNoZWQgOy0pDQo+ID4NCj4gPiBKb2UNCj4gPg0KPiA+DQo+ID4gT24gMS8xMS8yMDE3 IDE6NTIgUE0sIE1hcnRpbiBTdGllbWVybGluZyB3cm90ZToNCj4gPj4gRGVhciBUU1ZlcnMsDQo+ ID4+DQo+ID4+IEZpcnN0IG9mIGFsbCwgYSBoYXBweSBuZXcgKHdlc3Rlcm4pIHllYXIhIDopDQo+ ID4+DQo+ID4+IEkgZGlkIHdvcmsgdGhyb3VnaCBhbGwgZG9jdW1lbnRzIHRoYXQgYXJlIGluIElF VEYgTEMsIElFU0cgcHJvY2Vzc2luZw0KPiA+PiBvciBiZWluZyByZXF1ZXN0ZWQgZm9yIHB1Ymxp Y2F0aW9uIGFzIG9mIDAxLzExLCAwOTowMCBwbSBVVEMuDQo+ID4+DQo+ID4+IFBsZWFzZSBmaW5k IGJlbG93IGFsbCBkb2N1bWVudHMgY2hlY2tlZCBhbmQgd2hhdCB0byBkbyB3aXRoIHRoZXNlDQo+ ID4+IGRvY3VtZW50cy4NCj4gPj4NCj4gPj4NCj4gPj4gRG9jdW1lbnRzIHRoYXQgcmVxdWlyZSBU U1YgYXR0ZW50aW9uOg0KPiA+PiBub25lLg0KPiA+Pg0KPiA+Pg0KPiA+PiBEb2N1bWVudHMgdGhh dCBkbyBub3QgcmVxdWlyZSBUU1YgYXR0ZW50aW9uOg0KPiA+PiBkcmFmdC1pZXRmLW9hdXRoLWp3 c3JlcS0wOQ0KPiA+PiBkcmFmdC1pZXRmLWlwc2VjbWUtcmZjNDMwN2Jpcy0xNQ0KPiA+PiBkcmFm dC1pZXRmLWdlb2pzb24tdGV4dC1zZXF1ZW5jZS0wMw0KPiA+PiBkcmFmdC1pZXRmLWRpbWUtYWdl bnQtb3ZlcmxvYWQtMDgNCj4gPj4gZHJhZnQtaWV0Zi1ibXdnLWlwdjYtbmQtMDQNCj4gPj4gZHJh ZnQtaWV0Zi1pbnRhcmVhLWhvc3RuYW1lLXByYWN0aWNlLTAzDQo+ID4+IGRyYWZ0LW1vaGFsaS1k aXNwYXRjaC1jYXVzZS1mb3Itc2VydmljZS1udW1iZXItMTINCj4gPj4gZHJhZnQtaWV0Zi10cmls bC1yZmM2NDM5YmlzLTA0DQo+ID4+IGRyYWZ0LWlldGYtdHJpbGwtZGlyZWN0b3J5LWFzc2lzdC1t ZWNoYW5pc21zLTEwDQo+ID4+IGRyYWZ0LWlldGYtdGVhcy1wMm1wLWxvb3NlLXBhdGgtcmVvcHQt MDgNCj4gPj4gZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLXJlc291cmNlLXNoYXJpbmctcHJvYy0wNg0K PiA+PiBkcmFmdC1pZXRmLXNpZHItcnBraS1vb2Itc2V0dXAtMDYNCj4gPj4gZHJhZnQtaWV0Zi1z aWRyLXB1YmxpY2F0aW9uLTEwDQo+ID4+IGRyYWZ0LWlldGYtc2lkci1hZHZlcnNlLWFjdGlvbnMt MDMNCj4gPj4gZHJhZnQtaWV0Zi1ydGd3Zy1ybGZhLW5vZGUtcHJvdGVjdGlvbi0xMA0KPiA+PiBk cmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRpbWUtMTINCj4gPj4gZHJhZnQtaWV0Zi1saXNwLXR5 cGUtaWFuYS0wNA0KPiA+PiBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTIyDQo+ID4+IGRyYWZ0LWll dGYtZWNyaXQtY2FyLWNyYXNoLTIxDQo+ID4+IGRyYWZ0LWlldGYtYmZjcGJpcy1iZmNwLXdlYnNv Y2tldC0xMw0KPiA+PiBkcmFmdC1pZXRmLTZtYW4tcmRuc3MtcmZjNjEwNmJpcy0xNA0KPiA+PiBk cmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1tY3B0dC1ycC1uYW1lc3BhY2UtMDQNCj4gPj4gZHJhZnQt bXVyY2hpc29uLXdlYmRhdi1wcmVmZXItMTMNCj4gPj4gZHJhZnQtaWV0Zi1kbnNvcC1lZG5zLWtl eS10YWctMDMNCj4gPj4gZHJhZnQtaWV0Zi1wYXlsb2FkLW1lbHBlLTA0DQo+ID4+IGRyYWZ0LWll dGYtaW5zaXBpZC1sb2dtZS1yZXFzLTExDQo+ID4+IGRyYWZ0LWlldGYtc29mdHdpcmUtbXVsdGlj YXN0LXByZWZpeC1vcHRpb24tMTENCj4gPj4gZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5nLTEw DQo+ID4+IGRyYWZ0LWlldGYtYmZjcGJpcy1zZHAtd3MtdXJpLTA3DQo+ID4+IGRyYWZ0LWlldGYt ZGhjLWRoY3B2Ni1mYWlsb3Zlci1wcm90b2NvbC0wMw0KPiA+PiBkcmFmdC1pZXRmLW52bzMtdXNl LWNhc2UtMTUNCj4gPj4gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1kc2xpdGUtbXVsdGljYXN0LTE0DQo+ ID4+DQo+ID4+IFRoYW5rcywNCj4gPj4NCj4gPj4gIE1hcnRpbg0KPiA+Pg0KPiA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBUc3YtYXJ0IG1h aWxpbmcgbGlzdA0KPiA+PiBUc3YtYXJ0QGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHN2LWFydA0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBUc3YtYXJ0IG1haWxpbmcgbGlzdA0K PiA+IFRzdi1hcnRAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Rzdi1hcnQNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IFRzdi1hcnQgbWFpbGluZyBsaXN0DQo+IFRzdi1hcnRAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90c3YtYXJ0DQo= From nobody Sat Jan 14 08:18: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 9CCDD129457 for ; Sat, 14 Jan 2017 08:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=unavailable 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 HsNYRt-uYK0I for ; Sat, 14 Jan 2017 08:18:34 -0800 (PST) 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 136D91294F1 for ; Sat, 14 Jan 2017 08:10:20 -0800 (PST) Received: from [192.168.1.158] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v0EG9xZT010863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Jan 2017 08:10:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (14C92) In-Reply-To: Date: Sat, 14 Jan 2017 08:09:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu> References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> To: "Black, David" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Martin Stiemerling , "Mirja Kuehlewind \(IETF\)" , "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 16:18:35 -0000 I've been giving them feedback for a while.=20 Joe > On Jan 14, 2017, at 7:07 AM, Black, David wrote: >=20 > As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd be willi= ng to help with a Transport review of this NVO3 use case draft. That'll hav= e to happen quickly, as it looks like IETF LC ended on Wednesday, and the dr= aft's on this week's telechat agenda. >=20 > Joe? >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Mirja Kuehle= wind >> (IETF) >> Sent: Saturday, January 14, 2017 6:49 AM >> To: Joe Touch >> Cc: Martin Stiemerling; tsv-art@ietf.org >> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of= 01/11 >>=20 >> Hi Joe, >>=20 >> I also thought that this could potentially have a transport review. If yo= u=E2=80=99d be able >> to send one that be great, please do so. Or what do you meant by it=E2=80= =99s already >> being watched? >>=20 >> Mirja >>=20 >>=20 >>> Am 13.01.2017 um 23:09 schrieb Joe Touch : >>>=20 >>> Hi Martin, >>>=20 >>> I've been tracking this one for a while: >>>=20 >>> draft-ietf-nvo3-use-case-15 >>>=20 >>> It does have significant transport issues, but it's already being >>> watched ;-) >>>=20 >>> Joe >>>=20 >>>=20 >>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote: >>>> Dear TSVers, >>>>=20 >>>> First of all, a happy new (western) year! :) >>>>=20 >>>> I did work through all documents that are in IETF LC, IESG processing >>>> or being requested for publication as of 01/11, 09:00 pm UTC. >>>>=20 >>>> Please find below all documents checked and what to do with these >>>> documents. >>>>=20 >>>>=20 >>>> Documents that require TSV attention: >>>> none. >>>>=20 >>>>=20 >>>> Documents that do not require TSV attention: >>>> draft-ietf-oauth-jwsreq-09 >>>> draft-ietf-ipsecme-rfc4307bis-15 >>>> draft-ietf-geojson-text-sequence-03 >>>> draft-ietf-dime-agent-overload-08 >>>> draft-ietf-bmwg-ipv6-nd-04 >>>> draft-ietf-intarea-hostname-practice-03 >>>> draft-mohali-dispatch-cause-for-service-number-12 >>>> draft-ietf-trill-rfc6439bis-04 >>>> draft-ietf-trill-directory-assist-mechanisms-10 >>>> draft-ietf-teas-p2mp-loose-path-reopt-08 >>>> draft-ietf-teas-gmpls-resource-sharing-proc-06 >>>> draft-ietf-sidr-rpki-oob-setup-06 >>>> draft-ietf-sidr-publication-10 >>>> draft-ietf-sidr-adverse-actions-03 >>>> draft-ietf-rtgwg-rlfa-node-protection-10 >>>> draft-ietf-mpls-residence-time-12 >>>> draft-ietf-lisp-type-iana-04 >>>> draft-ietf-ecrit-ecall-22 >>>> draft-ietf-ecrit-car-crash-21 >>>> draft-ietf-bfcpbis-bfcp-websocket-13 >>>> draft-ietf-6man-rdnss-rfc6106bis-14 >>>> draft-holmberg-dispatch-mcptt-rp-namespace-04 >>>> draft-murchison-webdav-prefer-13 >>>> draft-ietf-dnsop-edns-key-tag-03 >>>> draft-ietf-payload-melpe-04 >>>> draft-ietf-insipid-logme-reqs-11 >>>> draft-ietf-softwire-multicast-prefix-option-11 >>>> draft-ietf-clue-rtp-mapping-10 >>>> draft-ietf-bfcpbis-sdp-ws-uri-07 >>>> draft-ietf-dhc-dhcpv6-failover-protocol-03 >>>> draft-ietf-nvo3-use-case-15 >>>> draft-ietf-softwire-dslite-multicast-14 >>>>=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 >>=20 >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art From nobody Sat Jan 14 09:23:12 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 CF8FC129C5C for ; Sat, 14 Jan 2017 09:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] 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 QNZcMa9aFIxx for ; Sat, 14 Jan 2017 09:23:00 -0800 (PST) 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 D5C7912A0C4 for ; Sat, 14 Jan 2017 09:22:57 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0EHMJJa014047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 14 Jan 2017 09:22:21 -0800 (PST) To: "Black, David" References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu> From: Joe Touch Message-ID: <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> Date: Sat, 14 Jan 2017 09:22:21 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Martin Stiemerling , "Mirja Kuehlewind \(IETF\)" , "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 17:23:03 -0000 David - I think it'd be useful for fresh eyes on this. IMO, it's full of vendor terminology that I don't think sufficiently differentiates the data center case from any other variant of virtual network. This is the use case doc that purports to motivate "yet another" UDP tunneling mechanism, which has generated quite a bit of controversy and I expect would be more relevant to TSV. However, I'm struck by the need to publish a use case doc so soon after the problem statement doc (just two years ago), but that's not a TSV issue. Joe On 1/14/2017 8:09 AM, Joe Touch wrote: > I've been giving them feedback for a while. > > Joe > >> On Jan 14, 2017, at 7:07 AM, Black, David wrote: >> >> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd be willing to help with a Transport review of this NVO3 use case draft. That'll have to happen quickly, as it looks like IETF LC ended on Wednesday, and the draft's on this week's telechat agenda. >> >> Joe? >> >> Thanks, --David >> >>> -----Original Message----- >>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Mirja Kuehlewind >>> (IETF) >>> Sent: Saturday, January 14, 2017 6:49 AM >>> To: Joe Touch >>> Cc: Martin Stiemerling; tsv-art@ietf.org >>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 >>> >>> Hi Joe, >>> >>> I also thought that this could potentially have a transport review. If you’d be able >>> to send one that be great, please do so. Or what do you meant by it’s already >>> being watched? >>> >>> Mirja >>> >>> >>>> Am 13.01.2017 um 23:09 schrieb Joe Touch : >>>> >>>> Hi Martin, >>>> >>>> I've been tracking this one for a while: >>>> >>>> draft-ietf-nvo3-use-case-15 >>>> >>>> It does have significant transport issues, but it's already being >>>> watched ;-) >>>> >>>> Joe >>>> >>>> >>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote: >>>>> Dear TSVers, >>>>> >>>>> First of all, a happy new (western) year! :) >>>>> >>>>> I did work through all documents that are in IETF LC, IESG processing >>>>> or being requested for publication as of 01/11, 09:00 pm UTC. >>>>> >>>>> Please find below all documents checked and what to do with these >>>>> documents. >>>>> >>>>> >>>>> Documents that require TSV attention: >>>>> none. >>>>> >>>>> >>>>> Documents that do not require TSV attention: >>>>> draft-ietf-oauth-jwsreq-09 >>>>> draft-ietf-ipsecme-rfc4307bis-15 >>>>> draft-ietf-geojson-text-sequence-03 >>>>> draft-ietf-dime-agent-overload-08 >>>>> draft-ietf-bmwg-ipv6-nd-04 >>>>> draft-ietf-intarea-hostname-practice-03 >>>>> draft-mohali-dispatch-cause-for-service-number-12 >>>>> draft-ietf-trill-rfc6439bis-04 >>>>> draft-ietf-trill-directory-assist-mechanisms-10 >>>>> draft-ietf-teas-p2mp-loose-path-reopt-08 >>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06 >>>>> draft-ietf-sidr-rpki-oob-setup-06 >>>>> draft-ietf-sidr-publication-10 >>>>> draft-ietf-sidr-adverse-actions-03 >>>>> draft-ietf-rtgwg-rlfa-node-protection-10 >>>>> draft-ietf-mpls-residence-time-12 >>>>> draft-ietf-lisp-type-iana-04 >>>>> draft-ietf-ecrit-ecall-22 >>>>> draft-ietf-ecrit-car-crash-21 >>>>> draft-ietf-bfcpbis-bfcp-websocket-13 >>>>> draft-ietf-6man-rdnss-rfc6106bis-14 >>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04 >>>>> draft-murchison-webdav-prefer-13 >>>>> draft-ietf-dnsop-edns-key-tag-03 >>>>> draft-ietf-payload-melpe-04 >>>>> draft-ietf-insipid-logme-reqs-11 >>>>> draft-ietf-softwire-multicast-prefix-option-11 >>>>> draft-ietf-clue-rtp-mapping-10 >>>>> draft-ietf-bfcpbis-sdp-ws-uri-07 >>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03 >>>>> draft-ietf-nvo3-use-case-15 >>>>> draft-ietf-softwire-dslite-multicast-14 >>>>> >>>>> 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 >>> _______________________________________________ >>> Tsv-art mailing list >>> Tsv-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/tsv-art From nobody Sat Jan 14 10:34:17 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 2A7E3129BC1 for ; Sat, 14 Jan 2017 10:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.856 X-Spam-Level: X-Spam-Status: No, score=-3.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=iH2lr+/7; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=AeqJNDiw 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 eXoGK4Q-ISLf for ; Sat, 14 Jan 2017 10:34:13 -0800 (PST) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 A8849129CEC for ; Sat, 14 Jan 2017 10:34:09 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:Content-Type:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=g/7VcwwSI/c9eGNMpJOjywVFLhMZoBVWdrybQiPUDBvrJ8XyGqxOHfhm 5hRhG+osUzKEtlwGES8rogCJgFZIbZzZ6fP8SrkB84ianOtP+sUsgZl/n aJqJyA2oozeYsmMwruJTbg1yJhkDJk8jnjWICNwnldZEE49xQE9IqROlW 0=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1484418849; x=1515954849; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=YorPp3ivMwGtzG1mytwJ5qcM1xNKAWFbuoVhUpAzfxU=; b=iH2lr+/7xWHktl6iQ9RHaX/HeoGF4k1DwMcWihee6jAdSJ9qnQ1K8zvN RIBa12kud0i6Kud7Zdg3CLXU7e7B0tSKGrlV46Qo0MdU7UXRJiyfL6PyC v2s2eNpeGFeZiDFMD0r3uc1A4bc4lpvZabSqdzE7mdwIlXjd2MkZm3S2W I=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2017 12:34:09 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2017 00:24:03 +0600 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0EIY6wg004997 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 14 Jan 2017 13:34:06 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v0EIY6wg004997 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1484418847; bh=UZ8UMNkVMZbJBhTIwBz1HkCjf3I=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=AeqJNDiwW5H8fo5q8hR94wqHrDOn7SF8LxgbMUTojSI4j3NGA4uaew1THad5jT963 HWNa2pDXDBXvnrc/gjtH/SYsDWBHeho+CDzR8YdaOJT1JKMFb9xDj9UEmRGBqVrcZn QSiVPchsy3vr2xzt0Y8Gq/Dpe86McACeuU34uq7M= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v0EIY6wg004997 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd54.lss.emc.com (RSA Interceptor); Sat, 14 Jan 2017 13:33:36 -0500 Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0EIXmlg026506 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sat, 14 Jan 2017 13:33:49 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Sat, 14 Jan 2017 13:33:47 -0500 To: Joe Touch Thread-Topic: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 Thread-Index: AQHSboC1a4J+V6O510Cup0rArafOQKE4jFeA///AJAg= Date: Sat, 14 Jan 2017 18:33:47 +0000 Message-ID: References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu>, <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> In-Reply-To: <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_c13ct0vtbhsad0lsqgreble31484418579981emailandroidcom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Martin Stiemerling , "Black, David" , "Mirja Kuehlewind \(IETF\)" , "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 18:34:16 -0000 --_000_c13ct0vtbhsad0lsqgreble31484418579981emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Joe, I'll take another look at this draft before the telechat. The NVO3 WG is pu= blishing this use case draft now in part because they badly lost their way = over the past couple of years :-(. I have not been a fan of this draft in t= he WG, but I don't fundamentally object to its publication. Could you provide a few examples of terminology in the draft that you view = as problematic? Thanks, --David ... Sent from my Android not-so-smartphone. -------- Original message -------- From: Joe Touch Date: 1/14/17 9:23 AM (GMT-08:00) To: "Black, David" Cc: "Mirja Kuehlewind (IETF)" , Martin Stiemerling , tsv-art@ietf.org Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 0= 1/11 David - I think it'd be useful for fresh eyes on this. IMO, it's full of vendor terminology that I don't think sufficiently differentiates the data center case from any other variant of virtual network. This is the use case doc that purports to motivate "yet another" UDP tunneling mechanism, which has generated quite a bit of controversy and I expect would be more relevant to TSV. However, I'm struck by the need to publish a use case doc so soon after the problem statement doc (just two years ago), but that's not a TSV issue. Joe On 1/14/2017 8:09 AM, Joe Touch wrote: > I've been giving them feedback for a while. > > Joe > >> On Jan 14, 2017, at 7:07 AM, Black, David wrote: >> >> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd be wil= ling to help with a Transport review of this NVO3 use case draft. That'll = have to happen quickly, as it looks like IETF LC ended on Wednesday, and th= e draft's on this week's telechat agenda. >> >> Joe? >> >> Thanks, --David >> >>> -----Original Message----- >>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Mirja Kueh= lewind >>> (IETF) >>> Sent: Saturday, January 14, 2017 6:49 AM >>> To: Joe Touch >>> Cc: Martin Stiemerling; tsv-art@ietf.org >>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as = of 01/11 >>> >>> Hi Joe, >>> >>> I also thought that this could potentially have a transport review. If = you=92d be able >>> to send one that be great, please do so. Or what do you meant by it=92s= already >>> being watched? >>> >>> Mirja >>> >>> >>>> Am 13.01.2017 um 23:09 schrieb Joe Touch : >>>> >>>> Hi Martin, >>>> >>>> I've been tracking this one for a while: >>>> >>>> draft-ietf-nvo3-use-case-15 >>>> >>>> It does have significant transport issues, but it's already being >>>> watched ;-) >>>> >>>> Joe >>>> >>>> >>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote: >>>>> Dear TSVers, >>>>> >>>>> First of all, a happy new (western) year! :) >>>>> >>>>> I did work through all documents that are in IETF LC, IESG processing >>>>> or being requested for publication as of 01/11, 09:00 pm UTC. >>>>> >>>>> Please find below all documents checked and what to do with these >>>>> documents. >>>>> >>>>> >>>>> Documents that require TSV attention: >>>>> none. >>>>> >>>>> >>>>> Documents that do not require TSV attention: >>>>> draft-ietf-oauth-jwsreq-09 >>>>> draft-ietf-ipsecme-rfc4307bis-15 >>>>> draft-ietf-geojson-text-sequence-03 >>>>> draft-ietf-dime-agent-overload-08 >>>>> draft-ietf-bmwg-ipv6-nd-04 >>>>> draft-ietf-intarea-hostname-practice-03 >>>>> draft-mohali-dispatch-cause-for-service-number-12 >>>>> draft-ietf-trill-rfc6439bis-04 >>>>> draft-ietf-trill-directory-assist-mechanisms-10 >>>>> draft-ietf-teas-p2mp-loose-path-reopt-08 >>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06 >>>>> draft-ietf-sidr-rpki-oob-setup-06 >>>>> draft-ietf-sidr-publication-10 >>>>> draft-ietf-sidr-adverse-actions-03 >>>>> draft-ietf-rtgwg-rlfa-node-protection-10 >>>>> draft-ietf-mpls-residence-time-12 >>>>> draft-ietf-lisp-type-iana-04 >>>>> draft-ietf-ecrit-ecall-22 >>>>> draft-ietf-ecrit-car-crash-21 >>>>> draft-ietf-bfcpbis-bfcp-websocket-13 >>>>> draft-ietf-6man-rdnss-rfc6106bis-14 >>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04 >>>>> draft-murchison-webdav-prefer-13 >>>>> draft-ietf-dnsop-edns-key-tag-03 >>>>> draft-ietf-payload-melpe-04 >>>>> draft-ietf-insipid-logme-reqs-11 >>>>> draft-ietf-softwire-multicast-prefix-option-11 >>>>> draft-ietf-clue-rtp-mapping-10 >>>>> draft-ietf-bfcpbis-sdp-ws-uri-07 >>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03 >>>>> draft-ietf-nvo3-use-case-15 >>>>> draft-ietf-softwire-dslite-multicast-14 >>>>> >>>>> 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 >>> _______________________________________________ >>> Tsv-art mailing list >>> Tsv-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/tsv-art --_000_c13ct0vtbhsad0lsqgreble31484418579981emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Joe, 

I'll take another look at this draft before the telechat. The NVO3 WG = is publishing this use case draft now in part because they badly lost their= way over the past couple of years :-(. I have not been a fan of this draft= in the WG, but I don't fundamentally object to its publication. 

Could you provide a few examples of terminology in the draft that you = view as problematic? 

Thanks, --David ... Sent from m= y Android not-so-smartphone.


-------- Original message --------
From: Joe Touch <touch@isi.edu>
Date: 1/14/17 9:23 AM (GMT-08:00)
To: "Black, David" <david.black@emc.com>
Cc: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, M= artin Stiemerling <mls.ietf@gmail.com>, tsv-art@ietf.org
Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as= of 01/11

David - I think it'd be useful for fresh eyes on t= his. IMO, it's full of
vendor terminology that I don't think sufficiently differentiates the
data center case from any other variant of virtual network.

This is the use case doc that purports to motivate "yet another" = UDP
tunneling mechanism, which has generated quite a bit of controversy and
I expect would be more relevant to TSV.

However, I'm struck by the need to publish a use case doc so soon after
the problem statement doc (just two years ago), but that's not a TSV issue.=

Joe


On 1/14/2017 8:09 AM, Joe Touch wrote:
> I've been giving them feedback for a while.
>
> Joe
>
>> On Jan 14, 2017, at 7:07 AM, Black, David <David.Black@dell.com= > wrote:
>>
>> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd = be willing to help with a Transport review of this NVO3 use case draft.&nbs= p; That'll have to happen quickly, as it looks like IETF LC ended on Wednes= day, and the draft's on this week's telechat agenda.
>>
>> Joe?
>>
>> Thanks, --David
>>
>>> -----Original Message-----
>>> From: Tsv-art [mai= lto:tsv-art-bounces@ietf.org] On Behalf Of Mirja Kuehlewind
>>> (IETF)
>>> Sent: Saturday, January 14, 2017 6:49 AM
>>> To: Joe Touch
>>> Cc: Martin Stiemerling; tsv-art@ietf.org
>>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC docu= ments as of 01/11
>>>
>>> Hi Joe,
>>>
>>> I also thought that this could potentially have a transport re= view. If you=92d be able
>>> to send one that be great, please do so. Or what do you meant = by it=92s already
>>> being watched?
>>>
>>> Mirja
>>>
>>>
>>>> Am 13.01.2017 um 23:09 schrieb Joe Touch <touch@isi.edu= >:
>>>>
>>>> Hi Martin,
>>>>
>>>> I've been tracking this one for a while:
>>>>
>>>> draft-ietf-nvo3-use-case-15
>>>>
>>>> It does have significant transport issues, but it's alread= y being
>>>> watched ;-)
>>>>
>>>> Joe
>>>>
>>>>
>>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote:
>>>>> Dear TSVers,
>>>>>
>>>>> First of all, a happy new (western) year! :)
>>>>>
>>>>> I did work through all documents that are in IETF LC, = IESG processing
>>>>> or being requested for publication as of 01/11, 09:00 = pm UTC.
>>>>>
>>>>> Please find below all documents checked and what to do= with these
>>>>> documents.
>>>>>
>>>>>
>>>>> Documents that require TSV attention:
>>>>> none.
>>>>>
>>>>>
>>>>> Documents that do not require TSV attention:
>>>>> draft-ietf-oauth-jwsreq-09
>>>>> draft-ietf-ipsecme-rfc4307bis-15
>>>>> draft-ietf-geojson-text-sequence-03
>>>>> draft-ietf-dime-agent-overload-08
>>>>> draft-ietf-bmwg-ipv6-nd-04
>>>>> draft-ietf-intarea-hostname-practice-03
>>>>> draft-mohali-dispatch-cause-for-service-number-12
>>>>> draft-ietf-trill-rfc6439bis-04
>>>>> draft-ietf-trill-directory-assist-mechanisms-10
>>>>> draft-ietf-teas-p2mp-loose-path-reopt-08
>>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06
>>>>> draft-ietf-sidr-rpki-oob-setup-06
>>>>> draft-ietf-sidr-publication-10
>>>>> draft-ietf-sidr-adverse-actions-03
>>>>> draft-ietf-rtgwg-rlfa-node-protection-10
>>>>> draft-ietf-mpls-residence-time-12
>>>>> draft-ietf-lisp-type-iana-04
>>>>> draft-ietf-ecrit-ecall-22
>>>>> draft-ietf-ecrit-car-crash-21
>>>>> draft-ietf-bfcpbis-bfcp-websocket-13
>>>>> draft-ietf-6man-rdnss-rfc6106bis-14
>>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04
>>>>> draft-murchison-webdav-prefer-13
>>>>> draft-ietf-dnsop-edns-key-tag-03
>>>>> draft-ietf-payload-melpe-04
>>>>> draft-ietf-insipid-logme-reqs-11
>>>>> draft-ietf-softwire-multicast-prefix-option-11
>>>>> draft-ietf-clue-rtp-mapping-10
>>>>> draft-ietf-bfcpbis-sdp-ws-uri-07
>>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03
>>>>> draft-ietf-nvo3-use-case-15
>>>>> draft-ietf-softwire-dslite-multicast-14
>>>>>
>>>>> 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
>>> _______________________________________________
>>> Tsv-art mailing list
>>> Tsv-art@ietf.org
>>> http= s://www.ietf.org/mailman/listinfo/tsv-art

 --_000_c13ct0vtbhsad0lsqgreble31484418579981emailandroidcom_-- From nobody Sat Jan 14 11:29:37 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 0E4D4129D06 for ; Sat, 14 Jan 2017 11:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] 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 aI-uy8j1HCh7 for ; Sat, 14 Jan 2017 11:29:32 -0800 (PST) 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 84A071294BF for ; Sat, 14 Jan 2017 11:29:32 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0EJSwhX028194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 14 Jan 2017 11:29:00 -0800 (PST) To: "Black, David" References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu> <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> From: Joe Touch Message-ID: <1e92262c-36f5-c173-e988-debc1c49e651@isi.edu> Date: Sat, 14 Jan 2017 11:28:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------65A82F140E95106D5D6A46DC" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Martin Stiemerling , "Mirja Kuehlewind \(IETF\)" , "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 19:29:35 -0000 This is a multi-part message in MIME format. --------------65A82F140E95106D5D6A46DC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit I'm not a fan of using human administrative, political, or economic boundary terms as if they had any meaning in a network architecture. Tenant system, VM, vGW, and even DC (or NVO3 for that matter) are insufficiently defined, IMO. But that's a fault of the entire WG, not just this doc. This leads to gibberis (IMO) like: One NVO3 network can provide connectivity to many TSs that attach to many different NVEs in a DC. TS dynamic placement and mobility results in frequent changes of the binding between a TS and an NVE. This doc boils down to "overlays are useful in data centers". Why wouldn't they be? How are data centers different (they really aren't, except that some fall into the class of "managed subnetworks" that can use custom settings). I really don't see the need for this doc at all. Joe On 1/14/2017 10:33 AM, Black, David wrote: > Joe, > > I'll take another look at this draft before the telechat. The NVO3 WG > is publishing this use case draft now in part because they badly lost > their way over the past couple of years :-(. I have not been a fan of > this draft in the WG, but I don't fundamentally object to its > publication. > > Could you provide a few examples of terminology in the draft that you > view as problematic? > > Thanks, --David ... Sent from my Android not-so-smartphone. > > > -------- Original message -------- > From: Joe Touch > Date: 1/14/17 9:23 AM (GMT-08:00) > To: "Black, David" > Cc: "Mirja Kuehlewind (IETF)" , Martin > Stiemerling , tsv-art@ietf.org > Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as > of 01/11 > > David - I think it'd be useful for fresh eyes on this. IMO, it's full of > vendor terminology that I don't think sufficiently differentiates the > data center case from any other variant of virtual network. > > This is the use case doc that purports to motivate "yet another" UDP > tunneling mechanism, which has generated quite a bit of controversy and > I expect would be more relevant to TSV. > > However, I'm struck by the need to publish a use case doc so soon after > the problem statement doc (just two years ago), but that's not a TSV > issue. > > Joe > > > On 1/14/2017 8:09 AM, Joe Touch wrote: > > I've been giving them feedback for a while. > > > > Joe > > > >> On Jan 14, 2017, at 7:07 AM, Black, David wrote: > >> > >> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd > be willing to help with a Transport review of this NVO3 use case > draft. That'll have to happen quickly, as it looks like IETF LC ended > on Wednesday, and the draft's on this week's telechat agenda. > >> > >> Joe? > >> > >> Thanks, --David > >> > >>> -----Original Message----- > >>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Mirja > Kuehlewind > >>> (IETF) > >>> Sent: Saturday, January 14, 2017 6:49 AM > >>> To: Joe Touch > >>> Cc: Martin Stiemerling; tsv-art@ietf.org > >>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC > documents as of 01/11 > >>> > >>> Hi Joe, > >>> > >>> I also thought that this could potentially have a transport > review. If you’d be able > >>> to send one that be great, please do so. Or what do you meant by > it’s already > >>> being watched? > >>> > >>> Mirja > >>> > >>> > >>>> Am 13.01.2017 um 23:09 schrieb Joe Touch : > >>>> > >>>> Hi Martin, > >>>> > >>>> I've been tracking this one for a while: > >>>> > >>>> draft-ietf-nvo3-use-case-15 > >>>> > >>>> It does have significant transport issues, but it's already being > >>>> watched ;-) > >>>> > >>>> Joe > >>>> > >>>> > >>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote: > >>>>> Dear TSVers, > >>>>> > >>>>> First of all, a happy new (western) year! :) > >>>>> > >>>>> I did work through all documents that are in IETF LC, IESG > processing > >>>>> or being requested for publication as of 01/11, 09:00 pm UTC. > >>>>> > >>>>> Please find below all documents checked and what to do with these > >>>>> documents. > >>>>> > >>>>> > >>>>> Documents that require TSV attention: > >>>>> none. > >>>>> > >>>>> > >>>>> Documents that do not require TSV attention: > >>>>> draft-ietf-oauth-jwsreq-09 > >>>>> draft-ietf-ipsecme-rfc4307bis-15 > >>>>> draft-ietf-geojson-text-sequence-03 > >>>>> draft-ietf-dime-agent-overload-08 > >>>>> draft-ietf-bmwg-ipv6-nd-04 > >>>>> draft-ietf-intarea-hostname-practice-03 > >>>>> draft-mohali-dispatch-cause-for-service-number-12 > >>>>> draft-ietf-trill-rfc6439bis-04 > >>>>> draft-ietf-trill-directory-assist-mechanisms-10 > >>>>> draft-ietf-teas-p2mp-loose-path-reopt-08 > >>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06 > >>>>> draft-ietf-sidr-rpki-oob-setup-06 > >>>>> draft-ietf-sidr-publication-10 > >>>>> draft-ietf-sidr-adverse-actions-03 > >>>>> draft-ietf-rtgwg-rlfa-node-protection-10 > >>>>> draft-ietf-mpls-residence-time-12 > >>>>> draft-ietf-lisp-type-iana-04 > >>>>> draft-ietf-ecrit-ecall-22 > >>>>> draft-ietf-ecrit-car-crash-21 > >>>>> draft-ietf-bfcpbis-bfcp-websocket-13 > >>>>> draft-ietf-6man-rdnss-rfc6106bis-14 > >>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04 > >>>>> draft-murchison-webdav-prefer-13 > >>>>> draft-ietf-dnsop-edns-key-tag-03 > >>>>> draft-ietf-payload-melpe-04 > >>>>> draft-ietf-insipid-logme-reqs-11 > >>>>> draft-ietf-softwire-multicast-prefix-option-11 > >>>>> draft-ietf-clue-rtp-mapping-10 > >>>>> draft-ietf-bfcpbis-sdp-ws-uri-07 > >>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03 > >>>>> draft-ietf-nvo3-use-case-15 > >>>>> draft-ietf-softwire-dslite-multicast-14 > >>>>> > >>>>> 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 > >>> _______________________________________________ > >>> Tsv-art mailing list > >>> Tsv-art@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tsv-art > --------------65A82F140E95106D5D6A46DC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I'm not a fan of using human administrative, political, or economic boundary terms as if they had any meaning in a network architecture.

Tenant system, VM, vGW, and even DC (or NVO3 for that matter) are insufficiently defined, IMO. But that's a fault of the entire WG, not just this doc.

This leads to gibberis (IMO) like:
  One NVO3 network can provide connectivity to many TSs that attach to
  many different NVEs in a DC. TS dynamic placement and mobility
  results in frequent changes of the binding between a TS and an NVE.
This doc boils down to "overlays are useful in data centers". Why wouldn't they be? How are data centers different (they really aren't, except that some fall into the class of "managed subnetworks" that can use custom settings).

I really don't see the need for this doc at all.

Joe


On 1/14/2017 10:33 AM, Black, David wrote:
Joe, 

I'll take another look at this draft before the telechat. The NVO3 WG is publishing this use case draft now in part because they badly lost their way over the past couple of years :-(. I have not been a fan of this draft in the WG, but I don't fundamentally object to its publication. 

Could you provide a few examples of terminology in the draft that you view as problematic? 

Thanks, --David ... Sent from my Android not-so-smartphone.


-------- Original message --------
From: Joe Touch <touch@isi.edu>
Date: 1/14/17 9:23 AM (GMT-08:00)
To: "Black, David" <david.black@emc.com>
Cc: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, Martin Stiemerling <mls.ietf@gmail.com>, tsv-art@ietf.org
Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11

David - I think it'd be useful for fresh eyes on this. IMO, it's full of
vendor terminology that I don't think sufficiently differentiates the
data center case from any other variant of virtual network.

This is the use case doc that purports to motivate "yet another" UDP
tunneling mechanism, which has generated quite a bit of controversy and
I expect would be more relevant to TSV.

However, I'm struck by the need to publish a use case doc so soon after
the problem statement doc (just two years ago), but that's not a TSV issue.

Joe


On 1/14/2017 8:09 AM, Joe Touch wrote:
> I've been giving them feedback for a while.
>
> Joe
>
>> On Jan 14, 2017, at 7:07 AM, Black, David <David.Black@dell.com> wrote:
>>
>> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd be willing to help with a Transport review of this NVO3 use case draft.  That'll have to happen quickly, as it looks like IETF LC ended on Wednesday, and the draft's on this week's telechat agenda.
>>
>> Joe?
>>
>> Thanks, --David
>>
>>> -----Original Message-----
>>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Mirja Kuehlewind
>>> (IETF)
>>> Sent: Saturday, January 14, 2017 6:49 AM
>>> To: Joe Touch
>>> Cc: Martin Stiemerling; tsv-art@ietf.org
>>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11
>>>
>>> Hi Joe,
>>>
>>> I also thought that this could potentially have a transport review. If you’d be able
>>> to send one that be great, please do so. Or what do you meant by it’s already
>>> being watched?
>>>
>>> Mirja
>>>
>>>
>>>> Am 13.01.2017 um 23:09 schrieb Joe Touch <touch@isi.edu>:
>>>>
>>>> Hi Martin,
>>>>
>>>> I've been tracking this one for a while:
>>>>
>>>> draft-ietf-nvo3-use-case-15
>>>>
>>>> It does have significant transport issues, but it's already being
>>>> watched ;-)
>>>>
>>>> Joe
>>>>
>>>>
>>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote:
>>>>> Dear TSVers,
>>>>>
>>>>> First of all, a happy new (western) year! :)
>>>>>
>>>>> I did work through all documents that are in IETF LC, IESG processing
>>>>> or being requested for publication as of 01/11, 09:00 pm UTC.
>>>>>
>>>>> Please find below all documents checked and what to do with these
>>>>> documents.
>>>>>
>>>>>
>>>>> Documents that require TSV attention:
>>>>> none.
>>>>>
>>>>>
>>>>> Documents that do not require TSV attention:
>>>>> draft-ietf-oauth-jwsreq-09
>>>>> draft-ietf-ipsecme-rfc4307bis-15
>>>>> draft-ietf-geojson-text-sequence-03
>>>>> draft-ietf-dime-agent-overload-08
>>>>> draft-ietf-bmwg-ipv6-nd-04
>>>>> draft-ietf-intarea-hostname-practice-03
>>>>> draft-mohali-dispatch-cause-for-service-number-12
>>>>> draft-ietf-trill-rfc6439bis-04
>>>>> draft-ietf-trill-directory-assist-mechanisms-10
>>>>> draft-ietf-teas-p2mp-loose-path-reopt-08
>>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06
>>>>> draft-ietf-sidr-rpki-oob-setup-06
>>>>> draft-ietf-sidr-publication-10
>>>>> draft-ietf-sidr-adverse-actions-03
>>>>> draft-ietf-rtgwg-rlfa-node-protection-10
>>>>> draft-ietf-mpls-residence-time-12
>>>>> draft-ietf-lisp-type-iana-04
>>>>> draft-ietf-ecrit-ecall-22
>>>>> draft-ietf-ecrit-car-crash-21
>>>>> draft-ietf-bfcpbis-bfcp-websocket-13
>>>>> draft-ietf-6man-rdnss-rfc6106bis-14
>>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04
>>>>> draft-murchison-webdav-prefer-13
>>>>> draft-ietf-dnsop-edns-key-tag-03
>>>>> draft-ietf-payload-melpe-04
>>>>> draft-ietf-insipid-logme-reqs-11
>>>>> draft-ietf-softwire-multicast-prefix-option-11
>>>>> draft-ietf-clue-rtp-mapping-10
>>>>> draft-ietf-bfcpbis-sdp-ws-uri-07
>>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03
>>>>> draft-ietf-nvo3-use-case-15
>>>>> draft-ietf-softwire-dslite-multicast-14
>>>>>
>>>>> 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
>>> _______________________________________________
>>> Tsv-art mailing list
>>> Tsv-art@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tsv-art

--------------65A82F140E95106D5D6A46DC-- From nobody Mon Jan 16 07:42:56 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 7D207129557 for ; Mon, 16 Jan 2017 07:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 BMZ1opFre68D for ; Mon, 16 Jan 2017 07:42:53 -0800 (PST) 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 E8CD212957F for ; Mon, 16 Jan 2017 07:42:52 -0800 (PST) Received: (qmail 1276 invoked from network); 16 Jan 2017 16:42:51 +0100 Received: from p5dec2f0e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.47.14) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Jan 2017 16:42:51 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <1e92262c-36f5-c173-e988-debc1c49e651@isi.edu> Date: Mon, 16 Jan 2017 16:42:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu> <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> <1e92262c-36f5-c173-e988-debc1c49e651@isi.edu> To: Joe Touch , "Black, David" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Martin Stiemerling , "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 15:42:55 -0000 Hi Joe, hi David, if one of you could actually still provide a =E2=80=9Eofficial=E2=80=9C = tsv-art review, that would help Spencer and me to refer to something in = our ballot position. But we would need that soon=E2=80=A6 anybody able = to do that? Thanks! Mirja > Am 14.01.2017 um 20:28 schrieb Joe Touch : >=20 > I'm not a fan of using human administrative, political, or economic = boundary terms as if they had any meaning in a network architecture. >=20 > Tenant system, VM, vGW, and even DC (or NVO3 for that matter) are = insufficiently defined, IMO. But that's a fault of the entire WG, not = just this doc. >=20 > This leads to gibberis (IMO) like: > One NVO3 network can provide connectivity to many TSs that attach to > many different NVEs in a DC. TS dynamic placement and mobility > results in frequent changes of the binding between a TS and an NVE. >=20 > This doc boils down to "overlays are useful in data centers". Why = wouldn't they be? How are data centers different (they really aren't, = except that some fall into the class of "managed subnetworks" that can = use custom settings). >=20 > I really don't see the need for this doc at all. > Joe >=20 >=20 > On 1/14/2017 10:33 AM, Black, David wrote: >> Joe,=20 >>=20 >> I'll take another look at this draft before the telechat. The NVO3 WG = is publishing this use case draft now in part because they badly lost = their way over the past couple of years :-(. I have not been a fan of = this draft in the WG, but I don't fundamentally object to its = publication.=20 >>=20 >> Could you provide a few examples of terminology in the draft that you = view as problematic?=20 >>=20 >> Thanks, --David ... Sent from my Android not-so-smartphone. >>=20 >>=20 >> -------- Original message -------- >> From: Joe Touch >> Date: 1/14/17 9:23 AM (GMT-08:00) >> To: "Black, David" >> Cc: "Mirja Kuehlewind (IETF)" , Martin = Stiemerling , tsv-art@ietf.org >> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents = as of 01/11 >>=20 >> David - I think it'd be useful for fresh eyes on this. IMO, it's full = of >> vendor terminology that I don't think sufficiently differentiates the >> data center case from any other variant of virtual network. >>=20 >> This is the use case doc that purports to motivate "yet another" UDP >> tunneling mechanism, which has generated quite a bit of controversy = and >> I expect would be more relevant to TSV. >>=20 >> However, I'm struck by the need to publish a use case doc so soon = after >> the problem statement doc (just two years ago), but that's not a TSV = issue. >>=20 >> Joe >>=20 >>=20 >> On 1/14/2017 8:09 AM, Joe Touch wrote: >> > I've been giving them feedback for a while.=20 >> > >> > Joe >> > >> >> On Jan 14, 2017, at 7:07 AM, Black, David = wrote: >> >> >> >> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd = be willing to help with a Transport review of this NVO3 use case draft. = That'll have to happen quickly, as it looks like IETF LC ended on = Wednesday, and the draft's on this week's telechat agenda. >> >> >> >> Joe? >> >> >> >> Thanks, --David >> >> >> >>> -----Original Message----- >> >>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of = Mirja Kuehlewind >> >>> (IETF) >> >>> Sent: Saturday, January 14, 2017 6:49 AM >> >>> To: Joe Touch >> >>> Cc: Martin Stiemerling; tsv-art@ietf.org >> >>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC = documents as of 01/11 >> >>> >> >>> Hi Joe, >> >>> >> >>> I also thought that this could potentially have a transport = review. If you=E2=80=99d be able >> >>> to send one that be great, please do so. Or what do you meant by = it=E2=80=99s already >> >>> being watched? >> >>> >> >>> Mirja >> >>> >> >>> >> >>>> Am 13.01.2017 um 23:09 schrieb Joe Touch : >> >>>> >> >>>> Hi Martin, >> >>>> >> >>>> I've been tracking this one for a while: >> >>>> >> >>>> draft-ietf-nvo3-use-case-15 >> >>>> >> >>>> It does have significant transport issues, but it's already = being >> >>>> watched ;-) >> >>>> >> >>>> Joe >> >>>> >> >>>> >> >>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote: >> >>>>> Dear TSVers, >> >>>>> >> >>>>> First of all, a happy new (western) year! :) >> >>>>> >> >>>>> I did work through all documents that are in IETF LC, IESG = processing >> >>>>> or being requested for publication as of 01/11, 09:00 pm UTC. >> >>>>> >> >>>>> Please find below all documents checked and what to do with = these >> >>>>> documents. >> >>>>> >> >>>>> >> >>>>> Documents that require TSV attention: >> >>>>> none. >> >>>>> >> >>>>> >> >>>>> Documents that do not require TSV attention: >> >>>>> draft-ietf-oauth-jwsreq-09 >> >>>>> draft-ietf-ipsecme-rfc4307bis-15 >> >>>>> draft-ietf-geojson-text-sequence-03 >> >>>>> draft-ietf-dime-agent-overload-08 >> >>>>> draft-ietf-bmwg-ipv6-nd-04 >> >>>>> draft-ietf-intarea-hostname-practice-03 >> >>>>> draft-mohali-dispatch-cause-for-service-number-12 >> >>>>> draft-ietf-trill-rfc6439bis-04 >> >>>>> draft-ietf-trill-directory-assist-mechanisms-10 >> >>>>> draft-ietf-teas-p2mp-loose-path-reopt-08 >> >>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06 >> >>>>> draft-ietf-sidr-rpki-oob-setup-06 >> >>>>> draft-ietf-sidr-publication-10 >> >>>>> draft-ietf-sidr-adverse-actions-03 >> >>>>> draft-ietf-rtgwg-rlfa-node-protection-10 >> >>>>> draft-ietf-mpls-residence-time-12 >> >>>>> draft-ietf-lisp-type-iana-04 >> >>>>> draft-ietf-ecrit-ecall-22 >> >>>>> draft-ietf-ecrit-car-crash-21 >> >>>>> draft-ietf-bfcpbis-bfcp-websocket-13 >> >>>>> draft-ietf-6man-rdnss-rfc6106bis-14 >> >>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04 >> >>>>> draft-murchison-webdav-prefer-13 >> >>>>> draft-ietf-dnsop-edns-key-tag-03 >> >>>>> draft-ietf-payload-melpe-04 >> >>>>> draft-ietf-insipid-logme-reqs-11 >> >>>>> draft-ietf-softwire-multicast-prefix-option-11 >> >>>>> draft-ietf-clue-rtp-mapping-10 >> >>>>> draft-ietf-bfcpbis-sdp-ws-uri-07 >> >>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03 >> >>>>> draft-ietf-nvo3-use-case-15 >> >>>>> draft-ietf-softwire-dslite-multicast-14 >> >>>>> >> >>>>> 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 >> >>> _______________________________________________ >> >>> Tsv-art mailing list >> >>> Tsv-art@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/tsv-art >>=20 >=20 >=20 From nobody Mon Jan 16 13:34:43 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 2A0D712969F for ; Mon, 16 Jan 2017 13:34:42 -0800 (PST) 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); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=uiC1dpYx; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=Hx04EOTt 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 2ILEcGfSwUXq for ; Mon, 16 Jan 2017 13:34:40 -0800 (PST) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 0C06212969B for ; Mon, 16 Jan 2017 13:34:40 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=ImSAN50sYg/8KTAVoPx2xQAZ7d2JIwEdgc2Lylm+NWhSTG2Vut1LhNde Zvrp8qJEFmXCJIckUEeVMEcNfUfZNc4VHtRMeNqobi9J7zy6i97Kak292 sTNOmMO1uMiqhTS+ToSp8du2h0ebt/jtwyQjjNQyNrUK+qITF+2px+C4u 8=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1484602480; x=1516138480; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lsqgk8NSjYk4D/ehl7tmXH0KvjU8zGLx97OOfDLgDG0=; b=uiC1dpYx+CvJNxKb+ZRXh77TvUiDHVxWsFHlgWaVwuIQekvimCAFqp7f jZtodeJBN+poB5Sadca58Et/gjcOCLOm3ECpZ7uhVwM/j47go1IthAPmv NsMBtiLO7aGmE21kr9G+p6ydkmIvg29zYWv25XNdetZyosChIFLBMzm0R 4=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2017 15:34:39 -0600 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 03:34:38 +0600 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0GLYapj000415 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Jan 2017 16:34:37 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com v0GLYapj000415 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1484602478; bh=J/X7hS5Dqtd5DoSaAtcOdW3PkUo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Hx04EOTtvqZkMKRMtXZR4IlQadLLJfpcQ6z7HpydCuyL2tEsLRYK2tmcyPnBVs15L gujeNpIUkZzZOWm1i1y4eXJ+vvVQymIbnIYfD8FECmLt2FrgDkjyaahsxrNlPiGcEN oQjdqKDjknoiArzfEGmR/p8FN5ugrpakMKHdBUA4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com v0GLYapj000415 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd02.lss.emc.com (RSA Interceptor); Mon, 16 Jan 2017 16:33:57 -0500 Received: from MXHUB318.corp.emc.com (MXHUB318.corp.emc.com [10.146.3.96]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0GLYPuh011089 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 16 Jan 2017 16:34:26 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB318.corp.emc.com ([10.146.3.96]) with mapi id 14.03.0266.001; Mon, 16 Jan 2017 16:34:25 -0500 To: "Mirja Kuehlewind (IETF)" , Joe Touch Thread-Topic: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 Thread-Index: AQHScA844fwGiaQhLkS6DrqqYQHMn6E7oEtw Date: Mon, 16 Jan 2017 21:34:24 +0000 Message-ID: References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu> <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> <1e92262c-36f5-c173-e988-debc1c49e651@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.108] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Martin Stiemerling , "Black, David" , "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 21:34:42 -0000 SSdsbCBnbyBkbyB0aGF0IHRvbW9ycm93Lg0KDQpUaGFua3MsIC0tRGF2aWQNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUc3YtYXJ0IFttYWlsdG86dHN2LWFydC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlyamEgS3VlaGxld2luZA0KPiAoSUVURikNCj4g U2VudDogTW9uZGF5LCBKYW51YXJ5IDE2LCAyMDE3IDEwOjQzIEFNDQo+IFRvOiBKb2UgVG91Y2g7 IEJsYWNrLCBEYXZpZA0KPiBDYzogTWFydGluIFN0aWVtZXJsaW5nOyB0c3YtYXJ0QGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbVHN2LWFydF0gVFNWIFRyaWFnZSB0ZWFtOiBSZXZpZXcgb2YgSUVU RiBMQyBkb2N1bWVudHMgYXMgb2YgMDEvMTENCj4gDQo+IEhpIEpvZSwgaGkgRGF2aWQsDQo+IA0K PiBpZiBvbmUgb2YgeW91IGNvdWxkIGFjdHVhbGx5IHN0aWxsIHByb3ZpZGUgYSDigJ5vZmZpY2lh bOKAnCB0c3YtYXJ0IHJldmlldywgdGhhdCB3b3VsZCBoZWxwDQo+IFNwZW5jZXIgYW5kIG1lIHRv IHJlZmVyIHRvIHNvbWV0aGluZyBpbiBvdXIgYmFsbG90IHBvc2l0aW9uLiBCdXQgd2Ugd291bGQg bmVlZA0KPiB0aGF0IHNvb27igKYgYW55Ym9keSBhYmxlIHRvIGRvIHRoYXQ/DQo+IA0KPiBUaGFu a3MhDQo+IE1pcmphDQo+IA0KPiANCj4gPiBBbSAxNC4wMS4yMDE3IHVtIDIwOjI4IHNjaHJpZWIg Sm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1PjoNCj4gPg0KPiA+IEknbSBub3QgYSBmYW4gb2YgdXNp bmcgaHVtYW4gYWRtaW5pc3RyYXRpdmUsIHBvbGl0aWNhbCwgb3IgZWNvbm9taWMgYm91bmRhcnkN Cj4gdGVybXMgYXMgaWYgdGhleSBoYWQgYW55IG1lYW5pbmcgaW4gYSBuZXR3b3JrIGFyY2hpdGVj dHVyZS4NCj4gPg0KPiA+IFRlbmFudCBzeXN0ZW0sIFZNLCB2R1csIGFuZCBldmVuIERDIChvciBO Vk8zIGZvciB0aGF0IG1hdHRlcikgYXJlDQo+IGluc3VmZmljaWVudGx5IGRlZmluZWQsIElNTy4g QnV0IHRoYXQncyBhIGZhdWx0IG9mIHRoZSBlbnRpcmUgV0csIG5vdCBqdXN0IHRoaXMgZG9jLg0K PiA+DQo+ID4gVGhpcyBsZWFkcyB0byBnaWJiZXJpcyAoSU1PKSBsaWtlOg0KPiA+ICAgT25lIE5W TzMgbmV0d29yayBjYW4gcHJvdmlkZSBjb25uZWN0aXZpdHkgdG8gbWFueSBUU3MgdGhhdCBhdHRh Y2ggdG8NCj4gPiAgIG1hbnkgZGlmZmVyZW50IE5WRXMgaW4gYSBEQy4gVFMgZHluYW1pYyBwbGFj ZW1lbnQgYW5kIG1vYmlsaXR5DQo+ID4gICByZXN1bHRzIGluIGZyZXF1ZW50IGNoYW5nZXMgb2Yg dGhlIGJpbmRpbmcgYmV0d2VlbiBhIFRTIGFuZCBhbiBOVkUuDQo+ID4NCj4gPiBUaGlzIGRvYyBi b2lscyBkb3duIHRvICJvdmVybGF5cyBhcmUgdXNlZnVsIGluIGRhdGEgY2VudGVycyIuIFdoeSB3 b3VsZG4ndCB0aGV5DQo+IGJlPyBIb3cgYXJlIGRhdGEgY2VudGVycyBkaWZmZXJlbnQgKHRoZXkg cmVhbGx5IGFyZW4ndCwgZXhjZXB0IHRoYXQgc29tZSBmYWxsIGludG8NCj4gdGhlIGNsYXNzIG9m ICJtYW5hZ2VkIHN1Ym5ldHdvcmtzIiB0aGF0IGNhbiB1c2UgY3VzdG9tIHNldHRpbmdzKS4NCj4g Pg0KPiA+IEkgcmVhbGx5IGRvbid0IHNlZSB0aGUgbmVlZCBmb3IgdGhpcyBkb2MgYXQgYWxsLg0K PiA+IEpvZQ0KPiA+DQo+ID4NCj4gPiBPbiAxLzE0LzIwMTcgMTA6MzMgQU0sIEJsYWNrLCBEYXZp ZCB3cm90ZToNCj4gPj4gSm9lLA0KPiA+Pg0KPiA+PiBJJ2xsIHRha2UgYW5vdGhlciBsb29rIGF0 IHRoaXMgZHJhZnQgYmVmb3JlIHRoZSB0ZWxlY2hhdC4gVGhlIE5WTzMgV0cgaXMNCj4gcHVibGlz aGluZyB0aGlzIHVzZSBjYXNlIGRyYWZ0IG5vdyBpbiBwYXJ0IGJlY2F1c2UgdGhleSBiYWRseSBs b3N0IHRoZWlyIHdheSBvdmVyDQo+IHRoZSBwYXN0IGNvdXBsZSBvZiB5ZWFycyA6LSguIEkgaGF2 ZSBub3QgYmVlbiBhIGZhbiBvZiB0aGlzIGRyYWZ0IGluIHRoZSBXRywgYnV0IEkNCj4gZG9uJ3Qg ZnVuZGFtZW50YWxseSBvYmplY3QgdG8gaXRzIHB1YmxpY2F0aW9uLg0KPiA+Pg0KPiA+PiBDb3Vs ZCB5b3UgcHJvdmlkZSBhIGZldyBleGFtcGxlcyBvZiB0ZXJtaW5vbG9neSBpbiB0aGUgZHJhZnQg dGhhdCB5b3UgdmlldyBhcw0KPiBwcm9ibGVtYXRpYz8NCj4gPj4NCj4gPj4gVGhhbmtzLCAtLURh dmlkIC4uLiBTZW50IGZyb20gbXkgQW5kcm9pZCBub3Qtc28tc21hcnRwaG9uZS4NCj4gPj4NCj4g Pj4NCj4gPj4gLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KPiA+PiBGcm9tOiBK b2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU+DQo+ID4+IERhdGU6IDEvMTQvMTcgOToyMyBBTSAoR01U LTA4OjAwKQ0KPiA+PiBUbzogIkJsYWNrLCBEYXZpZCIgPGRhdmlkLmJsYWNrQGVtYy5jb20+DQo+ ID4+IENjOiAiTWlyamEgS3VlaGxld2luZCAoSUVURikiIDxpZXRmQGt1ZWhsZXdpbmQubmV0Piwg TWFydGluIFN0aWVtZXJsaW5nDQo+IDxtbHMuaWV0ZkBnbWFpbC5jb20+LCB0c3YtYXJ0QGlldGYu b3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbVHN2LWFydF0gVFNWIFRyaWFnZSB0ZWFtOiBSZXZpZXcg b2YgSUVURiBMQyBkb2N1bWVudHMgYXMgb2YNCj4gMDEvMTENCj4gPj4NCj4gPj4gRGF2aWQgLSBJ IHRoaW5rIGl0J2QgYmUgdXNlZnVsIGZvciBmcmVzaCBleWVzIG9uIHRoaXMuIElNTywgaXQncyBm dWxsIG9mDQo+ID4+IHZlbmRvciB0ZXJtaW5vbG9neSB0aGF0IEkgZG9uJ3QgdGhpbmsgc3VmZmlj aWVudGx5IGRpZmZlcmVudGlhdGVzIHRoZQ0KPiA+PiBkYXRhIGNlbnRlciBjYXNlIGZyb20gYW55 IG90aGVyIHZhcmlhbnQgb2YgdmlydHVhbCBuZXR3b3JrLg0KPiA+Pg0KPiA+PiBUaGlzIGlzIHRo ZSB1c2UgY2FzZSBkb2MgdGhhdCBwdXJwb3J0cyB0byBtb3RpdmF0ZSAieWV0IGFub3RoZXIiIFVE UA0KPiA+PiB0dW5uZWxpbmcgbWVjaGFuaXNtLCB3aGljaCBoYXMgZ2VuZXJhdGVkIHF1aXRlIGEg Yml0IG9mIGNvbnRyb3ZlcnN5IGFuZA0KPiA+PiBJIGV4cGVjdCB3b3VsZCBiZSBtb3JlIHJlbGV2 YW50IHRvIFRTVi4NCj4gPj4NCj4gPj4gSG93ZXZlciwgSSdtIHN0cnVjayBieSB0aGUgbmVlZCB0 byBwdWJsaXNoIGEgdXNlIGNhc2UgZG9jIHNvIHNvb24gYWZ0ZXINCj4gPj4gdGhlIHByb2JsZW0g c3RhdGVtZW50IGRvYyAoanVzdCB0d28geWVhcnMgYWdvKSwgYnV0IHRoYXQncyBub3QgYSBUU1Yg aXNzdWUuDQo+ID4+DQo+ID4+IEpvZQ0KPiA+Pg0KPiA+Pg0KPiA+PiBPbiAxLzE0LzIwMTcgODow OSBBTSwgSm9lIFRvdWNoIHdyb3RlOg0KPiA+PiA+IEkndmUgYmVlbiBnaXZpbmcgdGhlbSBmZWVk YmFjayBmb3IgYSB3aGlsZS4NCj4gPj4gPg0KPiA+PiA+IEpvZQ0KPiA+PiA+DQo+ID4+ID4+IE9u IEphbiAxNCwgMjAxNywgYXQgNzowNyBBTSwgQmxhY2ssIERhdmlkIDxEYXZpZC5CbGFja0BkZWxs LmNvbT4gd3JvdGU6DQo+ID4+ID4+DQo+ID4+ID4+IEFzIG9uZSBvZiB0aGUgYXV0aG9ycyBvZiB0 aGUgTlZPMyBhcmNoaXRlY3R1cmUgUkZDLCBSRkMgODAxNCwgSSdkIGJlIHdpbGxpbmcNCj4gdG8g aGVscCB3aXRoIGEgVHJhbnNwb3J0IHJldmlldyBvZiB0aGlzIE5WTzMgdXNlIGNhc2UgZHJhZnQu ICBUaGF0J2xsIGhhdmUgdG8NCj4gaGFwcGVuIHF1aWNrbHksIGFzIGl0IGxvb2tzIGxpa2UgSUVU RiBMQyBlbmRlZCBvbiBXZWRuZXNkYXksIGFuZCB0aGUgZHJhZnQncyBvbg0KPiB0aGlzIHdlZWsn cyB0ZWxlY2hhdCBhZ2VuZGEuDQo+ID4+ID4+DQo+ID4+ID4+IEpvZT8NCj4gPj4gPj4NCj4gPj4g Pj4gVGhhbmtzLCAtLURhdmlkDQo+ID4+ID4+DQo+ID4+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+PiA+Pj4gRnJvbTogVHN2LWFydCBbbWFpbHRvOnRzdi1hcnQtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pcmphDQo+IEt1ZWhsZXdpbmQNCj4gPj4gPj4+IChJRVRG KQ0KPiA+PiA+Pj4gU2VudDogU2F0dXJkYXksIEphbnVhcnkgMTQsIDIwMTcgNjo0OSBBTQ0KPiA+ PiA+Pj4gVG86IEpvZSBUb3VjaA0KPiA+PiA+Pj4gQ2M6IE1hcnRpbiBTdGllbWVybGluZzsgdHN2 LWFydEBpZXRmLm9yZw0KPiA+PiA+Pj4gU3ViamVjdDogUmU6IFtUc3YtYXJ0XSBUU1YgVHJpYWdl IHRlYW06IFJldmlldyBvZiBJRVRGIExDIGRvY3VtZW50cyBhcyBvZg0KPiAwMS8xMQ0KPiA+PiA+ Pj4NCj4gPj4gPj4+IEhpIEpvZSwNCj4gPj4gPj4+DQo+ID4+ID4+PiBJIGFsc28gdGhvdWdodCB0 aGF0IHRoaXMgY291bGQgcG90ZW50aWFsbHkgaGF2ZSBhIHRyYW5zcG9ydCByZXZpZXcuIElmIHlv deKAmWQNCj4gYmUgYWJsZQ0KPiA+PiA+Pj4gdG8gc2VuZCBvbmUgdGhhdCBiZSBncmVhdCwgcGxl YXNlIGRvIHNvLiBPciB3aGF0IGRvIHlvdSBtZWFudCBieSBpdOKAmXMNCj4gYWxyZWFkeQ0KPiA+ PiA+Pj4gYmVpbmcgd2F0Y2hlZD8NCj4gPj4gPj4+DQo+ID4+ID4+PiBNaXJqYQ0KPiA+PiA+Pj4N Cj4gPj4gPj4+DQo+ID4+ID4+Pj4gQW0gMTMuMDEuMjAxNyB1bSAyMzowOSBzY2hyaWViIEpvZSBU b3VjaCA8dG91Y2hAaXNpLmVkdT46DQo+ID4+ID4+Pj4NCj4gPj4gPj4+PiBIaSBNYXJ0aW4sDQo+ ID4+ID4+Pj4NCj4gPj4gPj4+PiBJJ3ZlIGJlZW4gdHJhY2tpbmcgdGhpcyBvbmUgZm9yIGEgd2hp bGU6DQo+ID4+ID4+Pj4NCj4gPj4gPj4+PiBkcmFmdC1pZXRmLW52bzMtdXNlLWNhc2UtMTUNCj4g Pj4gPj4+Pg0KPiA+PiA+Pj4+IEl0IGRvZXMgaGF2ZSBzaWduaWZpY2FudCB0cmFuc3BvcnQgaXNz dWVzLCBidXQgaXQncyBhbHJlYWR5IGJlaW5nDQo+ID4+ID4+Pj4gd2F0Y2hlZCA7LSkNCj4gPj4g Pj4+Pg0KPiA+PiA+Pj4+IEpvZQ0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4NCj4gPj4gPj4+Pj4gT24g MS8xMS8yMDE3IDE6NTIgUE0sIE1hcnRpbiBTdGllbWVybGluZyB3cm90ZToNCj4gPj4gPj4+Pj4g RGVhciBUU1ZlcnMsDQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+IEZpcnN0IG9mIGFsbCwgYSBoYXBw eSBuZXcgKHdlc3Rlcm4pIHllYXIhIDopDQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+IEkgZGlkIHdv cmsgdGhyb3VnaCBhbGwgZG9jdW1lbnRzIHRoYXQgYXJlIGluIElFVEYgTEMsIElFU0cgcHJvY2Vz c2luZw0KPiA+PiA+Pj4+PiBvciBiZWluZyByZXF1ZXN0ZWQgZm9yIHB1YmxpY2F0aW9uIGFzIG9m IDAxLzExLCAwOTowMCBwbSBVVEMuDQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+IFBsZWFzZSBmaW5k IGJlbG93IGFsbCBkb2N1bWVudHMgY2hlY2tlZCBhbmQgd2hhdCB0byBkbyB3aXRoIHRoZXNlDQo+ ID4+ID4+Pj4+IGRvY3VtZW50cy4NCj4gPj4gPj4+Pj4NCj4gPj4gPj4+Pj4NCj4gPj4gPj4+Pj4g RG9jdW1lbnRzIHRoYXQgcmVxdWlyZSBUU1YgYXR0ZW50aW9uOg0KPiA+PiA+Pj4+PiBub25lLg0K PiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+PiBEb2N1bWVudHMgdGhhdCBkbyBub3Qg cmVxdWlyZSBUU1YgYXR0ZW50aW9uOg0KPiA+PiA+Pj4+PiBkcmFmdC1pZXRmLW9hdXRoLWp3c3Jl cS0wOQ0KPiA+PiA+Pj4+PiBkcmFmdC1pZXRmLWlwc2VjbWUtcmZjNDMwN2Jpcy0xNQ0KPiA+PiA+ Pj4+PiBkcmFmdC1pZXRmLWdlb2pzb24tdGV4dC1zZXF1ZW5jZS0wMw0KPiA+PiA+Pj4+PiBkcmFm dC1pZXRmLWRpbWUtYWdlbnQtb3ZlcmxvYWQtMDgNCj4gPj4gPj4+Pj4gZHJhZnQtaWV0Zi1ibXdn LWlwdjYtbmQtMDQNCj4gPj4gPj4+Pj4gZHJhZnQtaWV0Zi1pbnRhcmVhLWhvc3RuYW1lLXByYWN0 aWNlLTAzDQo+ID4+ID4+Pj4+IGRyYWZ0LW1vaGFsaS1kaXNwYXRjaC1jYXVzZS1mb3Itc2Vydmlj ZS1udW1iZXItMTINCj4gPj4gPj4+Pj4gZHJhZnQtaWV0Zi10cmlsbC1yZmM2NDM5YmlzLTA0DQo+ ID4+ID4+Pj4+IGRyYWZ0LWlldGYtdHJpbGwtZGlyZWN0b3J5LWFzc2lzdC1tZWNoYW5pc21zLTEw DQo+ID4+ID4+Pj4+IGRyYWZ0LWlldGYtdGVhcy1wMm1wLWxvb3NlLXBhdGgtcmVvcHQtMDgNCj4g Pj4gPj4+Pj4gZHJhZnQtaWV0Zi10ZWFzLWdtcGxzLXJlc291cmNlLXNoYXJpbmctcHJvYy0wNg0K PiA+PiA+Pj4+PiBkcmFmdC1pZXRmLXNpZHItcnBraS1vb2Itc2V0dXAtMDYNCj4gPj4gPj4+Pj4g ZHJhZnQtaWV0Zi1zaWRyLXB1YmxpY2F0aW9uLTEwDQo+ID4+ID4+Pj4+IGRyYWZ0LWlldGYtc2lk ci1hZHZlcnNlLWFjdGlvbnMtMDMNCj4gPj4gPj4+Pj4gZHJhZnQtaWV0Zi1ydGd3Zy1ybGZhLW5v ZGUtcHJvdGVjdGlvbi0xMA0KPiA+PiA+Pj4+PiBkcmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRp bWUtMTINCj4gPj4gPj4+Pj4gZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS0wNA0KPiA+PiA+Pj4+ PiBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTIyDQo+ID4+ID4+Pj4+IGRyYWZ0LWlldGYtZWNyaXQt Y2FyLWNyYXNoLTIxDQo+ID4+ID4+Pj4+IGRyYWZ0LWlldGYtYmZjcGJpcy1iZmNwLXdlYnNvY2tl dC0xMw0KPiA+PiA+Pj4+PiBkcmFmdC1pZXRmLTZtYW4tcmRuc3MtcmZjNjEwNmJpcy0xNA0KPiA+ PiA+Pj4+PiBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1tY3B0dC1ycC1uYW1lc3BhY2UtMDQNCj4g Pj4gPj4+Pj4gZHJhZnQtbXVyY2hpc29uLXdlYmRhdi1wcmVmZXItMTMNCj4gPj4gPj4+Pj4gZHJh ZnQtaWV0Zi1kbnNvcC1lZG5zLWtleS10YWctMDMNCj4gPj4gPj4+Pj4gZHJhZnQtaWV0Zi1wYXls b2FkLW1lbHBlLTA0DQo+ID4+ID4+Pj4+IGRyYWZ0LWlldGYtaW5zaXBpZC1sb2dtZS1yZXFzLTEx DQo+ID4+ID4+Pj4+IGRyYWZ0LWlldGYtc29mdHdpcmUtbXVsdGljYXN0LXByZWZpeC1vcHRpb24t MTENCj4gPj4gPj4+Pj4gZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5nLTEwDQo+ID4+ID4+Pj4+ IGRyYWZ0LWlldGYtYmZjcGJpcy1zZHAtd3MtdXJpLTA3DQo+ID4+ID4+Pj4+IGRyYWZ0LWlldGYt ZGhjLWRoY3B2Ni1mYWlsb3Zlci1wcm90b2NvbC0wMw0KPiA+PiA+Pj4+PiBkcmFmdC1pZXRmLW52 bzMtdXNlLWNhc2UtMTUNCj4gPj4gPj4+Pj4gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1kc2xpdGUtbXVs dGljYXN0LTE0DQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+IFRoYW5rcywNCj4gPj4gPj4+Pj4NCj4g Pj4gPj4+Pj4gTWFydGluDQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+Pj4+IFRzdi1hcnQgbWFpbGlu ZyBsaXN0DQo+ID4+ID4+Pj4+IFRzdi1hcnRAaWV0Zi5vcmcNCj4gPj4gPj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90c3YtYXJ0DQo+ID4+ID4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPj4+PiBUc3YtYXJ0 IG1haWxpbmcgbGlzdA0KPiA+PiA+Pj4+IFRzdi1hcnRAaWV0Zi5vcmcNCj4gPj4gPj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rzdi1hcnQNCj4gPj4gPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+PiBUc3Yt YXJ0IG1haWxpbmcgbGlzdA0KPiA+PiA+Pj4gVHN2LWFydEBpZXRmLm9yZw0KPiA+PiA+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90c3YtYXJ0DQo+ID4+DQo+ID4NCj4g Pg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gVHN2LWFydCBtYWlsaW5nIGxpc3QNCj4gVHN2LWFydEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rzdi1hcnQNCg== From nobody Mon Jan 16 14:23:07 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 605C71296F8 for ; Mon, 16 Jan 2017 14:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 OBYG4PVWJfc7 for ; Mon, 16 Jan 2017 14:23:04 -0800 (PST) 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 9F7EF1296E8 for ; Mon, 16 Jan 2017 14:23:03 -0800 (PST) Received: (qmail 25766 invoked from network); 16 Jan 2017 23:23:00 +0100 Received: from p5dec2f0e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.47.14) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Jan 2017 23:23:00 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Mon, 16 Jan 2017 23:22:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8A78727F-F14A-4D5F-99B7-C993BDAF7EB6@kuehlewind.net> References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu> <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> <1e92262c-36f5-c173-e988-debc1c49e651@isi.edu> To: "Black, David" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Martin Stiemerling , "tsv-art@ietf.org" , Joe Touch Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 22:23:06 -0000 Thanks! > Am 16.01.2017 um 22:34 schrieb Black, David : >=20 > I'll go do that tomorrow. >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind >> (IETF) >> Sent: Monday, January 16, 2017 10:43 AM >> To: Joe Touch; Black, David >> Cc: Martin Stiemerling; tsv-art@ietf.org >> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents = as of 01/11 >>=20 >> Hi Joe, hi David, >>=20 >> if one of you could actually still provide a =E2=80=9Eofficial=E2=80=9C= tsv-art review, that would help >> Spencer and me to refer to something in our ballot position. But we = would need >> that soon=E2=80=A6 anybody able to do that? >>=20 >> Thanks! >> Mirja >>=20 >>=20 >>> Am 14.01.2017 um 20:28 schrieb Joe Touch : >>>=20 >>> I'm not a fan of using human administrative, political, or economic = boundary >> terms as if they had any meaning in a network architecture. >>>=20 >>> Tenant system, VM, vGW, and even DC (or NVO3 for that matter) are >> insufficiently defined, IMO. But that's a fault of the entire WG, not = just this doc. >>>=20 >>> This leads to gibberis (IMO) like: >>> One NVO3 network can provide connectivity to many TSs that attach = to >>> many different NVEs in a DC. TS dynamic placement and mobility >>> results in frequent changes of the binding between a TS and an NVE. >>>=20 >>> This doc boils down to "overlays are useful in data centers". Why = wouldn't they >> be? How are data centers different (they really aren't, except that = some fall into >> the class of "managed subnetworks" that can use custom settings). >>>=20 >>> I really don't see the need for this doc at all. >>> Joe >>>=20 >>>=20 >>> On 1/14/2017 10:33 AM, Black, David wrote: >>>> Joe, >>>>=20 >>>> I'll take another look at this draft before the telechat. The NVO3 = WG is >> publishing this use case draft now in part because they badly lost = their way over >> the past couple of years :-(. I have not been a fan of this draft in = the WG, but I >> don't fundamentally object to its publication. >>>>=20 >>>> Could you provide a few examples of terminology in the draft that = you view as >> problematic? >>>>=20 >>>> Thanks, --David ... Sent from my Android not-so-smartphone. >>>>=20 >>>>=20 >>>> -------- Original message -------- >>>> From: Joe Touch >>>> Date: 1/14/17 9:23 AM (GMT-08:00) >>>> To: "Black, David" >>>> Cc: "Mirja Kuehlewind (IETF)" , Martin = Stiemerling >> , tsv-art@ietf.org >>>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents = as of >> 01/11 >>>>=20 >>>> David - I think it'd be useful for fresh eyes on this. IMO, it's = full of >>>> vendor terminology that I don't think sufficiently differentiates = the >>>> data center case from any other variant of virtual network. >>>>=20 >>>> This is the use case doc that purports to motivate "yet another" = UDP >>>> tunneling mechanism, which has generated quite a bit of controversy = and >>>> I expect would be more relevant to TSV. >>>>=20 >>>> However, I'm struck by the need to publish a use case doc so soon = after >>>> the problem statement doc (just two years ago), but that's not a = TSV issue. >>>>=20 >>>> Joe >>>>=20 >>>>=20 >>>> On 1/14/2017 8:09 AM, Joe Touch wrote: >>>>> I've been giving them feedback for a while. >>>>>=20 >>>>> Joe >>>>>=20 >>>>>> On Jan 14, 2017, at 7:07 AM, Black, David = wrote: >>>>>>=20 >>>>>> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd = be willing >> to help with a Transport review of this NVO3 use case draft. That'll = have to >> happen quickly, as it looks like IETF LC ended on Wednesday, and the = draft's on >> this week's telechat agenda. >>>>>>=20 >>>>>> Joe? >>>>>>=20 >>>>>> Thanks, --David >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of = Mirja >> Kuehlewind >>>>>>> (IETF) >>>>>>> Sent: Saturday, January 14, 2017 6:49 AM >>>>>>> To: Joe Touch >>>>>>> Cc: Martin Stiemerling; tsv-art@ietf.org >>>>>>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC = documents as of >> 01/11 >>>>>>>=20 >>>>>>> Hi Joe, >>>>>>>=20 >>>>>>> I also thought that this could potentially have a transport = review. If you=E2=80=99d >> be able >>>>>>> to send one that be great, please do so. Or what do you meant by = it=E2=80=99s >> already >>>>>>> being watched? >>>>>>>=20 >>>>>>> Mirja >>>>>>>=20 >>>>>>>=20 >>>>>>>> Am 13.01.2017 um 23:09 schrieb Joe Touch : >>>>>>>>=20 >>>>>>>> Hi Martin, >>>>>>>>=20 >>>>>>>> I've been tracking this one for a while: >>>>>>>>=20 >>>>>>>> draft-ietf-nvo3-use-case-15 >>>>>>>>=20 >>>>>>>> It does have significant transport issues, but it's already = being >>>>>>>> watched ;-) >>>>>>>>=20 >>>>>>>> Joe >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote: >>>>>>>>> Dear TSVers, >>>>>>>>>=20 >>>>>>>>> First of all, a happy new (western) year! :) >>>>>>>>>=20 >>>>>>>>> I did work through all documents that are in IETF LC, IESG = processing >>>>>>>>> or being requested for publication as of 01/11, 09:00 pm UTC. >>>>>>>>>=20 >>>>>>>>> Please find below all documents checked and what to do with = these >>>>>>>>> documents. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Documents that require TSV attention: >>>>>>>>> none. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Documents that do not require TSV attention: >>>>>>>>> draft-ietf-oauth-jwsreq-09 >>>>>>>>> draft-ietf-ipsecme-rfc4307bis-15 >>>>>>>>> draft-ietf-geojson-text-sequence-03 >>>>>>>>> draft-ietf-dime-agent-overload-08 >>>>>>>>> draft-ietf-bmwg-ipv6-nd-04 >>>>>>>>> draft-ietf-intarea-hostname-practice-03 >>>>>>>>> draft-mohali-dispatch-cause-for-service-number-12 >>>>>>>>> draft-ietf-trill-rfc6439bis-04 >>>>>>>>> draft-ietf-trill-directory-assist-mechanisms-10 >>>>>>>>> draft-ietf-teas-p2mp-loose-path-reopt-08 >>>>>>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06 >>>>>>>>> draft-ietf-sidr-rpki-oob-setup-06 >>>>>>>>> draft-ietf-sidr-publication-10 >>>>>>>>> draft-ietf-sidr-adverse-actions-03 >>>>>>>>> draft-ietf-rtgwg-rlfa-node-protection-10 >>>>>>>>> draft-ietf-mpls-residence-time-12 >>>>>>>>> draft-ietf-lisp-type-iana-04 >>>>>>>>> draft-ietf-ecrit-ecall-22 >>>>>>>>> draft-ietf-ecrit-car-crash-21 >>>>>>>>> draft-ietf-bfcpbis-bfcp-websocket-13 >>>>>>>>> draft-ietf-6man-rdnss-rfc6106bis-14 >>>>>>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04 >>>>>>>>> draft-murchison-webdav-prefer-13 >>>>>>>>> draft-ietf-dnsop-edns-key-tag-03 >>>>>>>>> draft-ietf-payload-melpe-04 >>>>>>>>> draft-ietf-insipid-logme-reqs-11 >>>>>>>>> draft-ietf-softwire-multicast-prefix-option-11 >>>>>>>>> draft-ietf-clue-rtp-mapping-10 >>>>>>>>> draft-ietf-bfcpbis-sdp-ws-uri-07 >>>>>>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03 >>>>>>>>> draft-ietf-nvo3-use-case-15 >>>>>>>>> draft-ietf-softwire-dslite-multicast-14 >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>>=20 >>>>>>>>> Martin >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> _______________________________________________ >>>>>>> Tsv-art mailing list >>>>>>> Tsv-art@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/tsv-art >>>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art From nobody Tue Jan 17 04:10:57 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 2432A129447 for ; Tue, 17 Jan 2017 04:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 WUFmOlsiONXs for ; Tue, 17 Jan 2017 04:10:54 -0800 (PST) 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 4DE671293E9 for ; Tue, 17 Jan 2017 04:10:54 -0800 (PST) Received: (qmail 17715 invoked from network); 17 Jan 2017 13:10:52 +0100 Received: from p5dec276e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.39.110) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Jan 2017 13:10:52 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> Date: Tue, 17 Jan 2017 13:10:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu> <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Martin Stiemerling , "Black, David" , "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 12:10:56 -0000 Hi Joe, I finally read the draft myself completely. I agree that there is = nothing in the draft that motivates a new tunnel protocol, however, the = draft is also not (explicitly) requiring a new protocol. This says in the summary: =E2=80=9EA tunnel encapsulation protocol is necessary.=E2=80=9C which clearly doesn=E2=80=99t say that an existing one might not be = sufficient. I don=E2=80=99t think there is anything we can do at this stage and with = this draft=E2=80=A6 I=E2=80=99ll wait for David=E2=80=99s review before I put in my ballot. Mirja > Am 14.01.2017 um 18:22 schrieb Joe Touch : >=20 > David - I think it'd be useful for fresh eyes on this. IMO, it's full = of > vendor terminology that I don't think sufficiently differentiates the > data center case from any other variant of virtual network. >=20 > This is the use case doc that purports to motivate "yet another" UDP > tunneling mechanism, which has generated quite a bit of controversy = and > I expect would be more relevant to TSV. >=20 > However, I'm struck by the need to publish a use case doc so soon = after > the problem statement doc (just two years ago), but that's not a TSV = issue. >=20 > Joe >=20 >=20 > On 1/14/2017 8:09 AM, Joe Touch wrote: >> I've been giving them feedback for a while.=20 >>=20 >> Joe >>=20 >>> On Jan 14, 2017, at 7:07 AM, Black, David = wrote: >>>=20 >>> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd be = willing to help with a Transport review of this NVO3 use case draft. = That'll have to happen quickly, as it looks like IETF LC ended on = Wednesday, and the draft's on this week's telechat agenda. >>>=20 >>> Joe? >>>=20 >>> Thanks, --David >>>=20 >>>> -----Original Message----- >>>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind >>>> (IETF) >>>> Sent: Saturday, January 14, 2017 6:49 AM >>>> To: Joe Touch >>>> Cc: Martin Stiemerling; tsv-art@ietf.org >>>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents = as of 01/11 >>>>=20 >>>> Hi Joe, >>>>=20 >>>> I also thought that this could potentially have a transport review. = If you=E2=80=99d be able >>>> to send one that be great, please do so. Or what do you meant by = it=E2=80=99s already >>>> being watched? >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>> Am 13.01.2017 um 23:09 schrieb Joe Touch : >>>>>=20 >>>>> Hi Martin, >>>>>=20 >>>>> I've been tracking this one for a while: >>>>>=20 >>>>> draft-ietf-nvo3-use-case-15 >>>>>=20 >>>>> It does have significant transport issues, but it's already being >>>>> watched ;-) >>>>>=20 >>>>> Joe >>>>>=20 >>>>>=20 >>>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote: >>>>>> Dear TSVers, >>>>>>=20 >>>>>> First of all, a happy new (western) year! :) >>>>>>=20 >>>>>> I did work through all documents that are in IETF LC, IESG = processing >>>>>> or being requested for publication as of 01/11, 09:00 pm UTC. >>>>>>=20 >>>>>> Please find below all documents checked and what to do with these >>>>>> documents. >>>>>>=20 >>>>>>=20 >>>>>> Documents that require TSV attention: >>>>>> none. >>>>>>=20 >>>>>>=20 >>>>>> Documents that do not require TSV attention: >>>>>> draft-ietf-oauth-jwsreq-09 >>>>>> draft-ietf-ipsecme-rfc4307bis-15 >>>>>> draft-ietf-geojson-text-sequence-03 >>>>>> draft-ietf-dime-agent-overload-08 >>>>>> draft-ietf-bmwg-ipv6-nd-04 >>>>>> draft-ietf-intarea-hostname-practice-03 >>>>>> draft-mohali-dispatch-cause-for-service-number-12 >>>>>> draft-ietf-trill-rfc6439bis-04 >>>>>> draft-ietf-trill-directory-assist-mechanisms-10 >>>>>> draft-ietf-teas-p2mp-loose-path-reopt-08 >>>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06 >>>>>> draft-ietf-sidr-rpki-oob-setup-06 >>>>>> draft-ietf-sidr-publication-10 >>>>>> draft-ietf-sidr-adverse-actions-03 >>>>>> draft-ietf-rtgwg-rlfa-node-protection-10 >>>>>> draft-ietf-mpls-residence-time-12 >>>>>> draft-ietf-lisp-type-iana-04 >>>>>> draft-ietf-ecrit-ecall-22 >>>>>> draft-ietf-ecrit-car-crash-21 >>>>>> draft-ietf-bfcpbis-bfcp-websocket-13 >>>>>> draft-ietf-6man-rdnss-rfc6106bis-14 >>>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04 >>>>>> draft-murchison-webdav-prefer-13 >>>>>> draft-ietf-dnsop-edns-key-tag-03 >>>>>> draft-ietf-payload-melpe-04 >>>>>> draft-ietf-insipid-logme-reqs-11 >>>>>> draft-ietf-softwire-multicast-prefix-option-11 >>>>>> draft-ietf-clue-rtp-mapping-10 >>>>>> draft-ietf-bfcpbis-sdp-ws-uri-07 >>>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03 >>>>>> draft-ietf-nvo3-use-case-15 >>>>>> draft-ietf-softwire-dslite-multicast-14 >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Martin >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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 >>>> _______________________________________________ >>>> 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 Tue Jan 17 07:38:57 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 ADECA129525 for ; Tue, 17 Jan 2017 07:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] 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 kRyYLi5bStk9 for ; Tue, 17 Jan 2017 07:38:51 -0800 (PST) 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 35D95129405 for ; Tue, 17 Jan 2017 07:38:51 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0HFc7Bo019368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Jan 2017 07:38:08 -0800 (PST) To: "Mirja Kuehlewind (IETF)" References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu> <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> From: Joe Touch Message-ID: <9b170723-141b-2f95-34fe-58b0791d1d62@isi.edu> Date: Tue, 17 Jan 2017 07:38:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Martin Stiemerling , "Black, David" , "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:38:56 -0000 On 1/17/2017 4:10 AM, Mirja Kuehlewind (IETF) wrote: > Hi Joe, > > I finally read the draft myself completely. I agree that there is nothing in the draft that motivates a new tunnel protocol, however, the draft is also not (explicitly) requiring a new protocol. > > This says in the summary: > > „A tunnel encapsulation protocol is necessary.“ > > which clearly doesn’t say that an existing one might not be sufficient. Good point, but it begs the question of the need for the rest of the document. The use cases have nothing to do uniquely with datacenters. > I don’t think there is anything we can do at this stage and with this draft… The IETF does err on the side of publishing (rather than requiring "proof of need or utility"). However, there's always the opportunity for pushback at the higher levels, e.g., to make sure that the doc itself indicates clearly what it does and does not contribute. E.g., it's possible to ask for a sentence explaining exactly how this is different from any other sort of overlay network - or stating clearly that the conclusion is that datacenters are not unique in their use of overlays. Joe > > I’ll wait for David’s review before I put in my ballot. > > Mirja > > >> Am 14.01.2017 um 18:22 schrieb Joe Touch : >> >> David - I think it'd be useful for fresh eyes on this. IMO, it's full of >> vendor terminology that I don't think sufficiently differentiates the >> data center case from any other variant of virtual network. >> >> This is the use case doc that purports to motivate "yet another" UDP >> tunneling mechanism, which has generated quite a bit of controversy and >> I expect would be more relevant to TSV. >> >> However, I'm struck by the need to publish a use case doc so soon after >> the problem statement doc (just two years ago), but that's not a TSV issue. >> >> Joe >> >> >> On 1/14/2017 8:09 AM, Joe Touch wrote: >>> I've been giving them feedback for a while. >>> >>> Joe >>> >>>> On Jan 14, 2017, at 7:07 AM, Black, David wrote: >>>> >>>> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd be willing to help with a Transport review of this NVO3 use case draft. That'll have to happen quickly, as it looks like IETF LC ended on Wednesday, and the draft's on this week's telechat agenda. >>>> >>>> Joe? >>>> >>>> Thanks, --David >>>> >>>>> -----Original Message----- >>>>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Mirja Kuehlewind >>>>> (IETF) >>>>> Sent: Saturday, January 14, 2017 6:49 AM >>>>> To: Joe Touch >>>>> Cc: Martin Stiemerling; tsv-art@ietf.org >>>>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 >>>>> >>>>> Hi Joe, >>>>> >>>>> I also thought that this could potentially have a transport review. If you’d be able >>>>> to send one that be great, please do so. Or what do you meant by it’s already >>>>> being watched? >>>>> >>>>> Mirja >>>>> >>>>> >>>>>> Am 13.01.2017 um 23:09 schrieb Joe Touch : >>>>>> >>>>>> Hi Martin, >>>>>> >>>>>> I've been tracking this one for a while: >>>>>> >>>>>> draft-ietf-nvo3-use-case-15 >>>>>> >>>>>> It does have significant transport issues, but it's already being >>>>>> watched ;-) >>>>>> >>>>>> Joe >>>>>> >>>>>> >>>>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote: >>>>>>> Dear TSVers, >>>>>>> >>>>>>> First of all, a happy new (western) year! :) >>>>>>> >>>>>>> I did work through all documents that are in IETF LC, IESG processing >>>>>>> or being requested for publication as of 01/11, 09:00 pm UTC. >>>>>>> >>>>>>> Please find below all documents checked and what to do with these >>>>>>> documents. >>>>>>> >>>>>>> >>>>>>> Documents that require TSV attention: >>>>>>> none. >>>>>>> >>>>>>> >>>>>>> Documents that do not require TSV attention: >>>>>>> draft-ietf-oauth-jwsreq-09 >>>>>>> draft-ietf-ipsecme-rfc4307bis-15 >>>>>>> draft-ietf-geojson-text-sequence-03 >>>>>>> draft-ietf-dime-agent-overload-08 >>>>>>> draft-ietf-bmwg-ipv6-nd-04 >>>>>>> draft-ietf-intarea-hostname-practice-03 >>>>>>> draft-mohali-dispatch-cause-for-service-number-12 >>>>>>> draft-ietf-trill-rfc6439bis-04 >>>>>>> draft-ietf-trill-directory-assist-mechanisms-10 >>>>>>> draft-ietf-teas-p2mp-loose-path-reopt-08 >>>>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06 >>>>>>> draft-ietf-sidr-rpki-oob-setup-06 >>>>>>> draft-ietf-sidr-publication-10 >>>>>>> draft-ietf-sidr-adverse-actions-03 >>>>>>> draft-ietf-rtgwg-rlfa-node-protection-10 >>>>>>> draft-ietf-mpls-residence-time-12 >>>>>>> draft-ietf-lisp-type-iana-04 >>>>>>> draft-ietf-ecrit-ecall-22 >>>>>>> draft-ietf-ecrit-car-crash-21 >>>>>>> draft-ietf-bfcpbis-bfcp-websocket-13 >>>>>>> draft-ietf-6man-rdnss-rfc6106bis-14 >>>>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04 >>>>>>> draft-murchison-webdav-prefer-13 >>>>>>> draft-ietf-dnsop-edns-key-tag-03 >>>>>>> draft-ietf-payload-melpe-04 >>>>>>> draft-ietf-insipid-logme-reqs-11 >>>>>>> draft-ietf-softwire-multicast-prefix-option-11 >>>>>>> draft-ietf-clue-rtp-mapping-10 >>>>>>> draft-ietf-bfcpbis-sdp-ws-uri-07 >>>>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03 >>>>>>> draft-ietf-nvo3-use-case-15 >>>>>>> draft-ietf-softwire-dslite-multicast-14 >>>>>>> >>>>>>> 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 >>>>> _______________________________________________ >>>>> 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 Tue Jan 17 08:17: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 AF128129553 for ; Tue, 17 Jan 2017 08:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 HBtknshFtmlY for ; Tue, 17 Jan 2017 08:17:39 -0800 (PST) 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 44CE61294EF for ; Tue, 17 Jan 2017 08:17:38 -0800 (PST) Received: (qmail 30200 invoked from network); 17 Jan 2017 17:17:36 +0100 Received: from p5dec276e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.39.110) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Jan 2017 17:17:36 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <9b170723-141b-2f95-34fe-58b0791d1d62@isi.edu> Date: Tue, 17 Jan 2017 17:17:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <23B76B26-164E-40B0-80E3-73E97C05B015@kuehlewind.net> References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu> <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> <9b170723-141b-2f95-34fe-58b0791d1d62@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Martin Stiemerling , "Black, David" , "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:17:40 -0000 Hi Joe, agreed but this still doesn=E2=80=99t justify a discuss. I will put a = comment in my ballot. However, these are probably comments that should = have been discussed at chartering=E2=80=A6 Mirja > Am 17.01.2017 um 16:38 schrieb Joe Touch : >=20 >=20 >=20 > On 1/17/2017 4:10 AM, Mirja Kuehlewind (IETF) wrote: >> Hi Joe, >>=20 >> I finally read the draft myself completely. I agree that there is = nothing in the draft that motivates a new tunnel protocol, however, the = draft is also not (explicitly) requiring a new protocol. >>=20 >> This says in the summary: >>=20 >> =E2=80=9EA tunnel encapsulation protocol is necessary.=E2=80=9C >>=20 >> which clearly doesn=E2=80=99t say that an existing one might not be = sufficient. >=20 > Good point, but it begs the question of the need for the rest of the > document. The use cases have nothing to do uniquely with datacenters. >> I don=E2=80=99t think there is anything we can do at this stage and = with this draft=E2=80=A6 >=20 > The IETF does err on the side of publishing (rather than requiring > "proof of need or utility"). However, there's always the opportunity = for > pushback at the higher levels, e.g., to make sure that the doc itself > indicates clearly what it does and does not contribute. E.g., it's > possible to ask for a sentence explaining exactly how this is = different > from any other sort of overlay network - or stating clearly that the > conclusion is that datacenters are not unique in their use of = overlays. >=20 > Joe >=20 >>=20 >> I=E2=80=99ll wait for David=E2=80=99s review before I put in my = ballot. >>=20 >> Mirja >>=20 >>=20 >>> Am 14.01.2017 um 18:22 schrieb Joe Touch : >>>=20 >>> David - I think it'd be useful for fresh eyes on this. IMO, it's = full of >>> vendor terminology that I don't think sufficiently differentiates = the >>> data center case from any other variant of virtual network. >>>=20 >>> This is the use case doc that purports to motivate "yet another" UDP >>> tunneling mechanism, which has generated quite a bit of controversy = and >>> I expect would be more relevant to TSV. >>>=20 >>> However, I'm struck by the need to publish a use case doc so soon = after >>> the problem statement doc (just two years ago), but that's not a TSV = issue. >>>=20 >>> Joe >>>=20 >>>=20 >>> On 1/14/2017 8:09 AM, Joe Touch wrote: >>>> I've been giving them feedback for a while.=20 >>>>=20 >>>> Joe >>>>=20 >>>>> On Jan 14, 2017, at 7:07 AM, Black, David = wrote: >>>>>=20 >>>>> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd = be willing to help with a Transport review of this NVO3 use case draft. = That'll have to happen quickly, as it looks like IETF LC ended on = Wednesday, and the draft's on this week's telechat agenda. >>>>>=20 >>>>> Joe? >>>>>=20 >>>>> Thanks, --David >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of = Mirja Kuehlewind >>>>>> (IETF) >>>>>> Sent: Saturday, January 14, 2017 6:49 AM >>>>>> To: Joe Touch >>>>>> Cc: Martin Stiemerling; tsv-art@ietf.org >>>>>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC = documents as of 01/11 >>>>>>=20 >>>>>> Hi Joe, >>>>>>=20 >>>>>> I also thought that this could potentially have a transport = review. If you=E2=80=99d be able >>>>>> to send one that be great, please do so. Or what do you meant by = it=E2=80=99s already >>>>>> being watched? >>>>>>=20 >>>>>> Mirja >>>>>>=20 >>>>>>=20 >>>>>>> Am 13.01.2017 um 23:09 schrieb Joe Touch : >>>>>>>=20 >>>>>>> Hi Martin, >>>>>>>=20 >>>>>>> I've been tracking this one for a while: >>>>>>>=20 >>>>>>> draft-ietf-nvo3-use-case-15 >>>>>>>=20 >>>>>>> It does have significant transport issues, but it's already = being >>>>>>> watched ;-) >>>>>>>=20 >>>>>>> Joe >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote: >>>>>>>> Dear TSVers, >>>>>>>>=20 >>>>>>>> First of all, a happy new (western) year! :) >>>>>>>>=20 >>>>>>>> I did work through all documents that are in IETF LC, IESG = processing >>>>>>>> or being requested for publication as of 01/11, 09:00 pm UTC. >>>>>>>>=20 >>>>>>>> Please find below all documents checked and what to do with = these >>>>>>>> documents. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Documents that require TSV attention: >>>>>>>> none. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Documents that do not require TSV attention: >>>>>>>> draft-ietf-oauth-jwsreq-09 >>>>>>>> draft-ietf-ipsecme-rfc4307bis-15 >>>>>>>> draft-ietf-geojson-text-sequence-03 >>>>>>>> draft-ietf-dime-agent-overload-08 >>>>>>>> draft-ietf-bmwg-ipv6-nd-04 >>>>>>>> draft-ietf-intarea-hostname-practice-03 >>>>>>>> draft-mohali-dispatch-cause-for-service-number-12 >>>>>>>> draft-ietf-trill-rfc6439bis-04 >>>>>>>> draft-ietf-trill-directory-assist-mechanisms-10 >>>>>>>> draft-ietf-teas-p2mp-loose-path-reopt-08 >>>>>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06 >>>>>>>> draft-ietf-sidr-rpki-oob-setup-06 >>>>>>>> draft-ietf-sidr-publication-10 >>>>>>>> draft-ietf-sidr-adverse-actions-03 >>>>>>>> draft-ietf-rtgwg-rlfa-node-protection-10 >>>>>>>> draft-ietf-mpls-residence-time-12 >>>>>>>> draft-ietf-lisp-type-iana-04 >>>>>>>> draft-ietf-ecrit-ecall-22 >>>>>>>> draft-ietf-ecrit-car-crash-21 >>>>>>>> draft-ietf-bfcpbis-bfcp-websocket-13 >>>>>>>> draft-ietf-6man-rdnss-rfc6106bis-14 >>>>>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04 >>>>>>>> draft-murchison-webdav-prefer-13 >>>>>>>> draft-ietf-dnsop-edns-key-tag-03 >>>>>>>> draft-ietf-payload-melpe-04 >>>>>>>> draft-ietf-insipid-logme-reqs-11 >>>>>>>> draft-ietf-softwire-multicast-prefix-option-11 >>>>>>>> draft-ietf-clue-rtp-mapping-10 >>>>>>>> draft-ietf-bfcpbis-sdp-ws-uri-07 >>>>>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03 >>>>>>>> draft-ietf-nvo3-use-case-15 >>>>>>>> draft-ietf-softwire-dslite-multicast-14 >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>> Martin >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> _______________________________________________ >>>>>> 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 >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Tue Jan 17 08:50:01 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 49AAA129AE8 for ; Tue, 17 Jan 2017 08:50:00 -0800 (PST) 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 DxfW3srfe9_W for ; Tue, 17 Jan 2017 08:49:57 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (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 B0B371279EB for ; Tue, 17 Jan 2017 08:49:57 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id w194so41395233ybe.0 for ; Tue, 17 Jan 2017 08:49:57 -0800 (PST) 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=5qeNwWmLPIdN99W+6XgeYv9C1Pc/DlraxWxR79Q3jiQ=; b=VLiObvL7wDTAKSpdjB6vfUBF9BUWALIONfGFqgEGD7rQbVcT0cV3bvEsPABCbimfs4 HCTT20IHh/2UL+iS84jH+7bDNF7RtX3kZs78tYfICq6gVbl4dziRzFJcQcYawM9Gw9J3 pSlwkD7czsaSozjC8Gnek23scy9Xhu67vVsvAdg50he6oL+rm93meYnuH23LuBkizFxM TGPwRh3TjKtFxTJS393qH7GDnpbYyQbjuKOk1wf62FfJBt5xTlohUBo+hoPBODY24nGL U5Ih4lIaYSjBTcvqRxZey6xQhqBZa9z6J2UcozW+rsU/HjXZ7DCShijlw9INwVh1lH3l BugA== 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=5qeNwWmLPIdN99W+6XgeYv9C1Pc/DlraxWxR79Q3jiQ=; b=j9oMX7nJq9pgjX2hOy+z6m96k70kNCB+kch6VZyuvJn69WD5K/nU8zkgZbgxXB8HyU OsMWtXNgKzJdX5ihmaYC4VNt4I8r2MOdRmGAedzzlFvTjxg6xuzc7m5W+rYwzghvx9Pp 25mkq/Lk5srERTczcbrEGphMrg79ePSmst3vqiNQH0V/ZgTWoR2zDh3EQqHdMsalxzP9 g+q2l3w/+xWT9kPH1qaSnsiIlG31g9zJmbaZgfzxOnhJxqKUVmaI002GlmNSPxserLDa nqmFzPkQtpv5vs85PGn9s70wL2h+UYZjHpma6c+O2vbGN/YpSWV/fF0IXAGupizSP3x+ dNXA== X-Gm-Message-State: AIkVDXKVIA3c7QWxdO4go4xkywBJa/vCyKaOaNYdJEb9ot3dnOcTOKqO/GzwFG3saUKGmp7kZvp4syaifhMFkg== X-Received: by 10.37.208.196 with SMTP id h187mr26905905ybg.198.1484671796485; Tue, 17 Jan 2017 08:49:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.221.4 with HTTP; Tue, 17 Jan 2017 08:49:55 -0800 (PST) In-Reply-To: <9b170723-141b-2f95-34fe-58b0791d1d62@isi.edu> References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu> <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> <9b170723-141b-2f95-34fe-58b0791d1d62@isi.edu> From: Spencer Dawkins at IETF Date: Tue, 17 Jan 2017 10:49:55 -0600 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=94eb2c05538209a4cd05464d17a3 Archived-At: Cc: Martin Stiemerling , "Black, David" , "Mirja Kuehlewind \(IETF\)" , "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:50:00 -0000 --94eb2c05538209a4cd05464d17a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FWIW, On Tue, Jan 17, 2017 at 9:38 AM, Joe Touch wrote: > > > On 1/17/2017 4:10 AM, Mirja Kuehlewind (IETF) wrote: > > Hi Joe, > > > > I finally read the draft myself completely. I agree that there is > nothing in the draft that motivates a new tunnel protocol, however, the > draft is also not (explicitly) requiring a new protocol. > > > > This says in the summary: > > > > =E2=80=9EA tunnel encapsulation protocol is necessary.=E2=80=9C > > > > which clearly doesn=E2=80=99t say that an existing one might not be suf= ficient. > > Good point, but it begs the question of the need for the rest of the > document. The use cases have nothing to do uniquely with datacenters. > > I don=E2=80=99t think there is anything we can do at this stage and wit= h this > draft=E2=80=A6 > > The IETF does err on the side of publishing (rather than requiring > "proof of need or utility"). However, there's always the opportunity for > pushback at the higher levels, e.g., to make sure that the doc itself > indicates clearly what it does and does not contribute. E.g., it's > possible to ask for a sentence explaining exactly how this is different > from any other sort of overlay network - or stating clearly that the > conclusion is that datacenters are not unique in their use of overlays. This sounds like a plan. I'll include that in my ballot comments. My biggest heartburn is that I'm not seeing a lot of details that separate the use cases AT THE PROTOCOL LEVEL - yeah, of course, you'd rather run compute-bound processes on real hardware, but how does that impact requirements for protocols? Spencer > Joe > > > > > I=E2=80=99ll wait for David=E2=80=99s review before I put in my ballot. > > > > Mirja > > > > > >> Am 14.01.2017 um 18:22 schrieb Joe Touch : > >> > >> David - I think it'd be useful for fresh eyes on this. IMO, it's full = of > >> vendor terminology that I don't think sufficiently differentiates the > >> data center case from any other variant of virtual network. > >> > >> This is the use case doc that purports to motivate "yet another" UDP > >> tunneling mechanism, which has generated quite a bit of controversy an= d > >> I expect would be more relevant to TSV. > >> > >> However, I'm struck by the need to publish a use case doc so soon afte= r > >> the problem statement doc (just two years ago), but that's not a TSV > issue. > >> > >> Joe > >> > >> > >> On 1/14/2017 8:09 AM, Joe Touch wrote: > >>> I've been giving them feedback for a while. > >>> > >>> Joe > >>> > >>>> On Jan 14, 2017, at 7:07 AM, Black, David > wrote: > >>>> > >>>> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd be > willing to help with a Transport review of this NVO3 use case draft. > That'll have to happen quickly, as it looks like IETF LC ended on > Wednesday, and the draft's on this week's telechat agenda. > >>>> > >>>> Joe? > >>>> > >>>> Thanks, --David > >>>> > >>>>> -----Original Message----- > >>>>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Mirja > Kuehlewind > >>>>> (IETF) > >>>>> Sent: Saturday, January 14, 2017 6:49 AM > >>>>> To: Joe Touch > >>>>> Cc: Martin Stiemerling; tsv-art@ietf.org > >>>>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents > as of 01/11 > >>>>> > >>>>> Hi Joe, > >>>>> > >>>>> I also thought that this could potentially have a transport review. > If you=E2=80=99d be able > >>>>> to send one that be great, please do so. Or what do you meant by > it=E2=80=99s already > >>>>> being watched? > >>>>> > >>>>> Mirja > >>>>> > >>>>> > >>>>>> Am 13.01.2017 um 23:09 schrieb Joe Touch : > >>>>>> > >>>>>> Hi Martin, > >>>>>> > >>>>>> I've been tracking this one for a while: > >>>>>> > >>>>>> draft-ietf-nvo3-use-case-15 > >>>>>> > >>>>>> It does have significant transport issues, but it's already being > >>>>>> watched ;-) > >>>>>> > >>>>>> Joe > >>>>>> > >>>>>> > >>>>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote: > >>>>>>> Dear TSVers, > >>>>>>> > >>>>>>> First of all, a happy new (western) year! :) > >>>>>>> > >>>>>>> I did work through all documents that are in IETF LC, IESG > processing > >>>>>>> or being requested for publication as of 01/11, 09:00 pm UTC. > >>>>>>> > >>>>>>> Please find below all documents checked and what to do with these > >>>>>>> documents. > >>>>>>> > >>>>>>> > >>>>>>> Documents that require TSV attention: > >>>>>>> none. > >>>>>>> > >>>>>>> > >>>>>>> Documents that do not require TSV attention: > >>>>>>> draft-ietf-oauth-jwsreq-09 > >>>>>>> draft-ietf-ipsecme-rfc4307bis-15 > >>>>>>> draft-ietf-geojson-text-sequence-03 > >>>>>>> draft-ietf-dime-agent-overload-08 > >>>>>>> draft-ietf-bmwg-ipv6-nd-04 > >>>>>>> draft-ietf-intarea-hostname-practice-03 > >>>>>>> draft-mohali-dispatch-cause-for-service-number-12 > >>>>>>> draft-ietf-trill-rfc6439bis-04 > >>>>>>> draft-ietf-trill-directory-assist-mechanisms-10 > >>>>>>> draft-ietf-teas-p2mp-loose-path-reopt-08 > >>>>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06 > >>>>>>> draft-ietf-sidr-rpki-oob-setup-06 > >>>>>>> draft-ietf-sidr-publication-10 > >>>>>>> draft-ietf-sidr-adverse-actions-03 > >>>>>>> draft-ietf-rtgwg-rlfa-node-protection-10 > >>>>>>> draft-ietf-mpls-residence-time-12 > >>>>>>> draft-ietf-lisp-type-iana-04 > >>>>>>> draft-ietf-ecrit-ecall-22 > >>>>>>> draft-ietf-ecrit-car-crash-21 > >>>>>>> draft-ietf-bfcpbis-bfcp-websocket-13 > >>>>>>> draft-ietf-6man-rdnss-rfc6106bis-14 > >>>>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04 > >>>>>>> draft-murchison-webdav-prefer-13 > >>>>>>> draft-ietf-dnsop-edns-key-tag-03 > >>>>>>> draft-ietf-payload-melpe-04 > >>>>>>> draft-ietf-insipid-logme-reqs-11 > >>>>>>> draft-ietf-softwire-multicast-prefix-option-11 > >>>>>>> draft-ietf-clue-rtp-mapping-10 > >>>>>>> draft-ietf-bfcpbis-sdp-ws-uri-07 > >>>>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03 > >>>>>>> draft-ietf-nvo3-use-case-15 > >>>>>>> draft-ietf-softwire-dslite-multicast-14 > >>>>>>> > >>>>>>> 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 > >>>>> _______________________________________________ > >>>>> 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 > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > --94eb2c05538209a4cd05464d17a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW,=C2=A0

On Tue, Jan 17, 2017 at 9:38 AM, Joe Touch <= ;touch@isi.edu> wrote:


On 1/17/2017 4:10 AM, Mirja Kuehlewind (IETF) wrote:
> Hi Joe,
>
> I finally read the draft myself completely. I agree that there is noth= ing in the draft that motivates a new tunnel protocol, however, the draft i= s also not (explicitly) requiring a new protocol.
>
> This says in the summary:
>
> =E2=80=9EA tunnel encapsulation protocol is necessary.=E2=80=9C
>
> which clearly doesn=E2=80=99t say that an existing one might not be su= fficient.

Good point, but it begs the question of the need for the rest of the=
document. The use cases have nothing to do uniquely with datacenters.
> I don=E2=80=99t think there is anything we can do at = this stage and with this draft=E2=80=A6

The IETF does err on the side of publishing (rather than requiring "proof of need or utility"). However, there's always the oppo= rtunity for
pushback at the higher levels, e.g., to make sure that the doc itself
indicates clearly what it does and does not contribute. E.g., it's
possible to ask for a sentence explaining exactly how this is different
from any other sort of overlay network - or stating clearly that the
conclusion is that datacenters are not unique in their use of overlays.

This sounds like a plan. I'll include that= in my ballot comments.

My biggest heartburn is th= at I'm not seeing a lot of details that separate the use cases AT THE P= ROTOCOL LEVEL - yeah, of course, you'd rather run compute-bound process= es on real hardware, but how does that impact requirements for protocols?

Spencer
=C2=A0
Joe

>
> I=E2=80=99ll wait for David=E2=80=99s review before I put in my ballot= .
>
> Mirja
>
>
>> Am 14.01.2017 um 18:22 schrieb Joe Touch <touch@isi.edu>:
>>
>> David - I think it'd be useful for fresh eyes on this. IMO, it= 's full of
>> vendor terminology that I don't think sufficiently differentia= tes the
>> data center case from any other variant of virtual network.
>>
>> This is the use case doc that purports to motivate "yet anoth= er" UDP
>> tunneling mechanism, which has generated quite a bit of controvers= y and
>> I expect would be more relevant to TSV.
>>
>> However, I'm struck by the need to publish a use case doc so s= oon after
>> the problem statement doc (just two years ago), but that's not= a TSV issue.
>>
>> Joe
>>
>>
>> On 1/14/2017 8:09 AM, Joe Touch wrote:
>>> I've been giving them feedback for a while.
>>>
>>> Joe
>>>
>>>> On Jan 14, 2017, at 7:07 AM, Black, David <David.Black@dell.com> wrote:
>>>>
>>>> As one of the authors of the NVO3 architecture RFC, RFC 80= 14, I'd be willing to help with a Transport review of this NVO3 use cas= e draft.=C2=A0 That'll have to happen quickly, as it looks like IETF LC= ended on Wednesday, and the draft's on this week's telechat agenda= .
>>>>
>>>> Joe?
>>>>
>>>> Thanks, --David
>>>>
>>>>> -----Original Message-----
>>>>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Mirja Kuehlewin= d
>>>>> (IETF)
>>>>> Sent: Saturday, January 14, 2017 6:49 AM
>>>>> To: Joe Touch
>>>>> Cc: Martin Stiemerling; tsv-art@ietf.org
>>>>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF= LC documents as of 01/11
>>>>>
>>>>> Hi Joe,
>>>>>
>>>>> I also thought that this could potentially have a tran= sport review. If you=E2=80=99d be able
>>>>> to send one that be great, please do so. Or what do yo= u meant by it=E2=80=99s already
>>>>> being watched?
>>>>>
>>>>> Mirja
>>>>>
>>>>>
>>>>>> Am 13.01.2017 um 23:09 schrieb Joe Touch <touch@isi.edu>:
>>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> I've been tracking this one for a while:
>>>>>>
>>>>>> draft-ietf-nvo3-use-case-15
>>>>>>
>>>>>> It does have significant transport issues, but it&= #39;s already being
>>>>>> watched ;-)
>>>>>>
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote= :
>>>>>>> Dear TSVers,
>>>>>>>
>>>>>>> First of all, a happy new (western) year! :) >>>>>>>
>>>>>>> I did work through all documents that are in I= ETF LC, IESG processing
>>>>>>> or being requested for publication as of 01/11= , 09:00 pm UTC.
>>>>>>>
>>>>>>> Please find below all documents checked and wh= at to do with these
>>>>>>> documents.
>>>>>>>
>>>>>>>
>>>>>>> Documents that require TSV attention:
>>>>>>> none.
>>>>>>>
>>>>>>>
>>>>>>> Documents that do not require TSV attention: >>>>>>> draft-ietf-oauth-jwsreq-09
>>>>>>> draft-ietf-ipsecme-rfc4307bis-15
>>>>>>> draft-ietf-geojson-text-sequence-03
>>>>>>> draft-ietf-dime-agent-overload-08
>>>>>>> draft-ietf-bmwg-ipv6-nd-04
>>>>>>> draft-ietf-intarea-hostname-practice-03 >>>>>>> draft-mohali-dispatch-cause-for-service-n= umber-12
>>>>>>> draft-ietf-trill-rfc6439bis-04
>>>>>>> draft-ietf-trill-directory-assist-mechani= sms-10
>>>>>>> draft-ietf-teas-p2mp-loose-path-reopt-08<= br> >>>>>>> draft-ietf-teas-gmpls-resource-sharing-pr= oc-06
>>>>>>> draft-ietf-sidr-rpki-oob-setup-06
>>>>>>> draft-ietf-sidr-publication-10
>>>>>>> draft-ietf-sidr-adverse-actions-03
>>>>>>> draft-ietf-rtgwg-rlfa-node-protection-10<= br> >>>>>>> draft-ietf-mpls-residence-time-12
>>>>>>> draft-ietf-lisp-type-iana-04
>>>>>>> draft-ietf-ecrit-ecall-22
>>>>>>> draft-ietf-ecrit-car-crash-21
>>>>>>> draft-ietf-bfcpbis-bfcp-websocket-13
>>>>>>> draft-ietf-6man-rdnss-rfc6106bis-14
>>>>>>> draft-holmberg-dispatch-mcptt-rp-namespac= e-04
>>>>>>> draft-murchison-webdav-prefer-13
>>>>>>> draft-ietf-dnsop-edns-key-tag-03
>>>>>>> draft-ietf-payload-melpe-04
>>>>>>> draft-ietf-insipid-logme-reqs-11
>>>>>>> draft-ietf-softwire-multicast-prefix-opti= on-11
>>>>>>> draft-ietf-clue-rtp-mapping-10
>>>>>>> draft-ietf-bfcpbis-sdp-ws-uri-07
>>>>>>> draft-ietf-dhc-dhcpv6-failover-protocol-0= 3
>>>>>>> draft-ietf-nvo3-use-case-15
>>>>>>> draft-ietf-softwire-dslite-multicast-14 >>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> _________________________________________= ______
>>>>>>> Tsv-art mailing list
>>>>>>> Tsv-art@ie= tf.org
>>>>>>> https://www.ietf.org/mailm= an/listinfo/tsv-art
>>>>>> _____________________________________________= __
>>>>>> Tsv-art mailing list
>>>>>> Tsv-art@ietf.o= rg
>>>>>> https://www.ietf.org/mailman/<= wbr>listinfo/tsv-art
>>>>> _______________________________________________ >>>>> 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

_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art<= br>

--94eb2c05538209a4cd05464d17a3-- From nobody Tue Jan 17 14:04:32 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 3E1BE1295D0 for ; Tue, 17 Jan 2017 14:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.846 X-Spam-Level: X-Spam-Status: No, score=-3.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=zNisC4Nu; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=Rl51olT7 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 MMWuZL0MSaCa for ; Tue, 17 Jan 2017 14:04:28 -0800 (PST) Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (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 F03021294E9 for ; Tue, 17 Jan 2017 14:04:27 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: MIME-Version:X-Sentrion-Hostname:X-RSA-Classifications; b=FMvqk6j3J1lILxdiY4AQgfNq5PfoHKR2ygrhmXkysgXKCQSgWtB2p6rg xPqS1V87LZGL/vEH7C9j72F/wkvNJkStJQXxKeSMlQYKZRMDckOhs21qC rF8BWtd7YWCB4SFnZsM8IZw/I1iDR9tdR/oyFDpafP+J5CiEuGrV7Fj2P c=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1484690667; x=1516226667; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=PlHCpAt5jlCWm8VCqWDm781Zo/fPFLgVMTw+jLAPMus=; b=zNisC4NuT4tZsLpCbqtRtr9SKE0et0apvjqMVQnrT6zQE22+l4WGHglq rnxQQjYca6TuYeDiQDylEr4fUgJeh9nA00unRWN97Nj4aGUwjRDP3OwsY PAf9F6AY9mCWesQhQ8pAMrST2nScPh28oaxg3OgKDJI5qGaom8S3HLgxC 0=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 16:04:27 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 04:04:26 +0600 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0HM4Otu001076 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Jan 2017 17:04:26 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v0HM4Otu001076 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1484690666; bh=lyPunpDLuWIctioSq+dSgQGxOvY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Rl51olT7NaNR7T3hjQD/d4PDNG49nO2fpQCaPzwPmcHeJB2kM2VZh5o97X0dnxyew EeXS9PFayePbV0qNUbbYZDRo3ZX4DCoH3Qhb8+RfOc/Vc+1AR5AZ+VYL5tLz8l8dIu /4Y6RehyL5yXu71JHYIzXQPhtZsdNRhQqca33Rqs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v0HM4Otu001076 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd54.lss.emc.com (RSA Interceptor); Tue, 17 Jan 2017 17:03:57 -0500 Received: from MXHUB302.corp.emc.com (MXHUB302.corp.emc.com [10.146.3.28]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0HM4AV7014195 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 17 Jan 2017 17:04:11 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB302.corp.emc.com ([10.146.3.28]) with mapi id 14.03.0266.001; Tue, 17 Jan 2017 17:04:10 -0500 To: Joe Touch Thread-Topic: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 Thread-Index: AQHSboC1a4J+V6O510Cup0rArafOQKE4jFeA///AJAiAAGM9gIAEjFDA Date: Tue, 17 Jan 2017 22:04:10 +0000 Message-ID: References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> <30599C28-08A3-4146-BB8D-116B864574EB@isi.edu> <65b73a6b-dadc-89ec-bf84-adba0a6b7ca7@isi.edu> <1e92262c-36f5-c173-e988-debc1c49e651@isi.edu> In-Reply-To: <1e92262c-36f5-c173-e988-debc1c49e651@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F7D8BFEMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Martin Stiemerling , "Black, David" , "Mirja Kuehlewind \(IETF\)" , "tsv-art@ietf.org" Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:04:31 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F7D8BFEMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm working on the review now. I concur with Joe's observation that the terminology situation is "a fault = of the entire WG" - one of the primary causes was the original AD decision = (at WG formation time) to force the WG's scope to span both MAC-in-IP encap= sulations like VXLAN and MPLS encapsulations like L3VPN, making it necessar= y to use neutral terminology that is not native to either of the underlay n= etwork technology domains ... and later on, both LISP and L2VPN joined the = adventure ... Subsequently, Alia dramatically cut back the scope of the NVO3 WG to {MAC,I= P}-in-IP virtual network encapsulations in the hope of enabling the WG to a= ctually do something useful ... but by then, the die was cast on terminolog= y. Thanks, --David From: Joe Touch [mailto:touch@isi.edu] Sent: Saturday, January 14, 2017 2:29 PM To: Black, David Cc: Mirja Kuehlewind (IETF); Martin Stiemerling; tsv-art@ietf.org Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 0= 1/11 I'm not a fan of using human administrative, political, or economic boundar= y terms as if they had any meaning in a network architecture. Tenant system, VM, vGW, and even DC (or NVO3 for that matter) are insuffici= ently defined, IMO. But that's a fault of the entire WG, not just this doc. This leads to gibberis (IMO) like: One NVO3 network can provide connectivity to many TSs that attach to many different NVEs in a DC. TS dynamic placement and mobility results in frequent changes of the binding between a TS and an NVE. This doc boils down to "overlays are useful in data centers". Why wouldn't = they be? How are data centers different (they really aren't, except that so= me fall into the class of "managed subnetworks" that can use custom setting= s). I really don't see the need for this doc at all. Joe On 1/14/2017 10:33 AM, Black, David wrote: Joe, I'll take another look at this draft before the telechat. The NVO3 WG is pu= blishing this use case draft now in part because they badly lost their way = over the past couple of years :-(. I have not been a fan of this draft in t= he WG, but I don't fundamentally object to its publication. Could you provide a few examples of terminology in the draft that you view = as problematic? Thanks, --David ... Sent from my Android not-so-smartphone. -------- Original message -------- From: Joe Touch Date: 1/14/17 9:23 AM (GMT-08:00) To: "Black, David" Cc: "Mirja Kuehlewind (IETF)" , Martin Stiemerling , t= sv-art@ietf.org Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 0= 1/11 David - I think it'd be useful for fresh eyes on this. IMO, it's full of vendor terminology that I don't think sufficiently differentiates the data center case from any other variant of virtual network. This is the use case doc that purports to motivate "yet another" UDP tunneling mechanism, which has generated quite a bit of controversy and I expect would be more relevant to TSV. However, I'm struck by the need to publish a use case doc so soon after the problem statement doc (just two years ago), but that's not a TSV issue. Joe On 1/14/2017 8:09 AM, Joe Touch wrote: > I've been giving them feedback for a while. > > Joe > >> On Jan 14, 2017, at 7:07 AM, Black, David wrote: >> >> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd be wil= ling to help with a Transport review of this NVO3 use case draft. That'll = have to happen quickly, as it looks like IETF LC ended on Wednesday, and th= e draft's on this week's telechat agenda. >> >> Joe? >> >> Thanks, --David >> >>> -----Original Message----- >>> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Mirja Kueh= lewind >>> (IETF) >>> Sent: Saturday, January 14, 2017 6:49 AM >>> To: Joe Touch >>> Cc: Martin Stiemerling; tsv-art@ietf.org >>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as = of 01/11 >>> >>> Hi Joe, >>> >>> I also thought that this could potentially have a transport review. If = you'd be able >>> to send one that be great, please do so. Or what do you meant by it's a= lready >>> being watched? >>> >>> Mirja >>> >>> >>>> Am 13.01.2017 um 23:09 schrieb Joe Touch : >>>> >>>> Hi Martin, >>>> >>>> I've been tracking this one for a while: >>>> >>>> draft-ietf-nvo3-use-case-15 >>>> >>>> It does have significant transport issues, but it's already being >>>> watched ;-) >>>> >>>> Joe >>>> >>>> >>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote: >>>>> Dear TSVers, >>>>> >>>>> First of all, a happy new (western) year! :) >>>>> >>>>> I did work through all documents that are in IETF LC, IESG processing >>>>> or being requested for publication as of 01/11, 09:00 pm UTC. >>>>> >>>>> Please find below all documents checked and what to do with these >>>>> documents. >>>>> >>>>> >>>>> Documents that require TSV attention: >>>>> none. >>>>> >>>>> >>>>> Documents that do not require TSV attention: >>>>> draft-ietf-oauth-jwsreq-09 >>>>> draft-ietf-ipsecme-rfc4307bis-15 >>>>> draft-ietf-geojson-text-sequence-03 >>>>> draft-ietf-dime-agent-overload-08 >>>>> draft-ietf-bmwg-ipv6-nd-04 >>>>> draft-ietf-intarea-hostname-practice-03 >>>>> draft-mohali-dispatch-cause-for-service-number-12 >>>>> draft-ietf-trill-rfc6439bis-04 >>>>> draft-ietf-trill-directory-assist-mechanisms-10 >>>>> draft-ietf-teas-p2mp-loose-path-reopt-08 >>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06 >>>>> draft-ietf-sidr-rpki-oob-setup-06 >>>>> draft-ietf-sidr-publication-10 >>>>> draft-ietf-sidr-adverse-actions-03 >>>>> draft-ietf-rtgwg-rlfa-node-protection-10 >>>>> draft-ietf-mpls-residence-time-12 >>>>> draft-ietf-lisp-type-iana-04 >>>>> draft-ietf-ecrit-ecall-22 >>>>> draft-ietf-ecrit-car-crash-21 >>>>> draft-ietf-bfcpbis-bfcp-websocket-13 >>>>> draft-ietf-6man-rdnss-rfc6106bis-14 >>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04 >>>>> draft-murchison-webdav-prefer-13 >>>>> draft-ietf-dnsop-edns-key-tag-03 >>>>> draft-ietf-payload-melpe-04 >>>>> draft-ietf-insipid-logme-reqs-11 >>>>> draft-ietf-softwire-multicast-prefix-option-11 >>>>> draft-ietf-clue-rtp-mapping-10 >>>>> draft-ietf-bfcpbis-sdp-ws-uri-07 >>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03 >>>>> draft-ietf-nvo3-use-case-15 >>>>> draft-ietf-softwire-dslite-multicast-14 >>>>> >>>>> 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 >>> _______________________________________________ >>> Tsv-art mailing list >>> Tsv-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/tsv-art --_000_CE03DB3D7B45C245BCA0D243277949362F7D8BFEMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m working on the = review now.

 <= /p>

I concur with Joe’s= observation that the terminology situation is “a fault of the entire= WG” - one of the primary causes was the original AD decision (at WG formation time) to force the WG’s scope to span both MAC-in-IP encap= sulations like VXLAN and MPLS encapsulations like L3VPN, making it necessar= y to use neutral terminology that is not native to either of the underlay n= etwork technology domains ... and later on, both LISP and L2VPN joined the adventure ...

 <= /p>

Subsequently, Alia dramat= ically cut back the scope of the NVO3 WG to {MAC,IP}-in-IP virtual network = encapsulations in the hope of enabling the WG to actually do something useful ... but by then, the die was cast on terminology.=

 <= /p>

Thanks, --David

 <= /p>

From: Joe Touch [mailto:touch@isi.edu]
Sent: Saturday, January 14, 2017 2:29 PM
To: Black, David
Cc: Mirja Kuehlewind (IETF); Martin Stiemerling; tsv-art@ietf.org Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents = as of 01/11

 

I'm not a fan of using human administrative, political, or economic boun= dary terms as if they had any meaning in a network architecture.=

Tenant system, VM, vGW, and even DC (or NVO3 for tha= t matter) are insufficiently defined, IMO. But that's a fault of the entire= WG, not just this doc.

This leads to gibberis (IMO) like:

  One NVO3 network can provide connectivity to many TSs that atta=
ch to
  many different NVEs in a DC. TS dynamic placement and mobility<=
o:p>
  results in frequent changes of the binding between a TS and an =
NVE.

This doc boils down to "overlays are useful in = data centers". Why wouldn't they be? How are data centers different (t= hey really aren't, except that some fall into the class of "managed su= bnetworks" that can use custom settings).

I really don't see the need for this doc at all.

Joe

 

On 1/14/2017 10:33 AM, Black, David wrote:

Joe, 

 

I'll take another look at this draft before the tele= chat. The NVO3 WG is publishing this use case draft now in part because the= y badly lost their way over the past couple of years :-(. I have not been a= fan of this draft in the WG, but I don't fundamentally object to its publication. 

 

Could you provide a few examples of terminology in t= he draft that you view as problematic? 

 

Thank= s, --David ... Sent from my Android not-so-smartphone.

 

 

-------- Original message --------

From: Joe Touch <= ;touch@isi.edu>

Date: 1/14/17 9:23 AM (GMT-08:00)

To: "Black, David" <david.black@emc.com>

Cc: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, Martin Stiemerling <mls.ietf@gmail.com>, tsv-art= @ietf.org

Subject: Re: [Tsv-art] TSV Triage team: Review of IE= TF LC documents as of 01/11

 

David - I think it'd be useful for fresh eyes on this. IMO, it'= s full of
vendor terminology that I don't think sufficiently differentiates the
data center case from any other variant of virtual network.

This is the use case doc that purports to motivate "yet another" = UDP
tunneling mechanism, which has generated quite a bit of controversy and
I expect would be more relevant to TSV.

However, I'm struck by the need to publish a use case doc so soon after
the problem statement doc (just two years ago), but that's not a TSV issue.=

Joe


On 1/14/2017 8:09 AM, Joe Touch wrote:
> I've been giving them feedback for a while.
>
> Joe
>
>> On Jan 14, 2017, at 7:07 AM, Black, David <David.Black@dell.com> wrote:
>>
>> As one of the authors of the NVO3 architecture RFC, RFC 8014, I'd = be willing to help with a Transport review of this NVO3 use case draft.&nbs= p; That'll have to happen quickly, as it looks like IETF LC ended on Wednes= day, and the draft's on this week's telechat agenda.
>>
>> Joe?
>>
>> Thanks, --David
>>
>>> -----Original Message-----
>>> From: Tsv-art [mai= lto:tsv-art-bounces@ietf.org] On Behalf Of Mirja Kuehlewind
>>> (IETF)
>>> Sent: Saturday, January 14, 2017 6:49 AM
>>> To: Joe Touch
>>> Cc: Martin Stiemerling; ts= v-art@ietf.org
>>> Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC docu= ments as of 01/11
>>>
>>> Hi Joe,
>>>
>>> I also thought that this could potentially have a transport re= view. If you’d be able
>>> to send one that be great, please do so. Or what do you meant = by it’s already
>>> being watched?
>>>
>>> Mirja
>>>
>>>
>>>> Am 13.01.2017 um 23:09 schrieb Joe Touch <touch@isi.edu>:
>>>>
>>>> Hi Martin,
>>>>
>>>> I've been tracking this one for a while:
>>>>
>>>> draft-ietf-nvo3-use-case-15
>>>>
>>>> It does have significant transport issues, but it's alread= y being
>>>> watched ;-)
>>>>
>>>> Joe
>>>>
>>>>
>>>>> On 1/11/2017 1:52 PM, Martin Stiemerling wrote:
>>>>> Dear TSVers,
>>>>>
>>>>> First of all, a happy new (western) year! :)
>>>>>
>>>>> I did work through all documents that are in IETF LC, = IESG processing
>>>>> or being requested for publication as of 01/11, 09:00 = pm UTC.
>>>>>
>>>>> Please find below all documents checked and what to do= with these
>>>>> documents.
>>>>>
>>>>>
>>>>> Documents that require TSV attention:
>>>>> none.
>>>>>
>>>>>
>>>>> Documents that do not require TSV attention:
>>>>> draft-ietf-oauth-jwsreq-09
>>>>> draft-ietf-ipsecme-rfc4307bis-15
>>>>> draft-ietf-geojson-text-sequence-03
>>>>> draft-ietf-dime-agent-overload-08
>>>>> draft-ietf-bmwg-ipv6-nd-04
>>>>> draft-ietf-intarea-hostname-practice-03
>>>>> draft-mohali-dispatch-cause-for-service-number-12
>>>>> draft-ietf-trill-rfc6439bis-04
>>>>> draft-ietf-trill-directory-assist-mechanisms-10
>>>>> draft-ietf-teas-p2mp-loose-path-reopt-08
>>>>> draft-ietf-teas-gmpls-resource-sharing-proc-06
>>>>> draft-ietf-sidr-rpki-oob-setup-06
>>>>> draft-ietf-sidr-publication-10
>>>>> draft-ietf-sidr-adverse-actions-03
>>>>> draft-ietf-rtgwg-rlfa-node-protection-10
>>>>> draft-ietf-mpls-residence-time-12
>>>>> draft-ietf-lisp-type-iana-04
>>>>> draft-ietf-ecrit-ecall-22
>>>>> draft-ietf-ecrit-car-crash-21
>>>>> draft-ietf-bfcpbis-bfcp-websocket-13
>>>>> draft-ietf-6man-rdnss-rfc6106bis-14
>>>>> draft-holmberg-dispatch-mcptt-rp-namespace-04
>>>>> draft-murchison-webdav-prefer-13
>>>>> draft-ietf-dnsop-edns-key-tag-03
>>>>> draft-ietf-payload-melpe-04
>>>>> draft-ietf-insipid-logme-reqs-11
>>>>> draft-ietf-softwire-multicast-prefix-option-11
>>>>> draft-ietf-clue-rtp-mapping-10
>>>>> draft-ietf-bfcpbis-sdp-ws-uri-07
>>>>> draft-ietf-dhc-dhcpv6-failover-protocol-03
>>>>> draft-ietf-nvo3-use-case-15
>>>>> draft-ietf-softwire-dslite-multicast-14
>>>>>
>>>>> 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
>>> _______________________________________________
>>> Tsv-art mailing list
>>> Tsv-art@ietf.org
>>> http= s://www.ietf.org/mailman/listinfo/tsv-art

 

--_000_CE03DB3D7B45C245BCA0D243277949362F7D8BFEMX307CL04corpem_-- From nobody Tue Jan 17 15:57:32 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 40376129408; Tue, 17 Jan 2017 15:57:27 -0800 (PST) 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); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=OeQDB6Ai; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=v5clMmdi 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 DuH4qYJeNvqw; Tue, 17 Jan 2017 15:57:25 -0800 (PST) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 3440A1293EB; Tue, 17 Jan 2017 15:57:25 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:Content-Type:Content-Transfer-Encoding: MIME-Version:X-Sentrion-Hostname:X-RSA-Classifications; b=pn7CgD9DZtLuJnTukSQ/qC0akOWFccix+ydHRqDSQF8IaWfq1hN2pk5y fMGD1T2xlmpHSZixejzEoxeas5twAnJIYqHa2OuuuJV43jD60OhrWVIXX KfVcwl1W6lbWuzvaXXX8Av88hYIyoqPxrgNuFkwGw0OXbW/q1jLSYYIXy w=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1484697445; x=1516233445; h=from:cc:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2TvTF0lAnEzr7wcfu7osUSXPdRDN19kgpS3SmWJP6PQ=; b=OeQDB6Ai5njEirBTWJ1OrpIwHhFI4on2S4Tsi7NJXfhpiqj/Pdulap6T uvT6wiXC4jlELnEmPWwtf6NpcswxZljDQLzYH2VQzFRYXEzn4eKtz4k5F wcqoYHadFTPPjubIt4p14cC1RjRlpjqgULEjPJ/d2x6E3clKTyabkLkhg U=; Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 17:57:24 -0600 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 05:57:24 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0HNvMRh005276 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Jan 2017 18:57:23 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v0HNvMRh005276 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1484697443; bh=W1NDpmTeMXvQ4yj+WVTViy+xcu0=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=v5clMmdifokBphDXiJecDSrwLx/SAFHWlmESOWzy76/SO6LMIUpoeoSyj6CMG1Ftl CuSSdLf1rtTUWHUIR90Us65DhOaukhI4Yo1wMS1M2AMygoSWRMdcxX8QKgmY7W0++y JW/ttnQl583nji4/e5Lf17pR3xt0DNstK5DYIAF8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v0HNvMRh005276 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd01.lss.emc.com (RSA Interceptor); Tue, 17 Jan 2017 18:56:33 -0500 Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0HNrXdL031750 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 17 Jan 2017 18:57:10 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Tue, 17 Jan 2017 18:55:44 -0500 To: "tsv-art@ietf.org" , The IESG Thread-Topic: TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 Thread-Index: AdJxHTT9+9vVjDKxS3qqR8JNKwRL+A== Date: Tue, 17 Jan 2017 23:55:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "nvo3@ietf.org" , "Black, David" Subject: [Tsv-art] TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 23:57:27 -0000 Document: draft-ietf-nvo3-use-case-15 Reviewer: David Black Review Date: January 17, 2017 IETF LC End Date: January 11, 2017 IESG Telechat date: January 19, 2017 Review result: Has Issues I've reviewed this document as part of TSV-ART's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. Please always CC tsv-art at ietf.org if you reply to or forward this review. This draft describes use cases for Data-Center Network Virtualization over Layer 3 (NVO3) technology being worked on the NVO3 WG. I should apologize for this review coming relatively late - the desirabilit= y of a TSV-ART review of this draft was not discovered until after IETF Last Call had concluded, and actually not until after an initial TSV-ART decisio= n had been made to not review this draft. In the spirit of full disclosure, I have been an active member of the NVO3 WG, and an author of two of its three published RFCs, RFC 7364 and RFC 8014. I have not seen much value in this use case draft, and for that reason I did not carefully review it in the WG. I have no fundamental objection to RFC publication of this draft, but having reviewed it in detai= l now, I believe it needs some serious attention before being approved for RFC publication, and hope that the IESG concurs. -- TSV-ART review comments: [T-1] There's one minor transport issue in this draft that requires correct= ion in Section 2. Basic NVO3 Networks: The TS reachability update mechanisms need be fast enough so that the updates do not cause any communication disruption/interruption. That requirement is overstated. NVO3 technology can and does disrupt communication by dropping packets when a TS (e.g., a virtual machine) moves to a different network attachment point (i.e., NVE). This requirement should be restated in terms of disruption to transport protocols - it's ok to drop a packet or two thereby causing a TCP or SCTP retransmission, but dropping enough packets to cause termination of a TCP connection or SCTP association is clearly unacceptable. In contrast, UDP-based applications will see packet drops in this (and othe= r) scenarios, but avoidance of that is not an NVO3 goal - while the U in UDP does not stand for Unreliable, in NVO3 context, this is a good way to think about that letter :-). -- Other review comments - Major Issue [A] Section 2 of the draft is a problem. While Section 1 characterizes Section 2 as describing a use case referred to as "DC East-West traffic," t= hat use case is not to be found in Section 2 (e.g., nothing in Section 2 appear= s to distinguish East-West traffic from North-South traffic). In its current form, Section 2 is really an NVO3 Background section, as it describes NVO3 terminology in general terms - while it uses different text, nearly all of the material that it contains can be found elsewhere, e.g., RFC 8014 on NVO3 Architecture (NB: This reviewer is an author of RFC 8014). Section 2's title should be changed to "NVO3 Background" or something similar, and Section 1 changed accordingly. - Minor issues [1] The draft's use of the term "NVO3 network" is sloppy and imprecise. This is actually an NVO3 Virtual Network or VN - the word "virtual" should be inserted in all cases. [2] This text in section 3 is vague on what a VPN is: This, in turn, becomes the case of interconnecting an NVO3 network and the virtual private network (VPN) on the Internet or wide-area networks (WAN). Note that a VPN is not implemented by NVO3 solution. By itself, the latter sentence is incorrect, however, reading onward, one discovers that not all forms of VPNs are intended - section 3.1 uses an IPsec VPN, and section 3.2 uses a BGP/MPLS L3VPN. I would suggest deleting the second sentence and rewriting the first to use these two technologies as an example, e.g.: WAN connectivity to the virtual gateway can be provided by VPN technologies such as IPsec VPNs [RFC4301] and BGP/MPLS IP VPNs [RFC 4364]. [3] The first paragraph in section 3.2 is very hard to understand for someo= ne who is not already an expert in BGP/MPLS VPNs (RFC 4364 & RFC 7432) - e.g., it contains many unexpanded acronyms from that domain - ASBR, PE, SP, etc., none of which appear in this draft's terminology section. It is not reason= able for a general use case draft such as this to assume that degree of expertis= e in another technical domain. [4] As written, this sentence in Section 4.2 is incorrect: As a result, a tunnel carrying NVO3 network traffic must be terminated at the GW/firewall where the NVO3 traffic is processed. as there are deployed "running code" counterexamples. The underlying problem appears to be that the use case in section 4.2 inclu= des an implicit, but unstated, requirement for physical network segmentation/ isolation via physical GW/firewall network nodes. That requirement needs t= o be stated, and I suggest changing the section title to somehow convey this physical segmentation/isolation requirement. - Editorial In Section 1. Introduction: The goal of data center network virtualization overlay (NVO3) networks is to decouple the communication among tenant systems from DC physical infrastructure networks and to allow one physical network infrastructure: Pluralize and edit to "The goals of ... are ... infrastructure to:" and edi= t the bulleted list so that each list item is a grammatically correct completion of this sentence in the singular (i.e., "The goal of ... is to:"= ). The paragraph about gateways in the Introduction ("An NVO3 network may interconnect ..." seems out of place - try moving it to somewhere in Section 2, e.g., so that it comes after the definition of the vGW acronym in the terminology section. In Section 1.1 Terminology: - DMZ definition should use the relative terms "more trusted" and "less trusted" in place of the absolute terms "trusted" and "untrusted" - In DC Operator definition: "A role who" -> "An entity that" That wording should also be used instead of "A company that" in the definition of DC Provider. Some usage of NVO3 terminology, while correct, makes this draft less accessible to those not familiar with the NVO3 WG. TS (Tenant System) is a particular problem although this sentence near the start of Section 2 that introduces the term is fine: A TS can be a physical server/device or a virtual machine (VM) on a server, i.e., end-device [RFC7365]. I would suggest that the draft be written in terms of Virtual Machines beyond this point, with a sentence added after the above sentence to say that the draft is written in terms of virtual machines as a motivating example of TSs for clarity, but the use cases apply to TSs in general, not just VMs. In section 4.1, use "physical servers" instead of "metal servers." The latter isn't even a good term - "bare metal servers" was probably intended, but "physical servers" is the better term. In section 5 Summary, remove the following paragraph: DC services may vary, from infrastructure as a service (IaaS), to platform as a service (PaaS), to software as a service (SaaS). In these services, NVO3 networks are just a portion of such services. as those *aaS terms occur nowhere else in the draft, and hence this text doesn't summarize any prior material. Thanks, --David -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- From nobody Tue Jan 17 16:07:42 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 2E0A812711D for ; Tue, 17 Jan 2017 16:07:41 -0800 (PST) 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); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=X/jXE7Rw; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=CyZapVKQ 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 gnagYbOkLpBm for ; Tue, 17 Jan 2017 16:07:39 -0800 (PST) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 34E6D127A90 for ; Tue, 17 Jan 2017 16:07:39 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=FpA88ncdVOwyNyHaiWWlV+E0/wHlUzkSzLs0/FaYKu28G9+r3lwD/g4R 0wtk9cqSv0xXEC1xRMkUjYtRcAM/+AJsv7fKc53ZuMcHS+gsg0Eqs0H9l q3S2YLGafYIhZOCCVJmxfIA6EMHQtmeP4m72N4y2yoSMdgud3LqzOnVTS Q=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1484698059; x=1516234059; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vYkROI9XvbFQ6oXpx5JOZXYSd80xJOSzHyup1gRdRpE=; b=X/jXE7RwF1FV7zSkQbZ1uYk6v1w2MXPJRD04kyj1bUpPVbmHXRzxXAoL bbbTnkwxSsF8su2zk2aApJYZjwHLhgS+MulzZvQPUUxiJQdCpftAjJNmI kgUJc1yd6rPITBpHqUrIYTNVkHxPsrEeiE7OAw56BXd98DfbDYZ5+x/74 I=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2017 18:07:38 -0600 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 05:59:56 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0I07bVP007332 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 17 Jan 2017 19:07:37 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v0I07bVP007332 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1484698057; bh=6XiHlKczCX9x2uQtSIm4Jp6DT5U=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=CyZapVKQE248wlqCUnI4hhpGrX9I0YwvZETb9bsVw2GrWPenyI0fmpvHSvjdZwQqw vKP2vbVwhtrCy6NhlPaek3l0UZCPNO0Z5btlVmF6TY+QGNdcXAURfTcfuP6KxQo5oB jTtJVxCrBF0zwnrhjPBxfrVPF1OqZFCE6JxsIe/I= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v0I07bVP007332 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd01.lss.emc.com (RSA Interceptor) for ; Tue, 17 Jan 2017 19:06:45 -0500 Received: from MXHUB308.corp.emc.com (MXHUB308.corp.emc.com [10.146.3.34]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0I07Mmc031691 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Tue, 17 Jan 2017 19:07:22 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB308.corp.emc.com ([10.146.3.34]) with mapi id 14.03.0266.001; Tue, 17 Jan 2017 19:07:22 -0500 To: "tsv-art@ietf.org" Thread-Topic: TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 Thread-Index: AdJxHTT9+9vVjDKxS3qqR8JNKwRL+AAADZdQ Date: Wed, 18 Jan 2017 00:07:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" Subject: Re: [Tsv-art] TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 00:07:41 -0000 Ok, I've completed and sent the review of this draft. One of the ADs will = need to put that review into the datatracker, which currently indicates tha= t TSV-ART will not review this draft ;-). I only found one minor transport= issue (incorrect requirement on communication disruption/interruption) ...= but ... I also found a major issue (one of the three use case categories is effecti= vely missing), and a number of minor issues. On terminology, we (the IETF) are stuck with a lot of it, but I did complai= n about TS (Tenant System) and suggest that the draft be mostly rewritten i= n terms of Virtual Machines (VMs). That should help some with clarity and = seems (IMHO) to be about the limit of what's reasonable, aside from pointin= g out that the section on use of BGP/MPLS VPNs is almost incomprehensible t= o those who aren't already familiar with them. Enjoy ;-), --David > -----Original Message----- > From: Black, David > Sent: Tuesday, January 17, 2017 6:56 PM > To: tsv-art@ietf.org; The IESG > Cc: nvo3@ietf.org; Black, David > Subject: TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 >=20 > Document: draft-ietf-nvo3-use-case-15 > Reviewer: David Black > Review Date: January 17, 2017 > IETF LC End Date: January 11, 2017 > IESG Telechat date: January 19, 2017 >=20 > Review result: Has Issues >=20 > I've reviewed this document as part of TSV-ART's ongoing effort to > review key IETF documents. These comments were written primarily for > the transport area directors, but are copied to the document's authors > for their information and to allow them to address any issues raised. > Please always CC tsv-art at ietf.org if you reply to or forward this > review. >=20 > This draft describes use cases for Data-Center Network Virtualization ove= r > Layer 3 (NVO3) technology being worked on the NVO3 WG. >=20 > I should apologize for this review coming relatively late - the desirabil= ity > of a TSV-ART review of this draft was not discovered until after IETF Las= t > Call had concluded, and actually not until after an initial TSV-ART decis= ion > had been made to not review this draft. >=20 > In the spirit of full disclosure, I have been an active member of the NVO= 3 > WG, and an author of two of its three published RFCs, RFC 7364 and RFC > 8014. I have not seen much value in this use case draft, and for that > reason I did not carefully review it in the WG. I have no fundamental > objection to RFC publication of this draft, but having reviewed it in det= ail > now, I believe it needs some serious attention before being approved for > RFC publication, and hope that the IESG concurs. >=20 > -- TSV-ART review comments: >=20 > [T-1] There's one minor transport issue in this draft that requires corre= ction > in Section 2. Basic NVO3 Networks: >=20 > The TS reachability update mechanisms need be fast enough so that > the updates do not cause any communication disruption/interruption. >=20 > That requirement is overstated. NVO3 technology can and does disrupt > communication by dropping packets when a TS (e.g., a virtual machine) > moves to a different network attachment point (i.e., NVE). >=20 > This requirement should be restated in terms of disruption to transport > protocols - it's ok to drop a packet or two thereby causing a TCP or SCTP > retransmission, but dropping enough packets to cause termination of > a TCP connection or SCTP association is clearly unacceptable. > In contrast, UDP-based applications will see packet drops in this (and ot= her) > scenarios, but avoidance of that is not an NVO3 goal - while the U in UDP > does not stand for Unreliable, in NVO3 context, this is a good way to > think about that letter :-). >=20 > -- Other review comments >=20 > - Major Issue >=20 > [A] Section 2 of the draft is a problem. While Section 1 characterizes > Section 2 as describing a use case referred to as "DC East-West traffic,"= that > use case is not to be found in Section 2 (e.g., nothing in Section 2 appe= ars > to distinguish East-West traffic from North-South traffic). In its curre= nt > form, Section 2 is really an NVO3 Background section, as it describes > NVO3 terminology in general terms - while it uses different text, nearly > all of the material that it contains can be found elsewhere, e.g., RFC 80= 14 > on NVO3 Architecture (NB: This reviewer is an author of RFC 8014). Secti= on > 2's title should be changed to "NVO3 Background" or something similar, > and Section 1 changed accordingly. >=20 > - Minor issues >=20 > [1] The draft's use of the term "NVO3 network" is sloppy and imprecise. > This is actually an NVO3 Virtual Network or VN - the word "virtual" > should be inserted in all cases. >=20 > [2] This text in section 3 is vague on what a VPN is: >=20 > This, in turn, > becomes the case of interconnecting an NVO3 network and the virtual > private network (VPN) on the Internet or wide-area networks (WAN). > Note that a VPN is not implemented by NVO3 solution. >=20 > By itself, the latter sentence is incorrect, however, reading onward, one > discovers that not all forms of VPNs are intended - section 3.1 uses an > IPsec VPN, and section 3.2 uses a BGP/MPLS L3VPN. I would suggest > deleting the second sentence and rewriting the first to use these two > technologies as an example, e.g.: >=20 > WAN connectivity to the virtual gateway can be provided by VPN > technologies such as IPsec VPNs [RFC4301] and BGP/MPLS IP > VPNs [RFC 4364]. >=20 > [3] The first paragraph in section 3.2 is very hard to understand for som= eone > who is not already an expert in BGP/MPLS VPNs (RFC 4364 & RFC 7432) - e.g= ., > it contains many unexpanded acronyms from that domain - ASBR, PE, SP, etc= ., > none of which appear in this draft's terminology section. It is not reas= onable > for a general use case draft such as this to assume that degree of expert= ise > in another technical domain. >=20 > [4] As written, this sentence in Section 4.2 is incorrect: >=20 > As a result, a tunnel carrying NVO3 > network traffic must be terminated at the GW/firewall where the NVO3 > traffic is processed. >=20 > as there are deployed "running code" counterexamples. >=20 > The underlying problem appears to be that the use case in section 4.2 inc= ludes > an implicit, but unstated, requirement for physical network segmentation/ > isolation via physical GW/firewall network nodes. That requirement needs= to > be stated, and I suggest changing the section title to somehow convey thi= s > physical segmentation/isolation requirement. >=20 > - Editorial >=20 > In Section 1. Introduction: >=20 > The goal of > data center network virtualization overlay (NVO3) networks is to > decouple the communication among tenant systems from DC physical > infrastructure networks and to allow one physical network > infrastructure: >=20 > Pluralize and edit to "The goals of ... are ... infrastructure to:" and e= dit > the bulleted list so that each list item is a grammatically correct > completion of this sentence in the singular (i.e., "The goal of ... is to= :"). >=20 > The paragraph about gateways in the Introduction ("An NVO3 network > may interconnect ..." seems out of place - try moving it to somewhere > in Section 2, e.g., so that it comes after the definition of the vGW > acronym in the terminology section. >=20 > In Section 1.1 Terminology: >=20 > - DMZ definition should use the relative terms "more trusted" and > "less trusted" in place of the absolute terms "trusted" and "untrusted" >=20 > - In DC Operator definition: "A role who" -> "An entity that" That wordi= ng > should also be used instead of "A company that" in the definition of > DC Provider. >=20 > Some usage of NVO3 terminology, while correct, makes this draft less > accessible to those not familiar with the NVO3 WG. TS (Tenant System) > is a particular problem although this sentence near the start of Section = 2 > that introduces the term is fine: >=20 > A TS can be a physical server/device or a virtual machine (VM) > on a server, i.e., end-device [RFC7365]. >=20 > I would suggest that the draft be written in terms of Virtual Machines > beyond this point, with a sentence added after the above sentence to > say that the draft is written in terms of virtual machines as a motivatin= g > example of TSs for clarity, but the use cases apply to TSs in general, no= t > just VMs. >=20 > In section 4.1, use "physical servers" instead of "metal servers." The > latter isn't even a good term - "bare metal servers" was probably intende= d, > but "physical servers" is the better term. >=20 > In section 5 Summary, remove the following paragraph: >=20 > DC services may vary, from infrastructure as a service (IaaS), to > platform as a service (PaaS), to software as a service (SaaS). > In these services, NVO3 networks are just a portion of such services. >=20 > as those *aaS terms occur nowhere else in the draft, and hence this text > doesn't summarize any prior material. >=20 > Thanks, --David > -------------------------------------------------------- > David L. Black, Distinguished Engineer > Dell EMC, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 > David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D > -------------------------------------------------------- >=20 From nobody Wed Jan 18 11:20:15 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 E2C30129579 for ; Wed, 18 Jan 2017 11:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] 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 m3LkHfm3w64V for ; Wed, 18 Jan 2017 11:20:10 -0800 (PST) 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 D33F9129571 for ; Wed, 18 Jan 2017 11:20:10 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0IJJi3w023115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jan 2017 11:19:45 -0800 (PST) To: "Black, David" , "tsv-art@ietf.org" References: From: Joe Touch Message-ID: <7128281e-4467-dd0b-f516-f485ea72cf79@isi.edu> Date: Wed, 18 Jan 2017 11:19:45 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 19:20:13 -0000 Thanks, David. I think (hope) the feedback will be useful. The group seems disorganized but not resistant to guidance. Joe On 1/17/2017 4:07 PM, Black, David wrote: > Ok, I've completed and sent the review of this draft. One of the ADs will need to put that review into the datatracker, which currently indicates that TSV-ART will not review this draft ;-). I only found one minor transport issue (incorrect requirement on communication disruption/interruption) ... but ... > > I also found a major issue (one of the three use case categories is effectively missing), and a number of minor issues. > > On terminology, we (the IETF) are stuck with a lot of it, but I did complain about TS (Tenant System) and suggest that the draft be mostly rewritten in terms of Virtual Machines (VMs). That should help some with clarity and seems (IMHO) to be about the limit of what's reasonable, aside from pointing out that the section on use of BGP/MPLS VPNs is almost incomprehensible to those who aren't already familiar with them. > > Enjoy ;-), --David > >> -----Original Message----- >> From: Black, David >> Sent: Tuesday, January 17, 2017 6:56 PM >> To: tsv-art@ietf.org; The IESG >> Cc: nvo3@ietf.org; Black, David >> Subject: TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 >> >> Document: draft-ietf-nvo3-use-case-15 >> Reviewer: David Black >> Review Date: January 17, 2017 >> IETF LC End Date: January 11, 2017 >> IESG Telechat date: January 19, 2017 >> >> Review result: Has Issues >> >> I've reviewed this document as part of TSV-ART's ongoing effort to >> review key IETF documents. These comments were written primarily for >> the transport area directors, but are copied to the document's authors >> for their information and to allow them to address any issues raised. >> Please always CC tsv-art at ietf.org if you reply to or forward this >> review. >> >> This draft describes use cases for Data-Center Network Virtualization over >> Layer 3 (NVO3) technology being worked on the NVO3 WG. >> >> I should apologize for this review coming relatively late - the desirability >> of a TSV-ART review of this draft was not discovered until after IETF Last >> Call had concluded, and actually not until after an initial TSV-ART decision >> had been made to not review this draft. >> >> In the spirit of full disclosure, I have been an active member of the NVO3 >> WG, and an author of two of its three published RFCs, RFC 7364 and RFC >> 8014. I have not seen much value in this use case draft, and for that >> reason I did not carefully review it in the WG. I have no fundamental >> objection to RFC publication of this draft, but having reviewed it in detail >> now, I believe it needs some serious attention before being approved for >> RFC publication, and hope that the IESG concurs. >> >> -- TSV-ART review comments: >> >> [T-1] There's one minor transport issue in this draft that requires correction >> in Section 2. Basic NVO3 Networks: >> >> The TS reachability update mechanisms need be fast enough so that >> the updates do not cause any communication disruption/interruption. >> >> That requirement is overstated. NVO3 technology can and does disrupt >> communication by dropping packets when a TS (e.g., a virtual machine) >> moves to a different network attachment point (i.e., NVE). >> >> This requirement should be restated in terms of disruption to transport >> protocols - it's ok to drop a packet or two thereby causing a TCP or SCTP >> retransmission, but dropping enough packets to cause termination of >> a TCP connection or SCTP association is clearly unacceptable. >> In contrast, UDP-based applications will see packet drops in this (and other) >> scenarios, but avoidance of that is not an NVO3 goal - while the U in UDP >> does not stand for Unreliable, in NVO3 context, this is a good way to >> think about that letter :-). >> >> -- Other review comments >> >> - Major Issue >> >> [A] Section 2 of the draft is a problem. While Section 1 characterizes >> Section 2 as describing a use case referred to as "DC East-West traffic," that >> use case is not to be found in Section 2 (e.g., nothing in Section 2 appears >> to distinguish East-West traffic from North-South traffic). In its current >> form, Section 2 is really an NVO3 Background section, as it describes >> NVO3 terminology in general terms - while it uses different text, nearly >> all of the material that it contains can be found elsewhere, e.g., RFC 8014 >> on NVO3 Architecture (NB: This reviewer is an author of RFC 8014). Section >> 2's title should be changed to "NVO3 Background" or something similar, >> and Section 1 changed accordingly. >> >> - Minor issues >> >> [1] The draft's use of the term "NVO3 network" is sloppy and imprecise. >> This is actually an NVO3 Virtual Network or VN - the word "virtual" >> should be inserted in all cases. >> >> [2] This text in section 3 is vague on what a VPN is: >> >> This, in turn, >> becomes the case of interconnecting an NVO3 network and the virtual >> private network (VPN) on the Internet or wide-area networks (WAN). >> Note that a VPN is not implemented by NVO3 solution. >> >> By itself, the latter sentence is incorrect, however, reading onward, one >> discovers that not all forms of VPNs are intended - section 3.1 uses an >> IPsec VPN, and section 3.2 uses a BGP/MPLS L3VPN. I would suggest >> deleting the second sentence and rewriting the first to use these two >> technologies as an example, e.g.: >> >> WAN connectivity to the virtual gateway can be provided by VPN >> technologies such as IPsec VPNs [RFC4301] and BGP/MPLS IP >> VPNs [RFC 4364]. >> >> [3] The first paragraph in section 3.2 is very hard to understand for someone >> who is not already an expert in BGP/MPLS VPNs (RFC 4364 & RFC 7432) - e.g., >> it contains many unexpanded acronyms from that domain - ASBR, PE, SP, etc., >> none of which appear in this draft's terminology section. It is not reasonable >> for a general use case draft such as this to assume that degree of expertise >> in another technical domain. >> >> [4] As written, this sentence in Section 4.2 is incorrect: >> >> As a result, a tunnel carrying NVO3 >> network traffic must be terminated at the GW/firewall where the NVO3 >> traffic is processed. >> >> as there are deployed "running code" counterexamples. >> >> The underlying problem appears to be that the use case in section 4.2 includes >> an implicit, but unstated, requirement for physical network segmentation/ >> isolation via physical GW/firewall network nodes. That requirement needs to >> be stated, and I suggest changing the section title to somehow convey this >> physical segmentation/isolation requirement. >> >> - Editorial >> >> In Section 1. Introduction: >> >> The goal of >> data center network virtualization overlay (NVO3) networks is to >> decouple the communication among tenant systems from DC physical >> infrastructure networks and to allow one physical network >> infrastructure: >> >> Pluralize and edit to "The goals of ... are ... infrastructure to:" and edit >> the bulleted list so that each list item is a grammatically correct >> completion of this sentence in the singular (i.e., "The goal of ... is to:"). >> >> The paragraph about gateways in the Introduction ("An NVO3 network >> may interconnect ..." seems out of place - try moving it to somewhere >> in Section 2, e.g., so that it comes after the definition of the vGW >> acronym in the terminology section. >> >> In Section 1.1 Terminology: >> >> - DMZ definition should use the relative terms "more trusted" and >> "less trusted" in place of the absolute terms "trusted" and "untrusted" >> >> - In DC Operator definition: "A role who" -> "An entity that" That wording >> should also be used instead of "A company that" in the definition of >> DC Provider. >> >> Some usage of NVO3 terminology, while correct, makes this draft less >> accessible to those not familiar with the NVO3 WG. TS (Tenant System) >> is a particular problem although this sentence near the start of Section 2 >> that introduces the term is fine: >> >> A TS can be a physical server/device or a virtual machine (VM) >> on a server, i.e., end-device [RFC7365]. >> >> I would suggest that the draft be written in terms of Virtual Machines >> beyond this point, with a sentence added after the above sentence to >> say that the draft is written in terms of virtual machines as a motivating >> example of TSs for clarity, but the use cases apply to TSs in general, not >> just VMs. >> >> In section 4.1, use "physical servers" instead of "metal servers." The >> latter isn't even a good term - "bare metal servers" was probably intended, >> but "physical servers" is the better term. >> >> In section 5 Summary, remove the following paragraph: >> >> DC services may vary, from infrastructure as a service (IaaS), to >> platform as a service (PaaS), to software as a service (SaaS). >> In these services, NVO3 networks are just a portion of such services. >> >> as those *aaS terms occur nowhere else in the draft, and hence this text >> doesn't summarize any prior material. >> >> Thanks, --David >> -------------------------------------------------------- >> David L. Black, Distinguished Engineer >> Dell EMC, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 Cell: +1 (978) 394-7754 >> David.Black@dell.com <=== NEW === >> -------------------------------------------------------- >> > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Thu Jan 19 04:54:25 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 5500B12007C; Thu, 19 Jan 2017 04:54:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148483046032.10361.17151574270407522527.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 04:54:20 -0800 Archived-At: Cc: matthew.bocci@nokia.com, tsv-art@ietf.org, nvo3@ietf.org, draft-ietf-nvo3-use-case@ietf.org, nvo3-chairs@ietf.org Subject: [Tsv-art] Spencer Dawkins' No Objection on draft-ietf-nvo3-use-case-15: (with COMMENT) X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 12:54:20 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-nvo3-use-case-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-nvo3-use-case/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Mirja that David Black's TSV-ART review (included as a Comment in Mirja's ballot) is worth a look before the draft goes to the RFC Editor. To the IESG: I don't object to the publication of this document, but my impression was that much of the text is describing use cases for NVO3 products, with less attention being paid to unique requirements of each use case for protocol work in the IETF, which is why IETF working groups need to think about use cases in the first place. Maybe that's worth keeping in mind for any future use case drafts that the IESG will be evaluating? From nobody Thu Jan 19 08:07:20 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 75DCF129446 for ; Thu, 19 Jan 2017 08:07:18 -0800 (PST) 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 g1K8hHlGnjTB for ; Thu, 19 Jan 2017 08:07:17 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 06045126FDC for ; Thu, 19 Jan 2017 08:07:17 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id z134so40007781lff.3 for ; Thu, 19 Jan 2017 08:07:16 -0800 (PST) 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=qfRVlTICNB6iBxSfA0oI7sF2sDPTb4s4oxpUBlA2YDk=; b=O/I/WWJY5J5bHhxZ/0cm5OXrG2UwOxeNFjbes2YhCdb/5llXaubiTXt87GluiFAmIB XPJfoXLVz8CT6d5gWwgO0HVreaxyqcD226rUOeakhmcOaRxJUOzvW6clOPCx+HZlfjsc H7YA3pCjIO/XLxFnkOveK65D8nV+yDXOsXFHHSNFMuyYfBqftsBymuBHWPauHv9rGvi0 vK8oLTmtCEMVW7bfOS2urdbthn9qVot/nbKWvSR3xwlmlJSHqvUcs45Y5hQ1I+RLQkl7 KukAceSFipMrssQXf0OtLkVfUQcd7bM8JSI9x2mmEuS7K62IOepaM+zIn6LX6lgjWGmi r57Q== 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=qfRVlTICNB6iBxSfA0oI7sF2sDPTb4s4oxpUBlA2YDk=; b=M3W6FpD67uuZ6I60I4dZKzSl59vPKh0o+QaUp03QBwbWgA5d1CYlp/aFHc3fjcqnS8 g7ABfEaVC4ZKSZzoAlXyFcj5GO7kiTNWQL+ll5L8S94in9vI+u60lMMpekRp/vsip1DB VPV+MnTvOoMKdaL2EK25LNbihuioZlMDuXhDByt2sMoWPucmLR9k1HpoNx0jj1NBTpUh knzfVQkhu4igUfqDvTKYR3ELM+j+uywkmxzMdWhP4Q76zJfQwnI5JwLBamvAphneABo8 lNwUBOI0UdIGkq6UrKDWpmRke3V737rLQp1TlyKD0qiKwXayVBfTReWa+NcAtXyu0Lmg AZOQ== X-Gm-Message-State: AIkVDXLWmYzPum/a3nrcywfl4upBpvwcQNM8w+nCc480Pud8vw2WhCl17zLKE01kKSPNRA== X-Received: by 10.25.132.6 with SMTP id g6mr3570884lfd.144.1484842034688; Thu, 19 Jan 2017 08:07:14 -0800 (PST) Received: from mn-mn0F-2.local (p200300063350F753885F9A288351D086.dip0.t-ipconnect.de. [2003:6:3350:f753:885f:9a28:8351:d086]) by smtp.googlemail.com with ESMTPSA id 25sm2092522ljt.11.2017.01.19.08.07.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 08:07:14 -0800 (PST) From: Martin Stiemerling To: tsv-art@ietf.org Message-ID: Date: Thu, 19 Jan 2017 17:07:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 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 01/19 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 16:07:18 -0000 Dear TSVers, I did work through all documents that are in IETF LC, IESG processing or being requested for publication as of 01/19, 4:00 m UTC. Please find below all documents checked and what to do with these documents. Documents that require TSV attention: draft-bradner-rfc3979bis-10 -- assigned to Brian (via the datatracker, which hopefully **did** sent out the assignment) Documents that do not require TSV attention: draft-freytag-lager-variant-rules-02 draft-ietf-sidr-delta-protocol-05 draft-ietf-kitten-krb-auth-indicator-06 draft-ietf-ccamp-flexible-grid-ospf-ext-07 draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 draft-ietf-lamps-eai-addresses-05 draft-ietf-mpls-tp-linear-protection-mib-11 draft-ietf-mmusic-4572-update-11 (*) (*) This sounded like in need, but it is purely describing media over TCP/TLS and how this is represented in SDP. Thanks, Martin From nobody Thu Jan 19 09:42:29 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 4C34E1293F9 for ; Thu, 19 Jan 2017 09:42:28 -0800 (PST) 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 BWqT5nTK6Q-z for ; Thu, 19 Jan 2017 09:42:26 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 0EDBB12943A for ; Thu, 19 Jan 2017 09:42:26 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id v186so42134029lfa.1 for ; Thu, 19 Jan 2017 09:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=fFORMcDihTH9mMUlH5xzKotvE3yjPbiUvOq3UwNdIn8=; b=aJZb1rTCTTpqrjs+XlI9R81Q1Iqt0+uca742skNCDSZDJl6TLTy8/cCLAbsVDJf+8a qKGoougLcY+lPYrJCSBrpjs4jwTGwHZ2c4lV/VTHjDyqQDhoVEy5BOBAVTNx955PVDib RW9aGhoCpbH3tyKd6FVSLx3PnVbd8ngcATzHq4N1HMj5Weg5RdNvi3Mud9fKRwvi72De gEnAgG3WkN8FXO2hBp++VDWSD9US9VRhftrkowr9H97KNpdUFQxB0ntpGQ305sxDxPfP Uj6NQ1jbvDzdHjNKbhv5ABRrEZ5ZY7TR2RJfe4eiuXQfZVoZnI4o1fO3BZCtX1f4ftGg yyzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fFORMcDihTH9mMUlH5xzKotvE3yjPbiUvOq3UwNdIn8=; b=sQnxk/SVy9FlmRajkin1smdR94Z2LzeBgV50w9yO9oeiBMffMRyd3XNGnUBSTFDo8N ZtS3LBJYjS1vXLhTsd2VcbI7vIGg17LrE0AhnVb0VU/pnnAN+zh7+sTcPxmXbpBW00Pk KtNxLwqrqKeQ8qq8K0yHClbNGtKB5nGRWvdqFuBExX/7TOs5i5EyLkn9SFRcDOapCY9M S3F/jiSZDbV3/mQvM2PQAsruPEDV2XB2o4+0Aiue8X6V8Wo6jqavKhCXPaIk4+KIIQom +hLVPKMYYiADiI2x9sRtzLWYncz8B5falDZOBKi86zDheIAdjF+e+1on2GcuI6DoN41V m+3Q== X-Gm-Message-State: AIkVDXJBwEAyidK88o2J4C6eFoTm4Y4ohiFSLXPgecTPLwPUoUhmduyN1+guu3eipsYRWw== X-Received: by 10.25.199.14 with SMTP id x14mr2896242lff.13.1484847743949; Thu, 19 Jan 2017 09:42:23 -0800 (PST) Received: from mn-mn0F-2.local (p200300063350F753F5B149E9ABACFFC9.dip0.t-ipconnect.de. [2003:6:3350:f753:f5b1:49e9:abac:ffc9]) by smtp.googlemail.com with ESMTPSA id d10sm2236705lfg.12.2017.01.19.09.42.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 09:42:23 -0800 (PST) To: Joe Touch , "Black, David" , tsv-art@ietf.org References: <7c475f41-c31d-b149-c20b-011cb2f87db0@gmail.com> <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> From: Martin Stiemerling Message-ID: Date: Thu, 19 Jan 2017 18:42:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7aa4a8d0-8270-40b9-4bb8-0d09fd79ea81@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 01/11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 17:42:28 -0000 Hi Joe and David, Thanks for taking care of this! > > It does have significant transport issues, but it's already being > watched ;-) Arg, ok, and I did believe that use case documents should be almost safe of not having transport issues. Martin > > Joe > > > On 1/11/2017 1:52 PM, Martin Stiemerling wrote: >> Dear TSVers, >> >> First of all, a happy new (western) year! :) >> >> I did work through all documents that are in IETF LC, IESG processing >> or being requested for publication as of 01/11, 09:00 pm UTC. >> >> Please find below all documents checked and what to do with these >> documents. >> >> >> Documents that require TSV attention: >> none. >> >> >> Documents that do not require TSV attention: >> draft-ietf-oauth-jwsreq-09 >> draft-ietf-ipsecme-rfc4307bis-15 >> draft-ietf-geojson-text-sequence-03 >> draft-ietf-dime-agent-overload-08 >> draft-ietf-bmwg-ipv6-nd-04 >> draft-ietf-intarea-hostname-practice-03 >> draft-mohali-dispatch-cause-for-service-number-12 >> draft-ietf-trill-rfc6439bis-04 >> draft-ietf-trill-directory-assist-mechanisms-10 >> draft-ietf-teas-p2mp-loose-path-reopt-08 >> draft-ietf-teas-gmpls-resource-sharing-proc-06 >> draft-ietf-sidr-rpki-oob-setup-06 >> draft-ietf-sidr-publication-10 >> draft-ietf-sidr-adverse-actions-03 >> draft-ietf-rtgwg-rlfa-node-protection-10 >> draft-ietf-mpls-residence-time-12 >> draft-ietf-lisp-type-iana-04 >> draft-ietf-ecrit-ecall-22 >> draft-ietf-ecrit-car-crash-21 >> draft-ietf-bfcpbis-bfcp-websocket-13 >> draft-ietf-6man-rdnss-rfc6106bis-14 >> draft-holmberg-dispatch-mcptt-rp-namespace-04 >> draft-murchison-webdav-prefer-13 >> draft-ietf-dnsop-edns-key-tag-03 >> draft-ietf-payload-melpe-04 >> draft-ietf-insipid-logme-reqs-11 >> draft-ietf-softwire-multicast-prefix-option-11 >> draft-ietf-clue-rtp-mapping-10 >> draft-ietf-bfcpbis-sdp-ws-uri-07 >> draft-ietf-dhc-dhcpv6-failover-protocol-03 >> draft-ietf-nvo3-use-case-15 >> draft-ietf-softwire-dslite-multicast-14 >> >> Thanks, >> >> Martin >> >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art > From nobody Thu Jan 19 14:24:30 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 7412D129614; Thu, 19 Jan 2017 14:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-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 W_85MjiqaBjd; Thu, 19 Jan 2017 14:24:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99CFA1294CA; Thu, 19 Jan 2017 14:24:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZD60648; Thu, 19 Jan 2017 22:24:17 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 19 Jan 2017 22:24:16 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Thu, 19 Jan 2017 14:24:10 -0800 From: Lucy yong To: "Black, David" , "tsv-art@ietf.org" , The IESG Thread-Topic: TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 Thread-Index: AdJxHTT9+9vVjDKxS3qqR8JNKwRL+ABe4J9g Date: Thu, 19 Jan 2017 22:24:09 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5853D8E0@SJCEML701-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.11] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58813C92.0040, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 68aebeeaa352afc2ccffe8c803df2ec2 Archived-At: Cc: "nvo3@ietf.org" Subject: Re: [Tsv-art] TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 22:24:23 -0000 Hi David, Thank you for your detail review and comments. Sorry for a delayed reply du= e to my business travel. I am the same as you who wish that some of your concerns should be caught o= ut and addressed in early stage. Unfortunately, we have to address them now= . Please see my reply inline below. -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David Sent: Tuesday, January 17, 2017 5:56 PM To: tsv-art@ietf.org; The IESG Cc: nvo3@ietf.org; Black, David Subject: [nvo3] TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 Document: draft-ietf-nvo3-use-case-15 Reviewer: David Black Review Date: January 17, 2017 IETF LC End Date: January 11, 2017 IESG Telechat date: January 19, 2017 Review result: Has Issues I've reviewed this document as part of TSV-ART's ongoing effort to review k= ey IETF documents. These comments were written primarily for the transport = area directors, but are copied to the document's authors for their informat= ion and to allow them to address any issues raised. Please always CC tsv-art at ietf.org if you reply to or forward this review= . This draft describes use cases for Data-Center Network Virtualization over = Layer 3 (NVO3) technology being worked on the NVO3 WG. I should apologize for this review coming relatively late - the desirabilit= y of a TSV-ART review of this draft was not discovered until after IETF Las= t Call had concluded, and actually not until after an initial TSV-ART decis= ion had been made to not review this draft. In the spirit of full disclosure, I have been an active member of the NVO3 = WG, and an author of two of its three published RFCs, RFC 7364 and RFC 8014= . I have not seen much value in this use case draft, and for that reason I did not carefully review it in the WG. I have no fundamental objection to RFC publication of this draft, but having reviewed it in detai= l now, I believe it needs some serious attention before being approved for = RFC publication, and hope that the IESG concurs. -- TSV-ART review comments: [T-1] There's one minor transport issue in this draft that requires correct= ion in Section 2. Basic NVO3 Networks: The TS reachability update mechanisms need be fast enough so that the updates do not cause any communication disruption/interruption. That requirement is overstated. NVO3 technology can and does disrupt commu= nication by dropping packets when a TS (e.g., a virtual machine) moves to a= different network attachment point (i.e., NVE). This requirement should be restated in terms of disruption to transport pro= tocols - it's ok to drop a packet or two thereby causing a TCP or SCTP retr= ansmission, but dropping enough packets to cause termination of a TCP conne= ction or SCTP association is clearly unacceptable. In contrast, UDP-based applications will see packet drops in this (and othe= r) scenarios, but avoidance of that is not an NVO3 goal - while the U in UD= P does not stand for Unreliable, in NVO3 context, this is a good way to thi= nk about that letter :-). [Lucy] how about: the update should not cause a disruption for applications= running on TSes. =20 -- Other review comments - Major Issue [A] Section 2 of the draft is a problem. While Section 1 characterizes Section 2 as describing a use case referred to as "DC East-West traffic," t= hat use case is not to be found in Section 2 (e.g., nothing in Section 2 ap= pears to distinguish East-West traffic from North-South traffic). In its c= urrent form, Section 2 is really an NVO3 Background section, as it describe= s NVO3 terminology in general terms - while it uses different text, nearly al= l of the material that it contains can be found elsewhere, e.g., RFC 8014 o= n NVO3 Architecture (NB: This reviewer is an author of RFC 8014). Section = 2's title should be changed to "NVO3 Background" or something similar, and = Section 1 changed accordingly. [Lucy] We can restate that the traffic from such applications is called DC = East-West traffic in the end of first paragraph if that is helpful. IMO: Ba= sic NVO3 Virtual Network is the right title for the section. Perhaps we can= shorten Section 2 description to focus on the use cases.=20 - Minor issues [1] The draft's use of the term "NVO3 network" is sloppy and imprecise. This is actually an NVO3 Virtual Network or VN - the word "virtual" should be inserted in all cases. [Lucy] Agree to use term "NVO3 Virtual Network or VN" in the doc. Will be c= hanged in next version. [2] This text in section 3 is vague on what a VPN is: This, in turn, becomes the case of interconnecting an NVO3 network and the virtual private network (VPN) on the Internet or wide-area networks (WAN). Note that a VPN is not implemented by NVO3 solution. By itself, the latter sentence is incorrect, however, reading onward, one d= iscovers that not all forms of VPNs are intended - section 3.1 uses an IPse= c VPN, and section 3.2 uses a BGP/MPLS L3VPN. I would suggest deleting the= second sentence and rewriting the first to use these two technologies as a= n example, e.g.: WAN connectivity to the virtual gateway can be provided by VPN technologies such as IPsec VPNs [RFC4301] and BGP/MPLS IP VPNs [RFC 4364]. [Lucy] Like your proposed text. [3] The first paragraph in section 3.2 is very hard to understand for someo= ne who is not already an expert in BGP/MPLS VPNs (RFC 4364 & RFC 7432) - e.= g., it contains many unexpanded acronyms from that domain - ASBR, PE, SP, e= tc., none of which appear in this draft's terminology section. It is not r= easonable for a general use case draft such as this to assume that degree o= f expertise in another technical domain. [Lucy] We received this comments from other reviewer and will fix them in n= ext version including expanding acronyme and providing references.=20 [4] As written, this sentence in Section 4.2 is incorrect: As a result, a tunnel carrying NVO3 network traffic must be terminated at the GW/firewall where the NVO3 traffic is processed. as there are deployed "running code" counterexamples. The underlying problem appears to be that the use case in section 4.2 inclu= des an implicit, but unstated, requirement for physical network segmentatio= n/ isolation via physical GW/firewall network nodes. That requirement need= s to be stated, and I suggest changing the section title to somehow convey = this physical segmentation/isolation requirement. [Lucy] Disagree. The use case in section 4.2 aims for a DC cloud applicatio= n for Internet users, where DMZ is required. When using NVO3 technology to = support an DMZ application, multiple NVO3 virtual networks can be used to a= chieve the goal. If that is not clear to you, we need to make it more clear= . - Editorial In Section 1. Introduction: The goal of data center network virtualization overlay (NVO3) networks is to decouple the communication among tenant systems from DC physical infrastructure networks and to allow one physical network infrastructure: Pluralize and edit to "The goals of ... are ... infrastructure to:" and edi= t the bulleted list so that each list item is a grammatically correct compl= etion of this sentence in the singular (i.e., "The goal of ... is to:"). The paragraph about gateways in the Introduction ("An NVO3 network may inte= rconnect ..." seems out of place - try moving it to somewhere in Section 2= , e.g., so that it comes after the definition of the vGW acronym in the ter= minology section. [Lucy] ack In Section 1.1 Terminology: - DMZ definition should use the relative terms "more trusted" and "less trusted" in place of the absolute terms "trusted" and "untrusted" [Lucy] ack - In DC Operator definition: "A role who" -> "An entity that" That wording should also be used instead of "A company that" in the definition of DC Provider. [Lucy] ack Some usage of NVO3 terminology, while correct, makes this draft less accessible to those not familiar with the NVO3 WG. TS (Tenant System) is a particular problem although this sentence near the start of Section 2 = that introduces the term is fine: A TS can be a physical server/device or a virtual machine (VM) on a server, i.e., end-device [RFC7365]. I would suggest that the draft be written in terms of Virtual Machines beyo= nd this point, with a sentence added after the above sentence to say that t= he draft is written in terms of virtual machines as a motivating example of= TSs for clarity, but the use cases apply to TSs in general, not just VMs. [Lucy] This draft uses NVO3 terms. Personally, I prefer that way. =20 In section 4.1, use "physical servers" instead of "metal servers." The latter isn't even a good term - "bare metal servers" was probably intended,= but "physical servers" is the better term. [Lucy] ack In section 5 Summary, remove the following paragraph: DC services may vary, from infrastructure as a service (IaaS), to platform as a service (PaaS), to software as a service (SaaS). In these services, NVO3 networks are just a portion of such services. as those *aaS terms occur nowhere else in the draft, and hence this text do= esn't summarize any prior material. [Lucy] We will add a NIST reference in next version for these DC service de= finition. Thanks, Lucy Thanks, --David -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From nobody Fri Jan 20 09:42: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 A2B891294B4; Fri, 20 Jan 2017 09:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 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, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=NM0Yzxoq; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=IzkNkYHg 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 lZ5ijD_9lCoN; Fri, 20 Jan 2017 09:42:07 -0800 (PST) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 253B012943D; Fri, 20 Jan 2017 09:42:07 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=Q4U3nadJM2nY2g+/bsGcwrI8LeVfM4XNEH06BXTzMXrw440kcu+G3kPW W5OEahFUPE8+cnN6OvzmqjjLsIdiLZZY/GUp2aWqsJtpQAmYra1J7F939 4yD2knk87PItcsmHgGZZKUwgocKjgsqTvsg7r5yTjAz2O0p3mP3VieWss w=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1484934127; x=1516470127; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=69z2FMciUTH3+MVBnUcUoHcIp6pQGnPwD0TbP0IieDI=; b=NM0YzxoqoYhdzY23wRwnsYNHcOjlMhZGHFQSjvK6X4GzbVGj9P5vuNvn 1MYwjHyEpZHfSIelWeqUVHL3YPmUDHFQLE69Jcbq+3LpESi3ngRaRYUSl BNyrv4enRmhOMcBIKFcprDkYCfFcwj3ThezS65JNpGcWNpsLjCLXFhfgp M=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2017 11:42:06 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2017 23:42:05 +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 v0KHg3VX008631 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 Jan 2017 12:42:05 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v0KHg3VX008631 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1484934125; bh=3El577mHb1JLCHerL/9T/tvtlkI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=IzkNkYHg4eJcYcCZ5s+1UthN6o37ADqd0v/aDaz/4FdLxi/+3Ub9frgNTjnULyO9r 8dUN1tG2xq+Zaf2ucm71kPzqMBVrWok/I2UhTHIsGaqIwpGLIvAvqKbEsvc7lhiCE0 rIeustR1kanyeqgg5Au76Aa3uOwkomBM5flC1LXA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v0KHg3VX008631 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd56.lss.emc.com (RSA Interceptor); Fri, 20 Jan 2017 12:41:41 -0500 Received: from MXHUB314.corp.emc.com (MXHUB314.corp.emc.com [10.146.3.92]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0KHfssh012244 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 20 Jan 2017 12:41:55 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB314.corp.emc.com ([10.146.3.92]) with mapi id 14.03.0266.001; Fri, 20 Jan 2017 12:41:54 -0500 To: Lucy yong , "tsv-art@ietf.org" , The IESG Thread-Topic: TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 Thread-Index: AdJxHTT9+9vVjDKxS3qqR8JNKwRL+ABe4J9gACo8uzA= Date: Fri, 20 Jan 2017 17:41:53 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D5853D8E0@SJCEML701-CHM.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D5853D8E0@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.108] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "nvo3@ietf.org" , "Black, David" Subject: Re: [Tsv-art] TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 17:42:09 -0000 Hi Lucy, Thanks for the response and suggested changes. The suggested changes are f= ine for anything that I don't comment on further here: > [T-1] There's one minor transport issue in this draft that requires corre= ction in > Section 2. Basic NVO3 Networks: >=20 > The TS reachability update mechanisms need be fast enough so that > the updates do not cause any communication disruption/interruption. > > That requirement is overstated. NVO3 technology can and does disrupt > communication by dropping packets when a TS (e.g., a virtual machine) mov= es to > a different network attachment point (i.e., NVE). [... snip ...] > [Lucy] how about: the update should not cause a disruption for applicatio= ns > running on TSes. The TS reachability update mechanisms need to be fast enough to not cause significant disruption to applications that use the network (e.g., a prot= ocol like TCP may see a few packet drops and have to retransmit, but does not drop the connection). Moving to application disruption from communication disruption is good - a concept that I'm looking to convey is that reliable transport protocols (li= ke TCP) can hide some minor communication disruptions from applications. > [A] Section 2 of the draft is a problem. =20 [... snip ...] > [Lucy] We can restate that the traffic from such applications is called D= C East- > West traffic in the end of first paragraph if that is helpful. IMO: Basic= NVO3 Virtual > Network is the right title for the section. Perhaps we can shorten Sectio= n 2 > description to focus on the use cases. A shortened Section 2 that focuses on use cases sounds promising. I'd like to see the rewritten text before commenting further. > [4] As written, this sentence in Section 4.2 is incorrect: >=20 > As a result, a tunnel carrying NVO3 > network traffic must be terminated at the GW/firewall where the NVO3 > traffic is processed. >=20 > as there are deployed "running code" counterexamples. [... snip ...] > [Lucy] Disagree. The use case in section 4.2 aims for a DC cloud applicat= ion for > Internet users, where DMZ is required. When using NVO3 technology to supp= ort > an DMZ application, multiple NVO3 virtual networks can be used to achieve= the > goal. If that is not clear to you, we need to make it more clear. There is deployed "running code" that does that class of DMZ enforcement (o= f a logical DMZ) without terminating tunnels at GW/firewall nodes between zones= . The sentence appears to only be correct when the DMZ is required to have ph= ysical boundaries. --- Editorial --- > I would suggest that the draft be written in terms of Virtual Machines be= yond this > point, with a sentence added after the above sentence to say that the dra= ft is > written in terms of virtual machines as a motivating example of TSs for c= larity, but > the use cases apply to TSs in general, not just VMs. > [Lucy] This draft uses NVO3 terms. Personally, I prefer that way. Ok, it's the editors'/authors' choice on whether to make this editorial cha= nge. > In section 5 Summary, remove the following paragraph: >=20 > DC services may vary, from infrastructure as a service (IaaS), to > platform as a service (PaaS), to software as a service (SaaS). > In these services, NVO3 networks are just a portion of such services. >=20 > as those *aaS terms occur nowhere else in the draft, and hence this text = doesn't > summarize any prior material. > [Lucy] We will add a NIST reference in next version for these DC service > definition. The Summary is still not a good place to introduce new concepts and termin= ology - this paragraph might work better in the Introduction. Thanks, --David > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Thursday, January 19, 2017 5:24 PM > To: Black, David; tsv-art@ietf.org; The IESG > Cc: nvo3@ietf.org > Subject: RE: TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 >=20 > Hi David, >=20 > Thank you for your detail review and comments. Sorry for a delayed reply = due to > my business travel. >=20 > I am the same as you who wish that some of your concerns should be caught= out > and addressed in early stage. Unfortunately, we have to address them now. > Please see my reply inline below. >=20 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David > Sent: Tuesday, January 17, 2017 5:56 PM > To: tsv-art@ietf.org; The IESG > Cc: nvo3@ietf.org; Black, David > Subject: [nvo3] TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 >=20 > Document: draft-ietf-nvo3-use-case-15 > Reviewer: David Black > Review Date: January 17, 2017 > IETF LC End Date: January 11, 2017 > IESG Telechat date: January 19, 2017 >=20 > Review result: Has Issues >=20 > I've reviewed this document as part of TSV-ART's ongoing effort to review= key > IETF documents. These comments were written primarily for the transport a= rea > directors, but are copied to the document's authors for their information= and to > allow them to address any issues raised. > Please always CC tsv-art at ietf.org if you reply to or forward this revi= ew. >=20 > This draft describes use cases for Data-Center Network Virtualization ove= r Layer 3 > (NVO3) technology being worked on the NVO3 WG. >=20 > I should apologize for this review coming relatively late - the desirabil= ity of a TSV- > ART review of this draft was not discovered until after IETF Last Call ha= d > concluded, and actually not until after an initial TSV-ART decision had b= een made > to not review this draft. >=20 > In the spirit of full disclosure, I have been an active member of the NVO= 3 WG, > and an author of two of its three published RFCs, RFC 7364 and RFC 8014. = I have > not seen much value in this use case draft, and for that > reason I did not carefully review it in the WG. I have no fundamental > objection to RFC publication of this draft, but having reviewed it in det= ail now, I > believe it needs some serious attention before being approved for RFC > publication, and hope that the IESG concurs. >=20 > -- TSV-ART review comments: >=20 > [T-1] There's one minor transport issue in this draft that requires corre= ction in > Section 2. Basic NVO3 Networks: >=20 > The TS reachability update mechanisms need be fast enough so that > the updates do not cause any communication disruption/interruption. >=20 > That requirement is overstated. NVO3 technology can and does disrupt > communication by dropping packets when a TS (e.g., a virtual machine) mov= es to > a different network attachment point (i.e., NVE). >=20 > This requirement should be restated in terms of disruption to transport p= rotocols > - it's ok to drop a packet or two thereby causing a TCP or SCTP retransmi= ssion, but > dropping enough packets to cause termination of a TCP connection or SCTP > association is clearly unacceptable. > In contrast, UDP-based applications will see packet drops in this (and ot= her) > scenarios, but avoidance of that is not an NVO3 goal - while the U in UDP= does > not stand for Unreliable, in NVO3 context, this is a good way to think ab= out that > letter :-). > [Lucy] how about: the update should not cause a disruption for applicatio= ns > running on TSes. >=20 > -- Other review comments >=20 > - Major Issue >=20 > [A] Section 2 of the draft is a problem. While Section 1 characterizes > Section 2 as describing a use case referred to as "DC East-West traffic,"= that use > case is not to be found in Section 2 (e.g., nothing in Section 2 appears = to > distinguish East-West traffic from North-South traffic). In its current = form, > Section 2 is really an NVO3 Background section, as it describes > NVO3 terminology in general terms - while it uses different text, nearly = all of the > material that it contains can be found elsewhere, e.g., RFC 8014 on NVO3 > Architecture (NB: This reviewer is an author of RFC 8014). Section 2's t= itle should > be changed to "NVO3 Background" or something similar, and Section 1 chang= ed > accordingly. > [Lucy] We can restate that the traffic from such applications is called D= C East- > West traffic in the end of first paragraph if that is helpful. IMO: Basic= NVO3 Virtual > Network is the right title for the section. Perhaps we can shorten Sectio= n 2 > description to focus on the use cases. >=20 > - Minor issues >=20 > [1] The draft's use of the term "NVO3 network" is sloppy and imprecise. > This is actually an NVO3 Virtual Network or VN - the word "virtual" > should be inserted in all cases. > [Lucy] Agree to use term "NVO3 Virtual Network or VN" in the doc. Will be > changed in next version. >=20 > [2] This text in section 3 is vague on what a VPN is: >=20 > This, in turn, > becomes the case of interconnecting an NVO3 network and the virtual > private network (VPN) on the Internet or wide-area networks (WAN). > Note that a VPN is not implemented by NVO3 solution. >=20 > By itself, the latter sentence is incorrect, however, reading onward, one > discovers that not all forms of VPNs are intended - section 3.1 uses an I= Psec VPN, > and section 3.2 uses a BGP/MPLS L3VPN. I would suggest deleting the seco= nd > sentence and rewriting the first to use these two technologies as an exam= ple, > e.g.: >=20 > WAN connectivity to the virtual gateway can be provided by VPN > technologies such as IPsec VPNs [RFC4301] and BGP/MPLS IP > VPNs [RFC 4364]. > [Lucy] Like your proposed text. >=20 > [3] The first paragraph in section 3.2 is very hard to understand for som= eone who > is not already an expert in BGP/MPLS VPNs (RFC 4364 & RFC 7432) - e.g., i= t > contains many unexpanded acronyms from that domain - ASBR, PE, SP, etc., > none of which appear in this draft's terminology section. It is not reas= onable for a > general use case draft such as this to assume that degree of expertise in= another > technical domain. > [Lucy] We received this comments from other reviewer and will fix them in= next > version including expanding acronyme and providing references. >=20 > [4] As written, this sentence in Section 4.2 is incorrect: >=20 > As a result, a tunnel carrying NVO3 > network traffic must be terminated at the GW/firewall where the NVO3 > traffic is processed. >=20 > as there are deployed "running code" counterexamples. >=20 > The underlying problem appears to be that the use case in section 4.2 inc= ludes an > implicit, but unstated, requirement for physical network segmentation/ is= olation > via physical GW/firewall network nodes. That requirement needs to be sta= ted, > and I suggest changing the section title to somehow convey this physical > segmentation/isolation requirement. > [Lucy] Disagree. The use case in section 4.2 aims for a DC cloud applicat= ion for > Internet users, where DMZ is required. When using NVO3 technology to supp= ort > an DMZ application, multiple NVO3 virtual networks can be used to achieve= the > goal. If that is not clear to you, we need to make it more clear. >=20 > - Editorial >=20 > In Section 1. Introduction: >=20 > The goal of > data center network virtualization overlay (NVO3) networks is to > decouple the communication among tenant systems from DC physical > infrastructure networks and to allow one physical network > infrastructure: >=20 > Pluralize and edit to "The goals of ... are ... infrastructure to:" and e= dit the > bulleted list so that each list item is a grammatically correct completio= n of this > sentence in the singular (i.e., "The goal of ... is to:"). >=20 > The paragraph about gateways in the Introduction ("An NVO3 network may > interconnect ..." seems out of place - try moving it to somewhere in Sec= tion 2, > e.g., so that it comes after the definition of the vGW acronym in the ter= minology > section. > [Lucy] ack >=20 > In Section 1.1 Terminology: >=20 > - DMZ definition should use the relative terms "more trusted" and > "less trusted" in place of the absolute terms "trusted" and "untrusted" > [Lucy] ack >=20 > - In DC Operator definition: "A role who" -> "An entity that" That wordi= ng > should also be used instead of "A company that" in the definition of > DC Provider. > [Lucy] ack >=20 > Some usage of NVO3 terminology, while correct, makes this draft less > accessible to those not familiar with the NVO3 WG. TS (Tenant System) > is a particular problem although this sentence near the start of Section = 2 that > introduces the term is fine: >=20 > A TS can be a physical server/device or a virtual machine (VM) > on a server, i.e., end-device [RFC7365]. >=20 > I would suggest that the draft be written in terms of Virtual Machines be= yond this > point, with a sentence added after the above sentence to say that the dra= ft is > written in terms of virtual machines as a motivating example of TSs for c= larity, but > the use cases apply to TSs in general, not just VMs. > [Lucy] This draft uses NVO3 terms. Personally, I prefer that way. >=20 > In section 4.1, use "physical servers" instead of "metal servers." The > latter isn't even a good term - "bare metal servers" was probably intende= d, but > "physical servers" is the better term. > [Lucy] ack >=20 > In section 5 Summary, remove the following paragraph: >=20 > DC services may vary, from infrastructure as a service (IaaS), to > platform as a service (PaaS), to software as a service (SaaS). > In these services, NVO3 networks are just a portion of such services. >=20 > as those *aaS terms occur nowhere else in the draft, and hence this text = doesn't > summarize any prior material. > [Lucy] We will add a NIST reference in next version for these DC service > definition. >=20 > Thanks, > Lucy >=20 > Thanks, --David > -------------------------------------------------------- > David L. Black, Distinguished Engineer > Dell EMC, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 > David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D > -------------------------------------------------------- >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3