From nobody Mon Aug 7 07:17:04 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 4E330132402 for ; Mon, 7 Aug 2017 07:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 tnGXiIj4fChV for ; Mon, 7 Aug 2017 07:17:00 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 085BC1323FC for ; Mon, 7 Aug 2017 07:17:00 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l82so3474964ywc.2 for ; Mon, 07 Aug 2017 07:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+7HHySWaZWwgm0uVqviKjfpeVIAIarHlgfRN5zHYzFI=; b=eb7dGhrPBf9PSqSiqnUOyywzzW9cIo/bJsGVlwlN7xUf/ROlq6HhJ6u3w2AcpqCAt/ IhRp8qvPES4m9N2rbGAOcoeE52+3Yuw5kcnSFlzY9wFFgoRLUzWV7Nerhv/wFN908uMB 7Zsv1jkMJOfBDx2JBI+BkyZzWoqfT+meWCagawHFd2idbK0ngfFC1EuBmRscebyM6Orc ng6FEq6XTzUiCq2rqpjTPKDNqt2oMgoKc+oLYNnLkRNCwX4LXgN30Oxz2lg27QBLZvSV dcTDGKZun4cnOTxV+OQemGuZ5DYBiTztOibneS3nnX/jYH418Ggnul/bFcp9vbc6wR2s /oVg== 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=+7HHySWaZWwgm0uVqviKjfpeVIAIarHlgfRN5zHYzFI=; b=LP0y1hoEtvQjfMHzjStnUSeLxN8J6yw3AnAhvesBjCZxIAhlUOHXNHa80o0+bFUZbN QtYQtLTIMDY0vEJOSV4B3aq+wV6tsaeY5TBEVuEohlsSmHtY8uLQjcu4m1N6dNfvgxdm lXiIE0CDQGgmHZecwCkOINme6Y+nvpJEn2/iqacCbi0xasEX+kHHsIbPwenWy1ROCTR4 xBlM8VhXBLsVzQP3Ff2wLlRmcucWUawtAEDg00/G/CzgI9sCm+rU8gRNtH/SmFufLtni BffQSEONsnsEkzrGIiueAABGmOX/Zk1xN6xmTLjxVTwYpiE0M40LfApFgnRpwwydJy4G iynQ== X-Gm-Message-State: AHYfb5jkoKaPhdxWXW4dG/W/Zl8ZMAZCNMIuHvVqYyL15eN9oB9BXmty 3mHuzcD6yeN29ovNwnnONdTSwTH6LWyI X-Received: by 10.37.52.201 with SMTP id b192mr544138yba.293.1502115419097; Mon, 07 Aug 2017 07:16:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Mon, 7 Aug 2017 07:16:58 -0700 (PDT) In-Reply-To: <33fa433f-52bf-172a-9151-c7dd8153407a@isi.edu> References: <44b6345c-359b-65b3-d71e-3210f676fbbc@isi.edu> <33fa433f-52bf-172a-9151-c7dd8153407a@isi.edu> From: Spencer Dawkins at IETF Date: Mon, 7 Aug 2017 09:16:58 -0500 Message-ID: To: Joe Touch Cc: "Mirja Kuehlewind (IETF)" , "tsv-art@ietf.org" Content-Type: multipart/alternative; boundary="001a1147cb6cf790aa05562a7f66" Archived-At: Subject: Re: [Tsv-art] do we need a checklist or guidelines? X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 14:17:02 -0000 --001a1147cb6cf790aa05562a7f66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, I kept meaning to read through this thread when I had time, and kept not having time ... until now. On Thu, Jul 20, 2017 at 9:27 AM, Joe Touch wrote: > > > On 7/20/2017 5:22 AM, Mirja Kuehlewind (IETF) wrote: > > Hi Joe, > > > > I would say that the points under c) are usually already discussed and > considered in the IETF (in tcpm where we sooner or later have all these > proposals presented at least once). However, I don=E2=80=99t see a need t= o further > formalize anything here because I don=E2=80=99t see how this could help. > > > > I also think that =E2=80=9Eattack=E2=80=9C is really not the right word= here. People are > free and should be encouraged to bring their idea to the IETF/tcpm and th= en > have a discussion with the experts there figuring out if their proposed > solution is the right approach or if there are other better alternatives. > Just trying to send these people away doesn=E2=80=99t help. > The issue is similar to security considerations, congestion issues with > UDP, etc - the community *is* extending and adapting TCP and certainly > we're providing feedback, but that feedback would be a lot more > efficient if the community knew what our expectations were, IMO. > > Especially when some of these requests for transport analysis happen in > days/hours before IESG review, as is too often the case. > If I might add one thought ... When Martin was still an AD, he and I (and some of the folks who are now serving on TSV-ART, of course) were working on https://trac.ietf.org/trac/tsv/wiki/tsvdir-common-issues, which was intended to be helpful for people performing transport reviews (then TSV-DIR, now TSV-ART), and we did a fairly extensive rework just before Martin stepped down, and then I've been kind of scrolling past this item on our weekly coordination spreadsheet since Mirja became an AD - but it has been on the TSV AD coordination spreadsheet since 2014! So, I suspect that - what Joe is talking about, could reasonably be added to that checklist (there's already a section on Use of UDP, and that needs a minor update = to point to RFC 8085), in the spirit of what Joe said about telling the community what our expectations are, and - it's long past time for Spencer to talk with Mirja about any other changes that we need to make to the checklist, which I'm betting at leas= t some of the TSV-ART members don't know about, much less the rest of the community, and - it would be a good thing for us to publish that checklist in a visible place and announce it for the community. Does that make sense to other people? And, Joe, thanks for nudging me to do the right thing. Spencer > Joe > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > --001a1147cb6cf790aa05562a7f66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, I kept meaning to read through this thread when I had = time, and kept not having time ... until now.=C2=A0

On Thu, Jul 20, 2017 at 9:27 AM, Joe Touc= h <= touch@isi.edu> wrote:


On 7/20/2017 5:22 AM, Mirja Kuehlewind (IETF) wrote:
> Hi Joe,
>
> I would say that the points under c) are usually already discussed and= considered in the IETF (in tcpm where we sooner or later have all these pr= oposals presented at least once). However, I don=E2=80=99t see a need to fu= rther formalize anything here because I don=E2=80=99t see how this could he= lp.
>
> I also think that =E2=80=9Eattack=E2=80=9C is really not the right wor= d here. People are free and should be encouraged to bring their idea to the= IETF/tcpm and then have a discussion with the experts there figuring out i= f their proposed solution is the right approach or if there are other bette= r alternatives. Just trying to send these people away doesn=E2=80=99t help.=
The issue is similar to security considerations, congestion issues w= ith
UDP, etc - the community *is* extending and adapting TCP and certainly
we're providing feedback, but that feedback would be a lot more
efficient if the community knew what our expectations were, IMO.

Especially when some of these requests for transport analysis happen in
days/hours before IESG review, as is too often the case.

If I might add one thought ...

W= hen Martin was still an AD, he and I (and some of the folks who are now ser= ving on TSV-ART, of course) were working on https://trac.ietf.org/trac/tsv/wiki/t= svdir-common-issues, which was intended to be helpful for people perfor= ming transport reviews (then TSV-DIR, now TSV-ART), and we did a fairly ext= ensive rework just before Martin stepped down, and then I've been kind = of scrolling past this item on our weekly coordination spreadsheet since Mi= rja became an AD - but it has been on the TSV AD coordination spreadsheet s= ince 2014!

So, I suspect that=C2=A0
    =
  • what Joe is talking about, could reasonably be added to that checklist = (there's already a section on Use of UDP, and that needs a minor update= to point to RFC 8085), in the spirit of what Joe said about telling the co= mmunity what our expectations are, and
  • it's long past time = for Spencer to talk with Mirja about any other changes that we need to make= to the checklist, which I'm betting at least some of the TSV-ART membe= rs don't know about, much less the rest of the community, and
  • i= t would be a good thing for us to publish that checklist in a visible place= and announce it for the community.
Does that make sense to o= ther people?

And, Joe, thanks for nudging me to do= the right thing.

Spencer


Joe

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

--001a1147cb6cf790aa05562a7f66-- From nobody Tue Aug 22 11:23:48 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 E8A53132452 for ; Tue, 22 Aug 2017 11:23:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Wesley Eddy To: X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: wes@mti-systems.com, mls.ietf@gmail.com, allison.mankin@gmail.com Message-ID: <150342622688.6104.10163104636206690508.idtracker@ietfa.amsl.com> Date: Tue, 22 Aug 2017 11:23:46 -0700 Archived-At: Subject: [Tsv-art] Open review assignments in tsvart X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 18:23:47 -0000 The following reviewers have assignments: For telechat 2017-08-31 Reviewer LC end Draft Joseph Touch 2017-08-28 draft-ietf-ospf-encapsulation-cap-06 For telechat 2017-09-14 Reviewer LC end Draft Wesley Eddy 2017-08-25 draft-ietf-sfc-nsh-19 Last calls: Reviewer LC end Draft Adrian Farrel 2017-07-07 draft-ietf-teas-gmpls-lsp-fastreroute-11 Yoshifumi Nishida 2017-04-09 draft-ietf-core-coap-tcp-tls-09 * * Other revision previously reviewed ** This revision already reviewed Next in the reviewer rotation: Janardhan Iyengar Allison Mankin Yoshifumi Nishida Joerg Ott Colin Perkins Michael Scharf Martin Stiemerling Joseph Touch Brian Trammell Michael Tüxen From nobody Tue Aug 22 11:41:58 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 38BF2132A12; Tue, 22 Aug 2017 11:41:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Wesley Eddy To: Cc: ietf@ietf.org, sfc@ietf.org, draft-ietf-sfc-nsh.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150342731718.6066.9872092086965343963@ietfa.amsl.com> Date: Tue, 22 Aug 2017 11:41:57 -0700 Archived-At: Subject: [Tsv-art] Tsvart last call review of draft-ietf-sfc-nsh-19 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 18:41:57 -0000 Reviewer: Wesley Eddy Review result: Not Ready In general, the document describes the NSH structure and some loose examples of how it might be used, but this isn't a very clear protocol specification. It's mostly just about NSH format and less on the expected behaviors of NSH speakers, how to maintain state of the NSH peers or other data structures, etc. It seems like there could easily be problems in interoperations between vendors coding solely based on the document. Section 5 on fragmentation considerations is nebulous and has technical issues. Specifically, it says that PMTUD should be used when NSH is encapsulated in IP. PMTUD requires ICMP to work, and has known issues when ICMP is blocked in the path. Is there a requirement is SFC networks running NSH that ICMP needs to be carried by the network? Further, there is no discussion here on PLPMTUD versus PMTUD, nor reference to the specific RFCs, algorithms, and options or configuration parameters suggested to do this properly in SFC systems. In Section 6, the assumptions, expectations, or hard requirements for mapping NSH onto an underlying "transport" are not very clear. Only examples are given, and some of these (e.g. Ethernet) are not capable of doing things like detecting fragmentation issues. Other examples (e.g. GRE) are tunnels where there may be more state. There is no discussion about whether there are assumptions about packet ordering/reordering, duplication, losses, corruption, etc. It isn't clear why the particular encapsulations discussed have been chosen rather than UDP or TCP-based options. There should probably be more discussion about what types of network paths NSH is suitable for and that the choice of an encapsulation for NSH needs to be appropriate to the underlying path between service entities. Some encapsulations will need to be tuned for the combination of path and offered load of traffic. Some can provide much more feedback to the NSH "layer" than others that are mainly open-loop. Propagation of errors through a service function chain or signaling of errors backwards on a chain seems like it bears further discussion. From nobody Tue Aug 22 20:27:38 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25767132376; Tue, 22 Aug 2017 20:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 MqMWJDnJKJVy; Tue, 22 Aug 2017 20:27:34 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 14AB71328D9; Tue, 22 Aug 2017 20:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=a505qSeO/ciUDkKwwEI3RFOrhbVekcBHLK4gMuQsqsU=; b=Ir0JMIE8xyj6nlKe8tUthlp83m Hkmul9UZdF5YeBTGIAjHrRb8eSjayd1jnajseRYBYIFwo0dTSkywFyXkHZi/LWCW0cggzchCkScHp LMZ6g8Q/CGrgKe0jm+QIFgnE8lSJzHXzH+F/pby+WZjvITHud0cxvuk652OuosMXr3pXeWt0dKCCo 6NeGns7OZDV2J4F0mfQmbiwO5dKNp2WozoHuYcJdMmgK+fNfFQVQPeUefHGFZX2CxYS0+jiS5zxQ9 iHT8W3XcGxPtmxpQ2aZPmykAYQA1wSR/lYMkCLWZ6k9KszdtfdCkfwbVYkKEctHb5XVib0G5bNztK PUoX/usg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58380 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dkMKI-003wY3-4k; Tue, 22 Aug 2017 23:27:33 -0400 To: Wesley Eddy , tsv-art@ietf.org Cc: ietf@ietf.org, sfc@ietf.org, draft-ietf-sfc-nsh.all@ietf.org References: <150342731718.6066.9872092086965343963@ietfa.amsl.com> From: Joe Touch Message-ID: <59162f72-fc2a-8303-e0d4-cf88f92704a1@strayalpha.com> Date: Tue, 22 Aug 2017 20:27:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150342731718.6066.9872092086965343963@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-sfc-nsh-19 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 03:27:36 -0000 FWIW, this doc would benefit from consideration of the terminology developed for draft-ietf-intarea-tunnels In particular, the issue of the differences between the MTU of a hop, path, and edge-to-edge (e.g., the last including receiver reassembly). Joe On 8/22/2017 11:41 AM, Wesley Eddy wrote: > Reviewer: Wesley Eddy > Review result: Not Ready > > In general, the document describes the NSH structure and some loose examples of > how it might be used, but this isn't a very clear protocol specification. It's > mostly just about NSH format and less on the expected behaviors of NSH > speakers, how to maintain state of the NSH peers or other data structures, etc. > It seems like there could easily be problems in interoperations between > vendors coding solely based on the document. > > Section 5 on fragmentation considerations is nebulous and has technical issues. > Specifically, it says that PMTUD should be used when NSH is encapsulated in > IP. PMTUD requires ICMP to work, and has known issues when ICMP is blocked in > the path. Is there a requirement is SFC networks running NSH that ICMP needs > to be carried by the network? Further, there is no discussion here on PLPMTUD > versus PMTUD, nor reference to the specific RFCs, algorithms, and options or > configuration parameters suggested to do this properly in SFC systems. > > In Section 6, the assumptions, expectations, or hard requirements for mapping > NSH onto an underlying "transport" are not very clear. Only examples are > given, and some of these (e.g. Ethernet) are not capable of doing things like > detecting fragmentation issues. Other examples (e.g. GRE) are tunnels where > there may be more state. There is no discussion about whether there are > assumptions about packet ordering/reordering, duplication, losses, corruption, > etc. > > It isn't clear why the particular encapsulations discussed have been chosen > rather than UDP or TCP-based options. > > There should probably be more discussion about what types of network paths NSH > is suitable for and that the choice of an encapsulation for NSH needs to be > appropriate to the underlying path between service entities. Some > encapsulations will need to be tuned for the combination of path and offered > load of traffic. Some can provide much more feedback to the NSH "layer" than > others that are mainly open-loop. > > Propagation of errors through a service function chain or signaling of errors > backwards on a chain seems like it bears further discussion. > > From nobody Thu Aug 31 21:26:00 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 87E631326EA; Thu, 31 Aug 2017 21:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 lNj4CJnTsBpU; Thu, 31 Aug 2017 21:25:56 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD53132F2F; Thu, 31 Aug 2017 21:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5526; q=dns/txt; s=iport; t=1504239956; x=1505449556; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=18h61dS+FxVOuwa2vAS4aWU0I5nVf4za32bc6WH2Ilg=; b=IUnhg1LDHNtslITwBCaTGjBrP1QpXgQ5Oo8WqG0a3yTrrvN/u6iZ4ZWi ftAHhP+61LjORc4crTulpc+/b0og/Id4rZwPemOapl9iXBzUP7SCQYjsn F1x3T/6s5gLbGlCUAdxk9hDOHH8x6wN3BRvFGHYsz8anrLPOCk6Zbgeao o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AAAF4ahZ/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBeQeOEJAfgU8ilieCEoVHAhqDdT8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECASMRMxIFCwIBCA4KAgImAgICMBUQAgQOBYopCK9PgieLYgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHoENgh2CAoFOgg4LgnKEdYMTMIIxBYl1jjyIPgKUT4IThWe?= =?us-ascii?q?KdIocjCgBHziBDXcVWwGFBRyBZ3aJT4EPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,456,1498521600"; d="scan'208";a="474880743" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2017 04:25:45 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v814PjAx024706 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Sep 2017 04:25:45 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 1 Sep 2017 00:25:44 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1263.000; Fri, 1 Sep 2017 00:25:44 -0400 From: "Carlos Pignataro (cpignata)" To: Wesley Eddy CC: "tsv-art@ietf.org" , IETF Discuss , Service Function Chaining IETF list , "draft-ietf-sfc-nsh.all@ietf.org" Thread-Topic: Tsvart last call review of draft-ietf-sfc-nsh-19 Thread-Index: AQHTG3ZXOtnqynvgGkaCoRatoAbe6qKfwOGA Date: Fri, 1 Sep 2017 04:25:44 +0000 Message-ID: <55F080C0-5639-4CE7-B5E2-8F86665CB617@cisco.com> References: <150342731718.6066.9872092086965343963@ietfa.amsl.com> In-Reply-To: <150342731718.6066.9872092086965343963@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.133] Content-Type: text/plain; charset="utf-8" Content-ID: <37C63ACB55306B459192FCE044B30F02@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-sfc-nsh-19 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 04:25:58 -0000 SGVsbG8sIFdlc2xleSwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3ISBQbGVhc2UgZmluZCBzb21l IGZvbGxvdy11cHMgaW5saW5lLg0KDQrigJQNCkNhcmxvcyBQaWduYXRhcm8sIGNhcmxvc0BjaXNj by5jb20NCg0K4oCcU29tZXRpbWVzIEkgdXNlIGJpZyB3b3JkcyB0aGF0IEkgZG8gbm90IGZ1bGx5 IHVuZGVyc3RhbmQsIHRvIG1ha2UgbXlzZWxmIHNvdW5kIG1vcmUgcGhvdG9zeW50aGVzaXMuIg0K DQo+IE9uIEF1ZyAyMiwgMjAxNywgYXQgMjo0MSBQTSwgV2VzbGV5IEVkZHkgPHdlc0BtdGktc3lz dGVtcy5jb20+IHdyb3RlOg0KPiANCj4gUmV2aWV3ZXI6IFdlc2xleSBFZGR5DQo+IFJldmlldyBy ZXN1bHQ6IE5vdCBSZWFkeQ0KPiANCj4gSW4gZ2VuZXJhbCwgdGhlIGRvY3VtZW50IGRlc2NyaWJl cyB0aGUgTlNIIHN0cnVjdHVyZSBhbmQgc29tZSBsb29zZSBleGFtcGxlcyBvZg0KPiBob3cgaXQg bWlnaHQgYmUgdXNlZCwgYnV0IHRoaXMgaXNuJ3QgYSB2ZXJ5IGNsZWFyIHByb3RvY29sIHNwZWNp ZmljYXRpb24uICBJdCdzDQo+IG1vc3RseSBqdXN0IGFib3V0IE5TSCBmb3JtYXQgYW5kIGxlc3Mg b24gdGhlIGV4cGVjdGVkIGJlaGF2aW9ycyBvZiBOU0gNCj4gc3BlYWtlcnMsIGhvdyB0byBtYWlu dGFpbiBzdGF0ZSBvZiB0aGUgTlNIIHBlZXJzIG9yIG90aGVyIGRhdGEgc3RydWN0dXJlcywgZXRj Lg0KPiBJdCBzZWVtcyBsaWtlIHRoZXJlIGNvdWxkIGVhc2lseSBiZSBwcm9ibGVtcyBpbiBpbnRl cm9wZXJhdGlvbnMgYmV0d2Vlbg0KPiB2ZW5kb3JzIGNvZGluZyBzb2xlbHkgYmFzZWQgb24gdGhl IGRvY3VtZW50Lg0KPiANCj4gU2VjdGlvbiA1IG9uIGZyYWdtZW50YXRpb24gY29uc2lkZXJhdGlv bnMgaXMgbmVidWxvdXMgYW5kIGhhcyB0ZWNobmljYWwgaXNzdWVzLg0KPiBTcGVjaWZpY2FsbHks IGl0IHNheXMgdGhhdCBQTVRVRCBzaG91bGQgYmUgdXNlZCB3aGVuIE5TSCBpcyBlbmNhcHN1bGF0 ZWQgaW4NCj4gSVAuICBQTVRVRCByZXF1aXJlcyBJQ01QIHRvIHdvcmssIGFuZCBoYXMga25vd24g aXNzdWVzIHdoZW4gSUNNUCBpcyBibG9ja2VkIGluDQo+IHRoZSBwYXRoLg0KDQpQbGVhc2Ugbm90 ZSB0aGF0IHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBzY29wZWQgdG8gd2l0aGluIGEgbWFuYWdlbWVu dCBkb21haW4sIGFuZCBub3QgdGhlIG9wZW4gSW50ZXJuZXQuDQoNCkFzIHN1Y2gsIHRoZSBleHBl Y3RhdGlvbiBpcyB0aGF0IHRoZSAybmQgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNSBzdWZmaWNlcy4g QW5kIHdpdGhpbiBzYWlkIGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgaXQgaXMgYWxzbyBleHBlY3Rl ZCB0aGF0IElDTVBzIHdpbGwgbm90IGJlIGJsb2NrZWQgKGV2ZW4gd2hlbiB0aGV5IGFyZSB1bnJl bGlhYmxlIGJ5IG5hdHVyZSkuDQoNCj4gIElzIHRoZXJlIGEgcmVxdWlyZW1lbnQgaXMgU0ZDIG5l dHdvcmtzIHJ1bm5pbmcgTlNIIHRoYXQgSUNNUCBuZWVkcw0KPiB0byBiZSBjYXJyaWVkIGJ5IHRo ZSBuZXR3b3JrPyAgRnVydGhlciwgdGhlcmUgaXMgbm8gZGlzY3Vzc2lvbiBoZXJlIG9uIFBMUE1U VUQNCj4gdmVyc3VzIFBNVFVELCBub3IgcmVmZXJlbmNlIHRvIHRoZSBzcGVjaWZpYyBSRkNzLCBh bGdvcml0aG1zLCBhbmQgb3B0aW9ucyBvcg0KPiBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMgc3Vn Z2VzdGVkIHRvIGRvIHRoaXMgcHJvcGVybHkgaW4gU0ZDIHN5c3RlbXMuDQoNClRoZXJlIGlzIG5v IHJlcXVpcmVtZW50IHRoYW4gSUNNUCBpcyBjYXJyaWVkIGJ5IHRoZSBuZXR3b3JrLCBzaW5jZSBO U0ggY2FuIHJ1biBkaXJlY3RseSBvdmVyIEV0aGVybmV0IGZvciBleGFtcGxlLg0KDQpGdXJ0aGVy LCBub3RlIHRoYXQgdGhlIHJlbGV2YW50IHNlbnRlbmNlIGJlZ2luczoNCuKAnCAgIEZvciBleGFt cGxlLCB3aGVuIHRoZSBOU0ggaXMgZW5jYXBzdWxhdGVkIGluIElQLCBJUC1sZXZlbCINCk1ha2lu ZyBpdCBhbiBleGFtcGxlIGFuZCBub3QgYSBub3JtYXRpdmUgYnJvYWQgcmVxdWlyZW1lbnQuDQoN ClBMUE1UVUQgaXMgbm90IG1lbnRpb25lZCBzaW5jZSB0aGVyZSBpcyBubyBUQ1AgYW5kIG5vIG90 aGVyIHBhY2tldGl6YXRpb24gbGF5ZXIgZm9yIHdoaWNoLCB0byBteSBrbm93bGVkZ2UsIFBMUE1U VUQgaXMgc3BlY2lmaWVkLg0KDQo+IA0KPiBJbiBTZWN0aW9uIDYsIHRoZSBhc3N1bXB0aW9ucywg ZXhwZWN0YXRpb25zLCBvciBoYXJkIHJlcXVpcmVtZW50cyBmb3IgbWFwcGluZw0KPiBOU0ggb250 byBhbiB1bmRlcmx5aW5nICJ0cmFuc3BvcnQiIGFyZSBub3QgdmVyeSBjbGVhci4gIE9ubHkgZXhh bXBsZXMgYXJlDQo+IGdpdmVuLCBhbmQgc29tZSBvZiB0aGVzZSAoZS5nLiBFdGhlcm5ldCkgYXJl IG5vdCBjYXBhYmxlIG9mIGRvaW5nIHRoaW5ncyBsaWtlDQo+IGRldGVjdGluZyBmcmFnbWVudGF0 aW9uIGlzc3Vlcy4gIE90aGVyIGV4YW1wbGVzIChlLmcuIEdSRSkgYXJlIHR1bm5lbHMgd2hlcmUN Cj4gdGhlcmUgbWF5IGJlIG1vcmUgc3RhdGUuICBUaGVyZSBpcyBubyBkaXNjdXNzaW9uIGFib3V0 IHdoZXRoZXIgdGhlcmUgYXJlDQo+IGFzc3VtcHRpb25zIGFib3V0IHBhY2tldCBvcmRlcmluZy9y ZW9yZGVyaW5nLCBkdXBsaWNhdGlvbiwgbG9zc2VzLCBjb3JydXB0aW9uLA0KPiBldGMuDQoNCkkg dGhpbmsgeW91IGhhdmUgYSBnb29kIHBvaW50IGhlcmUgaW4gZW5jbG9zaW5nIOKAnHRyYW5zcG9y dOKAnSB3aXRoaW4gcXVvdGVzLiBXaGF0IGlzIG1lYW50IGhlcmUgaXMgYW4gZW5jYXBzdWxhdGlv biwgYW5kIG5vdCBhIHRyYW5zcG9ydCBpbiB0aGUgVFNWIHNlbnNlIG9mIHRoZSB0ZXJtLg0KDQpX ZSBjYW4gdXNlIG1vcmUgcHJlY2lzaW9uIG9uIHRoaXMuIFdvdWxkIHRoYXQgaGVscCBhIGJpdD8N Cg0KPiANCj4gSXQgaXNuJ3QgY2xlYXIgd2h5IHRoZSBwYXJ0aWN1bGFyIGVuY2Fwc3VsYXRpb25z IGRpc2N1c3NlZCBoYXZlIGJlZW4gY2hvc2VuDQo+IHJhdGhlciB0aGFuIFVEUCBvciBUQ1AtYmFz ZWQgb3B0aW9ucy4NCj4gDQoNClRoZSBtYXJrZXQgY2hvc2UgdGhvc2UuIE5vdGUgdGhhdCB0aGVy ZSBhcmUgVURQLWJhc2VkIG9wdGlvbnMsIHN1Y2ggYXMgVnhsYW4tZ3BlLg0KDQo+IFRoZXJlIHNo b3VsZCBwcm9iYWJseSBiZSBtb3JlIGRpc2N1c3Npb24gYWJvdXQgd2hhdCB0eXBlcyBvZiBuZXR3 b3JrIHBhdGhzIE5TSA0KPiBpcyBzdWl0YWJsZSBmb3IgYW5kIHRoYXQgdGhlIGNob2ljZSBvZiBh biBlbmNhcHN1bGF0aW9uIGZvciBOU0ggbmVlZHMgdG8gYmUNCj4gYXBwcm9wcmlhdGUgdG8gdGhl IHVuZGVybHlpbmcgcGF0aCBiZXR3ZWVuIHNlcnZpY2UgZW50aXRpZXMuICBTb21lDQo+IGVuY2Fw c3VsYXRpb25zIHdpbGwgbmVlZCB0byBiZSB0dW5lZCBmb3IgdGhlIGNvbWJpbmF0aW9uIG9mIHBh dGggYW5kIG9mZmVyZWQNCj4gbG9hZCBvZiB0cmFmZmljLiAgU29tZSBjYW4gcHJvdmlkZSBtdWNo IG1vcmUgZmVlZGJhY2sgdG8gdGhlIE5TSCAibGF5ZXIiIHRoYW4NCj4gb3RoZXJzIHRoYXQgYXJl IG1haW5seSBvcGVuLWxvb3AuDQoNClNpbmNlIHRoZXJlIGFyZSBubyByZXF1aXJlbWVudCBvZiB0 aGUgdW5kZXJseWluZyBsYXllciwgbm8gcGFydGljdWxhciBmZWVkYmFjayBuZWVkZWQuDQoNCj4g DQo+IFByb3BhZ2F0aW9uIG9mIGVycm9ycyB0aHJvdWdoIGEgc2VydmljZSBmdW5jdGlvbiBjaGFp biBvciBzaWduYWxpbmcgb2YgZXJyb3JzDQo+IGJhY2t3YXJkcyBvbiBhIGNoYWluIHNlZW1zIGxp a2UgaXQgYmVhcnMgZnVydGhlciBkaXNjdXNzaW9uLg0KPiANCj4gDQoNCk9BTSwgd2hpY2ggaW5j bHVkZXMgcHJvcGFnYXRpb24gb2YgZXJyb3JzLCBpcyBleHBsaWNpdGx5IG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoaXMgc3BlYyAoc2VlIE8gYml0IGRlZmluaXRpb24pLg0KDQpJIHdvdWxkIGxpa2Ug dG8gaGVhciB5b3VyIGZlZWRiYWNrIChhbmQsIGlkZWFsbHksIHNwZWNpZmljIHJlY29tbWVuZGF0 aW9ucyBhbmQgc3VnZ2VzdGlvbnMpIHJlZ2FyZGluZyB0aGUgdXNlIG9mIOKAnHRyYW5zcG9ydOKA nSBpbiBTZWN0aW9uIDYuDQoNClRoYW5rcyENCg0K4oCUIENhcmxvcy4NCg0KDQo=