Hi Benoit,

Thanks for the review.

I put my comments in lines.

On Tue, Feb 2, 2016 at 1:42 PM, Benoit Claise <bclaise= @cisco.com> wrote:

Benoit C= laise has entered the following ballot position for
draft-ietf-tsvwg-sctp-failover-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/s= tatement/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/dra= ft-ietf-tsvwg-sctp-failover/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As discussed by J=C3=BCrgen Sch=C3=B6nw=C3=A4der (part of this OPS DIR revi= ew) and the
authors.

J=C3=BCrgen: Since the I-D introduces the new state Potentially Failed, doe= s
this
=C2=A0 imply that an update of the SCTP-MIB [RFC3873] (sctpAssocState) is =C2=A0 needed as well? Are there additional MIB objects to report, e.g., =C2=A0 spt_pathpfthld and spt_pathcpthld? I see some additional SCTP
=C2=A0 related docs in TSVWG and perhaps after they have been completed an<= br> =C2=A0 update of the SCTP-MIB would make sense to consider.

Yoshifumi Nishida: I think it makes senses to update MIB. We'll check with implementors and other experts.
Thanks for pointing it out.

Ideally, you should add a sentence or two expressing that RFC3873 should be updated to support this functionality with a few objects that ...

OK. I think we can put some sentences for thi= s.

Thanks,
--
Yoshi

--001a114268268c1b22052ada5f0d-- From nobody Wed Feb 3 05:41:43 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 933F91AC3F1; Wed, 3 Feb 2016 05:41:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203134142.22654.10573.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 05:41:42 -0800 Archived-At: Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, draft-ietf-tsvwg-sctp-failover@ietf.org, tsvwg-chairs@ietf.org Subject: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:41:42 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-tsvwg-sctp-failover-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-tsvwg-sctp-failover/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a clearly written specification. - Should this formally UPDATE 4960? I don't care but some might:-) If you want new SCTP implementations to include this then adding the UPDATES may make sense. - 3.2, step 9: Just wondering: is this still true even if the implementation knows that the ack was received from a destination address that is currently in the PF state? (Say if all destination addresses are on different interfaces, and I can see on which interface I rx'd the ack, and that maps 1:1 with a destination address in the PF state.) From nobody Wed Feb 3 08:24:40 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4952B1AD36F; Wed, 3 Feb 2016 08:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 taQ0wq3dgnU6; Wed, 3 Feb 2016 08:24:35 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 F28561AD36B; Wed, 3 Feb 2016 08:24:34 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u13GOSga020767 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Feb 2016 10:24:29 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Yoshifumi Nishida" Date: Wed, 03 Feb 2016 10:24:27 -0600 Message-ID: In-Reply-To: References: <20160202225623.24909.58704.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Cc: "gorry@erg.abdn.ac.uk" , tsvwg-chairs@ietf.org, tsvwg , The IESG , draft-ietf-tsvwg-sctp-failover@ietf.org Subject: Re: [tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 16:24:36 -0000 Thanks for the response. Comments inline: Ben. On 3 Feb 2016, at 3:31, Yoshifumi Nishida wrote: > Hi Ben, > > Thank you so much for very detailed comments. > I put my comments in line > . > [...] >> > > Yes, If PFMR is bigger than zero, there's a situation where a path has > a > non-zero error count, but not haven't entered the PF state. > In this case, the path stays in active state which is the current SCTP > behavior based on RFC4960. > The error counter must not be reset as it prevents entering PF state > after > proceeding errors. > In other words, by setting PFMR bigger than zero, you can delay > launching > SCTP-PF logic. Does that mean that the error-count cannot be reset prior to entering the PF state? What if you get a successful heartbeat or a data acknowledgment prior to reaching PFMR? [...] > >> - 6: The recommended value for PFMR is redundant with an earlier >> section. >> > > Yes, It's actually rather intentional. We tried to make it very > explicit... > Do you suggest to remove this? It's up to you. Redundant 2119 keywords can make things error prone for future updates. OTOH, they are in the same draft, and they are currently consistent, so it's not a huge deal. > >> >> Editorial: >> >> - There are a number of places where paragraphs are put into long >> numbered lists for no apparent reason. Could those not just be normal >> paragraphs? As it is, I keep getting section numbers and paragraph >> numbers confused. >> > > Yes, it's a bit confusing, but we might want to use lists here if > possible. > How about using (1) or (A) instead of simple number? > Maybe. It's probably even okay as is, as long as it's on "purpose" :-) > >> >> - 3.2, 4, last paragraph: >> The current wording can be interpreted ambiguously. I think you mean >> the >> following: >> OLD >> The sender MUST NOT change the state and the error counter of >> any destination address regardless of whether it has been chosen >> for transmission or not. >> NEW >> The sender MUST NOT change the state and the error counter of >> any destination address simply because it has been chosen for >> transmission. >> END >> > > Hmm. I might be wrong. But, the new sentence might not prohibit > changing > the state or error count when the destination address has not been > chosen > for transmission. Please let me know if I miss something. Isn't this section about destination selection? Why would it need to talk about cases that don't involve destination selection. As currently stated, someone could read it to mean you can never change the state and error count at all. I note that the similar guidance in other sections uses language of the form of "as a result of choosing the destination address for data transmission." [...] From nobody Wed Feb 3 11:06:07 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B831B2B54; Wed, 3 Feb 2016 11:06:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203190604.29151.45386.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 11:06:04 -0800 Archived-At: Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, draft-ietf-tsvwg-sctp-failover@ietf.org, tsvwg-chairs@ietf.org Subject: [tsvwg] Barry Leiba's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 19:06:04 -0000 Barry Leiba has entered the following ballot position for draft-ietf-tsvwg-sctp-failover-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-tsvwg-sctp-failover/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In addition to the 2119 issues that Ben has raised... In Section 3.2 bullet 1: The RECOMMENDED value of PFMR is 0, but other values MAY be used. "SHOULD do X, but MAY do Y" makes no sense. In this case, you can (should) just remove "but other values MAY be used". You might instead say *why* 0 is recommended at a 2119 level (implying that it has interoperability implications). In bullet 9, I found this to be oddly worded: A SCTP sender MAY clear the error counter and move a destination address back to active state if it has other information, than the acknowledgment, that uniquely determines which destination, among multiple destination addresses, the chunk reached. Perhaps this?: NEW A SCTP sender MAY clear the error counter and move a destination address back to active state if it has information other than the acknowledgment that uniquely determines which destination, among multiple destination addresses, the chunk reached. END From nobody Wed Feb 3 13:31:44 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52C01B2D64; Wed, 3 Feb 2016 13:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.577 X-Spam-Level: ** X-Spam-Status: No, score=2.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 hXooPCDPKTD6; Wed, 3 Feb 2016 13:31:35 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2DBC1B2D5F; Wed, 3 Feb 2016 13:31:34 -0800 (PST) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C63C52781DC; Thu, 4 Feb 2016 06:31:32 +0900 (JST) Received: by mail-yw0-f179.google.com with SMTP id g127so13142926ywf.2; Wed, 03 Feb 2016 13:31:32 -0800 (PST) X-Gm-Message-State: AG10YORZkACVP8q9BO7/4yqufLa6prrB9vJYiOGTtw7NdC/yP6uM32YU3OHr3ztkN4jsIjX8wL6SlibowWkCYQ== MIME-Version: 1.0 X-Received: by 10.13.205.199 with SMTP id p190mr2325845ywd.116.1454535091272; Wed, 03 Feb 2016 13:31:31 -0800 (PST) Received: by 10.13.196.3 with HTTP; Wed, 3 Feb 2016 13:31:31 -0800 (PST) In-Reply-To: <20160203134142.22654.10573.idtracker@ietfa.amsl.com> References: <20160203134142.22654.10573.idtracker@ietfa.amsl.com> Date: Wed, 3 Feb 2016 13:31:31 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a114e5eb66dc9e8052ae45738 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , tsvwg-chairs@ietf.org, tsvwg , The IESG , draft-ietf-tsvwg-sctp-failover@ietf.org Subject: Re: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 21:31:39 -0000 --001a114e5eb66dc9e8052ae45738 Content-Type: text/plain; charset=UTF-8 Hi Stephan, Thanks for the comments. On Wed, Feb 3, 2016 at 5:41 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-tsvwg-sctp-failover-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-tsvwg-sctp-failover/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > Thanks for a clearly written specification. > > - Should this formally UPDATE 4960? I don't care but some > might:-) If you want new SCTP implementations to include > this then adding the UPDATES may make sense. > Yes, this has been brought up several times. After some discussions with folks include 4960 authors, we have chosen this. If necessary, we can revisit this point. > > - 3.2, step 9: Just wondering: is this still true even if > the implementation knows that the ack was received from a > destination address that is currently in the PF state? > (Say if all destination addresses are on different > interfaces, and I can see on which interface I rx'd the > ack, and that maps 1:1 with a destination address in the PF > state.) > This is SHOULD statement. So, if an implementation can utilize some info outside of SCTP, it can override it. Regards, -- Yoshi --001a114e5eb66dc9e8052ae45738 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Stephan,

Thanks for the comments.

On Wed, Feb 3, 2016 at 5:41 AM,= Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:<= br>

Stephen Farrell has entered the following= ballot position for
draft-ietf-tsvwg-sctp-failover-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/s= tatement/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/dra= ft-ietf-tsvwg-sctp-failover/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for a clearly written specification.

- Should this formally UPDATE 4960? I don't care but some
might:-) If you want new SCTP implementations to include
this then adding the UPDATES may make sense.

Yes, this has been brought up several times.=C2=A0

After so= me discussions with folks include 4960 authors, we have chosen this.=C2=A0<= /div>

If necessary, we can revisit this point.

- 3.2, step 9: Just wondering: is this still true even if
the implementation knows that the ack was received from a
destination address that is currently in the PF state?
(Say if all destination addresses are on different
interfaces, and I can see on which interface I rx'd the
ack, and that maps 1:1 with a destination address in the PF
state.)

This is SHOULD statement. So, i= f an implementation can utilize some info outside of SCTP, it can override = it.

Regards,

Yoshi

--001a114e5eb66dc9e8052ae45738-- From nobody Wed Feb 3 19:46:43 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883031B3920; Wed, 3 Feb 2016 19:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.224 X-Spam-Level: ** X-Spam-Status: No, score=2.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 20AYdVUPNMRH; Wed, 3 Feb 2016 19:46:39 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 355491B3921; Wed, 3 Feb 2016 19:46:38 -0800 (PST) Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C294B2781A4; Thu, 4 Feb 2016 12:46:36 +0900 (JST) Received: by mail-yk0-f180.google.com with SMTP id r207so35545680ykd.2; Wed, 03 Feb 2016 19:46:36 -0800 (PST) X-Gm-Message-State: AG10YORRH4pBhArgFnaJOI5JDhRNrdZ6m+V8TxzTIoZyJUqrvAJpZDgLVCLPcnkjV9mdaw0/TKVAuhEXzMyTWw== MIME-Version: 1.0 X-Received: by 10.37.86.7 with SMTP id k7mr2782904ybb.82.1454557595482; Wed, 03 Feb 2016 19:46:35 -0800 (PST) Received: by 10.13.196.3 with HTTP; Wed, 3 Feb 2016 19:46:35 -0800 (PST) In-Reply-To: References: <20160202225623.24909.58704.idtracker@ietfa.amsl.com>

Date: Wed, 3 Feb 2016 19:46:35 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: Ben Campbell Content-Type: multipart/alternative; boundary=001a11426826c8cf7c052ae9944b Archived-At: Cc: "gorry@erg.abdn.ac.uk" , tsvwg , tsvwg-chairs@ietf.org, draft-ietf-tsvwg-sctp-failover@ietf.org, The IESG Subject: Re: [tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 03:46:41 -0000 --001a11426826c8cf7c052ae9944b Content-Type: text/plain; charset=UTF-8 Hi Ben, Thanks for the comments. On Wed, Feb 3, 2016 at 8:24 AM, Ben Campbell wrote: > > Thanks for the response. Comments inline: > > Ben. > > On 3 Feb 2016, at 3:31, Yoshifumi Nishida wrote: > > Hi Ben, >> >> Thank you so much for very detailed comments. >> I put my comments in line >> . >> >> > [...] > > >>> >> Yes, If PFMR is bigger than zero, there's a situation where a path has a >> non-zero error count, but not haven't entered the PF state. >> In this case, the path stays in active state which is the current SCTP >> behavior based on RFC4960. >> The error counter must not be reset as it prevents entering PF state after >> proceeding errors. >> In other words, by setting PFMR bigger than zero, you can delay launching >> SCTP-PF logic. >> > > Does that mean that the error-count cannot be reset prior to entering the > PF state? What if you get a successful heartbeat or a data acknowledgment > prior to reaching PFMR? > When the path is in active state, it just follows RFC4960 descriptions. So, in this case, the error count will be reset as specified in the RFC. This draft specifies how to enter PF state and how to behave in PF state, but doesn't specify the behavior in active state. I think we can put some clarifications of this if that will be helpful. > > [...] > > >> - 6: The recommended value for PFMR is redundant with an earlier >>> section. >>> >>> >> Yes, It's actually rather intentional. We tried to make it very >> explicit... >> Do you suggest to remove this? >> > > It's up to you. Redundant 2119 keywords can make things error prone for > future updates. OTOH, they are in the same draft, and they are currently > consistent, so it's not a huge deal. Editorial: >>> >>> - There are a number of places where paragraphs are put into long >>> numbered lists for no apparent reason. Could those not just be normal >>> paragraphs? As it is, I keep getting section numbers and paragraph >>> numbers confused. >>> >>> >> Yes, it's a bit confusing, but we might want to use lists here if >> possible. >> How about using (1) or (A) instead of simple number? >> >> > Maybe. It's probably even okay as is, as long as it's on "purpose" :-) OK. > > >> >>> - 3.2, 4, last paragraph: >>> The current wording can be interpreted ambiguously. I think you mean the >>> following: >>> OLD >>> The sender MUST NOT change the state and the error counter of >>> any destination address regardless of whether it has been chosen >>> for transmission or not. >>> NEW >>> The sender MUST NOT change the state and the error counter of >>> any destination address simply because it has been chosen for >>> transmission. >>> END >>> >>> >> Hmm. I might be wrong. But, the new sentence might not prohibit changing >> the state or error count when the destination address has not been chosen >> for transmission. Please let me know if I miss something. >> > > Isn't this section about destination selection? Why would it need to talk > about cases that don't involve destination selection. As currently stated, > someone could read it to mean you can never change the state and error > count at all. > I see your point. I am thinking about using the following sentence to make it clear on this point. "The sender MUST NOT change the state and the error counter of any destination addresses as the result of the selection." Thanks! -- Yoshi --001a11426826c8cf7c052ae9944b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Ben,

Thanks for the comments.

On Wed, Feb 3, = 2016 at 8:24 AM, Ben Campbell <ben@nostrum.com> wrote:

Thanks for the response. Comments inline:

Ben.

On 3 Feb 2016, at 3:31, Yoshifumi Nishida wrote:

Hi Ben,

Thank you so much for very detailed comments.
I put my comments in line
.

[...]

Yes, If PFMR is bigger than zero, there's a situation where a path has = a
non-zero error count, but not haven't entered the PF state.
In this case, the path stays in active state which is the current SCTP
behavior based on RFC4960.
The error counter must not be reset as it prevents entering PF state after<= br> proceeding errors.
In other words, by setting PFMR bigger than zero, you can delay launching SCTP-PF logic.

Does that mean that the error-count cannot be reset prior to entering the P= F state? What if you get a successful heartbeat or a data acknowledgment pr= ior to reaching PFMR?

When the path is = in active state, it just follows RFC4960 descriptions. So, in this case, th= e error count will be reset as specified in the RFC.

This dra= ft specifies how to enter PF state and how to behave in PF state, but doesn= 't specify the behavior in active state.

I think we can put s= ome clarifications of this if that will be helpful.

=C2=A0

[...]

- 6: The recommended value for PFMR is redundant with an earlier
section.

Yes, It's actually rather intentional. We tried to make it very explici= t...
Do you suggest to remove this?

It's up to you. Redundant 2119 keywords can make things error prone for= future updates. OTOH, they are in the same draft, and they are currently c= onsistent, so it's not a huge deal.=C2=A0

=
Editorial:

- There are a number of places where paragraphs are put into long
numbered lists for no apparent reason. Could those not just be normal
paragraphs?=C2=A0 As it is, I keep getting section numbers and paragraph numbers confused.

Yes, it's a bit confusing, but we might want to use lists here if possi= ble.
How about using (1) or (A) instead of simple number?

Maybe. It's probably even okay as is, as long as it's on "purp= ose" :-)

OK. =C2=A0

- 3.2, 4, last paragraph:
The current wording can be interpreted ambiguously. I think you mean the following:
OLD
The sender MUST NOT change the state and the error counter of
=C2=A0any destination address regardless of whether it has been chosen
=C2=A0for transmission or not.
NEW
The sender MUST NOT change the state and the error counter of
=C2=A0any destination address simply because it has been chosen for
=C2=A0transmission.
END

Hmm. I might be wrong. But, the new sentence might not prohibit changing the state or error count when the destination address has not been chosen for transmission. Please let me know if I miss something.

Isn't this section about destination selection? Why would it need to ta= lk about cases that don't involve destination selection. As currently s= tated, someone could read it to mean you can never change the state and err= or count at all.

=C2=A0

I see your point. I = am thinking about using the following sentence to make it clear on this poi= nt.

"The sender MUST NOT change the state and= the error counter of any destination addresses as the result of the select= ion."

Thanks!

Yoshi

--001a11426826c8cf7c052ae9944b-- From nobody Wed Feb 3 20:12:22 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFCF1B3954; Wed, 3 Feb 2016 20:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 aERx3RRzWxbe; Wed, 3 Feb 2016 20:12:19 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 603AE1B3953; Wed, 3 Feb 2016 20:12:19 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u144CE1P097436 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Feb 2016 22:12:14 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Yoshifumi Nishida" Date: Wed, 03 Feb 2016 22:12:13 -0600 Message-ID: In-Reply-To: References: <20160202225623.24909.58704.idtracker@ietfa.amsl.com>

MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5213) Archived-At: Cc: "gorry@erg.abdn.ac.uk" , tsvwg-chairs@ietf.org, tsvwg , The IESG , draft-ietf-tsvwg-sctp-failover@ietf.org Subject: Re: [tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 04:12:21 -0000 On 3 Feb 2016, at 21:46, Yoshifumi Nishida wrote: > Hi Ben, > > Thanks for the comments. > > On Wed, Feb 3, 2016 at 8:24 AM, Ben Campbell wrote: > >> >> Thanks for the response. Comments inline: >> >> Ben. >> >> On 3 Feb 2016, at 3:31, Yoshifumi Nishida wrote: >> >> Hi Ben, >>> >>> Thank you so much for very detailed comments. >>> I put my comments in line >>> . >>> >>> >> [...] >> >> >>>> >>> Yes, If PFMR is bigger than zero, there's a situation where a path >>> has a >>> non-zero error count, but not haven't entered the PF state. >>> In this case, the path stays in active state which is the current >>> SCTP >>> behavior based on RFC4960. >>> The error counter must not be reset as it prevents entering PF state >>> after >>> proceeding errors. >>> In other words, by setting PFMR bigger than zero, you can delay >>> launching >>> SCTP-PF logic. >>> >> >> Does that mean that the error-count cannot be reset prior to entering >> the >> PF state? What if you get a successful heartbeat or a data >> acknowledgment >> prior to reaching PFMR? >> > > When the path is in active state, it just follows RFC4960 > descriptions. So, > in this case, the error count will be reset as specified in the RFC. > This draft specifies how to enter PF state and how to behave in PF > state, > but doesn't specify the behavior in active state. > I think we can put some clarifications of this if that will be > helpful. I see, and that makes sense. It might be helpful to add a sentence (unless it's already there and I missed it) to mention this is handled as per 4960. [...] >> >> >>> >>>> - 3.2, 4, last paragraph: >>>> The current wording can be interpreted ambiguously. I think you >>>> mean the >>>> following: >>>> OLD >>>> The sender MUST NOT change the state and the error counter of >>>> any destination address regardless of whether it has been chosen >>>> for transmission or not. >>>> NEW >>>> The sender MUST NOT change the state and the error counter of >>>> any destination address simply because it has been chosen for >>>> transmission. >>>> END >>>> >>>> >>> Hmm. I might be wrong. But, the new sentence might not prohibit >>> changing >>> the state or error count when the destination address has not been >>> chosen >>> for transmission. Please let me know if I miss something. >>> >> >> Isn't this section about destination selection? Why would it need to >> talk >> about cases that don't involve destination selection. As currently >> stated, >> someone could read it to mean you can never change the state and >> error >> count at all. >> > > I see your point. I am thinking about using the following sentence to > make > it clear on this point. > > "The sender MUST NOT change the state and the error counter of any > destination addresses as the result of the selection." That would help, thanks. > Ben. From nobody Wed Feb 3 21:38:43 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D4D1A9073; Wed, 3 Feb 2016 21:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.23 X-Spam-Level: * X-Spam-Status: No, score=1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 YKvHxH-24HfI; Wed, 3 Feb 2016 21:38:37 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180B61A9071; Wed, 3 Feb 2016 21:38:36 -0800 (PST) Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BDF54278224; Thu, 4 Feb 2016 14:38:34 +0900 (JST) Received: by mail-yk0-f169.google.com with SMTP id u9so36212870ykd.1; Wed, 03 Feb 2016 21:38:34 -0800 (PST) X-Gm-Message-State: AG10YOS99BR4XSzzhuyorFDc6wEmYgSe1lnY7QWJOL6pvlbFde4W4vVfc3EYECxg3y9sGQmyzaxBc+uwwqhAwg== MIME-Version: 1.0 X-Received: by 10.37.90.215 with SMTP id o206mr2992194ybb.85.1454564313518; Wed, 03 Feb 2016 21:38:33 -0800 (PST) Received: by 10.13.196.3 with HTTP; Wed, 3 Feb 2016 21:38:33 -0800 (PST) In-Reply-To: <20160203190604.29151.45386.idtracker@ietfa.amsl.com> References: <20160203190604.29151.45386.idtracker@ietfa.amsl.com> Date: Wed, 3 Feb 2016 21:38:33 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: Barry Leiba Content-Type: multipart/alternative; boundary=001a1142593835dfef052aeb25f4 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , tsvwg-chairs@ietf.org, tsvwg , The IESG , draft-ietf-tsvwg-sctp-failover@ietf.org Subject: Re: [tsvwg] Barry Leiba's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 05:38:39 -0000 --001a1142593835dfef052aeb25f4 Content-Type: text/plain; charset=UTF-8 Hi Barry, Thanks for the comments. Please see inlines. On Wed, Feb 3, 2016 at 11:06 AM, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-tsvwg-sctp-failover-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-tsvwg-sctp-failover/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In addition to the 2119 issues that Ben has raised... > > In Section 3.2 bullet 1: > > The RECOMMENDED value of PFMR is > 0, but other values MAY be used. > "SHOULD do X, but MAY do Y" makes no sense. In this case, you can > (should) just remove "but other values MAY be used". You might instead > say *why* 0 is recommended at a 2119 level (implying that it has > interoperability implications). > OK. We will remove "but..". > > In bullet 9, I found this to be oddly worded: > > A SCTP sender MAY clear the error counter > and move a destination address back to active state if it has > other information, than the acknowledgment, that uniquely > determines which destination, among multiple destination > addresses, the chunk reached. > > Perhaps this?: > > NEW > A SCTP sender MAY clear the error counter > and move a destination address back to active state if it has > information other than the acknowledgment that uniquely > determines which destination, among multiple destination > addresses, the chunk reached. > END > I see. I might want to disambiguate "that uniquely..." part just in case. How about something like this? A SCTP sender MAY clear the error counter and move a destination address back to active state by other information than acknowledgments when it can uniquely determine which destination, among multiple destination addresses, the chunk reached. Thanks, -- Yoshi --001a1142593835dfef052aeb25f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Barry,

Thanks for the comments. Plea= se see inlines.

On Wed, Feb 3, 2016 at 11:06 AM, Barry Leiba <barryleiba@computer.= org> wrote:

Barry Leiba has entered the f= ollowing ballot position for
draft-ietf-tsvwg-sctp-failover-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/s= tatement/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/dra= ft-ietf-tsvwg-sctp-failover/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In addition to the 2119 issues that Ben has raised...

In Section 3.2 bullet 1:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The RECOMMENDED value of PFMR is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 0, but other values MAY be used.=C2=A0

"SHOULD do X, but MAY do Y" makes no sense.=C2=A0 In this case, y= ou can
(should) just remove "but other values MAY be used".=C2=A0 You mi= ght instead
say *why* 0 is recommended at a 2119 level (implying that it has
interoperability implications).

OK. We will remove "but..".
=C2=A0

In bullet 9, I found this to be oddly worded:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 A SCTP sender MAY clear the error counter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and move a destination address back to active s= tate if it has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other information, than the acknowledgment, tha= t uniquely
=C2=A0 =C2=A0 =C2=A0 =C2=A0 determines which destination, among multiple de= stination
=C2=A0 =C2=A0 =C2=A0 =C2=A0 addresses, the chunk reached.

Perhaps this?:

NEW
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A SCTP sender MAY clear the error counter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and move a destination address back to active s= tate if it has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 information other than the acknowledgment that = uniquely
=C2=A0 =C2=A0 =C2=A0 =C2=A0 determines which destination, among multiple de= stination
=C2=A0 =C2=A0 =C2=A0 =C2=A0 addresses, the chunk reached.
END

I see. I might want to disambiguate= "that uniquely..." part just in case. How about something like t= his?

A SCTP sender MAY clear the error counter and= move a destination address back to active state by

other informa= tion than acknowledgments when it can uniquely=C2=A0determine which destina= tion,=C2=A0

among multiple destination addresses, the chunk reach= ed.

Thanks,

Yoshi

--001a1142593835dfef052aeb25f4-- From nobody Thu Feb 4 05:37:17 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3C71B2F4F; Thu, 4 Feb 2016 05:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 1tZwBkhO14pY; Thu, 4 Feb 2016 05:37:13 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 1960F1B2F4E; Thu, 4 Feb 2016 05:37:13 -0800 (PST) Received: by mail-ig0-x22e.google.com with SMTP id hb3so34869922igb.0; Thu, 04 Feb 2016 05:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Cea83ibE0Qin3Rf39yQyKlW5L4YDgd2LdPQMmk7/R78=; b=C6Yp0F4Y0fWgw26D6LPF9tWrS8n//64pDRs2OaW4PR+oQg1IZbGkgdahWrSCki1YI1 NB/9Nlaf/Oyz6CP+eHG9vOHjHAY7J8F4sfAnA8D+qSx7MbntkIHr34Joxr4L3wZ7KPxs 52MZeKXdVmYIKHiKenxcJcWnmqNkHWSDZQtVkasspZhqJy1qNdDg1SO7OCsCx0hz3Vzc URRJ0bSFL/wKbz4AiW5kxu7BsOcjGfzt+6KB56dnRGOiBD4t9KAnJCu27vnrufTqctiE qwoqTXvhQgebApjDXSm6+mrEMtqLgT/wq2rdHn7ZE4uTRexdU6CPCMLCh48pE5ncnt74 0yKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Cea83ibE0Qin3Rf39yQyKlW5L4YDgd2LdPQMmk7/R78=; b=etiUGZ6RGj36rZ4fbCAdZqYjglEfrOa1ua73lhMuE2t5ozzGPXSFaR6gr0G4AYn/vF d962T0+5ZWiDxsptlGL3qCbJCUwHC3fj/ryR7okKCz/xGjHsOCkBnryCZgyvWZ8axOfN LOAqxs/QLPrf/RIOSF9KGkrSGczb0mfQ7G+ARxJ+4tNVdzJ+1NcyScjcJI7cxF5c7RMH Efv0lGE+CQmVNUYq18MHcv5nV/1HsMNTwbJw7YYkIgi31pvA8fHeHGcA3ZiKnkU0byoP h+hNHIlQI6jSKFyIOCu/SYiJaW3AqPQqJaIWHJkmxRptguYJYCq6VwqPLv3eFRhqRdhV Q8EA== X-Gm-Message-State: AG10YOS3XOCguoaCx+YOUYZlIn36ByniwX8O8iaz81JPTKxIKim+nIn5YQiUEoWFyIDusVvWiy7LpkLp7R5blQ== MIME-Version: 1.0 X-Received: by 10.50.142.68 with SMTP id ru4mr10161778igb.54.1454593032538; Thu, 04 Feb 2016 05:37:12 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.156.5 with HTTP; Thu, 4 Feb 2016 05:37:12 -0800 (PST) In-Reply-To: References: <20160203190604.29151.45386.idtracker@ietfa.amsl.com> Date: Thu, 4 Feb 2016 08:37:12 -0500 X-Google-Sender-Auth: Fj-PSunQI6xBEMDNjEoj1TxRp-s Message-ID: From: Barry Leiba To: Yoshifumi Nishida Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , The IESG , draft-ietf-tsvwg-sctp-failover@ietf.org, "tsvwg-chairs@ietf.org" , tsvwg Subject: Re: [tsvwg] Barry Leiba's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 13:37:14 -0000 >> In bullet 9, I found this to be oddly worded: >> >> A SCTP sender MAY clear the error counter >> and move a destination address back to active state if it has >> other information, than the acknowledgment, that uniquely >> determines which destination, among multiple destination >> addresses, the chunk reached. >> >> Perhaps this?: >> >> NEW >> A SCTP sender MAY clear the error counter >> and move a destination address back to active state if it has >> information other than the acknowledgment that uniquely >> determines which destination, among multiple destination >> addresses, the chunk reached. >> END > > I see. I might want to disambiguate "that uniquely..." part just in case. > How about something like this? > > A SCTP sender MAY clear the error counter and move a destination address > back to active state by > other information than acknowledgments when it can uniquely determine which > destination, > among multiple destination addresses, the chunk reached. Part of the oddness is "other information than acknowledgments", which seems to be awkward English usage; "information other than acknowledgments" reads better. I would also put a comma after that, to end up with this, after your change and mine: NEW A SCTP sender MAY clear the error counter and move a destination address back to active state by information other than acknowledgments, when it can uniquely determine which destination, among multiple destination addresses, the chunk reached. END Thanks for the quick response, Barry From nobody Thu Feb 4 09:22:59 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3DA1A1A27; Thu, 4 Feb 2016 09:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3RISZeY6fqDe; Thu, 4 Feb 2016 09:22:55 -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 92AA81A002C; Thu, 4 Feb 2016 09:22:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDY44279; Thu, 04 Feb 2016 17:22:51 +0000 (GMT) Received: from lhreml704-cah.china.huawei.com (10.201.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 4 Feb 2016 17:22:49 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 4 Feb 2016 17:22:49 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0235.001; Thu, 4 Feb 2016 09:22:44 -0800 From: Linda Dunbar To: "draft-ietf-tsvwg-circuit-breaker@ietf.org" , "ops-dir@ietf.org" , "ops-ads@tools.ietf.org" , "tsvwg@ietf.org" Thread-Topic: review comments to draft-ietf-tsvwg-circuit-breaker-11 Thread-Index: AdFfcKiUd2SscsOJQXSDBn9IGJAp/w== Date: Thu, 4 Feb 2016 17:22:44 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DE716B@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.190] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DE716Bdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56B388EC.007A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 15893b89674ec88e852f9f2ef2b2e3d8 Archived-At: Subject: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 17:22:58 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657DE716Bdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These = comments were written with the intent of improving the operational aspects = of the IETF drafts. Comments that are not addressed in last call may be inc= luded in AD reviews during the IESG review. Document editors and WG chairs = should treat these comments just like any other last call comments. Major issue with the proposed approach: Traffic continuously go from Ingress and egress. If the Ingress and egress nodes don't have synchronized timers as SONET/SD= H (most packet routers/switches don't have synchronized timer), the meters = collected by both ends can't be correlated properly (i.e. they are meaning= less). The only ways for the meters on both Ingress and Egress to work reliably (w= ithout synchronized timer) is via ECN, or via synthetic data (like IPPM). For "Circuit Breaker based on RTP", DPI has to be deployed to detect RTP if= the Ingress and egress nodes are the end points of tunnel (i.e. aggregated= traffic). The approach is very expensive. Minor issue: Typos: - Page 5: The paragraph before 1.1: "Circuit Breaker has in fact being tripped": do you mean "being triggered"? Regards, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657DE716Bdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have= reviewed this document as part of the Operational directorate's ongoing ef= fort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational a= spects of the IETF drafts. Comments that are not addressed in last call may= be included in AD reviews during the IESG review. Document editors and WG = chairs should treat these comments just like any other last call comments.

Major = issue with the proposed approach:

&= nbsp;

Traffi= c continuously go from Ingress and egress.

If the= Ingress and egress nodes don’t have synchronized timers as SON= ET/SDH (most packet routers/switches don’t have synchronized timer), the meters collected by both ends can’t be correlated properly= (i.e. they are meaningless).

&= nbsp;

The on= ly ways for the meters on both Ingress and Egress to work reliably (without= synchronized timer) is via ECN, or via synthetic data (like IPPM).

&= nbsp;

For &#= 8220;Circuit Breaker based on RTP”, DPI has to be deployed to detect = RTP if the Ingress and egress nodes are the end points of tunnel (i.e. aggregated traffic). The approach is very expensive.

&= nbsp;

Minor issue:

Typos:

- &= nbsp; Page 5: The paragraph before 1.1:<= /p>

“Circuit Breaker ha= s in fact being tripped”: do you mean “being triggered”?

Regards, Linda D= unbar

--_000_4A95BA014132FF49AE685FAB4B9F17F657DE716Bdfweml701chm_-- From nobody Thu Feb 4 18:04:57 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7401B2C96; Thu, 4 Feb 2016 18:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.23 X-Spam-Level: * X-Spam-Status: No, score=1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 VzDkplLaCLOz; Thu, 4 Feb 2016 18:04:55 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE721B2C8C; Thu, 4 Feb 2016 18:04:54 -0800 (PST) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id EE68E278259; Fri, 5 Feb 2016 11:04:52 +0900 (JST) Received: by mail-yk0-f174.google.com with SMTP id z7so53583277yka.3; Thu, 04 Feb 2016 18:04:52 -0800 (PST) X-Gm-Message-State: AG10YOQ46bgpXjS53wzPmAsBKE2+oPTQHabsOVDQBUKgNit9viFoSz+LVL9/H6eDpgVYucYe9w6cbVLD/FFP1w== MIME-Version: 1.0 X-Received: by 10.37.57.195 with SMTP id g186mr5821990yba.38.1454637891614; Thu, 04 Feb 2016 18:04:51 -0800 (PST) Received: by 10.13.196.3 with HTTP; Thu, 4 Feb 2016 18:04:51 -0800 (PST) In-Reply-To: References: <20160203190604.29151.45386.idtracker@ietfa.amsl.com>

Date: Thu, 4 Feb 2016 18:04:51 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: Barry Leiba Content-Type: multipart/alternative; boundary=94eb2c08e18ace83de052afc4644 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "tsvwg-chairs@ietf.org" , tsvwg , draft-ietf-tsvwg-sctp-failover@ietf.org, The IESG Subject: Re: [tsvwg] Barry Leiba's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 02:04:57 -0000 --94eb2c08e18ace83de052afc4644 Content-Type: text/plain; charset=UTF-8 Hi Barry, On Thu, Feb 4, 2016 at 5:37 AM, Barry Leiba wrote: > >> In bullet 9, I found this to be oddly worded: > >> > >> A SCTP sender MAY clear the error counter > >> and move a destination address back to active state if it has > >> other information, than the acknowledgment, that uniquely > >> determines which destination, among multiple destination > >> addresses, the chunk reached. > >> > >> Perhaps this?: > >> > >> NEW > >> A SCTP sender MAY clear the error counter > >> and move a destination address back to active state if it has > >> information other than the acknowledgment that uniquely > >> determines which destination, among multiple destination > >> addresses, the chunk reached. > >> END > > > > I see. I might want to disambiguate "that uniquely..." part just in case. > > How about something like this? > > > > A SCTP sender MAY clear the error counter and move a destination address > > back to active state by > > other information than acknowledgments when it can uniquely determine > which > > destination, > > among multiple destination addresses, the chunk reached. > > Part of the oddness is "other information than acknowledgments", which > seems to be awkward English usage; "information other than > acknowledgments" reads better. I would also put a comma after that, > to end up with this, after your change and mine: > > NEW > A SCTP sender MAY clear the error counter and move a destination > address back to active state by information other than > acknowledgments, when it can uniquely determine which destination, > among multiple destination addresses, the chunk reached. > END Got it. Thanks for the suggestion. I'll update the draft. Regards, -- Yoshi --94eb2c08e18ace83de052afc4644 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Barry,

On Thu, Feb 4, 2016 at 5:37 AM, Barry Leiba = <barryleiba= @computer.org> wrote:

>> In bullet 9, I found this to be oddly worded:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A SCTP sender MAY clear the error= counter
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and move a destination address ba= ck to active state if it has
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other information, than the ackno= wledgment, that uniquely
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0determines which destination, amo= ng multiple destination
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses, the chunk reached.
>>
>> Perhaps this?:
>>
>> NEW
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A SCTP sender MAY clear the error= counter
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and move a destination address ba= ck to active state if it has
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information other than the acknow= ledgment that uniquely
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0determines which destination, amo= ng multiple destination
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses, the chunk reached.
>> END
>
> I see. I might want to disambiguate "that uniquely..." part = just in case.
> How about something like this?
>
> A SCTP sender MAY clear the error counter and move a destination addre= ss
> back to active state by
> other information than acknowledgments when it can uniquely determine = which
> destination,
> among multiple destination addresses, the chunk reached.

Part of the oddness is "other information than acknowledgments&= quot;, which
seems to be awkward English usage; "information other than
acknowledgments" reads better.=C2=A0 I would also put a comma after th= at,
to end up with this, after your change and mine:

NEW
A SCTP sender MAY clear the error counter and move a destination
address back to active state by information other than
acknowledgments, when it can uniquely determine which destination,
among multiple destination addresses, the chunk reached. END

Got it. Thanks for the suggestio= n. I'll update the draft.

Regards,

-= -

Yoshi

--94eb2c08e18ace83de052afc4644-- From nobody Fri Feb 5 00:44:40 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4261A9073; Fri, 5 Feb 2016 00:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 74wenMm3E4oa; Fri, 5 Feb 2016 00:44:35 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 89FFE1A9071; Fri, 5 Feb 2016 00:44:35 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id E9B7C1B0016C; Fri, 5 Feb 2016 08:52:02 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Fri, 5 Feb 2016 08:44:34 -0000 Message-ID: <5a86a79b4d94475d90c200a47f85ca82.squirrel@erg.abdn.ac.uk> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DE716B@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657DE716B@dfweml701-chm> Date: Fri, 5 Feb 2016 08:44:34 -0000 From: gorry@erg.abdn.ac.uk To: "Linda Dunbar" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "ops-dir@ietf.org" , "ops-ads@tools.ietf.org" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-circuit-breaker@ietf.org" Subject: Re: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 08:44:37 -0000 Thanks, a few clarifications below, best wishes, Gorry > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written with the intent of improving the operational > aspects of the IETF drafts. Comments that are not addressed in last call > may be included in AD reviews during the IESG review. Document editors and > WG chairs should treat these comments just like any other last call > comments. > > Major issue with the proposed approach: > > Traffic continuously go from Ingress and egress. > If the Ingress and egress nodes don't have synchronized timers as > SONET/SDH (most packet routers/switches don't have synchronized timer), > the meters collected by both ends can't be correlated properly (i.e. they > are meaningless). > > The only ways for the meters on both Ingress and Egress to work reliably > (without synchronized timer) is via ECN, or via synthetic data (like > IPPM). > I think one could use IPPM methods, but the intention is not to track accurate congestion levels, but to trigger on persistent overload. The ID describes such measurements taken over intervals "of seconds to possibly many tens of seconds". I don't think this requires the tight timing of SDH/SONET. > For "Circuit Breaker based on RTP", DPI has to be deployed to detect RTP > if the Ingress and egress nodes are the end points of tunnel (i.e. > aggregated traffic). The approach is very expensive. > Section 6.1 makes it clear that endpoint implementation is expected for the RTP circuit breaker, although as you say with DPI, and access to traffic someone could decide to implement this within a network device: "Although the mechanisms can be implemented in a RTP-aware network devices, these mechanisms are also suitable for implementation in endpoints (e.g., as a part of the tranport system), where they can also compliment end-to-end congestion control methods. A shorter response time enables these mechanisms to triggers before other forms of circuit breaker (e.g., circuit breakers operating on traffic aggregates at a point along the network path)." > Minor issue: > Typos: > > > - Page 5: The paragraph before 1.1: > "Circuit Breaker has in fact being tripped": do you mean "being > triggered"? > Thanks, will be fixed. > > Regards, Linda Dunbar > > From nobody Fri Feb 5 09:16:44 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54401B3BC7; Fri, 5 Feb 2016 09:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 xbAeO5YxjzeC; Fri, 5 Feb 2016 09:16:41 -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 607831B3BC4; Fri, 5 Feb 2016 09:16:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDZ77561; Fri, 05 Feb 2016 17:16:35 +0000 (GMT) Received: from LHREML702-CAH.china.huawei.com (10.201.5.99) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 5 Feb 2016 17:16:34 +0000 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 5 Feb 2016 17:16:34 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0235.001; Fri, 5 Feb 2016 09:16:23 -0800 From: Linda Dunbar To: "gorry@erg.abdn.ac.uk" Thread-Topic: review comments to draft-ietf-tsvwg-circuit-breaker-11 Thread-Index: AdFfcKiUd2SscsOJQXSDBn9IGJAp/wAw9V8AAADQXHA= Date: Fri, 5 Feb 2016 17:16:23 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DE77CE@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657DE716B@dfweml701-chm> <5a86a79b4d94475d90c200a47f85ca82.squirrel@erg.abdn.ac.uk> In-Reply-To: <5a86a79b4d94475d90c200a47f85ca82.squirrel@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56B4D8F4.0180, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6942ccbe8699dfc955667449710dc799 Archived-At: Cc: "ops-dir@ietf.org" , "ops-ads@tools.ietf.org" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-circuit-breaker@ietf.org" Subject: Re: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 17:16:43 -0000 Gorry,=20 For "trigger on persistent overload", why not consider the Link Utilization= measurement on ports (which is much more reliable and much simpler).=20 As a matter of fact, it is a very commonly deployed procedure by many opera= tors to use "link utilization " (cross a configured threshold) to trigger t= he needed actions (or what you call "circuit breaker" in your draft) for th= e network.=20 Linda -----Original Message----- From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk]=20 Sent: Friday, February 05, 2016 2:45 AM To: Linda Dunbar Cc: draft-ietf-tsvwg-circuit-breaker@ietf.org; ops-dir@ietf.org; ops-ads@to= ols.ietf.org; tsvwg@ietf.org Subject: Re: review comments to draft-ietf-tsvwg-circuit-breaker-11 Thanks, a few clarifications below, best wishes, Gorry > I have reviewed this document as part of the Operational directorate's=20 > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written with the intent of improving the=20 > operational aspects of the IETF drafts. Comments that are not=20 > addressed in last call may be included in AD reviews during the IESG=20 > review. Document editors and WG chairs should treat these comments=20 > just like any other last call comments. > > Major issue with the proposed approach: > > Traffic continuously go from Ingress and egress. > If the Ingress and egress nodes don't have synchronized timers as=20 > SONET/SDH (most packet routers/switches don't have synchronized=20 > timer), the meters collected by both ends can't be correlated =20 > properly (i.e. they are meaningless). > > The only ways for the meters on both Ingress and Egress to work=20 > reliably (without synchronized timer) is via ECN, or via synthetic=20 > data (like IPPM). > I think one could use IPPM methods, but the intention is not to track accur= ate congestion levels, but to trigger on persistent overload. The ID descri= bes such measurements taken over intervals "of seconds to possibly many ten= s of seconds". I don't think this requires the tight timing of SDH/SONET. > For "Circuit Breaker based on RTP", DPI has to be deployed to detect=20 > RTP if the Ingress and egress nodes are the end points of tunnel (i.e. > aggregated traffic). The approach is very expensive. > Section 6.1 makes it clear that endpoint implementation is expected for the= RTP circuit breaker, although as you say with DPI, and access to traffic s= omeone could decide to implement this within a network device: "Although the mechanisms can be implemented in a RTP-aware network devices, these mechanisms are also suitable for implementation in endpoints (e.g., as a part of the tranport system), where they can also compliment end-to-end congestion control methods. A shorter response time enables these mechanisms to triggers before other forms of circuit breaker (e.g., circuit breakers operating on traffic aggregates at a point along the network path)." > Minor issue: > Typos: > > > - Page 5: The paragraph before 1.1: > "Circuit Breaker has in fact being tripped": do you mean "being=20 > triggered"? > Thanks, will be fixed. > > Regards, Linda Dunbar > > From nobody Fri Feb 5 13:43:05 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BF51B2D50; Fri, 5 Feb 2016 13:43:02 -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, SPF_PASS=-0.001] autolearn=ham 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 eLK3Vay5Rcdc; Fri, 5 Feb 2016 13:43:00 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 E54E01A885E; Fri, 5 Feb 2016 13:42:56 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id s2so49937165oie.2; Fri, 05 Feb 2016 13:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=aMb8ckDXEWWczoDSXVkL6J+t8iyymPrj5nm17v3aerI=; b=HpdKf7CQy6AxwIz5hBZI7/X8fR3oZhbZitvDPwBlnu64XatcNtiNoYg06NW5b4HUWw WSRBaJNuKyaaGjFD2XEWd3cQtxUr/TmAJJ84Sj8M7SWeO8hEqMchwJyXSSp+OkgLQ8k0 CYG1uNOHwemVh36pZJwLSpGw7KVRH+zNxuKHcIywx+udXpJjRSVxXzM4pThi7rW14zqn wwfliZetzj/uB4/QQCGnxeUDLOtj4wVotJW2SApkCzKlGHdoPMq0NgGZ96uAUgCs6GSL oh3fw4y4Wid32YxerTjVXwuCfBHYcWlA2dmIFhvBQCTr/BKA1vZ3BQe4+RN7FdsDAI37 qHNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=aMb8ckDXEWWczoDSXVkL6J+t8iyymPrj5nm17v3aerI=; b=HNsUPrlkqcESmE615ioL9gHyqzbR0h2TROeRD1KVUqlL8fYgdow+12Tna4SNGpaI2H Z+1tGhhsS2FUveaSytYjKKGONDryP3aIq9ICXgWGSd7jqsp+xylX6OgZ2HV8EbErYHd3 uQer3GEWusAENiSYdLZrgm6hWQ6Rgd9bEh6AE9lBYCWPqDu9+7c+ARVzO9MoxeJPe90T PUVC2y/CAFlMhZiNYLUMvhsdSo6k+m3BIVwuCGufwlD8nmf9MoMx6FuwmBm19azuS7iF SNcpH9eLewhYEUCiZpzQg67pnDsAdL0Imt9kFY9JEmMw31DCiY035wO9fvG0muHmQ/J1 lAQQ== X-Gm-Message-State: AG10YOQdLPbbgmwD7qb59uyKG7mu2ISvJIAwHeZ8vBbT01Z81YpG58Sf4QAhVMZ4waRssUs9jJZJ1a1MlIqKvA== X-Received: by 10.202.241.214 with SMTP id p205mr10411285oih.126.1454708576320; Fri, 05 Feb 2016 13:42:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.196.104 with HTTP; Fri, 5 Feb 2016 13:42:36 -0800 (PST) From: "Andrew G. Malis" Date: Fri, 5 Feb 2016 16:42:36 -0500 Message-ID: To: IETF Discussion Content-Type: multipart/alternative; boundary=94eb2c094b58f18145052b0cbb70 Archived-At: Cc: "" , "rtg-dir@ietf.org" , tsvwg@ietf.org, IESG , draft-ietf-tsvwg-circuit-breaker.all@ietf.org Subject: [tsvwg] RtgDir review: draft-ietf-tsvwg-circuit-breaker-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 21:43:02 -0000 --94eb2c094b58f18145052b0cbb70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the IESG. For more information about the Routing Directorate, please see = =E2=80=8B http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir It would be helpful if you could consider these comments along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-tsvwg-circuit-breaker-11.txt Reviewer: Andy Malis Review Date: February 5, 2016 IETF LC End Date: February 9, 2016 Intended Status: Best Current Practice Summary: I have some minor concerns about this document that I think should be resolved before publication. Major Issues: No major issues found. Minor Issues: Page 3, first paragraph: There are no citations to the claim that non-congestion-controlled traffic "can form a significant proportion of the total traffic traversing a link". Sure, video is a major part of Internet traffic these days, but much Internet video is dynamically adaptive. One or more citations would be useful. Section 4: There are so many issues that they should be numbered, so that they can be referred to individually (from another document, for example). Page 11: In my opinion, the second and third requirements on this page should be "MUST"s rather than "SHOULD"s. Page 12, discussion of "In-Band" near the bottom of the page: This paragraph implies that an in-band control method will always provide fate-sharing of the control and regular traffic. It may provide fate-sharing, but that is by no means assured. For example, the network may be using ECMP, or traffic tunnels for data but not control traffic. Section 5: I'm not sure why Section 5 is a separate section, and not integrated into Section 3 as new subsections, which I think would be an improvement. Page 13, first paragraph: "presented in figure 2" -> "presented in figures 1 and 2". Page 19, fourth paragraph: This paragraph states that "IP-based traffic is generally assumed to be congestion-controlled". This is true for TCP-based traffic, but I would not make such an assumption for all IP-based traffic. Nits: The abbreviation "CB" is defined early in the document, but is hardly if ever used thereafter, rather "Circuit Breaker" is almost always spelled out. It may be useful to actually use the abbreviation. Page 3, first paragraph, fifth line, "connection" -> "connections". Figure 1: Move the vertical line between the "Measure" and "Trigger" boxes one space to the right. Page 10, fourth paragraph: "If necessary, MAY combine" -> "If necessary, a CB MAY combine". Page 11, fifth paragraph: "needs to be" -> "MUST" Page 12, second paragraph: There are two separate references to Section 8. One combined reference should be sufficient. Page 12, second to last paragraph: "in-Band" should have the "i" capitalized. Page 15, last paragraph: "tranport" -> "transport" Page 17, fifth paragraph: "Pseudo Wire" -> "PW" Regards, Andy --94eb2c094b58f18145052b0cbb70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

I have been selected = as the Routing Directorate reviewer for this draft. The Routing Directorate= seeks to review all routing or routing-related drafts as they pass through= IETF last call and IESG review, and sometimes on special request. The purp= ose of the review is to provide assistance to the IESG. For more informatio= n about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/= rtg/trac/wiki/RtgDir

It would be helpful if yo= u could consider these comments along with any other IETF Last Call comment= s that you receive, and strive to resolve them through discussion or by upd= ating the draft.

Document: draft-ietf-tsvwg-circui= t-breaker-11.txt

Reviewer: Andy Malis

Review Date: Febr= uary 5, 2016

IETF LC End Date: February 9, 2016

Intende= d Status: Best Current Practice

Summary:

I have some minor concerns about this document that I think= should be resolved before publication.

Major Issu= es:

No major issues found.

Minor Issues:

Page 3, first paragraph: There are= no citations to the claim that non-congestion-controlled traffic "can= form a significant proportion of the total traffic traversing a link"= . Sure, video is a major part of Internet traffic these days, but much Inte= rnet video is dynamically adaptive. One or more citations would be useful.<= /div>

Section 4: There are so many issues that they shou= ld be numbered, so that they can be referred to individually (from another = document, for example).

Page 11: In my opinion, th= e second and third requirements on this page should be "MUST"s ra= ther than "SHOULD"s.

Page 12, discussion= of "In-Band" near the bottom of the page: This paragraph implies= that an in-band control method will always provide fate-sharing of the con= trol and regular traffic. It may provide fate-sharing, but that is by no me= ans assured. For example, the network may be using ECMP, or traffic tunnels= for data but not control traffic.

Section 5: I= 9;m not sure why Section 5 is a separate section, and not integrated into S= ection 3 as new subsections, which I think would be an improvement.

Page 13, first paragraph: "presented in figure 2&quo= t; -> "presented in figures 1 and 2".

Page 19, fourth paragraph: This paragraph states that "IP-based traff= ic is generally assumed to be congestion-controlled". This is true for= TCP-based traffic, but I would not make such an assumption for all IP-base= d traffic.

Nits:

The abbr= eviation "CB" is defined early in the document, but is hardly if = ever used thereafter, rather "Circuit Breaker" is almost always s= pelled out. It may be useful to actually use the abbreviation.

Page 3, first paragraph, fifth line, "connection" -&= gt; "connections".

Figure 1: Move the ve= rtical line between the "Measure" and "Trigger" boxes o= ne space to the right.

Page 10, fourth paragraph: = "If necessary, MAY combine" -> "If necessary, a CB MAY co= mbine".

Page 11, fifth paragraph: "needs= to be" -> "MUST"

Page 12, secon= d paragraph: There are two separate references to Section 8. One combined r= eference should be sufficient.

Page 12, second to = last paragraph: "in-Band" should have the "i" capitaliz= ed.

Page 15, last paragraph: "tranport" = -> "transport"

Page 17, fifth paragra= ph: "Pseudo Wire" -> "PW"

R= egards,

Andy

--94eb2c094b58f18145052b0cbb70-- From nobody Wed Feb 10 10:55:24 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883891B2EB2; Wed, 10 Feb 2016 10:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 gPfqQdoyAJ7I; Wed, 10 Feb 2016 10:55:20 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECBB1B2EAB; Wed, 10 Feb 2016 10:55:20 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 12BA31B001B1; Wed, 10 Feb 2016 19:02:46 +0000 (GMT) Received: from 178.83.155.242 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 10 Feb 2016 18:55:18 -0000 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DE77CE@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657DE716B@dfweml701-chm> <5a86a79b4d94475d90c200a47f85ca82.squirrel@erg.abdn.ac.uk> <4A95BA014132FF49AE685FAB4B9F17F657DE77CE@dfweml701-chm> Date: Wed, 10 Feb 2016 18:55:18 -0000 From: gorry@erg.abdn.ac.uk To: "Linda Dunbar" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "ops-dir@ietf.org" , "ops-ads@tools.ietf.org" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-circuit-breaker@ietf.org" Subject: Re: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 18:55:22 -0000 HI Linda, I think considering the "link utilization " on a physical interface may be OK to detect overload - but this is not the main focus of the document. Gorry > Gorry, > > For "trigger on persistent overload", why not consider the Link > Utilization measurement on ports (which is much more reliable and much > simpler). > > As a matter of fact, it is a very commonly deployed procedure by many > operators to use "link utilization " (cross a configured threshold) to > trigger the needed actions (or what you call "circuit breaker" in your > draft) for the network. > > Linda > > > -----Original Message----- > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > Sent: Friday, February 05, 2016 2:45 AM > To: Linda Dunbar > Cc: draft-ietf-tsvwg-circuit-breaker@ietf.org; ops-dir@ietf.org; > ops-ads@tools.ietf.org; tsvwg@ietf.org > Subject: Re: review comments to draft-ietf-tsvwg-circuit-breaker-11 > > Thanks, a few clarifications below, > > best wishes, > > Gorry > > >> I have reviewed this document as part of the Operational directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written with the intent of improving the >> operational aspects of the IETF drafts. Comments that are not >> addressed in last call may be included in AD reviews during the IESG >> review. Document editors and WG chairs should treat these comments >> just like any other last call comments. >> >> Major issue with the proposed approach: >> >> Traffic continuously go from Ingress and egress. >> If the Ingress and egress nodes don't have synchronized timers as >> SONET/SDH (most packet routers/switches don't have synchronized >> timer), the meters collected by both ends can't be correlated >> properly (i.e. they are meaningless). >> >> The only ways for the meters on both Ingress and Egress to work >> reliably (without synchronized timer) is via ECN, or via synthetic >> data (like IPPM). >> > I think one could use IPPM methods, but the intention is not to track > accurate congestion levels, but to trigger on persistent overload. The ID > describes such measurements taken over intervals "of seconds to possibly > many tens of seconds". I don't think this requires the tight timing of > SDH/SONET. > >> For "Circuit Breaker based on RTP", DPI has to be deployed to detect >> RTP if the Ingress and egress nodes are the end points of tunnel (i.e. >> aggregated traffic). The approach is very expensive. >> > > Section 6.1 makes it clear that endpoint implementation is expected for > the RTP circuit breaker, although as you say with DPI, and access to > traffic someone could decide to implement this within a network device: > > "Although the mechanisms can be implemented in a RTP-aware network > devices, these mechanisms are also suitable for implementation in > endpoints (e.g., as a part of the tranport system), where they can > also compliment end-to-end congestion control methods. A shorter > response time enables these mechanisms to triggers before other forms > of circuit breaker (e.g., circuit breakers operating on traffic > aggregates at a point along the network path)." > >> Minor issue: >> Typos: >> >> >> - Page 5: The paragraph before 1.1: >> "Circuit Breaker has in fact being tripped": do you mean "being >> triggered"? >> > Thanks, will be fixed. > >> >> Regards, Linda Dunbar >> >> > From nobody Wed Feb 10 13:47:50 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39071B305B; Wed, 10 Feb 2016 13:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 aeH3Cuc4yIhC; Wed, 10 Feb 2016 13:47:44 -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 87B301B305F; Wed, 10 Feb 2016 13:47:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEE84190; Wed, 10 Feb 2016 21:47:41 +0000 (GMT) Received: from LHREML701-CAH.china.huawei.com (10.201.5.93) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 10 Feb 2016 21:47:40 +0000 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 10 Feb 2016 21:47:39 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0235.001; Wed, 10 Feb 2016 13:47:37 -0800 From: Linda Dunbar To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11 Thread-Index: AdFfcKiUd2SscsOJQXSDBn9IGJAp/wAw9V8AAADQXHABD/kJAAAK6yIg Date: Wed, 10 Feb 2016 21:47:37 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DEA31E@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657DE716B@dfweml701-chm> <5a86a79b4d94475d90c200a47f85ca82.squirrel@erg.abdn.ac.uk> <4A95BA014132FF49AE685FAB4B9F17F657DE77CE@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56BBAFFD.0130, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d5f637374030e15de793405e54a361fd Archived-At: Cc: "ops-dir@ietf.org" , "ops-ads@tools.ietf.org" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-circuit-breaker@ietf.org" Subject: Re: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 21:47:47 -0000 Gorry,=20 Most network today have >10G links/ports. A few milliseconds difference in = timer can result in very big differences in the collected measurement betwe= en Ingress and egress. I just want to point out that the proposed mechanism= can't accurately detect overload if both ingress and egress nodes don't us= e synchronized timer. Linda -----Original Message----- From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk]=20 Sent: Wednesday, February 10, 2016 12:55 PM To: Linda Dunbar Cc: gorry@erg.abdn.ac.uk; ops-dir@ietf.org; ops-ads@tools.ietf.org; tsvwg@i= etf.org; draft-ietf-tsvwg-circuit-breaker@ietf.org Subject: Re: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11 HI Linda, I think considering the "link utilization " on a physical interface may be = OK to detect overload - but this is not the main focus of the document. Gorry > Gorry, > > For "trigger on persistent overload", why not consider the Link=20 > Utilization measurement on ports (which is much more reliable and much=20 > simpler). > > As a matter of fact, it is a very commonly deployed procedure by many=20 > operators to use "link utilization " (cross a configured threshold) to=20 > trigger the needed actions (or what you call "circuit breaker" in your > draft) for the network. > > Linda > > > -----Original Message----- > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > Sent: Friday, February 05, 2016 2:45 AM > To: Linda Dunbar > Cc: draft-ietf-tsvwg-circuit-breaker@ietf.org; ops-dir@ietf.org;=20 > ops-ads@tools.ietf.org; tsvwg@ietf.org > Subject: Re: review comments to draft-ietf-tsvwg-circuit-breaker-11 > > Thanks, a few clarifications below, > > best wishes, > > Gorry > > >> I have reviewed this document as part of the Operational=20 >> directorate's ongoing effort to review all IETF documents being processe= d by the IESG. >> These comments were written with the intent of improving the=20 >> operational aspects of the IETF drafts. Comments that are not=20 >> addressed in last call may be included in AD reviews during the IESG=20 >> review. Document editors and WG chairs should treat these comments=20 >> just like any other last call comments. >> >> Major issue with the proposed approach: >> >> Traffic continuously go from Ingress and egress. >> If the Ingress and egress nodes don't have synchronized timers as=20 >> SONET/SDH (most packet routers/switches don't have synchronized=20 >> timer), the meters collected by both ends can't be correlated=20 >> properly (i.e. they are meaningless). >> >> The only ways for the meters on both Ingress and Egress to work=20 >> reliably (without synchronized timer) is via ECN, or via synthetic=20 >> data (like IPPM). >> > I think one could use IPPM methods, but the intention is not to track=20 > accurate congestion levels, but to trigger on persistent overload. The=20 > ID describes such measurements taken over intervals "of seconds to=20 > possibly many tens of seconds". I don't think this requires the tight=20 > timing of SDH/SONET. > >> For "Circuit Breaker based on RTP", DPI has to be deployed to detect=20 >> RTP if the Ingress and egress nodes are the end points of tunnel (i.e. >> aggregated traffic). The approach is very expensive. >> > > Section 6.1 makes it clear that endpoint implementation is expected=20 > for the RTP circuit breaker, although as you say with DPI, and access=20 > to traffic someone could decide to implement this within a network devic= e: > > "Although the mechanisms can be implemented in a RTP-aware network > devices, these mechanisms are also suitable for implementation in > endpoints (e.g., as a part of the tranport system), where they can > also compliment end-to-end congestion control methods. A shorter > response time enables these mechanisms to triggers before other forms > of circuit breaker (e.g., circuit breakers operating on traffic > aggregates at a point along the network path)." > >> Minor issue: >> Typos: >> >> >> - Page 5: The paragraph before 1.1: >> "Circuit Breaker has in fact being tripped": do you mean "being=20 >> triggered"? >> > Thanks, will be fixed. > >> >> Regards, Linda Dunbar >> >> > From nobody Thu Feb 11 02:32:09 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401231ACEAE; Thu, 11 Feb 2016 02:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 z7l5m3SxYcBz; Thu, 11 Feb 2016 02:32:05 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id E39B01ACEAC; Thu, 11 Feb 2016 02:32:04 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 77AEC1B001AB; Thu, 11 Feb 2016 10:39:32 +0000 (GMT) Received: from 195.176.96.242 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Thu, 11 Feb 2016 10:32:03 -0000 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DEA31E@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657DE716B@dfweml701-chm> <5a86a79b4d94475d90c200a47f85ca82.squirrel@erg.abdn.ac.uk> <4A95BA014132FF49AE685FAB4B9F17F657DE77CE@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657DEA31E@dfweml701-chm> Date: Thu, 11 Feb 2016 10:32:03 -0000 From: gorry@erg.abdn.ac.uk To: "Linda Dunbar" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "ops-dir@ietf.org" , "ops-ads@tools.ietf.org" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-circuit-breaker@ietf.org" Subject: Re: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 10:32:08 -0000 Linda, I maybe confused you. I'm not disagreeing that it can be good for an operator to monitor port utilisation, nor that there may be additional parameters in a switch, router, etc that can help someone detect problems and to react quicker than a circuit breaker would, congestion control is always better (IMHO). If implemented, such mechanisms should happen before the transport circuit breaker triggers (as a last resort to react when excessive congestion still remains, sure a truly huge number of bits can have passed on a 10G link in this interval). The circuit breaker mechanism is intended to work over long time scales (a fast trip works on a time that is long compared to the endpoint congestion control) and the other circuit breakers on a still longer timescale: I'm expecting a circuit breaker to take action when excessive congestion is observed that persists for seconds to many tens of seconds and the synchronisation to measure excessive congestion over this period doesn't need to be anywhere at the level of milliseconds. Does that help set the context? Gorry > Gorry, > > Most network today have >10G links/ports. A few milliseconds difference in > timer can result in very big differences in the collected measurement > between Ingress and egress. I just want to point out that the proposed > mechanism can't accurately detect overload if both ingress and egress > nodes don't use synchronized timer. > > Linda > > -----Original Message----- > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > Sent: Wednesday, February 10, 2016 12:55 PM > To: Linda Dunbar > Cc: gorry@erg.abdn.ac.uk; ops-dir@ietf.org; ops-ads@tools.ietf.org; > tsvwg@ietf.org; draft-ietf-tsvwg-circuit-breaker@ietf.org > Subject: Re: [tsvwg] review comments to > draft-ietf-tsvwg-circuit-breaker-11 > > HI Linda, > > I think considering the "link utilization " on a physical interface may be > OK to detect overload - but this is not the main focus of the document. > > Gorry > >> Gorry, >> >> For "trigger on persistent overload", why not consider the Link >> Utilization measurement on ports (which is much more reliable and much >> simpler). >> >> As a matter of fact, it is a very commonly deployed procedure by many >> operators to use "link utilization " (cross a configured threshold) to >> trigger the needed actions (or what you call "circuit breaker" in your >> draft) for the network. >> >> Linda >> >> >> -----Original Message----- >> From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] >> Sent: Friday, February 05, 2016 2:45 AM >> To: Linda Dunbar >> Cc: draft-ietf-tsvwg-circuit-breaker@ietf.org; ops-dir@ietf.org; >> ops-ads@tools.ietf.org; tsvwg@ietf.org >> Subject: Re: review comments to draft-ietf-tsvwg-circuit-breaker-11 >> >> Thanks, a few clarifications below, >> >> best wishes, >> >> Gorry >> >> >>> I have reviewed this document as part of the Operational >>> directorate's ongoing effort to review all IETF documents being >>> processed by the IESG. >>> These comments were written with the intent of improving the >>> operational aspects of the IETF drafts. Comments that are not >>> addressed in last call may be included in AD reviews during the IESG >>> review. Document editors and WG chairs should treat these comments >>> just like any other last call comments. >>> >>> Major issue with the proposed approach: >>> >>> Traffic continuously go from Ingress and egress. >>> If the Ingress and egress nodes don't have synchronized timers as >>> SONET/SDH (most packet routers/switches don't have synchronized >>> timer), the meters collected by both ends can't be correlated >>> properly (i.e. they are meaningless). >>> >>> The only ways for the meters on both Ingress and Egress to work >>> reliably (without synchronized timer) is via ECN, or via synthetic >>> data (like IPPM). >>> >> I think one could use IPPM methods, but the intention is not to track >> accurate congestion levels, but to trigger on persistent overload. The >> ID describes such measurements taken over intervals "of seconds to >> possibly many tens of seconds". I don't think this requires the tight >> timing of SDH/SONET. >> >>> For "Circuit Breaker based on RTP", DPI has to be deployed to detect >>> RTP if the Ingress and egress nodes are the end points of tunnel (i.e. >>> aggregated traffic). The approach is very expensive. >>> >> >> Section 6.1 makes it clear that endpoint implementation is expected >> for the RTP circuit breaker, although as you say with DPI, and access >> to traffic someone could decide to implement this within a network >> device: >> >> "Although the mechanisms can be implemented in a RTP-aware network >> devices, these mechanisms are also suitable for implementation in >> endpoints (e.g., as a part of the tranport system), where they can >> also compliment end-to-end congestion control methods. A shorter >> response time enables these mechanisms to triggers before other forms >> of circuit breaker (e.g., circuit breakers operating on traffic >> aggregates at a point along the network path)." >> >>> Minor issue: >>> Typos: >>> >>> >>> - Page 5: The paragraph before 1.1: >>> "Circuit Breaker has in fact being tripped": do you mean "being >>> triggered"? >>> >> Thanks, will be fixed. >> >>> >>> Regards, Linda Dunbar >>> >>> >> > From nobody Thu Feb 11 06:27:18 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533341B324F; Thu, 11 Feb 2016 06:27:17 -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, SPF_PASS=-0.001] autolearn=ham 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 wso_m_5LM931; Thu, 11 Feb 2016 06:27:13 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 A60C11B324C; Thu, 11 Feb 2016 06:27:13 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id u200so40058872ywf.0; Thu, 11 Feb 2016 06:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zKvuCZVaG0cPWfwcDrz06L8GYQV1XQWguaNOqMrRHMs=; b=ENWtpC8q2pwi5CWUeItrazikUmaQQJVi85bdICErOl+F8htd4qGATf+cNvVr3C0lsf jrZ08rmbjGOw4A5LXgWRThF4Ad7FywCgBgGroYq9pXHs3+Z2DaZtIsC5XBzCzV2rxAxo C85WvmuNTZZj0krhbtwFS5B1lkVuqAs0zriPco5jPI9Eb5TxJQ0jnwrWc/h4VMtq/yZf OdAHXyQwJeMGxVn8w8Oh8JBfl0FxhSfuU3YdOtCLnigGh6QlVPZH6prZU47vmTwWLrQN DdiJCjrQ8IsKFV+3JfjSpqmMN11HmzARfbV7J6z46XfeS0Lr+oDQHZ+S7V5Bpj6fETHD 5/TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zKvuCZVaG0cPWfwcDrz06L8GYQV1XQWguaNOqMrRHMs=; b=mU27GQjGq76UYnedlWrwIY4aazNlHnAgtEN81/39J5KaY10IVYZSlIdQI1k/C1Q2px mALf6sVmky7yU0L5TPxe8mR2E+efAI5yZ+LzL0H+ggN6JfmWlCf9U0wH2qMiKhYZkpM2 2aHOBFh6Vt0WDXEqrwivt3wnaajtmUp5Vb8hQtfEnaUJwJAf2Aj+uQ70mNmK5vXlR9cq L7LdRBei9Tk7RyCLDimTYHpSXeaW1b4yrvSChAoeiRtfs5j86uLHrPzzLJhHda3GRIoa 3LQ0bouqxH1nl8NZDqkCo+1SBLHTmbOqS6cufqt6emQhHjWO/SmYNPnNjRoSw/AOJiX9 sQuA== X-Gm-Message-State: AG10YOTpeRVz+u5oQGKM8t1kV5hohevDVRpFVLGFooDMEEvZz/HMxqPfyITw5zPOfi6Z1gSxpAu/tvRrqUQOsA== MIME-Version: 1.0 X-Received: by 10.13.210.7 with SMTP id u7mr23469072ywd.100.1455200832843; Thu, 11 Feb 2016 06:27:12 -0800 (PST) Received: by 10.37.99.65 with HTTP; Thu, 11 Feb 2016 06:27:12 -0800 (PST) In-Reply-To: References: <4A95BA014132FF49AE685FAB4B9F17F657DE716B@dfweml701-chm> <5a86a79b4d94475d90c200a47f85ca82.squirrel@erg.abdn.ac.uk> <4A95BA014132FF49AE685FAB4B9F17F657DE77CE@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657DEA31E@dfweml701-chm> Date: Thu, 11 Feb 2016 08:27:12 -0600 Message-ID: From: Spencer Dawkins at IETF To: "gorry@erg.abdn.ac.uk" Content-Type: multipart/alternative; boundary=001a114e7e78b7fa19052b7f58ba Archived-At: Cc: "ops-dir@ietf.org" , "ops-ads@tools.ietf.org" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-circuit-breaker@ietf.org" , Linda Dunbar Subject: Re: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 14:27:17 -0000 --001a114e7e78b7fa19052b7f58ba Content-Type: text/plain; charset=UTF-8 Hi, Gorry, Absolutely NOT speaking as AD on this one ... just asking a question. On Thu, Feb 11, 2016 at 4:32 AM, wrote: > Linda, > > I maybe confused you. > > I'm not disagreeing that it can be good for an operator to monitor port > utilisation, nor that there may be additional parameters in a switch, > router, etc that can help someone detect problems and to react quicker > than a circuit breaker would, congestion control is always better (IMHO). > If implemented, such mechanisms should happen before the transport circuit > breaker triggers (as a last resort to react when excessive congestion > still remains, sure a truly huge number of bits can have passed on a 10G > link in this interval). > > The circuit breaker mechanism is intended to work over long time scales (a > fast trip works on a time that is long compared to the endpoint congestion > control) and the other circuit breakers on a still longer timescale: I'm > expecting a circuit breaker to take action when excessive congestion is > observed that persists for seconds to many tens of seconds and the > synchronisation to measure excessive congestion over this period doesn't > need to be anywhere at the level of milliseconds. > > Does that help set the context? I'm assuming that it does ... If so, I'm thinking that the Introduction is pretty clear about the difference between a transport circuit breaker and transport-level congestion control ("let transport-level congestion control work, if it's going to, and trip a transport circuit breaker if not"). I'm wondering if Linda's comment points to the possibility of adding a paragraph about the difference between a transport circuit breaker and link utilization on ports, when that's available (also "let link utilization work in milliseconds if it's going to, and do something else if not"). I don't have an opinion about how useful or appropriate that would be, but wanted to ask the question while you're looking at review comments, and not at some point in the future. Thanks! Spencer > Gorry > > > > Gorry, > > > > Most network today have >10G links/ports. A few milliseconds difference > in > > timer can result in very big differences in the collected measurement > > between Ingress and egress. I just want to point out that the proposed > > mechanism can't accurately detect overload if both ingress and egress > > nodes don't use synchronized timer. > > > > Linda > > > > -----Original Message----- > > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > > Sent: Wednesday, February 10, 2016 12:55 PM > > To: Linda Dunbar > > Cc: gorry@erg.abdn.ac.uk; ops-dir@ietf.org; ops-ads@tools.ietf.org; > > tsvwg@ietf.org; draft-ietf-tsvwg-circuit-breaker@ietf.org > > Subject: Re: [tsvwg] review comments to > > draft-ietf-tsvwg-circuit-breaker-11 > > > > HI Linda, > > > > I think considering the "link utilization " on a physical interface may > be > > OK to detect overload - but this is not the main focus of the document. > > > > Gorry > > > >> Gorry, > >> > >> For "trigger on persistent overload", why not consider the Link > >> Utilization measurement on ports (which is much more reliable and much > >> simpler). > >> > >> As a matter of fact, it is a very commonly deployed procedure by many > >> operators to use "link utilization " (cross a configured threshold) to > >> trigger the needed actions (or what you call "circuit breaker" in your > >> draft) for the network. > >> > >> Linda > >> > >> > >> -----Original Message----- > >> From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > >> Sent: Friday, February 05, 2016 2:45 AM > >> To: Linda Dunbar > >> Cc: draft-ietf-tsvwg-circuit-breaker@ietf.org; ops-dir@ietf.org; > >> ops-ads@tools.ietf.org; tsvwg@ietf.org > >> Subject: Re: review comments to draft-ietf-tsvwg-circuit-breaker-11 > >> > >> Thanks, a few clarifications below, > >> > >> best wishes, > >> > >> Gorry > >> > >> > >>> I have reviewed this document as part of the Operational > >>> directorate's ongoing effort to review all IETF documents being > >>> processed by the IESG. > >>> These comments were written with the intent of improving the > >>> operational aspects of the IETF drafts. Comments that are not > >>> addressed in last call may be included in AD reviews during the IESG > >>> review. Document editors and WG chairs should treat these comments > >>> just like any other last call comments. > >>> > >>> Major issue with the proposed approach: > >>> > >>> Traffic continuously go from Ingress and egress. > >>> If the Ingress and egress nodes don't have synchronized timers as > >>> SONET/SDH (most packet routers/switches don't have synchronized > >>> timer), the meters collected by both ends can't be correlated > >>> properly (i.e. they are meaningless). > >>> > >>> The only ways for the meters on both Ingress and Egress to work > >>> reliably (without synchronized timer) is via ECN, or via synthetic > >>> data (like IPPM). > >>> > >> I think one could use IPPM methods, but the intention is not to track > >> accurate congestion levels, but to trigger on persistent overload. The > >> ID describes such measurements taken over intervals "of seconds to > >> possibly many tens of seconds". I don't think this requires the tight > >> timing of SDH/SONET. > >> > >>> For "Circuit Breaker based on RTP", DPI has to be deployed to detect > >>> RTP if the Ingress and egress nodes are the end points of tunnel (i.e. > >>> aggregated traffic). The approach is very expensive. > >>> > >> > >> Section 6.1 makes it clear that endpoint implementation is expected > >> for the RTP circuit breaker, although as you say with DPI, and access > >> to traffic someone could decide to implement this within a network > >> device: > >> > >> "Although the mechanisms can be implemented in a RTP-aware network > >> devices, these mechanisms are also suitable for implementation in > >> endpoints (e.g., as a part of the tranport system), where they can > >> also compliment end-to-end congestion control methods. A shorter > >> response time enables these mechanisms to triggers before other forms > >> of circuit breaker (e.g., circuit breakers operating on traffic > >> aggregates at a point along the network path)." > >> > >>> Minor issue: > >>> Typos: > >>> > >>> > >>> - Page 5: The paragraph before 1.1: > >>> "Circuit Breaker has in fact being tripped": do you mean "being > >>> triggered"? > >>> > >> Thanks, will be fixed. > >> > >>> > >>> Regards, Linda Dunbar > >>> > >>> > >> > > > > --001a114e7e78b7fa19052b7f58ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, Gorry,=C2=A0

Absolutely NOT speakin= g as AD on this one ... just asking a question.

<= br>

On Thu, Feb 11, 2016 at 4:32 AM, <gorr= y@erg.abdn.ac.uk> wrote:

Li= nda,

I maybe confused you.

I'm not disagreeing that it can be good for an operator to monitor port=
utilisation, nor that there may be additional parameters in a switch,
router, etc that can help someone detect problems and to react quicker
than a circuit breaker would, congestion control is always better (IMHO). If implemented, such mechanisms should happen before the transport circuit<= br> breaker triggers (as a last resort to react when excessive congestion
still remains, sure a truly huge number of bits can have passed on a 10G link in this interval).

The circuit breaker mechanism is intended to work over long time scales (a<= br> fast trip works on a time that is long compared to the endpoint congestion<= br> control) and the other circuit breakers on a still longer timescale: I'= m
expecting a circuit breaker to take action when excessive congestion is
observed that persists for seconds to many tens of seconds and the
synchronisation to measure excessive congestion over this period doesn'= t
need to be anywhere at the level of milliseconds.

Does that help set the context?

I'm ass= uming that it does ...=C2=A0

If so, I'm thinki= ng that the Introduction is pretty clear about the difference between a tra= nsport circuit breaker and transport-level congestion control ("let tr= ansport-level congestion control work, if it's going to, and trip a tra= nsport circuit breaker if not").=C2=A0

I'= m wondering if Linda's comment points to the possibility of adding a pa= ragraph about the difference between a transport circuit breaker and link u= tilization on ports, when that's available (also "let link utiliza= tion work in milliseconds if it's going to, and do something else if no= t").

I don't have an opinion about how us= eful or appropriate that would be, but wanted to ask the question while you= 're looking at review comments, and not at some point in the future.

Thanks!

Spencer

= =C2=A0

Gorry

> Gorry,
>
> Most network today have >10G links/ports. A few milliseconds differ= ence in
> timer can result in very big differences in the collected measurement<= br> > between Ingress and egress. I just want to point out that the proposed=
> mechanism can't accurately detect overload if both ingress and egr= ess
> nodes don't use synchronized timer.
>
> Linda
>
> -----Original Message-----
> From: gorry@erg.abdn.ac.uk= [mailto:gorry@erg.abdn.ac.uk]<= br> > Sent: Wednesday, February 10, 2016 12:55 PM
> To: Linda Dunbar
> Cc: gorry@erg.abdn.ac.uk; = ops-dir@ietf.org; ops-ads@tools.ietf.org;
> tsvwg@ietf.org; draft-ietf-tsvwg-circuit-break= er@ietf.org
> Subject: Re: [tsvwg] review comments to
> draft-ietf-tsvwg-circuit-breaker-11
>
> HI Linda,
>
> I think considering the "link utilization " on a physical in= terface may be
> OK to detect overload - but this is not the main focus of the document= .
>
> Gorry
>
>> Gorry,
>>
>> For "trigger on persistent overload", why not consider t= he Link
>> Utilization measurement on ports (which is much more reliable and = much
>> simpler).
>>
>> As a matter of fact, it is a very commonly deployed procedure by m= any
>> operators to use "link utilization " (cross a configured= threshold) to
>> trigger the needed actions (or what you call "circuit breaker= " in your
>> draft) for the network.
>>
>> Linda
>>
>>
>> -----Original Message-----
>> From: gorry@erg.abdn.ac.uk= [mailto:gorry@erg.abdn.ac.uk]
>> Sent: Friday, February 05, 2016 2:45 AM
>> To: Linda Dunbar
>> Cc: d= raft-ietf-tsvwg-circuit-breaker@ietf.org; ops-dir@ietf.org;
>> ops-ads@tools.ietf.org; tsvwg@ietf.org
>> Subject: Re: review comments to draft-ietf-tsvwg-circuit-breaker-1= 1
>>
>> Thanks, a few clarifications below,
>>
>> best wishes,
>>
>> Gorry
>>
>>
>>> I have reviewed this document as part of the Operational
>>> directorate's ongoing effort to review all IETF documents = being
>>> processed by the IESG.
>>> These comments were written with the intent of improving the >>> operational aspects of the IETF drafts. Comments that are not<= br> >>> addressed in last call may be included in AD reviews during th= e IESG
>>> review. Document editors and WG chairs should treat these comm= ents
>>> just like any other last call comments.
>>>
>>> Major issue with the proposed approach:
>>>
>>> Traffic continuously go from Ingress and egress.
>>> If the Ingress and egress nodes don't=C2=A0 have synchroni= zed timers as
>>> SONET/SDH (most packet routers/switches don't have synchro= nized
>>> timer), the meters collected by both ends can't be correla= ted
>>> properly (i.e. they are meaningless).
>>>
>>> The only ways for the meters on both Ingress and Egress to wor= k
>>> reliably (without synchronized timer) is via ECN, or via synth= etic
>>> data (like IPPM).
>>>
>> I think one could use IPPM methods, but the intention is not to tr= ack
>> accurate congestion levels, but to trigger on persistent overload.= The
>> ID describes such measurements taken over intervals "of secon= ds to
>> possibly many tens of seconds". I don't think this requir= es the tight
>> timing of SDH/SONET.
>>
>>> For "Circuit Breaker based on RTP", DPI has to be de= ployed to detect
>>> RTP if the Ingress and egress nodes are the end points of tunn= el (i.e.
>>> aggregated traffic). The approach is very expensive.
>>>
>>
>> Section 6.1 makes it clear that endpoint implementation is expecte= d
>> for the RTP circuit breaker, although as you say with DPI, and acc= ess
>> to traffic someone could decide=C2=A0 to implement this within a n= etwork
>> device:
>>
>>=C2=A0 =C2=A0"Although the mechanisms can be implemented in a = RTP-aware network
>>=C2=A0 =C2=A0 devices, these mechanisms are also suitable for imple= mentation in
>>=C2=A0 =C2=A0 endpoints (e.g., as a part of the tranport system), w= here they can
>>=C2=A0 =C2=A0 also compliment end-to-end congestion control methods= .=C2=A0 A shorter
>>=C2=A0 =C2=A0 response time enables these mechanisms to triggers be= fore other forms
>>=C2=A0 =C2=A0 of circuit breaker (e.g., circuit breakers operating = on traffic
>>=C2=A0 =C2=A0 aggregates at a point along the network path)."<= br> >>
>>> Minor issue:
>>> Typos:
>>>
>>>
>>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 Page 5: The=C2=A0 paragraph befor= e 1.1:
>>> "Circuit Breaker has in fact being tripped": do you = mean "being
>>> triggered"?
>>>
>> Thanks, will be fixed.
>>
>>>
>>> Regards, Linda Dunbar
>>>
>>>
>>
>

--001a114e7e78b7fa19052b7f58ba-- From nobody Thu Feb 11 15:02:18 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50A71B3BDB; Thu, 11 Feb 2016 15:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Pk7FlI1xqHS2; Thu, 11 Feb 2016 15:01:59 -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 598971B3BDF; Thu, 11 Feb 2016 15:01:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIK09552; Thu, 11 Feb 2016 23:01:54 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 11 Feb 2016 23:01:51 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Thu, 11 Feb 2016 15:01:44 -0800 From: Linda Dunbar To: Spencer Dawkins at IETF , "gorry@erg.abdn.ac.uk" Thread-Topic: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11 Thread-Index: AdFfcKiUd2SscsOJQXSDBn9IGJAp/wAw9V8AAADQXHABD/kJAAAK6yIgABXMEYAACDZoAAABMpOQ Date: Thu, 11 Feb 2016 23:01:44 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DEAAF0@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657DE716B@dfweml701-chm> <5a86a79b4d94475d90c200a47f85ca82.squirrel@erg.abdn.ac.uk> <4A95BA014132FF49AE685FAB4B9F17F657DE77CE@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657DEA31E@dfweml701-chm>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.190] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DEAAF0dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56BD12E2.025B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a35d62b8149d2d45e74b7256b6add059 Archived-At: Cc: "ops-dir@ietf.org" , "ops-ads@tools.ietf.org" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-circuit-breaker@ietf.org" Subject: Re: [tsvwg] review comments to draft-ietf-tsvwg-circuit-breaker-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 23:02:06 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657DEAAF0dfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgd2l0aCBTcGVuY2Vy4oCZcyBhcHByb2FjaC4gVGhhbmtzLg0KDQpMaW5kYQ0KDQpGcm9t OiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiBbbWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21h aWwuY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDExLCAyMDE2IDg6MjcgQU0NClRvOiBn b3JyeUBlcmcuYWJkbi5hYy51aw0KQ2M6IExpbmRhIER1bmJhcjsgb3BzLWRpckBpZXRmLm9yZzsg b3BzLWFkc0B0b29scy5pZXRmLm9yZzsgdHN2d2dAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHN2d2ct Y2lyY3VpdC1icmVha2VyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RzdndnXSByZXZpZXcgY29t bWVudHMgdG8gZHJhZnQtaWV0Zi10c3Z3Zy1jaXJjdWl0LWJyZWFrZXItMTENCg0KSGksIEdvcnJ5 LA0KDQpBYnNvbHV0ZWx5IE5PVCBzcGVha2luZyBhcyBBRCBvbiB0aGlzIG9uZSAuLi4ganVzdCBh c2tpbmcgYSBxdWVzdGlvbi4NCg0KT24gVGh1LCBGZWIgMTEsIDIwMTYgYXQgNDozMiBBTSwgPGdv cnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4+IHdyb3RlOg0K TGluZGEsDQoNCkkgbWF5YmUgY29uZnVzZWQgeW91Lg0KDQpJJ20gbm90IGRpc2FncmVlaW5nIHRo YXQgaXQgY2FuIGJlIGdvb2QgZm9yIGFuIG9wZXJhdG9yIHRvIG1vbml0b3IgcG9ydA0KdXRpbGlz YXRpb24sIG5vciB0aGF0IHRoZXJlIG1heSBiZSBhZGRpdGlvbmFsIHBhcmFtZXRlcnMgaW4gYSBz d2l0Y2gsDQpyb3V0ZXIsIGV0YyB0aGF0IGNhbiBoZWxwIHNvbWVvbmUgZGV0ZWN0IHByb2JsZW1z IGFuZCB0byByZWFjdCBxdWlja2VyDQp0aGFuIGEgY2lyY3VpdCBicmVha2VyIHdvdWxkLCBjb25n ZXN0aW9uIGNvbnRyb2wgaXMgYWx3YXlzIGJldHRlciAoSU1ITykuDQpJZiBpbXBsZW1lbnRlZCwg c3VjaCBtZWNoYW5pc21zIHNob3VsZCBoYXBwZW4gYmVmb3JlIHRoZSB0cmFuc3BvcnQgY2lyY3Vp dA0KYnJlYWtlciB0cmlnZ2VycyAoYXMgYSBsYXN0IHJlc29ydCB0byByZWFjdCB3aGVuIGV4Y2Vz c2l2ZSBjb25nZXN0aW9uDQpzdGlsbCByZW1haW5zLCBzdXJlIGEgdHJ1bHkgaHVnZSBudW1iZXIg b2YgYml0cyBjYW4gaGF2ZSBwYXNzZWQgb24gYSAxMEcNCmxpbmsgaW4gdGhpcyBpbnRlcnZhbCku DQoNClRoZSBjaXJjdWl0IGJyZWFrZXIgbWVjaGFuaXNtIGlzIGludGVuZGVkIHRvIHdvcmsgb3Zl ciBsb25nIHRpbWUgc2NhbGVzIChhDQpmYXN0IHRyaXAgd29ya3Mgb24gYSB0aW1lIHRoYXQgaXMg bG9uZyBjb21wYXJlZCB0byB0aGUgZW5kcG9pbnQgY29uZ2VzdGlvbg0KY29udHJvbCkgYW5kIHRo ZSBvdGhlciBjaXJjdWl0IGJyZWFrZXJzIG9uIGEgc3RpbGwgbG9uZ2VyIHRpbWVzY2FsZTogSSdt DQpleHBlY3RpbmcgYSBjaXJjdWl0IGJyZWFrZXIgdG8gdGFrZSBhY3Rpb24gd2hlbiBleGNlc3Np dmUgY29uZ2VzdGlvbiBpcw0Kb2JzZXJ2ZWQgdGhhdCBwZXJzaXN0cyBmb3Igc2Vjb25kcyB0byBt YW55IHRlbnMgb2Ygc2Vjb25kcyBhbmQgdGhlDQpzeW5jaHJvbmlzYXRpb24gdG8gbWVhc3VyZSBl eGNlc3NpdmUgY29uZ2VzdGlvbiBvdmVyIHRoaXMgcGVyaW9kIGRvZXNuJ3QNCm5lZWQgdG8gYmUg YW55d2hlcmUgYXQgdGhlIGxldmVsIG9mIG1pbGxpc2Vjb25kcy4NCg0KRG9lcyB0aGF0IGhlbHAg c2V0IHRoZSBjb250ZXh0Pw0KDQpJJ20gYXNzdW1pbmcgdGhhdCBpdCBkb2VzIC4uLg0KDQpJZiBz bywgSSdtIHRoaW5raW5nIHRoYXQgdGhlIEludHJvZHVjdGlvbiBpcyBwcmV0dHkgY2xlYXIgYWJv dXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHRyYW5zcG9ydCBjaXJjdWl0IGJyZWFrZXIgYW5k IHRyYW5zcG9ydC1sZXZlbCBjb25nZXN0aW9uIGNvbnRyb2wgKCJsZXQgdHJhbnNwb3J0LWxldmVs IGNvbmdlc3Rpb24gY29udHJvbCB3b3JrLCBpZiBpdCdzIGdvaW5nIHRvLCBhbmQgdHJpcCBhIHRy YW5zcG9ydCBjaXJjdWl0IGJyZWFrZXIgaWYgbm90IikuDQoNCkknbSB3b25kZXJpbmcgaWYgTGlu ZGEncyBjb21tZW50IHBvaW50cyB0byB0aGUgcG9zc2liaWxpdHkgb2YgYWRkaW5nIGEgcGFyYWdy YXBoIGFib3V0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYSB0cmFuc3BvcnQgY2lyY3VpdCBicmVh a2VyIGFuZCBsaW5rIHV0aWxpemF0aW9uIG9uIHBvcnRzLCB3aGVuIHRoYXQncyBhdmFpbGFibGUg KGFsc28gImxldCBsaW5rIHV0aWxpemF0aW9uIHdvcmsgaW4gbWlsbGlzZWNvbmRzIGlmIGl0J3Mg Z29pbmcgdG8sIGFuZCBkbyBzb21ldGhpbmcgZWxzZSBpZiBub3QiKS4NCg0KSSBkb24ndCBoYXZl IGFuIG9waW5pb24gYWJvdXQgaG93IHVzZWZ1bCBvciBhcHByb3ByaWF0ZSB0aGF0IHdvdWxkIGJl LCBidXQgd2FudGVkIHRvIGFzayB0aGUgcXVlc3Rpb24gd2hpbGUgeW91J3JlIGxvb2tpbmcgYXQg cmV2aWV3IGNvbW1lbnRzLCBhbmQgbm90IGF0IHNvbWUgcG9pbnQgaW4gdGhlIGZ1dHVyZS4NCg0K VGhhbmtzIQ0KDQpTcGVuY2VyDQoNCkdvcnJ5DQoNCg0KPiBHb3JyeSwNCj4NCj4gTW9zdCBuZXR3 b3JrIHRvZGF5IGhhdmUgPjEwRyBsaW5rcy9wb3J0cy4gQSBmZXcgbWlsbGlzZWNvbmRzIGRpZmZl cmVuY2UgaW4NCj4gdGltZXIgY2FuIHJlc3VsdCBpbiB2ZXJ5IGJpZyBkaWZmZXJlbmNlcyBpbiB0 aGUgY29sbGVjdGVkIG1lYXN1cmVtZW50DQo+IGJldHdlZW4gSW5ncmVzcyBhbmQgZWdyZXNzLiBJ IGp1c3Qgd2FudCB0byBwb2ludCBvdXQgdGhhdCB0aGUgcHJvcG9zZWQNCj4gbWVjaGFuaXNtIGNh bid0IGFjY3VyYXRlbHkgZGV0ZWN0IG92ZXJsb2FkIGlmIGJvdGggaW5ncmVzcyBhbmQgZWdyZXNz DQo+IG5vZGVzIGRvbid0IHVzZSBzeW5jaHJvbml6ZWQgdGltZXIuDQo+DQo+IExpbmRhDQo+DQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGdvcnJ5QGVyZy5hYmRuLmFjLnVr PG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4gW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51 azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+XQ0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1 YXJ5IDEwLCAyMDE2IDEyOjU1IFBNDQo+IFRvOiBMaW5kYSBEdW5iYXINCj4gQ2M6IGdvcnJ5QGVy Zy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az47IG9wcy1kaXJAaWV0Zi5v cmc8bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmc+OyBvcHMtYWRzQHRvb2xzLmlldGYub3JnPG1haWx0 bzpvcHMtYWRzQHRvb2xzLmlldGYub3JnPjsNCj4gdHN2d2dAaWV0Zi5vcmc8bWFpbHRvOnRzdndn QGlldGYub3JnPjsgZHJhZnQtaWV0Zi10c3Z3Zy1jaXJjdWl0LWJyZWFrZXJAaWV0Zi5vcmc8bWFp bHRvOmRyYWZ0LWlldGYtdHN2d2ctY2lyY3VpdC1icmVha2VyQGlldGYub3JnPg0KPiBTdWJqZWN0 OiBSZTogW3RzdndnXSByZXZpZXcgY29tbWVudHMgdG8NCj4gZHJhZnQtaWV0Zi10c3Z3Zy1jaXJj dWl0LWJyZWFrZXItMTENCj4NCj4gSEkgTGluZGEsDQo+DQo+IEkgdGhpbmsgY29uc2lkZXJpbmcg dGhlICJsaW5rIHV0aWxpemF0aW9uICIgb24gYSBwaHlzaWNhbCBpbnRlcmZhY2UgbWF5IGJlDQo+ IE9LIHRvIGRldGVjdCBvdmVybG9hZCAtIGJ1dCB0aGlzIGlzIG5vdCB0aGUgbWFpbiBmb2N1cyBv ZiB0aGUgZG9jdW1lbnQuDQo+DQo+IEdvcnJ5DQo+DQo+PiBHb3JyeSwNCj4+DQo+PiBGb3IgInRy aWdnZXIgb24gcGVyc2lzdGVudCBvdmVybG9hZCIsIHdoeSBub3QgY29uc2lkZXIgdGhlIExpbmsN Cj4+IFV0aWxpemF0aW9uIG1lYXN1cmVtZW50IG9uIHBvcnRzICh3aGljaCBpcyBtdWNoIG1vcmUg cmVsaWFibGUgYW5kIG11Y2gNCj4+IHNpbXBsZXIpLg0KPj4NCj4+IEFzIGEgbWF0dGVyIG9mIGZh Y3QsIGl0IGlzIGEgdmVyeSBjb21tb25seSBkZXBsb3llZCBwcm9jZWR1cmUgYnkgbWFueQ0KPj4g b3BlcmF0b3JzIHRvIHVzZSAibGluayB1dGlsaXphdGlvbiAiIChjcm9zcyBhIGNvbmZpZ3VyZWQg dGhyZXNob2xkKSB0bw0KPj4gdHJpZ2dlciB0aGUgbmVlZGVkIGFjdGlvbnMgKG9yIHdoYXQgeW91 IGNhbGwgImNpcmN1aXQgYnJlYWtlciIgaW4geW91cg0KPj4gZHJhZnQpIGZvciB0aGUgbmV0d29y ay4NCj4+DQo+PiBMaW5kYQ0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4gRnJvbTogZ29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVr PiBbbWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51 az5dDQo+PiBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA1LCAyMDE2IDI6NDUgQU0NCj4+IFRvOiBM aW5kYSBEdW5iYXINCj4+IENjOiBkcmFmdC1pZXRmLXRzdndnLWNpcmN1aXQtYnJlYWtlckBpZXRm Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi10c3Z3Zy1jaXJjdWl0LWJyZWFrZXJAaWV0Zi5vcmc+OyBv cHMtZGlyQGlldGYub3JnPG1haWx0bzpvcHMtZGlyQGlldGYub3JnPjsNCj4+IG9wcy1hZHNAdG9v bHMuaWV0Zi5vcmc8bWFpbHRvOm9wcy1hZHNAdG9vbHMuaWV0Zi5vcmc+OyB0c3Z3Z0BpZXRmLm9y ZzxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogcmV2aWV3IGNvbW1lbnRz IHRvIGRyYWZ0LWlldGYtdHN2d2ctY2lyY3VpdC1icmVha2VyLTExDQo+Pg0KPj4gVGhhbmtzLCBh IGZldyBjbGFyaWZpY2F0aW9ucyBiZWxvdywNCj4+DQo+PiBiZXN0IHdpc2hlcywNCj4+DQo+PiBH b3JyeQ0KPj4NCj4+DQo+Pj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBv ZiB0aGUgT3BlcmF0aW9uYWwNCj4+PiBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJl dmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcNCj4+PiBwcm9jZXNzZWQgYnkgdGhlIElFU0cu DQo+Pj4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHdpdGggdGhlIGludGVudCBvZiBpbXBy b3ZpbmcgdGhlDQo+Pj4gb3BlcmF0aW9uYWwgYXNwZWN0cyBvZiB0aGUgSUVURiBkcmFmdHMuIENv bW1lbnRzIHRoYXQgYXJlIG5vdA0KPj4+IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5IGJlIGlu Y2x1ZGVkIGluIEFEIHJldmlld3MgZHVyaW5nIHRoZSBJRVNHDQo+Pj4gcmV2aWV3LiBEb2N1bWVu dCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzDQo+Pj4g anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+Pj4NCj4+PiBNYWpvciBp c3N1ZSB3aXRoIHRoZSBwcm9wb3NlZCBhcHByb2FjaDoNCj4+Pg0KPj4+IFRyYWZmaWMgY29udGlu dW91c2x5IGdvIGZyb20gSW5ncmVzcyBhbmQgZWdyZXNzLg0KPj4+IElmIHRoZSBJbmdyZXNzIGFu ZCBlZ3Jlc3Mgbm9kZXMgZG9uJ3QgIGhhdmUgc3luY2hyb25pemVkIHRpbWVycyBhcw0KPj4+IFNP TkVUL1NESCAobW9zdCBwYWNrZXQgcm91dGVycy9zd2l0Y2hlcyBkb24ndCBoYXZlIHN5bmNocm9u aXplZA0KPj4+IHRpbWVyKSwgdGhlIG1ldGVycyBjb2xsZWN0ZWQgYnkgYm90aCBlbmRzIGNhbid0 IGJlIGNvcnJlbGF0ZWQNCj4+PiBwcm9wZXJseSAoaS5lLiB0aGV5IGFyZSBtZWFuaW5nbGVzcyku DQo+Pj4NCj4+PiBUaGUgb25seSB3YXlzIGZvciB0aGUgbWV0ZXJzIG9uIGJvdGggSW5ncmVzcyBh bmQgRWdyZXNzIHRvIHdvcmsNCj4+PiByZWxpYWJseSAod2l0aG91dCBzeW5jaHJvbml6ZWQgdGlt ZXIpIGlzIHZpYSBFQ04sIG9yIHZpYSBzeW50aGV0aWMNCj4+PiBkYXRhIChsaWtlIElQUE0pLg0K Pj4+DQo+PiBJIHRoaW5rIG9uZSBjb3VsZCB1c2UgSVBQTSBtZXRob2RzLCBidXQgdGhlIGludGVu dGlvbiBpcyBub3QgdG8gdHJhY2sNCj4+IGFjY3VyYXRlIGNvbmdlc3Rpb24gbGV2ZWxzLCBidXQg dG8gdHJpZ2dlciBvbiBwZXJzaXN0ZW50IG92ZXJsb2FkLiBUaGUNCj4+IElEIGRlc2NyaWJlcyBz dWNoIG1lYXN1cmVtZW50cyB0YWtlbiBvdmVyIGludGVydmFscyAib2Ygc2Vjb25kcyB0bw0KPj4g cG9zc2libHkgbWFueSB0ZW5zIG9mIHNlY29uZHMiLiBJIGRvbid0IHRoaW5rIHRoaXMgcmVxdWly ZXMgdGhlIHRpZ2h0DQo+PiB0aW1pbmcgb2YgU0RIL1NPTkVULg0KPj4NCj4+PiBGb3IgIkNpcmN1 aXQgQnJlYWtlciBiYXNlZCBvbiBSVFAiLCBEUEkgaGFzIHRvIGJlIGRlcGxveWVkIHRvIGRldGVj dA0KPj4+IFJUUCBpZiB0aGUgSW5ncmVzcyBhbmQgZWdyZXNzIG5vZGVzIGFyZSB0aGUgZW5kIHBv aW50cyBvZiB0dW5uZWwgKGkuZS4NCj4+PiBhZ2dyZWdhdGVkIHRyYWZmaWMpLiBUaGUgYXBwcm9h Y2ggaXMgdmVyeSBleHBlbnNpdmUuDQo+Pj4NCj4+DQo+PiBTZWN0aW9uIDYuMSBtYWtlcyBpdCBj bGVhciB0aGF0IGVuZHBvaW50IGltcGxlbWVudGF0aW9uIGlzIGV4cGVjdGVkDQo+PiBmb3IgdGhl IFJUUCBjaXJjdWl0IGJyZWFrZXIsIGFsdGhvdWdoIGFzIHlvdSBzYXkgd2l0aCBEUEksIGFuZCBh Y2Nlc3MNCj4+IHRvIHRyYWZmaWMgc29tZW9uZSBjb3VsZCBkZWNpZGUgIHRvIGltcGxlbWVudCB0 aGlzIHdpdGhpbiBhIG5ldHdvcmsNCj4+IGRldmljZToNCj4+DQo+PiAgICJBbHRob3VnaCB0aGUg bWVjaGFuaXNtcyBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gYSBSVFAtYXdhcmUgbmV0d29yaw0KPj4g ICAgZGV2aWNlcywgdGhlc2UgbWVjaGFuaXNtcyBhcmUgYWxzbyBzdWl0YWJsZSBmb3IgaW1wbGVt ZW50YXRpb24gaW4NCj4+ICAgIGVuZHBvaW50cyAoZS5nLiwgYXMgYSBwYXJ0IG9mIHRoZSB0cmFu cG9ydCBzeXN0ZW0pLCB3aGVyZSB0aGV5IGNhbg0KPj4gICAgYWxzbyBjb21wbGltZW50IGVuZC10 by1lbmQgY29uZ2VzdGlvbiBjb250cm9sIG1ldGhvZHMuICBBIHNob3J0ZXINCj4+ICAgIHJlc3Bv bnNlIHRpbWUgZW5hYmxlcyB0aGVzZSBtZWNoYW5pc21zIHRvIHRyaWdnZXJzIGJlZm9yZSBvdGhl ciBmb3Jtcw0KPj4gICAgb2YgY2lyY3VpdCBicmVha2VyIChlLmcuLCBjaXJjdWl0IGJyZWFrZXJz IG9wZXJhdGluZyBvbiB0cmFmZmljDQo+PiAgICBhZ2dyZWdhdGVzIGF0IGEgcG9pbnQgYWxvbmcg dGhlIG5ldHdvcmsgcGF0aCkuIg0KPj4NCj4+PiBNaW5vciBpc3N1ZToNCj4+PiBUeXBvczoNCj4+ Pg0KPj4+DQo+Pj4gLSAgICAgICAgUGFnZSA1OiBUaGUgIHBhcmFncmFwaCBiZWZvcmUgMS4xOg0K Pj4+ICJDaXJjdWl0IEJyZWFrZXIgaGFzIGluIGZhY3QgYmVpbmcgdHJpcHBlZCI6IGRvIHlvdSBt ZWFuICJiZWluZw0KPj4+IHRyaWdnZXJlZCI/DQo+Pj4NCj4+IFRoYW5rcywgd2lsbCBiZSBmaXhl ZC4NCj4+DQo+Pj4NCj4+PiBSZWdhcmRzLCBMaW5kYSBEdW5iYXINCj4+Pg0KPj4+DQo+Pg0KPg0K DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657DEAAF0dfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpi O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZ3JlZSB3aXRoIFNwZW5jZXLigJlzIGFw cHJvYWNoLiBUaGFua3MuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpbmRhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNwZW5jZXIg RGF3a2lucyBhdCBJRVRGIFttYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDExLCAyMDE2IDg6MjcgQU08YnI+ DQo8Yj5Ubzo8L2I+IGdvcnJ5QGVyZy5hYmRuLmFjLnVrPGJyPg0KPGI+Q2M6PC9iPiBMaW5kYSBE dW5iYXI7IG9wcy1kaXJAaWV0Zi5vcmc7IG9wcy1hZHNAdG9vbHMuaWV0Zi5vcmc7IHRzdndnQGll dGYub3JnOyBkcmFmdC1pZXRmLXRzdndnLWNpcmN1aXQtYnJlYWtlckBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3RzdndnXSByZXZpZXcgY29tbWVudHMgdG8gZHJhZnQtaWV0Zi10 c3Z3Zy1jaXJjdWl0LWJyZWFrZXItMTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpLCBHb3JyeSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFic29sdXRlbHkgTk9UIHNwZWFraW5nIGFzIEFEIG9uIHRoaXMg b25lIC4uLiBqdXN0IGFza2luZyBhIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFRodSwgRmViIDExLCAyMDE2IGF0IDQ6MzIgQU0sICZsdDs8YSBocmVm PSJtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiIHRhcmdldD0iX2JsYW5rIj5nb3JyeUBlcmcu YWJkbi5hYy51azwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TGluZGEsPGJyPg0KPGJyPg0KSSBtYXliZSBjb25mdXNlZCB5b3UuPGJyPg0KPGJyPg0K SSdtIG5vdCBkaXNhZ3JlZWluZyB0aGF0IGl0IGNhbiBiZSBnb29kIGZvciBhbiBvcGVyYXRvciB0 byBtb25pdG9yIHBvcnQ8YnI+DQp1dGlsaXNhdGlvbiwgbm9yIHRoYXQgdGhlcmUgbWF5IGJlIGFk ZGl0aW9uYWwgcGFyYW1ldGVycyBpbiBhIHN3aXRjaCw8YnI+DQpyb3V0ZXIsIGV0YyB0aGF0IGNh biBoZWxwIHNvbWVvbmUgZGV0ZWN0IHByb2JsZW1zIGFuZCB0byByZWFjdCBxdWlja2VyPGJyPg0K dGhhbiBhIGNpcmN1aXQgYnJlYWtlciB3b3VsZCwgY29uZ2VzdGlvbiBjb250cm9sIGlzIGFsd2F5 cyBiZXR0ZXIgKElNSE8pLjxicj4NCklmIGltcGxlbWVudGVkLCBzdWNoIG1lY2hhbmlzbXMgc2hv dWxkIGhhcHBlbiBiZWZvcmUgdGhlIHRyYW5zcG9ydCBjaXJjdWl0PGJyPg0KYnJlYWtlciB0cmln Z2VycyAoYXMgYSBsYXN0IHJlc29ydCB0byByZWFjdCB3aGVuIGV4Y2Vzc2l2ZSBjb25nZXN0aW9u PGJyPg0Kc3RpbGwgcmVtYWlucywgc3VyZSBhIHRydWx5IGh1Z2UgbnVtYmVyIG9mIGJpdHMgY2Fu IGhhdmUgcGFzc2VkIG9uIGEgMTBHPGJyPg0KbGluayBpbiB0aGlzIGludGVydmFsKS48YnI+DQo8 YnI+DQpUaGUgY2lyY3VpdCBicmVha2VyIG1lY2hhbmlzbSBpcyBpbnRlbmRlZCB0byB3b3JrIG92 ZXIgbG9uZyB0aW1lIHNjYWxlcyAoYTxicj4NCmZhc3QgdHJpcCB3b3JrcyBvbiBhIHRpbWUgdGhh dCBpcyBsb25nIGNvbXBhcmVkIHRvIHRoZSBlbmRwb2ludCBjb25nZXN0aW9uPGJyPg0KY29udHJv bCkgYW5kIHRoZSBvdGhlciBjaXJjdWl0IGJyZWFrZXJzIG9uIGEgc3RpbGwgbG9uZ2VyIHRpbWVz Y2FsZTogSSdtPGJyPg0KZXhwZWN0aW5nIGEgY2lyY3VpdCBicmVha2VyIHRvIHRha2UgYWN0aW9u IHdoZW4gZXhjZXNzaXZlIGNvbmdlc3Rpb24gaXM8YnI+DQpvYnNlcnZlZCB0aGF0IHBlcnNpc3Rz IGZvciBzZWNvbmRzIHRvIG1hbnkgdGVucyBvZiBzZWNvbmRzIGFuZCB0aGU8YnI+DQpzeW5jaHJv bmlzYXRpb24gdG8gbWVhc3VyZSBleGNlc3NpdmUgY29uZ2VzdGlvbiBvdmVyIHRoaXMgcGVyaW9k IGRvZXNuJ3Q8YnI+DQpuZWVkIHRvIGJlIGFueXdoZXJlIGF0IHRoZSBsZXZlbCBvZiBtaWxsaXNl Y29uZHMuPGJyPg0KPGJyPg0KRG9lcyB0aGF0IGhlbHAgc2V0IHRoZSBjb250ZXh0PzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGFzc3VtaW5nIHRoYXQg aXQgZG9lcyAuLi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SWYgc28sIEknbSB0aGlua2luZyB0aGF0IHRoZSBJbnRyb2R1Y3Rpb24g aXMgcHJldHR5IGNsZWFyIGFib3V0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYSB0cmFuc3BvcnQg Y2lyY3VpdCBicmVha2VyIGFuZCB0cmFuc3BvcnQtbGV2ZWwgY29uZ2VzdGlvbiBjb250cm9sICgm cXVvdDtsZXQgdHJhbnNwb3J0LWxldmVsIGNvbmdlc3Rpb24gY29udHJvbCB3b3JrLCBpZiBpdCdz IGdvaW5nIHRvLCBhbmQgdHJpcCBhIHRyYW5zcG9ydA0KIGNpcmN1aXQgYnJlYWtlciBpZiBub3Qm cXVvdDspLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JJ20gd29uZGVyaW5nIGlmIExpbmRhJ3MgY29tbWVudCBwb2ludHMgdG8gdGhl IHBvc3NpYmlsaXR5IG9mIGFkZGluZyBhIHBhcmFncmFwaCBhYm91dCB0aGUgZGlmZmVyZW5jZSBi ZXR3ZWVuIGEgdHJhbnNwb3J0IGNpcmN1aXQgYnJlYWtlciBhbmQgbGluayB1dGlsaXphdGlvbiBv biBwb3J0cywgd2hlbiB0aGF0J3MgYXZhaWxhYmxlIChhbHNvICZxdW90O2xldCBsaW5rIHV0aWxp emF0aW9uIHdvcmsgaW4gbWlsbGlzZWNvbmRzDQogaWYgaXQncyBnb2luZyB0bywgYW5kIGRvIHNv bWV0aGluZyBlbHNlIGlmIG5vdCZxdW90OykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgaGF2ZSBhbiBvcGluaW9uIGFib3V0IGhv dyB1c2VmdWwgb3IgYXBwcm9wcmlhdGUgdGhhdCB3b3VsZCBiZSwgYnV0IHdhbnRlZCB0byBhc2sg dGhlIHF1ZXN0aW9uIHdoaWxlIHlvdSdyZSBsb29raW5nIGF0IHJldmlldyBjb21tZW50cywgYW5k IG5vdCBhdCBzb21lIHBvaW50IGluIHRoZSBmdXR1cmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlbmNlcjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFz cz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+R29ycnk8L3NwYW4+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCiZndDsgR29ycnksPGJyPg0KJmd0 Ozxicj4NCiZndDsgTW9zdCBuZXR3b3JrIHRvZGF5IGhhdmUgJmd0OzEwRyBsaW5rcy9wb3J0cy4g QSBmZXcgbWlsbGlzZWNvbmRzIGRpZmZlcmVuY2UgaW48YnI+DQomZ3Q7IHRpbWVyIGNhbiByZXN1 bHQgaW4gdmVyeSBiaWcgZGlmZmVyZW5jZXMgaW4gdGhlIGNvbGxlY3RlZCBtZWFzdXJlbWVudDxi cj4NCiZndDsgYmV0d2VlbiBJbmdyZXNzIGFuZCBlZ3Jlc3MuIEkganVzdCB3YW50IHRvIHBvaW50 IG91dCB0aGF0IHRoZSBwcm9wb3NlZDxicj4NCiZndDsgbWVjaGFuaXNtIGNhbid0IGFjY3VyYXRl bHkgZGV0ZWN0IG92ZXJsb2FkIGlmIGJvdGggaW5ncmVzcyBhbmQgZWdyZXNzPGJyPg0KJmd0OyBu b2RlcyBkb24ndCB1c2Ugc3luY2hyb25pemVkIHRpbWVyLjxicj4NCiZndDs8YnI+DQomZ3Q7IExp bmRhPGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom Z3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayI+Z29ycnlAZXJn LmFiZG4uYWMudWs8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFj LnVrIj5nb3JyeUBlcmcuYWJkbi5hYy51azwvYT5dPGJyPg0KJmd0OyBTZW50OiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDEwLCAyMDE2IDEyOjU1IFBNPGJyPg0KJmd0OyBUbzogTGluZGEgRHVuYmFyPGJy Pg0KJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrIj5nb3JyeUBl cmcuYWJkbi5hYy51azwvYT47IDxhIGhyZWY9Im1haWx0bzpvcHMtZGlyQGlldGYub3JnIj4NCm9w cy1kaXJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86b3BzLWFkc0B0b29scy5pZXRmLm9y ZyI+b3BzLWFkc0B0b29scy5pZXRmLm9yZzwvYT47PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86 dHN2d2dAaWV0Zi5vcmciPnRzdndnQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0 LWlldGYtdHN2d2ctY2lyY3VpdC1icmVha2VyQGlldGYub3JnIj4NCmRyYWZ0LWlldGYtdHN2d2ct Y2lyY3VpdC1icmVha2VyQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6IFt0c3Z3 Z10gcmV2aWV3IGNvbW1lbnRzIHRvPGJyPg0KJmd0OyBkcmFmdC1pZXRmLXRzdndnLWNpcmN1aXQt YnJlYWtlci0xMTxicj4NCiZndDs8YnI+DQomZ3Q7IEhJIExpbmRhLDxicj4NCiZndDs8YnI+DQom Z3Q7IEkgdGhpbmsgY29uc2lkZXJpbmcgdGhlICZxdW90O2xpbmsgdXRpbGl6YXRpb24gJnF1b3Q7 IG9uIGEgcGh5c2ljYWwgaW50ZXJmYWNlIG1heSBiZTxicj4NCiZndDsgT0sgdG8gZGV0ZWN0IG92 ZXJsb2FkIC0gYnV0IHRoaXMgaXMgbm90IHRoZSBtYWluIGZvY3VzIG9mIHRoZSBkb2N1bWVudC48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBHb3JyeTxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBHb3JyeSw8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZvciAmcXVvdDt0cmlnZ2VyIG9uIHBlcnNpc3Rl bnQgb3ZlcmxvYWQmcXVvdDssIHdoeSBub3QgY29uc2lkZXIgdGhlIExpbms8YnI+DQomZ3Q7Jmd0 OyBVdGlsaXphdGlvbiBtZWFzdXJlbWVudCBvbiBwb3J0cyAod2hpY2ggaXMgbXVjaCBtb3JlIHJl bGlhYmxlIGFuZCBtdWNoPGJyPg0KJmd0OyZndDsgc2ltcGxlcikuPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBBcyBhIG1hdHRlciBvZiBmYWN0LCBpdCBpcyBhIHZlcnkgY29tbW9ubHkgZGVw bG95ZWQgcHJvY2VkdXJlIGJ5IG1hbnk8YnI+DQomZ3Q7Jmd0OyBvcGVyYXRvcnMgdG8gdXNlICZx dW90O2xpbmsgdXRpbGl6YXRpb24gJnF1b3Q7IChjcm9zcyBhIGNvbmZpZ3VyZWQgdGhyZXNob2xk KSB0bzxicj4NCiZndDsmZ3Q7IHRyaWdnZXIgdGhlIG5lZWRlZCBhY3Rpb25zIChvciB3aGF0IHlv dSBjYWxsICZxdW90O2NpcmN1aXQgYnJlYWtlciZxdW90OyBpbiB5b3VyPGJyPg0KJmd0OyZndDsg ZHJhZnQpIGZvciB0aGUgbmV0d29yay48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IExpbmRh PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVy Zy5hYmRuLmFjLnVrIj5nb3JyeUBlcmcuYWJkbi5hYy51azwvYT4gW21haWx0bzo8YSBocmVmPSJt YWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9hPl08YnI+ DQomZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA1LCAyMDE2IDI6NDUgQU08YnI+DQom Z3Q7Jmd0OyBUbzogTGluZGEgRHVuYmFyPGJyPg0KJmd0OyZndDsgQ2M6IDxhIGhyZWY9Im1haWx0 bzpkcmFmdC1pZXRmLXRzdndnLWNpcmN1aXQtYnJlYWtlckBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi10 c3Z3Zy1jaXJjdWl0LWJyZWFrZXJAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOm9wcy1k aXJAaWV0Zi5vcmciPm9wcy1kaXJAaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9 Im1haWx0bzpvcHMtYWRzQHRvb2xzLmlldGYub3JnIj5vcHMtYWRzQHRvb2xzLmlldGYub3JnPC9h PjsgPGEgaHJlZj0ibWFpbHRvOnRzdndnQGlldGYub3JnIj4NCnRzdndnQGlldGYub3JnPC9hPjxi cj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiByZXZpZXcgY29tbWVudHMgdG8gZHJhZnQtaWV0Zi10 c3Z3Zy1jaXJjdWl0LWJyZWFrZXItMTE8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5r cywgYSBmZXcgY2xhcmlmaWNhdGlvbnMgYmVsb3csPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBiZXN0IHdpc2hlcyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEdvcnJ5PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJIGhhdmUgcmV2aWV3ZWQgdGhp cyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBPcGVyYXRpb25hbDxicj4NCiZndDsmZ3Q7Jmd0OyBk aXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMg YmVpbmc8YnI+DQomZ3Q7Jmd0OyZndDsgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLjxicj4NCiZndDsm Z3Q7Jmd0OyBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50IG9mIGlt cHJvdmluZyB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsgb3BlcmF0aW9uYWwgYXNwZWN0cyBvZiB0aGUg SUVURiBkcmFmdHMuIENvbW1lbnRzIHRoYXQgYXJlIG5vdDxicj4NCiZndDsmZ3Q7Jmd0OyBhZGRy ZXNzZWQgaW4gbGFzdCBjYWxsIG1heSBiZSBpbmNsdWRlZCBpbiBBRCByZXZpZXdzIGR1cmluZyB0 aGUgSUVTRzxicj4NCiZndDsmZ3Q7Jmd0OyByZXZpZXcuIERvY3VtZW50IGVkaXRvcnMgYW5kIFdH IGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHM8YnI+DQomZ3Q7Jmd0OyZndDsganVz dCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPGJyPg0KJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IE1ham9yIGlzc3VlIHdpdGggdGhlIHByb3Bvc2VkIGFwcHJvYWNoOjxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUcmFmZmljIGNvbnRpbnVvdXNseSBn byBmcm9tIEluZ3Jlc3MgYW5kIGVncmVzcy48YnI+DQomZ3Q7Jmd0OyZndDsgSWYgdGhlIEluZ3Jl c3MgYW5kIGVncmVzcyBub2RlcyBkb24ndCZuYnNwOyBoYXZlIHN5bmNocm9uaXplZCB0aW1lcnMg YXM8YnI+DQomZ3Q7Jmd0OyZndDsgU09ORVQvU0RIIChtb3N0IHBhY2tldCByb3V0ZXJzL3N3aXRj aGVzIGRvbid0IGhhdmUgc3luY2hyb25pemVkPGJyPg0KJmd0OyZndDsmZ3Q7IHRpbWVyKSwgdGhl IG1ldGVycyBjb2xsZWN0ZWQgYnkgYm90aCBlbmRzIGNhbid0IGJlIGNvcnJlbGF0ZWQ8YnI+DQom Z3Q7Jmd0OyZndDsgcHJvcGVybHkgKGkuZS4gdGhleSBhcmUgbWVhbmluZ2xlc3MpLjxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUgb25seSB3YXlzIGZvciB0aGUgbWV0ZXJz IG9uIGJvdGggSW5ncmVzcyBhbmQgRWdyZXNzIHRvIHdvcms8YnI+DQomZ3Q7Jmd0OyZndDsgcmVs aWFibHkgKHdpdGhvdXQgc3luY2hyb25pemVkIHRpbWVyKSBpcyB2aWEgRUNOLCBvciB2aWEgc3lu dGhldGljPGJyPg0KJmd0OyZndDsmZ3Q7IGRhdGEgKGxpa2UgSVBQTSkuPGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgSSB0aGluayBvbmUgY291bGQgdXNlIElQUE0gbWV0aG9kcywgYnV0 IHRoZSBpbnRlbnRpb24gaXMgbm90IHRvIHRyYWNrPGJyPg0KJmd0OyZndDsgYWNjdXJhdGUgY29u Z2VzdGlvbiBsZXZlbHMsIGJ1dCB0byB0cmlnZ2VyIG9uIHBlcnNpc3RlbnQgb3ZlcmxvYWQuIFRo ZTxicj4NCiZndDsmZ3Q7IElEIGRlc2NyaWJlcyBzdWNoIG1lYXN1cmVtZW50cyB0YWtlbiBvdmVy IGludGVydmFscyAmcXVvdDtvZiBzZWNvbmRzIHRvPGJyPg0KJmd0OyZndDsgcG9zc2libHkgbWFu eSB0ZW5zIG9mIHNlY29uZHMmcXVvdDsuIEkgZG9uJ3QgdGhpbmsgdGhpcyByZXF1aXJlcyB0aGUg dGlnaHQ8YnI+DQomZ3Q7Jmd0OyB0aW1pbmcgb2YgU0RIL1NPTkVULjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IEZvciAmcXVvdDtDaXJjdWl0IEJyZWFrZXIgYmFzZWQgb24gUlRQJnF1 b3Q7LCBEUEkgaGFzIHRvIGJlIGRlcGxveWVkIHRvIGRldGVjdDxicj4NCiZndDsmZ3Q7Jmd0OyBS VFAgaWYgdGhlIEluZ3Jlc3MgYW5kIGVncmVzcyBub2RlcyBhcmUgdGhlIGVuZCBwb2ludHMgb2Yg dHVubmVsIChpLmUuPGJyPg0KJmd0OyZndDsmZ3Q7IGFnZ3JlZ2F0ZWQgdHJhZmZpYykuIFRoZSBh cHByb2FjaCBpcyB2ZXJ5IGV4cGVuc2l2ZS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IFNlY3Rpb24gNi4xIG1ha2VzIGl0IGNsZWFyIHRoYXQgZW5kcG9pbnQg aW1wbGVtZW50YXRpb24gaXMgZXhwZWN0ZWQ8YnI+DQomZ3Q7Jmd0OyBmb3IgdGhlIFJUUCBjaXJj dWl0IGJyZWFrZXIsIGFsdGhvdWdoIGFzIHlvdSBzYXkgd2l0aCBEUEksIGFuZCBhY2Nlc3M8YnI+ DQomZ3Q7Jmd0OyB0byB0cmFmZmljIHNvbWVvbmUgY291bGQgZGVjaWRlJm5ic3A7IHRvIGltcGxl bWVudCB0aGlzIHdpdGhpbiBhIG5ldHdvcms8YnI+DQomZ3Q7Jmd0OyBkZXZpY2U6PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsmcXVvdDtBbHRob3VnaCB0aGUgbWVjaGFu aXNtcyBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gYSBSVFAtYXdhcmUgbmV0d29yazxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyBkZXZpY2VzLCB0aGVzZSBtZWNoYW5pc21zIGFyZSBhbHNvIHN1aXRh YmxlIGZvciBpbXBsZW1lbnRhdGlvbiBpbjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBlbmRw b2ludHMgKGUuZy4sIGFzIGEgcGFydCBvZiB0aGUgdHJhbnBvcnQgc3lzdGVtKSwgd2hlcmUgdGhl eSBjYW48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgYWxzbyBjb21wbGltZW50IGVuZC10by1l bmQgY29uZ2VzdGlvbiBjb250cm9sIG1ldGhvZHMuJm5ic3A7IEEgc2hvcnRlcjxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyByZXNwb25zZSB0aW1lIGVuYWJsZXMgdGhlc2UgbWVjaGFuaXNtcyB0 byB0cmlnZ2VycyBiZWZvcmUgb3RoZXIgZm9ybXM8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg b2YgY2lyY3VpdCBicmVha2VyIChlLmcuLCBjaXJjdWl0IGJyZWFrZXJzIG9wZXJhdGluZyBvbiB0 cmFmZmljPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IGFnZ3JlZ2F0ZXMgYXQgYSBwb2ludCBh bG9uZyB0aGUgbmV0d29yayBwYXRoKS4mcXVvdDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyBNaW5vciBpc3N1ZTo8YnI+DQomZ3Q7Jmd0OyZndDsgVHlwb3M6PGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IC0mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgUGFnZSA1OiBUaGUmbmJzcDsgcGFyYWdyYXBoIGJlZm9yZSAxLjE6PGJyPg0K Jmd0OyZndDsmZ3Q7ICZxdW90O0NpcmN1aXQgQnJlYWtlciBoYXMgaW4gZmFjdCBiZWluZyB0cmlw cGVkJnF1b3Q7OiBkbyB5b3UgbWVhbiAmcXVvdDtiZWluZzxicj4NCiZndDsmZ3Q7Jmd0OyB0cmln Z2VyZWQmcXVvdDs/PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhhbmtzLCB3aWxs IGJlIGZpeGVkLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7IFJlZ2FyZHMsIExpbmRhIER1bmJhcjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_4A95BA014132FF49AE685FAB4B9F17F657DEAAF0dfweml701chm_-- From nobody Thu Feb 11 16:43:18 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12831B3D29; Thu, 11 Feb 2016 16:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 jdYp-g93T3xu; Thu, 11 Feb 2016 16:42:57 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2341A6F9B; Thu, 11 Feb 2016 16:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3117; q=dns/txt; s=iport; t=1455237776; x=1456447376; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=mL5RujlLu8pt2gOMhBLBDxrzwPJDepndMbkm/4CJxWo=; b=Gg5THBw8M2Q3J7IFjxx+Tl/fDNi645iMMbdDdGzAmYhBVynQGEfTM/dm hyj9TCrkWB1HH1ha+yYCSMwdjb8kbFNgfVdf9hMWPTA+QulC2un7DG2u2 iRfYkc5+0JVUIiaf7euNAx4/L+PMo+fJUwRxvtZx056JbJztdNVzT2t8a Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQBTKr1W/5tdJa1egzpSbQaIVbEpA?= =?us-ascii?q?Q2BZyOFagKBOTgUAQEBAQEBAX8LhEEBAQEEOj0CDAQCAQgRBAEBHwkHMhQJCAI?= =?us-ascii?q?EDgUIiBIOwTUBAQEBAQEBAQEBAQEBAQEBAQEBAQEVikeIbAWNJ4lQAYVNh36BY?= =?us-ascii?q?0qDeYhVjj0BHgEBQoNkagGHInwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,433,1449532800"; d="scan'208";a="236764588" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2016 00:42:55 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1C0gt7U008862 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Feb 2016 00:42:55 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 18:42:55 -0600 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 18:42:55 -0600 From: "Surendra Kumar (smkumar)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.txt Thread-Index: AQHRZQhY9c88+3ynwkOLHr9c9z3LPJ8nh70QgAAKsuA= Date: Fri, 12 Feb 2016 00:42:55 +0000 Message-ID: References: <20160211201106.3882.86407.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.10.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 00:43:02 -0000 2nd attempt to get it sent right. -----Original Message----- From: Surendra Kumar (smkumar)=20 Sent: Thursday, February 11, 2016 4:09 PM To: sfc@ietf.org Cc: 'tsvwg@ietf.org' ; draft-kumar-sfc-nsh-udp-transport@to= ols.ietf.org Subject: FW: New Version Notification for draft-kumar-sfc-nsh-udp-transport= -02.txt Hello All, We published -02 version of the UDP transport draft for NSH based on the fe= edback we received from David Black and others. In particular, it aligns with the usage guidelines in I-D.ietf-tsvwg-rfc540= 5bis version-07 w.r.t congestion control, security and other considerations= . Your feedback on the draft is very much appreciated. Regards, nsh-udp draft co-authors PS: Home for this draft is still being hashed out. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, February 11, 2016 12:11 PM To: Walter Haeffner ; Rajeev Manur ; Larry Kreeger (kreeger) ; Surendra Kumar (s= mkumar) ; Surendra Kumar (smkumar) ; = David T. Melman ; Sumandra Majee ; Dav= id Melman ; Larry Kreeger (kreeger) Subject: New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.= txt A new version of I-D, draft-kumar-sfc-nsh-udp-transport-02.txt has been successfully submitted by Surendra Kumar and posted to the IETF re= pository. Name: draft-kumar-sfc-nsh-udp-transport Revision: 02 Title: UDP Transport for Network Service Header Document date: 2016-02-11 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-kumar-sfc-nsh-ud= p-transport-02.txt Status: https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-udp-tr= ansport/ Htmlized: https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transpo= rt-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-sfc-nsh-udp= -transport-02 Abstract: This draft describes the transport encapsulation to carry Network Service Header (NSH) over UDP transport protocol. This enables applications and services using NSH to communicate over a simple layer-3 network without topological constraints. It brings down the barrier to deploy NSH by not requiring additional overhead as is typical of overlay encapsulation mechanisms designed on top of UDP. As a first benefit, this method eases the deployment of Service Function Chaining (SFC) by allowing SFC components to utilize the basic UDP/IP stack available in virtually all network elements and end systems to setup the virtual network and realize Service Function Chains (SFCs). = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Feb 12 06:44:16 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C9E1A039C; Fri, 12 Feb 2016 06:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Ai0LpozeuqSB; Fri, 12 Feb 2016 06:44:13 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 86EA31A0397; Fri, 12 Feb 2016 06:44:13 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 4F0AF1B001A1; Fri, 12 Feb 2016 14:51:40 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Fri, 12 Feb 2016 14:44:12 -0000 Message-ID: <93d97b2202774864de937bf414502d8c.squirrel@erg.abdn.ac.uk> In-Reply-To: References: Date: Fri, 12 Feb 2016 14:44:12 -0000 From: gorry@erg.abdn.ac.uk To: "Andrew G. Malis" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "rtg-dir@ietf.org" , IETF Discussion , rtg-ads@ietf.org, tsvwg@ietf.org, IESG , draft-ietf-tsvwg-circuit-breaker.all@ietf.org Subject: Re: [tsvwg] RtgDir review: draft-ietf-tsvwg-circuit-breaker-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:44:15 -0000 Thank you for sending your comments, I have tried to make changes that incorporate comments from the various area reviews, and expect to shortly release an ID revision (12) that has these improvements. Details of the points addressed are below. Gorry --- Summary: I have some minor concerns about this document that I think should be resolved before publication. Major Issues: No major issues found. Minor Issues: Page 3, first paragraph: There are no citations to the claim that non-congestion-controlled traffic "can form a significant proportion of the total traffic traversing a link". Sure, video is a major part of Internet traffic these days, but much Internet video is dynamically adaptive. One or more citations would be useful. -GF: Understood, but I want to consult on the most suitable reference. Section 4: There are so many issues that they should be numbered, so that they can be referred to individually (from another document, for example). -GF: Numbered. Page 11: In my opinion, the second and third requirements on this page should be "MUST"s rather than "SHOULD"s. -GF: Changed: A Circuit Breaker MUST be constructed so that it does not trigger under light or intermittent congestion. -GF: I did not change: �The default response to a trigger SHOULD disable all traffic that contributed to congestion.� - I query if it really important to dictate the �default� MUST? Page 12, discussion of "In-Band" near the bottom of the page: This paragraph implies that an in-band control method will always provide fate-sharing of the control and regular traffic. It may provide fate-sharing, but that is by no means assured. For example, the network may be using ECMP, or traffic tunnels for data but not control traffic. -GF: Added: �This fate-sharing property is weaker when some or all of the measured traffic is sent using a path that differs from the path taken by the control traffic (e.g., where traffic follows a different path de to use of equal-cost multipath routing, traffic engineering, or tunnels for specific types of traffic). � Section 5: I'm not sure why Section 5 is a separate section, and not integrated into Section 3 as new subsections, which I think would be an improvement. -GF: I had contemplated this move, and have no preference. In the new revision I moved the text to section 3. Page 13, first paragraph: "presented in figure 2" -> "presented in figures 1 and 2�. -GF: done. Page 19, fourth paragraph: This paragraph states that "IP-based traffic is generally assumed to be congestion-controlled". This is true for TCP-based traffic, but I would not make such an assumption for all IP-based traffic. - GF: Rephrased a little, although the present protocol assumption is that UDP-based traffic needs to provide some form of congestion response, the reality is that this is not always the case. Nits: The abbreviation "CB" is defined early in the document, but is hardly if ever used thereafter, rather "Circuit Breaker" is almost always spelled out. It may be useful to actually use the abbreviation. -GF: done within the normative section, where the term is used a lot. Page 3, first paragraph, fifth line, "connection" -> "connections". -GF: done. Figure 1: Move the vertical line between the "Measure" and "Trigger" boxes one space to the right. -GF: Thanks for spotting, done. Page 10, fourth paragraph: "If necessary, MAY combine" -> "If necessary, a CB MAY combine". -GF: done. Page 11, fifth paragraph: "needs to be" -> "MUST" -GF: done. Page 12, second paragraph: There are two separate references to Section 8. One combined reference should be sufficient. -GF: done. Page 12, second to last paragraph: "in-Band" should have the "i" capitalized. -GF: done. Page 15, last paragraph: "tranport" -> "transport" -GF: done. Page 17, fifth paragraph: "Pseudo Wire" -> "PW" -GF: done. Regards, Andy From nobody Fri Feb 12 06:48:42 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BE61A0470; Fri, 12 Feb 2016 06:48:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160212144839.18024.16843.idtracker@ietfa.amsl.com> Date: Fri, 12 Feb 2016 06:48:39 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-circuit-breaker-12.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:48:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Network Transport Circuit Breakers Author : Godred Fairhurst Filename : draft-ietf-tsvwg-circuit-breaker-12.txt Pages : 26 Date : 2016-02-12 Abstract: This document explains what is meant by the term "network transport Circuit Breaker" (CB). It describes the need for circuit breakers for network tunnels and applications when using non-congestion- controlled traffic, and explains where circuit breakers are, and are not, needed. It also defines requirements for building a circuit breaker and the expected outcomes of using a circuit breaker within the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-circuit-breaker-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-circuit-breaker-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 12 08:03:34 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D381A1F1D; Fri, 12 Feb 2016 08:03:23 -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, SPF_PASS=-0.001] autolearn=ham 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 RU701-uXTpcU; Fri, 12 Feb 2016 08:03:22 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 2D5451A2130; Fri, 12 Feb 2016 08:03:22 -0800 (PST) Received: by mail-ob0-x22b.google.com with SMTP id gc3so26245229obb.3; Fri, 12 Feb 2016 08:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yh4IMz+4Bmube+Ng4HEafgBokDG7NyRJqYcbb+aymGI=; b=rKyc1xGVpwteqUNRKXp1z17XeSb8TOO1tg5sbuig9pUuEzHu2yuS0pxCZHXUVYQDA8 I5xAhaH5VOEXGSGVnScydu1Qp0w/TIqrLkQPj/lpMkW70/mV/HshGCBtgwZ7kfTKetT/ b4jClyHGo9p3jj+uGJ+cSaRgvFmzyzWKwIijVHucq9/pTuyQgAvc5i5ZIUapyW41Bnwf Tu1pvls3jdoZCuk6AZPjaB3yjNL2O5q/ZR+jZqcuRW/fWWdN7Lh0Sv3EJqxXRyl/rWnG 8FVaaNv3VSi6wouhfypO/9rU2bMeuBj05oefQpm2J/UJctrdpA7nduAvTQkhD8jX8Dln 5pGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yh4IMz+4Bmube+Ng4HEafgBokDG7NyRJqYcbb+aymGI=; b=cduEIRukwLjxtDZGR82V4hkGbR+TPK4WcOIAZnW47Jwyhlye6D5abU2yUvrMSvmUSy Om0wfNzN3PYAVShFl+ZpCM/+f+RUd9Qa9y8YzWR4Vz7WCxTrGEuBGUfirN0XGikiQvzb Px1kusMNifqhkZ12ZGpyB5U+ZsF0x6iC4B4CJfWA6V+rRvRWlj0pUI49ID+QyObA5C7W jC5lcJxDT+Xtp6zK0Qps7KEz5z8WeNgvU+zyKr/RGwmee8nj4Fgz17Ck+8Lx32bcZ8Ct yXjCujCEY/yJLvFFADdBDtkT87AHuEBltrMHsgx8OcvSkT48yRrQTb9VKYKFFvvBbhUf gGuw== X-Gm-Message-State: AG10YOQG0NQHXjLagY80yIX+gG+mA2bf0Brm8p9gzXAPf4OoVPUisdE7nYMwYZZBnRWLFA/sV0s7DUTCw14oug== X-Received: by 10.182.135.132 with SMTP id ps4mr1959429obb.58.1455293001658; Fri, 12 Feb 2016 08:03:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.196.104 with HTTP; Fri, 12 Feb 2016 08:03:02 -0800 (PST) In-Reply-To: <93d97b2202774864de937bf414502d8c.squirrel@erg.abdn.ac.uk> References: <93d97b2202774864de937bf414502d8c.squirrel@erg.abdn.ac.uk> From: "Andrew G. Malis" Date: Fri, 12 Feb 2016 11:03:02 -0500 Message-ID: To: gorry@erg.abdn.ac.uk Content-Type: multipart/alternative; boundary=089e01177c17687a38052b94ce64 Archived-At: Cc: "rtg-dir@ietf.org" , IETF Discussion , "" , tsvwg@ietf.org, IESG , draft-ietf-tsvwg-circuit-breaker.all@ietf.org Subject: Re: [tsvwg] RtgDir review: draft-ietf-tsvwg-circuit-breaker-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:03:23 -0000 --089e01177c17687a38052b94ce64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gorry, Thank you for sending your comments, I have tried to make changes that > incorporate comments from the various area reviews, and expect to shortly > release an ID revision (12) that has these improvements. Details of the > points addressed are below. > I=E2=80=99m glad to help. I noticed one new typo in your response, which ma= y only be in your email, but may be in the new text as well. > Page 12, discussion of "In-Band" near the bottom of the page: This > paragraph implies that an in-band control method will always provide > fate-sharing of the control and regular traffic. It may provide > fate-sharing, but that is by no means assured. For example, the network m= ay > be using ECMP, or traffic tunnels for data but not control traffic. > -GF: Added: =E2=80=9CThis fate-sharing property is weaker when some or al= l of the > measured traffic is sent using a path that differs from the path taken by > the control traffic (e.g., where traffic follows a different path de to > use of equal-cost multipath routing, traffic engineering, or tunnels for > specific types of traffic). =E2=80=9D > Change =E2=80=9Cpath de to=E2=80=9D to =E2=80=9Cpath due to=E2=80=9D. Cheers, Andy --089e01177c17687a38052b94ce64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Gorry,

Thank you for sending y= our comments, I have tried to make changes that
incorporate comments from the various area reviews, and expect to shortly release an ID revision (12) that has these improvements. Details of the
points addressed are below.

I=E2= =80=99m glad to help. I noticed one new typo in your response, which may on= ly be in your email, but may be in the new text as well.

=C2=A0

Page 12, discussion of "In-Band"= ; near the bottom of the page: This
paragraph implies that an in-band control method will always provide
fate-sharing of the control and regular traffic. It may provide
fate-sharing, but that is by no means assured. For example, the network may=
be using ECMP, or traffic tunnels for data but not control traffic.
-GF: Added: =E2=80=9CThis fate-sharing property is weaker when some = or all of the
measured traffic is sent using a path that differs from the path taken by the control traffic (e.g., where traffic follows a different path de to
use of equal-cost multipath routing, traffic engineering, or tunnels for specific types of traffic). =E2=80=9D

Change =E2=80=9Cpath de to=E2=80=9D to =E2=80=9Cpath due to=E2=80=9D.

Cheers,

Andy

<= /div>

--089e01177c17687a38052b94ce64-- From nobody Sat Feb 13 23:15:56 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14081B347F for ; Sat, 13 Feb 2016 23:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.692 X-Spam-Level: X-Spam-Status: No, score=0.692 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 vucNKGfHbR7B for ; Sat, 13 Feb 2016 23:15:52 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 877E51A8863 for ; Sat, 13 Feb 2016 23:15:52 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u1E7FmiN004238 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Feb 2016 02:15:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1455434150; bh=SIt/F4a0aKRqY0+fzwfy3AXpLsKi+GefojmhobsK9QU=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=WqDReJMs0AYzgto6dDpJLMdNZxYh7Wv+ftWbiKAbsVec7VsdfzawFeH/NoRpw8Maq XtOcxd0F4XW9+ReJ8aTp0LoprfVaWb3LDn9S2ADrBuLtud7vGd/Kvp4yFff9ovNNK2 YRvHxC4jqIJYbFmUNCHRVoNxNWOX/pUA6G7ESsO0= From: "Paul E. Jones" To: "Brian E Carpenter" , "Black, David" , "tsvwg@ietf.org" Date: Sun, 14 Feb 2016 07:15:50 +0000 Message-Id: In-Reply-To: <56B02B88.2050308@gmail.com> User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.109.150.103]); Sun, 14 Feb 2016 02:15:50 -0500 (EST) Archived-At: Subject: Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - ends Feb 13 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 07:15:54 -0000 Brian, >> Traditionally, DSCP values have been thought of as being site >> specific, with each site selecting its own code points for >> controlling per-hop-behavior to influence the QoS for=20 >>transport-layer >> flows. > >It isn't really "tradition"; it's defined that way in RFC 2474. I would >suggest something like > > DSCP values are in principle site specific, with each site selecting=20 >its > own code points for controlling per-hop-behavior to influence the QoS= =20 >for > transport-layer flows. Sounds good. I've made this change to my local draft. >Also, is this the place to mention that there is ongoing work on=20 >diffserv >interconnection between carriers (draft-ietf-tsvwg-diffserv-intercon)? >This is relevant, because if successful, we can expect the code points=20 >used >for interconnection to become very widely used. In general, it's best to not speculate, I think. If they become so=20 widely used, I doubt a reference would be necessary. However, I'm not=20 opposed to adding something if the group wants it. Exactly what were=20 you thinking? I would hope this does not hold up the draft due to a=20 missing reference. > >> 2. Relation to Other Standards > >Largish nit: not all RFCs are standards. This should probably be: > > 2. Relation to Other Documents OK, I can do that. Is "documents" preferred or should we say=20 "specifications"? >> The DSCP value set by the endpoint is not trusted by the network.= =20 >>In >> addition, the DSCP value may be remarked at any place in the=20 >>network >> for a variety of reasons to any other DSCP value, including=20 >>default >> forwarding (DF) value to provide basic best effort service. The >> mitigation for such action is through an authorization mechanism. >> Such authorization mechanism is outside the scope of this=20 >>document. > >I don't think authorization is *the* mitigation; it's one possible >mitigation. Another possible mitigation is=20 >draft-ietf-tsvwg-diffserv-intercon, >for example. OK, I changed "the" to "a". This focus of this document is the web=20 browser, so I think the trust issues here are separate from those of=20 interconnection, or am I wrong? > >> Table 1: Recommended DSCP Values for WebRTC Applications >... >> The above table assumes that packets marked with CS1 are treated=20 >>as >> "less than best effort". > >Needless to say, this still gives me heartburn. Firstly, it is *not*=20 >CS1. >Its DSCP value is binary 001000 but the behavior abbreviation is LE, as >defined in RFC 3662. It's an example of a site-specific code point.=20 >IMHO >it should be called LE in the table and the text. There should be a=20 >statement >that the standard use of this code point is a *different* behavior=20 >called >CS1. This was used to be consistent with RFC 4594. If LE is preferred, I can= =20 change it, but then should that mean we need to revised RFC 4594? =20 Section 3.2 of RFC 3662 says there are one of several values that might=20 be used for LE traffic, with CS1 being one choice. So, is it wrong to=20 specify CS1 here and RFC 4594? > >> It is common for CS1 to be treated the same as DF,... > >Right, in which case marking your traffic LE and getting DF treatment=20 >is not >so bad. But it's completely compatible with RFC 2474 for CS1 to be=20 >treated >better than DF. I think that risk should be mentioned. OK, how about right after that sentence I add: "However, it is also possible per [RFC2474] for CS1 traffic to be given=20 better treatment than DF, thus caution should be exercised when electing= =20 to use CS1." Then I would start a new paragraph to talk about EF. > >> Implementers should also note >> that excess EF traffic is dropped. This could mean that a packet >> marked as EF may not get through as opposed to a packet marked=20 >>with a >> different DSCP value. > >But that's exactly why you use EF for traffic that wants timely=20 >delivery >more than it hates loss. People designing codecs kind of know this. Is the warning harmful? I think it's useful for those who do not know=20 this. >> In summary, DSCP marking provides neither guarantees nor promised >> levels of service. The service provided to a packet is dependent >> upon the network design along the path, as well as the network >> conditions at every hop. > >That's a bit of a gloomy ending. It might be fair to insert a sentence >in the middle, like: However, DSCP marking is expected to provide >a statistical improvement in the real-time service as a whole. Yeah, it is gloomy. I'm not sure who wrote that, but somebody felt we=20 needed this reminder of reality. Personally, I don't like gloom and=20 doom, especially since there are ways to effectively use DSCP. :-) I'll add your suggested sentence. Now, I've been "warned" before about publishing updated in the middle of= =20 a LC review. I think the review period has now concluded. Shall I=20 publish what I have and give folks one more opportunity to look over the= =20 text? Thanks! Paul From nobody Sun Feb 14 11:40:43 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB421B2BEC for ; Sun, 14 Feb 2016 11:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 1o5z2xI7zOLm for ; Sun, 14 Feb 2016 11:40:40 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 D6BC21B2BEA for ; Sun, 14 Feb 2016 11:40:39 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id c10so76664701pfc.2 for ; Sun, 14 Feb 2016 11:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=3gUPezpJcowm8PMqt1x8t+QOKm12foMfGoyue2JPyDg=; b=Z/SZmIHvzDWJRFOBrb/gNwRlTn53YlvZXBBxx/ZLsPiB1vRdgxI2WQh/Pr79CqAaKd b5mPR/kF5jMVihY/eqdgaHB3v2EOliV1GnoKR1K6ZtLIudP1DQdqxYXXbYelf5VkTfYk 5rPyOmk3eHzxs773BzxeKN2LdV1fvZ3XVCXOTkQaJF1r/6bvAfxJ/vK17t2TQlbQcqtu ijAaHSFs4Zy6oP277/ZLRn6urPi1RZtWb7eCWYPbTXzooTkH8nJO9aglu2iUz6pu5AAz R70JaYKuHeAAYr1WQ/UWj+TKnM4925vAAHLRyMzw/RsCx4W61s8DKpwElOzi+/EUWXd1 JNcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=3gUPezpJcowm8PMqt1x8t+QOKm12foMfGoyue2JPyDg=; b=EI6DJewd9HgR3cFFJa5fPy6XRXZaxLX7XQy20r4FWrKX2VzR6aHYa+bAV8PVIq3dRC /6bhJZL8ba55YOsThr+pq39LI3rpAd0ah3Un3gSaPdH36U7rIbYeTMTTKA0kwRAayyS+ le9JOGVCaVOyNkvBoznLckBSwJL+YL/blc5oroGNQPZ1OA+ukXL79GjNq2fQzZdI8lM/ fZVkcC977f5FlEaWum8iWucg63zOrU1mXyxtU3FR0zv+JkUbDIRO2fY/Ld7oXHDeOD72 ZymqYbOdbp0jxmQ66Th1HD/s78psR6Np03DWbQy1Kj0X7rsSI/Pv9TdRzvjV1tBGJOZJ ij8w== X-Gm-Message-State: AG10YOT2iTvXtqWQkYd5o6ivRiGgczBoj01QesFomZ+vyTzRecLpFU1TmqvbMv5D3XYQWA== X-Received: by 10.98.33.77 with SMTP id h74mr18128475pfh.157.1455478839446; Sun, 14 Feb 2016 11:40:39 -0800 (PST) Received: from ?IPv6:2406:e007:413e:1:28cc:dc4c:9703:6781? ([2406:e007:413e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id tp6sm33228770pab.25.2016.02.14.11.40.35 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 14 Feb 2016 11:40:37 -0800 (PST) To: "Paul E. Jones" , "Black, David" , "tsvwg@ietf.org" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <56C0D831.1010107@gmail.com> Date: Mon, 15 Feb 2016 08:40:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - ends Feb 13 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 19:40:42 -0000 Hi Paul, On 14/02/2016 20:15, Paul E. Jones wrote: > Brian, > >>> Traditionally, DSCP values have been thought of as being site >>> specific, with each site selecting its own code points for >>> controlling per-hop-behavior to influence the QoS for transport-layer >>> flows. >> >> It isn't really "tradition"; it's defined that way in RFC 2474. I would >> suggest something like >> >> DSCP values are in principle site specific, with each site selecting its >> own code points for controlling per-hop-behavior to influence the QoS for >> transport-layer flows. > > Sounds good. I've made this change to my local draft. > > >> Also, is this the place to mention that there is ongoing work on diffserv >> interconnection between carriers (draft-ietf-tsvwg-diffserv-intercon)? >> This is relevant, because if successful, we can expect the code points used >> for interconnection to become very widely used. > > In general, it's best to not speculate, I think. If they become so widely used, I doubt a reference would be necessary. > However, I'm not opposed to adding something if the group wants it. Exactly what were you thinking? I would hope this does not > hold up the draft due to a missing reference. I take your point about dangling references, although both are tsvwg drafts so maybe the WG chairs have an opinion about whether this is a real concern. But yes, no need to mention it here - see below. > >> >>> 2. Relation to Other Standards >> >> Largish nit: not all RFCs are standards. This should probably be: >> >> 2. Relation to Other Documents > > OK, I can do that. Is "documents" preferred or should we say "specifications"? I have no strong view on that. >>> The DSCP value set by the endpoint is not trusted by the network. In >>> addition, the DSCP value may be remarked at any place in the network >>> for a variety of reasons to any other DSCP value, including default >>> forwarding (DF) value to provide basic best effort service. The >>> mitigation for such action is through an authorization mechanism. >>> Such authorization mechanism is outside the scope of this document. >> >> I don't think authorization is *the* mitigation; it's one possible >> mitigation. Another possible mitigation is draft-ietf-tsvwg-diffserv-intercon, >> for example. > > OK, I changed "the" to "a". This focus of this document is the web browser, so I think the trust issues here are separate from > those of interconnection, or am I wrong? Well, it all depends, unfortunately. If the browser is in a domain that has no diffserv support at all, and the next domain along does no diffserv conditioning at ingress, but then does support diffserv interconnection at egres, and so on further along the path, things may work out... On balance a better reference here would be RFC7657 Section 3.2, which discusses this aspect and does have an informational reference to -diffserv-intercon. >>> Table 1: Recommended DSCP Values for WebRTC Applications >> ... >>> The above table assumes that packets marked with CS1 are treated as >>> "less than best effort". >> >> Needless to say, this still gives me heartburn. Firstly, it is *not* CS1. >> Its DSCP value is binary 001000 but the behavior abbreviation is LE, as >> defined in RFC 3662. It's an example of a site-specific code point. IMHO >> it should be called LE in the table and the text. There should be a statement >> that the standard use of this code point is a *different* behavior called >> CS1. > > This was used to be consistent with RFC 4594. If LE is preferred, I can change it, but then should that mean we need to revised > RFC 4594? Section 3.2 of RFC 3662 says there are one of several values that might be used for LE traffic, with CS1 being one > choice. So, is it wrong to specify CS1 here and RFC 4594? RFC 4594 simply describes CS1 as "Low-Priority - Any flow that has no BW assurance" which is completely consistent with RFC 2474. However, I think its citations of RFC 3662 are problematic. The underlying problem is that RFC 3662 is badly written in this respect. This text is completely inconsistent with RFC 2474: If a CS PHB is used, note that this configuration will violate the "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will have a less timely forwarding than CS0. An operator's goal of providing an LE PDB is sufficient cause for violating the SHOULD. What that *should* say is something like: If the DSCP value reserved for CS1 by RFC 2474 is used to indicate the LE PDB, this configuration will violate the "MUST" of section 4.3 of RFC 2474 [RFC2474] and will nullify the intention of RFC 2474 of backwards compatibility with IP Precedence. An operator providing an LE PDB by overriding the standard meaning of the DSCP value reserved for CS1 is intentionally violating RFC 2474. So yes, if the community wants to get this right, RFC 4594 needs some cosmetic work and RFC 3662 needs to be corrected and moved to standards track. But for the present draft, I still think that suggesting to use the code point reserved for CS1 in the vague hope that it will get the unstandardized behaviour called LE is a very bad idea. In most networks it will get default service, but in diffserv-aware networks it seems like a coin-toss whether it gets slightly better or slightly worse service than default. So what would I do in your shoes? Firstly, I would label it LE in the table where you have CS1. Secondly, I would note that LE is not standardized, and that the DSCP value SHOULD be equated to DF unless it is known that the local network supports LE, in which case it should be equated to whatever DSCP value is used locally to support LE, which might or might not be the same as CS1. >> >>> It is common for CS1 to be treated the same as DF,... >> >> Right, in which case marking your traffic LE and getting DF treatment is not >> so bad. But it's completely compatible with RFC 2474 for CS1 to be treated >> better than DF. I think that risk should be mentioned. > OK, how about right after that sentence I add: > > "However, it is also possible per [RFC2474] for CS1 traffic to be given better treatment than DF, thus caution should be > exercised when electing to use CS1." > > Then I would start a new paragraph to talk about EF. > >> >>> Implementers should also note >>> that excess EF traffic is dropped. This could mean that a packet >>> marked as EF may not get through as opposed to a packet marked with a >>> different DSCP value. >> >> But that's exactly why you use EF for traffic that wants timely delivery >> more than it hates loss. People designing codecs kind of know this. > > Is the warning harmful? I think it's useful for those who do not know this. Agreed, it's just that the phrasing seems to suggest this is a bug rather than the intended behaviour. >>> In summary, DSCP marking provides neither guarantees nor promised >>> levels of service. The service provided to a packet is dependent >>> upon the network design along the path, as well as the network >>> conditions at every hop. >> >> That's a bit of a gloomy ending. It might be fair to insert a sentence >> in the middle, like: However, DSCP marking is expected to provide >> a statistical improvement in the real-time service as a whole. > > Yeah, it is gloomy. I'm not sure who wrote that, but somebody felt we needed this reminder of reality. Personally, I don't > like gloom and doom, especially since there are ways to effectively use DSCP. :-) > > I'll add your suggested sentence. > > Now, I've been "warned" before about publishing updated in the middle of a LC review. I think the review period has now > concluded. Shall I publish what I have and give folks one more opportunity to look over the text? Ah, that decision is above my pay grade... Regards Brian From nobody Sun Feb 14 20:45:02 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F991B2D38 for ; Sun, 14 Feb 2016 20:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 CtLfEVyEsPMM for ; Sun, 14 Feb 2016 20:44:59 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 6321D1B2D2A for ; Sun, 14 Feb 2016 20:44:59 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u1F4irAj005082 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Feb 2016 23:44:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1455511495; bh=jc59O0FzghR1g2TwKtuAZo08oy12YpGKsM+0N66ii7A=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=Xp/2wZ42VhPPF4zG8OrTde3NylDb9fy3d8fzcT3kM7H0i3VSifILO52hFgXi10lv1 AqmgrIUdX2uL2LMURs4W00NoWqnpvTmUEmXUElw/XoKQedlLj64wGgKbG16g8ildB3 p0xqy4LSLELrDNws37MYPX+UHvQ5PBMT+R4rp3z4= From: "Paul E. Jones" To: "Brian E Carpenter" , "Black, David" , "tsvwg@ietf.org" Date: Mon, 15 Feb 2016 04:44:57 +0000 Message-Id: In-Reply-To: <56C0D831.1010107@gmail.com> User-Agent: eM_Client/6.0.24316.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Sun, 14 Feb 2016 23:44:55 -0500 (EST) Archived-At: Subject: Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - ends Feb 13 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 04:45:01 -0000 Brian, >>>> The DSCP value set by the endpoint is not trusted by the=20 >>>>network. In >>>> addition, the DSCP value may be remarked at any place in the=20 >>>>network >>>> for a variety of reasons to any other DSCP value, including=20 >>>>default >>>> forwarding (DF) value to provide basic best effort service. =20 >>>>The >>>> mitigation for such action is through an authorization=20 >>>>mechanism. >>>> Such authorization mechanism is outside the scope of this=20 >>>>document. >>> >>> I don't think authorization is *the* mitigation; it's one possible >>> mitigation. Another possible mitigation is=20 >>>draft-ietf-tsvwg-diffserv-intercon, >>> for example. >> >> OK, I changed "the" to "a". This focus of this document is the web=20 >>browser, so I think the trust issues here are separate from >> those of interconnection, or am I wrong? > >Well, it all depends, unfortunately. If the browser is in a domain that= =20 >has no >diffserv support at all, and the next domain along does no diffserv=20 >conditioning >at ingress, but then does support diffserv interconnection at egres,=20 >and so >on further along the path, things may work out... > >On balance a better reference here would be RFC7657 Section 3.2, which >discusses this aspect and does have an informational reference to=20 >-diffserv-intercon. This particular paragraph deals with endpoint trust and the fact it=20 might be re-marked. I think if we want to talk more about network=20 treatment, we should say something in the following section. There is a= =20 paragraph that starts with "If a packet enters a network that has no=20 support..." Perhaps there or a new paragraph following. If you could suggest text, that would be good. I'm rather confident=20 that if I suggest something, it will be wrong on some technical point.=20 :-) > >>>> Table 1: Recommended DSCP Values for WebRTC Applications >>> ... >>>> The above table assumes that packets marked with CS1 are=20 >>>>treated as >>>> "less than best effort". >>> >>> Needless to say, this still gives me heartburn. Firstly, it is *not*= =20 >>>CS1. >>> Its DSCP value is binary 001000 but the behavior abbreviation is LE,= =20 >>>as >>> defined in RFC 3662. It's an example of a site-specific code point.= =20 >>>IMHO >>> it should be called LE in the table and the text. There should be a= =20 >>>statement >>> that the standard use of this code point is a *different* behavior=20 >>>called >>> CS1. >> >> This was used to be consistent with RFC 4594. If LE is preferred, I= =20 >>can change it, but then should that mean we need to revised >> RFC 4594? Section 3.2 of RFC 3662 says there are one of several=20 >>values that might be used for LE traffic, with CS1 being one >> choice. So, is it wrong to specify CS1 here and RFC 4594? > >RFC 4594 simply describes CS1 as "Low-Priority - Any flow that has no=20 >BW assurance" >which is completely consistent with RFC 2474. However, I think its=20 >citations >of RFC 3662 are problematic. The underlying problem is that RFC 3662 is= =20 >badly >written in this respect. This text is completely inconsistent with RFC=20 >2474: > > If a CS PHB is used, note that this configuration will violate the > "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will=20 >have > a less timely forwarding than CS0. An operator's goal of providing > an LE PDB is sufficient cause for violating the SHOULD. > >What that *should* say is something like: > > If the DSCP value reserved for CS1 by RFC 2474 is used to indicate=20 >the LE > PDB, this configuration will violate the "MUST" of section 4.3 of=20 >RFC 2474 > [RFC2474] and will nullify the intention of RFC 2474 of backwards > compatibility with IP Precedence. An operator providing an LE PDB > by overriding the standard meaning of the DSCP value reserved for=20 >CS1 > is intentionally violating RFC 2474. > >So yes, if the community wants to get this right, RFC 4594 needs some=20 >cosmetic >work and RFC 3662 needs to be corrected and moved to standards track. >But for the present draft, I still think that suggesting to use the=20 >code >point reserved for CS1 in the vague hope that it will get the=20 >unstandardized >behaviour called LE is a very bad idea. In most networks it will get=20 >default >service, but in diffserv-aware networks it seems like a coin-toss=20 >whether >it gets slightly better or slightly worse service than default. > >So what would I do in your shoes? > >Firstly, I would label it LE in the table where you have CS1. > >Secondly, I would note that LE is not standardized, and that the DSCP=20 >value >SHOULD be equated to DF unless it is known that the local network=20 >supports >LE, in which case it should be equated to whatever DSCP value is used >locally to support LE, which might or might not be the same as CS1. OK, I've noted this in the spec. Doing what you suggest would simplify=20 the language related to CS1 (perhaps replacing the second paragraph=20 below the table with works the reflect what you just stated above. =20 However, this leaves us without a value. I'm not sure who wanted CS1=20 from the outset, but it's there. I guess we need to see if folks can agree with replacing CS1 (and the=20 explicit value that carries) with LE and leaving the value unspecified. = =20 I think we should not say it's equal to DF, though, as there is then no=20 differentiation between "very low" and "low". Maybe just say that the=20 value is network-dependent? I don't know. >>>> Implementers should also note >>>> that excess EF traffic is dropped. This could mean that a=20 >>>>packet >>>> marked as EF may not get through as opposed to a packet marked= =20 >>>>with a >>>> different DSCP value. >>> >>> But that's exactly why you use EF for traffic that wants timely=20 >>>delivery >>> more than it hates loss. People designing codecs kind of know this. >> >> Is the warning harmful? I think it's useful for those who do not=20 >>know this. > >Agreed, it's just that the phrasing seems to suggest this is a bug=20 >rather than >the intended behaviour. Ok, how about we add "This is not a flaw, but how excess EF traffic is=20 intended to be treated." at the end of that paragraph? Paul From nobody Mon Feb 15 13:54:00 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657231B2C92 for ; Mon, 15 Feb 2016 13:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 tu2GCsANlg09 for ; Mon, 15 Feb 2016 13:53:57 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586171B2C90 for ; Mon, 15 Feb 2016 13:53:57 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id x65so93073051pfb.1 for ; Mon, 15 Feb 2016 13:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=ZY1dSouFF4OE33kyHS4Ym1ObAm3sw68+X/Vu+uqK81A=; b=M7lGW706ZtaWQGx4yDJs9TzebUaVuHJ0Tc6uPOAuDHjHx6goT3PCVxKr9R2mKvPrdx qrG7okqUEqa6j0uWQR+JN2BoujPYyAFpQ0T0JPYK+3gDg/0T4rb5dUKnEkE0jI6IAwpY zK0H+mHRINGLDxCCJfIwxLQcXNn5LtOdHj0JUWB5RkJ36qahZJNXJwhq3s1AL5KOKZDy XpfMJIN/pcPqe+Dc5jfg5/1jdS7CaPs/cmV7KLfvMYNEdjgoeVJRVxzZHQJDKczYSLDG cGXeWR0Bj2e524YfR5lzsDjiWLjMvLVOUgZX9Fd4fcsGscJrAd5rmQ1wqfNOlYiFhXVD wKqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=ZY1dSouFF4OE33kyHS4Ym1ObAm3sw68+X/Vu+uqK81A=; b=GBhdjIiFR/40sBDkHYG1M2PMN1aSYevnbXulEDdhK3VZN5BvgRTXbhvOVe4jEwZ7DB pgJQ6bk03IC7WnG3aLNAbNhBvqsaIA4qeIMwpFvTdenDIjvTK3/WiSeBV7ZeKIuCgRPu +CzAwN/P1O0TFUgVufbKoFsMLlnNtUcU0foTvo0aNxgTZVmZCI6L8FuDHuoaAeHr9CvF uiQkCsGWhtf10h8K1kdeYpxV63+0uEwjau0+JLMOvdmEvt2LdGh47Zsiit7vHQAREIr8 f6AhvthKsiX+ZTF9DWXR5qI/8/SEeZmwkh3cGpJLCTNvJmiEKyLsF0bERyId7gazToNG URlQ== X-Gm-Message-State: AG10YOS7+njrw1pydd4rPrxNUYwtHw16CwhQCPBICZnNnaxrWgaTtiADOpElh7l0aZkH3A== X-Received: by 10.98.32.150 with SMTP id m22mr26405301pfj.27.1455573237019; Mon, 15 Feb 2016 13:53:57 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id ah10sm40751202pad.23.2016.02.15.13.53.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Feb 2016 13:53:55 -0800 (PST) To: "Paul E. Jones" , "Black, David" , "tsvwg@ietf.org" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <56C248F2.5010807@gmail.com> Date: Tue, 16 Feb 2016 10:53:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-rtcweb-qos-12 - ends Feb 13 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 21:53:59 -0000 Hi Paul, On 15/02/2016 17:44, Paul E. Jones wrote: > Brian, > >>>>> The DSCP value set by the endpoint is not trusted by the network. In >>>>> addition, the DSCP value may be remarked at any place in the network >>>>> for a variety of reasons to any other DSCP value, including default >>>>> forwarding (DF) value to provide basic best effort service. The >>>>> mitigation for such action is through an authorization mechanism. >>>>> Such authorization mechanism is outside the scope of this document. >>>> >>>> I don't think authorization is *the* mitigation; it's one possible >>>> mitigation. Another possible mitigation is draft-ietf-tsvwg-diffserv-intercon, >>>> for example. >>> >>> OK, I changed "the" to "a". This focus of this document is the web browser, so I think the trust issues here are separate from >>> those of interconnection, or am I wrong? >> >> Well, it all depends, unfortunately. If the browser is in a domain that has no >> diffserv support at all, and the next domain along does no diffserv conditioning >> at ingress, but then does support diffserv interconnection at egres, and so >> on further along the path, things may work out... >> >> On balance a better reference here would be RFC7657 Section 3.2, which >> discusses this aspect and does have an informational reference to -diffserv-intercon. > > This particular paragraph deals with endpoint trust and the fact it might be re-marked. I think if we want to talk more about > network treatment, we should say something in the following section. There is a paragraph that starts with "If a packet enters > a network that has no support..." Perhaps there or a new paragraph following. > > If you could suggest text, that would be good. I'm rather confident that if I suggest something, it will be wrong on some > technical point. :-) I think it only needs a few words pointing to the full discussion: There is benefit in marking traffic even if it only benefits the first few hops. The implications are discussed in Section 3.2 of [RFC7657]. >> >>>>> Table 1: Recommended DSCP Values for WebRTC Applications >>>> ... >>>>> The above table assumes that packets marked with CS1 are treated as >>>>> "less than best effort". >>>> >>>> Needless to say, this still gives me heartburn. Firstly, it is *not* CS1. >>>> Its DSCP value is binary 001000 but the behavior abbreviation is LE, as >>>> defined in RFC 3662. It's an example of a site-specific code point. IMHO >>>> it should be called LE in the table and the text. There should be a statement >>>> that the standard use of this code point is a *different* behavior called >>>> CS1. >>> >>> This was used to be consistent with RFC 4594. If LE is preferred, I can change it, but then should that mean we need to >>> revised >>> RFC 4594? Section 3.2 of RFC 3662 says there are one of several values that might be used for LE traffic, with CS1 being one >>> choice. So, is it wrong to specify CS1 here and RFC 4594? >> >> RFC 4594 simply describes CS1 as "Low-Priority - Any flow that has no BW assurance" >> which is completely consistent with RFC 2474. However, I think its citations >> of RFC 3662 are problematic. The underlying problem is that RFC 3662 is badly >> written in this respect. This text is completely inconsistent with RFC 2474: >> >> If a CS PHB is used, note that this configuration will violate the >> "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will have >> a less timely forwarding than CS0. An operator's goal of providing >> an LE PDB is sufficient cause for violating the SHOULD. >> >> What that *should* say is something like: >> >> If the DSCP value reserved for CS1 by RFC 2474 is used to indicate the LE >> PDB, this configuration will violate the "MUST" of section 4.3 of RFC 2474 >> [RFC2474] and will nullify the intention of RFC 2474 of backwards >> compatibility with IP Precedence. An operator providing an LE PDB >> by overriding the standard meaning of the DSCP value reserved for CS1 >> is intentionally violating RFC 2474. >> >> So yes, if the community wants to get this right, RFC 4594 needs some cosmetic >> work and RFC 3662 needs to be corrected and moved to standards track. >> But for the present draft, I still think that suggesting to use the code >> point reserved for CS1 in the vague hope that it will get the unstandardized >> behaviour called LE is a very bad idea. In most networks it will get default >> service, but in diffserv-aware networks it seems like a coin-toss whether >> it gets slightly better or slightly worse service than default. >> >> So what would I do in your shoes? >> >> Firstly, I would label it LE in the table where you have CS1. >> >> Secondly, I would note that LE is not standardized, and that the DSCP value >> SHOULD be equated to DF unless it is known that the local network supports >> LE, in which case it should be equated to whatever DSCP value is used >> locally to support LE, which might or might not be the same as CS1. > > OK, I've noted this in the spec. Doing what you suggest would simplify the language related to CS1 (perhaps replacing the > second paragraph below the table with works the reflect what you just stated above. However, this leaves us without a value. > I'm not sure who wanted CS1 from the outset, but it's there. The whole confusion stems from a few careless words in RFC 3622. Suggesting to support LE is a fine idea; calling its code point CS1 is confusing. > I guess we need to see if folks can agree with replacing CS1 (and the explicit value that carries) with LE and leaving the value > unspecified. I think we should not say it's equal to DF, though, as there is then no differentiation between "very low" and > "low". Which is indeed likely to be the case in practice. > Maybe just say that the value is network-dependent? I don't know. Yes; that is the exact implication of RFC 2474 and what the operators active in the diffserv WG said they wanted. My concern is that people often fail to understand this and end up with magical expectations about the effect of setting a DSCP value. >>>>> Implementers should also note >>>>> that excess EF traffic is dropped. This could mean that a packet >>>>> marked as EF may not get through as opposed to a packet marked with a >>>>> different DSCP value. >>>> >>>> But that's exactly why you use EF for traffic that wants timely delivery >>>> more than it hates loss. People designing codecs kind of know this. >>> >>> Is the warning harmful? I think it's useful for those who do not know this. >> >> Agreed, it's just that the phrasing seems to suggest this is a bug rather than >> the intended behaviour. > > Ok, how about we add "This is not a flaw, but how excess EF traffic is intended to be treated." at the end of that paragraph? Sure, that would be fine for me. Brian From nobody Tue Feb 16 01:02:07 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 565FF1AC40E; Tue, 16 Feb 2016 01:02:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160216090203.31967.16363.idtracker@ietfa.amsl.com> Date: Tue, 16 Feb 2016 01:02:03 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-behave-requirements-update-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 09:02:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Network Address Translation (NAT) Behavioral Requirements Updates Authors : Reinaldo Penno Simon Perreault Mohamed Boucadair Senthil Sivakumar Kengo Naito Filename : draft-ietf-tsvwg-behave-requirements-update-07.txt Pages : 13 Date : 2016-02-16 Abstract: This document clarifies and updates several requirements of RFC4787, RFC5382, and RFC5508 based on operational and development experience. The focus of this document is NAT44. This document updates RFCs 4787, 5382, and 5508. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-behave-requirements-update/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-behave-requirements-update-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-behave-requirements-update-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 16 14:03:38 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B96B1B3CFE; Thu, 11 Feb 2016 16:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 gpmsoXGha_rp; Thu, 11 Feb 2016 16:09:29 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0E61B3CF8; Thu, 11 Feb 2016 16:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2775; q=dns/txt; s=iport; t=1455235769; x=1456445369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h52+AzzLO+BizeyISoIKEOA+aDCEuQ0viS7rp+qvUjE=; b=A+tM/xIoF8PUOcNhMKGJ3yqXhezKb5Rxf0RN+OETxSGm8Abuvl84RiqL z/zpj72gjhGIt19RxrpcuDGCoi+vpfG7p2gnLW1+UMmVssY7/Yaygi5i7 pkqxemTx4Vt2phQfTy8SWePhDpl0w+6BtX6fo/91U9z/zIZSS26KXtsQz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQAeIr1W/5FdJa1egzpSbQaIVbEqA?= =?us-ascii?q?Q2BZyOFagKBNjgUAQEBAQEBAX8LhEEBAQEEOj0CDAQCAQgRBAEBHwkHMhQHAQE?= =?us-ascii?q?FAwIEDgUIiBIOwSYBAQEBAQEBAQEBAQEBAQEBAQEBAQEVikiIbAWNJ4lQAYVNh?= =?us-ascii?q?36BZEqDeYhVjj0BHgEBQoNlagGHVnwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,433,1449532800"; d="scan'208";a="236753898" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2016 00:09:28 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u1C09Smr005134 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Feb 2016 00:09:28 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 18:09:27 -0600 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 18:09:27 -0600 From: "Surendra Kumar (smkumar)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.txt Thread-Index: AQHRZQhY9c88+3ynwkOLHr9c9z3LPJ8nh70Q Date: Fri, 12 Feb 2016 00:09:27 +0000 Message-ID: References: <20160211201106.3882.86407.idtracker@ietfa.amsl.com> In-Reply-To: <20160211201106.3882.86407.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.10.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 16 Feb 2016 14:03:37 -0800 Cc: "tsvwg@ietf.org" , "draft-kumar-sfc-nsh-udp-transport@tools.ietf.org" Subject: [tsvwg] FW: New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 00:09:38 -0000 Hello All, We published -02 version of the UDP transport draft for NSH based on the fe= edback we received from David Black and others. In particular, it aligns with the usage guidelines in I-D.ietf-tsvwg-rfc540= 5bis version-07 w.r.t congestion control, security and other considerations= . Your feedback on the draft is very much appreciated. Regards, nsh-udp draft co-authors PS: Home for this draft is still being hashed out. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, February 11, 2016 12:11 PM To: Walter Haeffner ; Rajeev Manur ; Larry Kreeger (kreeger) ; Surendra Kumar (s= mkumar) ; Surendra Kumar (smkumar) ; = David T. Melman ; Sumandra Majee ; Dav= id Melman ; Larry Kreeger (kreeger) Subject: New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.= txt A new version of I-D, draft-kumar-sfc-nsh-udp-transport-02.txt has been successfully submitted by Surendra Kumar and posted to the IETF re= pository. Name: draft-kumar-sfc-nsh-udp-transport Revision: 02 Title: UDP Transport for Network Service Header Document date: 2016-02-11 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-kumar-sfc-nsh-ud= p-transport-02.txt Status: https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-udp-tr= ansport/ Htmlized: https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transpo= rt-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-sfc-nsh-udp= -transport-02 Abstract: This draft describes the transport encapsulation to carry Network Service Header (NSH) over UDP transport protocol. This enables applications and services using NSH to communicate over a simple layer-3 network without topological constraints. It brings down the barrier to deploy NSH by not requiring additional overhead as is typical of overlay encapsulation mechanisms designed on top of UDP. As a first benefit, this method eases the deployment of Service Function Chaining (SFC) by allowing SFC components to utilize the basic UDP/IP stack available in virtually all network elements and end systems to setup the virtual network and realize Service Function Chains (SFCs). = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Feb 17 08:28:30 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5268B1A8A86; Wed, 17 Feb 2016 08:28:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160217162828.19579.85711.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 08:28:28 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-failover-16.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 16:28:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : SCTP-PF: Quick Failover Algorithm in SCTP Authors : Yoshifumi Nishida Preethi Natarajan Armando Caro Paul D. Amer Karen E. E. Nielsen Filename : draft-ietf-tsvwg-sctp-failover-16.txt Pages : 22 Date : 2016-02-17 Abstract: SCTP supports multi-homing. However, when the failover operation specified in RFC4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. To overcome this problem this document specifies a quick failover algorithm (SCTP-PF) based on the introduction of a Potentially Failed (PF) state in SCTP Path Management. The document also specifies a dormant state operation of SCTP. This dormant state operation is required to be followed by an SCTP-PF implementation, but it may equally well be applied by a standard RFC4960 SCTP implementation. Additionally, the document introduces an alternative switchback operation mode called Primary Path Switchover that will be beneficial in certain situations. This mode of operation applies to both a standard RFC4960 SCTP implementation as well as to a SCTP-PF implementation. The procedures defined in the document require only minimal modifications to the RFC4960 specification. The procedures are sender-side only and do not impact the SCTP receiver. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-failover-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 17 10:03:59 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF3F1B2B10; Wed, 17 Feb 2016 10:03:58 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160217180358.1364.2023.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 10:03:58 -0800 Archived-At: Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, rfc-editor@rfc-editor.org, tsvwg-chairs@ietf.org, draft-ietf-tsvwg-sctp-failover@ietf.org, The IESG Subject: [tsvwg] Protocol Action: 'SCTP-PF: Quick Failover Algorithm in SCTP' to Proposed Standard (draft-ietf-tsvwg-sctp-failover-16.txt) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 18:03:59 -0000 The IESG has approved the following document: - 'SCTP-PF: Quick Failover Algorithm in SCTP' (draft-ietf-tsvwg-sctp-failover-16.txt) as Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/ Technical Summary This describes a standards-track procedure for SCTP to support of failover when working with a multi-homed SCTP end-point: SCTP supports multi-homing. However, when the failover operation specified in RFC4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. To overcome this problem this document specifies a quick failover algorithm (SCTP-PF) based on the introduction of a Potentially Failed (PF) state in SCTP Path Management. The document also specifies a dormant state operation of SCTP. This dormant state operation is required to be followed by an SCTP-PF implementation, but it may equally well be applied by a standard RFC4960 SCTP implementation. Additionally, the document introduces an alternative switchback operation mode called Primary Path Switchover that will be beneficial in certain situations. This mode of operation applies to both a standard RFC4960 SCTP implementation as well as to a SCTP-PF implementation. The procedures defined in the document require only minimal modifications to the RFC4960 specification. The procedures are sender-side only and do not impact the SCTP receiver. Working Group Summary Nothing out of the ordinary happened during work on this draft. Document Quality Gorry Fairhurst performed an extensive review of -05 version. The working group requested a change of intended status (from Experimental to Proposed Standard) during document development, and this was approved. Personnel Gorry Fairhurst is the document shepherd. Spencer Dawkins is the responsible AD. From nobody Wed Feb 17 11:07:43 2016 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6091B2C48; Wed, 17 Feb 2016 11:07:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160217190742.31516.66397.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 11:07:42 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-circuit-breaker-13.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 19:07:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Network Transport Circuit Breakers Author : Godred Fairhurst Filename : draft-ietf-tsvwg-circuit-breaker-13.txt Pages : 26 Date : 2016-02-17 Abstract: This document explains what is meant by the term "network transport Circuit Breaker" (CB). It describes the need for circuit breakers for network tunnels and applications when using non-congestion- controlled traffic, and explains where circuit breakers are, and are not, needed. It also defines requirements for building a circuit breaker and the expected outcomes of using a circuit breaker within the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-circuit-breaker-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-circuit-breaker-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 17 15:15:43 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAA91A8724 for ; Wed, 17 Feb 2016 15:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.307 X-Spam-Level: X-Spam-Status: No, score=-4.307 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_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 QK_OWiOLMNe4 for ; Wed, 17 Feb 2016 15:15:34 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 8F7C61A6FC8 for ; Wed, 17 Feb 2016 15:15:34 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u1HNFNGY006836 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Feb 2016 18:15:24 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u1HNFNGY006836 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1455750925; bh=R2LvuHkgrL5wQTQY3YdYvaeYIoY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EDXxiNsUrOeuZeaYPJY9y6xrn6zya+KZq3i8JI0COpmu86mrAnBF0PdDOfqHxeyXc n4Vr5+F99cfVGmZcfnKM4K6gKrcIkQQq+iKBk8sKq0ZZVSVgvn8VRN0Q872HpU33Wp 9kElar0Wcg4sm49HbJEZf8uqUdObilYZauv975Rc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u1HNFNGY006836 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd51.lss.emc.com (RSA Interceptor); Wed, 17 Feb 2016 18:15:01 -0500 Received: from MXHUB226.corp.emc.com (MXHUB226.corp.emc.com [10.253.68.96]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u1HNFCbM021757 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 17 Feb 2016 18:15:12 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.172]) by MXHUB226.corp.emc.com ([10.253.68.96]) with mapi id 14.03.0266.001; Wed, 17 Feb 2016 18:15:11 -0500 From: "Black, David" To: Lucy yong , "tsvwg@ietf.org" , "draft-ietf-tsvwg-gre-in-udp-encap@tools.ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-09.txt Thread-Index: AQHRWKUJ8L1krBuKeEiW5S1S8J/PD58RjtMAgB9vs4A= Date: Wed, 17 Feb 2016 23:15:11 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D57239942@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D57239942@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.112] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "gorry@erg.abdn.ac.uk" Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 23:15:41 -0000 V2hpbGUgc2lsZW5jZSBpcyBnb2xkZW4gb24gdGhpcyBkcmFmdCAoYSBzdHJvbmcgaW5kaWNhdGlv biB0aGF0IGl0J3MgY2xvc2UgdG8gZG9uZSksIHdlIGRvIG5lZWQNCnRvIHJlc29sdmUgdGhpcyBy ZW1haW5pbmcgb3BlbiBpc3N1ZSBvbiBVRFAgc291cmNlIHBvcnQgY29uZmlndXJhdGlvbiB3cnQg bWlkZGxlYm94ZXMuDQpIZXJlJ3MgdGhlIHRleHQgaW52b2x2ZWQgKGZyb20gU2VjdGlvbiA0LjIp Og0KDQogICBIZW5jZSwgdXNlIFVEUCBzcmMgcG9ydCBmb3IgZW50cm9weSBtYXkgaW1wYWN0IG1p ZGRsZWJveCBiZWhhdmlvci4NCiAgIElmIGEgR1JFLWluLVVEUCB0dW5uZWwgaXMgZXhwZWN0ZWQg dG8gcGFzcyBhIG1pZGRsZWJveCwgdG8gYXZvaWQgdGhlDQogICBpbXBhY3QsIHRoZSBvcGVyYXRv ciBlaXRoZXIgZGlzYWJsZSBVRFAgc291cmNlIHBvcnQgZm9yIGVudHJvcHkgb3INCiAgIGNvbmZp Z3VyZSB0aGUgbWlkZGxlYm94IHRvIGRlYWwgd2l0aCB0aGUgVURQIHNvdXJjZSBwb3J0IHZhcmlh dGlvbi4NCg0KTHVjeSBhc2tzOg0KDQo+PiBUaGlzIG9wZXJhdGlvbiBjYW4gYmUgZG9uZSBlYXNp bHkgZm9yIGEgd2VsbC1tYW5hZ2VkIG9wZXJhdG9yIG5ldHdvcmsuIE1heWJlDQo+PiBoYXJkIGlu IGdlbmVyYWwgSW50ZXJuZXQuIExpa2UgdG8gZ2V0IHRoZSBjb21tdW5pdHkgZmVlZGJhY2sgaWYg dGhpcyB3aWxsIGJlIGENCj4+IGNvbmNlcm4gb3Igbm90LiBJZiB5ZXMsIHdoYXQgaXMgdGhlIGJl dHRlciBhbHRlcm5hdGl2ZT8NCg0KPFdHIGNoYWlyIGhhdCBPRkY+DQoNCkkgYWdyZWUgdGhhdCB0 aGlzIGlzIGEgY29uY2Vybi4gIEx1Y3kncyBxdWVzdGlvbiBzdWdnZXN0cyB0aGF0IHRoZSB0ZXh0 IG9uIHRoaXMgdG9waWMNCmJlIHNlcGFyYXRlZCBpbnRvIHNlcGFyYXRlIHByb3Zpc2lvbnMgZm9y IEdlbmVyYWwgSW50ZXJuZXQgYW5kIFdlbGwgTWFuYWdlZCBPcGVyYXRvcg0KTmV0d29yayBzY2Vu YXJpb3MgLSBJIGFncmVlIHRoYXQgdGhpcyBpcyBhIGdvb2QgYXBwcm9hY2ggYW5kIHdvdWxkIHN1 Z2dlc3QgdGhhdA0KdGhlIGRlZmF1bHQgY29uZmlndXJhdGlvbiBmb3IgdGhlIEdlbmVyYWwgSW50 ZXJuZXQgdXNhZ2Ugc2NlbmFyaW8gYmUgbm8gc291cmNlIHBvcnQNCmVudHJvcHkuICBJbiBjb250 cmFzdCwgdGhlIGRlZmF1bHQgY29uZmlndXJhdGlvbiBmb3IgV2VsbCBNYW5hZ2VkIE9wZXJhdG9y IE5ldHdvcmsNCnVzYWdlIGNvdWxkIGJlIGVudHJvcHkgb3Igbm8tZW50cm9weSBkZXBlbmRpbmcg b24gdGhlIG1vdGl2YXRpb24gZm9yIHVzZSBvZiBHUkUvVURQDQotIG5vLWVudHJvcHkgY291bGQg YmUgYSBmaW5lIGRlZmF1bHQgY29uZmlndXJhdGlvbiB3aGVuIEdSRS9VRFAgaXMgdXNlZCBmb3Ig Y29ubmVjdGl2aXR5DQpwdXJwb3NlcyBhbmQgdGFraW5nIGFkdmFudGFnZSBvZiBFQ01QIFtvciBM QUddIGlzIG5vdCBhIGdvYWwuDQoNCjwvV0cgY2hhaXIgaGF0IE9GRj4NCg0KVGhhbmtzLCAtLURh dmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTHVjeSB5b25nIFtt YWlsdG86bHVjeS55b25nQGh1YXdlaS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI4 LCAyMDE2IDY6NDIgUE0NCj4gVG86IHRzdndnQGlldGYub3JnOyBkcmFmdC1pZXRmLXRzdndnLWdy ZS1pbi11ZHAtZW5jYXBAdG9vbHMuaWV0Zi5vcmcNCj4gQ2M6IEJsYWNrLCBEYXZpZDsgZ29ycnlA ZXJnLmFiZG4uYWMudWsNCj4gU3ViamVjdDogRlc6IFt0c3Z3Z10gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi10c3Z3Zy1ncmUtaW4tdWRwLWVuY2FwLTA5LnR4dA0KPiANCj4gSGkgQWxsLA0KPiANCj4g VGhpcyB2ZXJzaW9uIGhhcyBxdWl0ZSBlZGl0aW5nIGNoYW5nZXMgd2hpY2ggd2VyZSBzdWdnZXN0 ZWQgYnkgdGhlIGNoYWlyIChEYXZpZA0KPiBCbGFjaykgYW5kIGJldHRlciBhbGlnbnMgd2l0aCA1 NDA1YmlzLiBUaGUgZHJhZnQgc3BlY2lmaWVzIGdyZS91ZHAgdHVubmVsIHVzYWdlIGluDQo+IHR3 byBlbnZpcm9ubWVudHM6IGdlbmVyYWwgSW50ZXJuZXQgYW5kIHdlbGwtbWFuYWdlZCBvcGVyYXRv ciBuZXR3b3JrDQo+IChXTU9OKSwgYW5kIG5hbWVzIHRoZSB0d28gYXBwbGljYXRpb25zIGFzIERl ZmF1bHQgR1JFLWluLVVEUCBUdW5uZWwgYW5kDQo+IFdNT04gR1JFLWluLVVEUCBUdW5uZWwsIHJl c3BlY3RpdmVseS4gSXQgc3BlY2lmaWVzIHRoZSByZXF1aXJlbWVudHMgZm9yIGVhY2gNCj4gdHlw ZSBvZiB0dW5uZWxzLg0KPiANCj4gVGhlIGRyYWZ0IGZ1cnRoZXIgZGVmaW5lcyBhIHdlbGwtbWFu YWdlZCBvcGVyYXRvciBuZXR3b3JrIGFzIG9mIGFuIElQIG5ldHdvcmsNCj4gdGhhdCBpcyB0cmFm ZmljLWVuZ2luZWVyZWQgYW5kL29yIG90aGVyd2lzZQ0KPiBtYW5hZ2VkIChlLmcuLCB2aWEgdXNl IG9mIHRyYWZmaWMgcmF0ZSBsaW1pdGVycykgdG8gYXZvaWQgY29uZ2VzdGlvbi4gVW5kZXIgYSB3 ZWxsLQ0KPiBtYW5hZ2VkIG9wZXJhdG9yIG5ldHdvcmssIGEgZ3JlL3VkcCB0dW5uZWwgaXMgbGVz cyByZXN0cmljdGl2ZSBjb21wYXJpbmcgdG8gYmUNCj4gdXNlZCBpbiBnZW5lcmFsIEludGVybmV0 Lg0KPiANCj4gVGhlIGRyYWZ0IGhhcyBhZGRyZXNzZWQgYWxsIGNvbW1lbnRzIGZyb20gdGhlIG1l ZXRpbmdzIGFuZCBtYWlscy4gT25lIGNhdmlhciBpczoNCj4gDQo+IFVzZSBvZiBVRFAgc3JjIHBv cnQgZm9yIGVudHJvcHkgbWF5IGltcGFjdCB3aXRoIG1pZGRsZWJveCBiZWhhdmlvciAoc2VlIGRy YWZ0KS4NCj4gVG8gYWRkcmVzcyB0aGlzIGNvbmZsaWN0LCB0aGUgZHJhZnQgcmVjb21tZW5kczoN Cj4gDQo+ICAgIElmIGEgR1JFLWluLVVEUCB0dW5uZWwgaXMgZXhwZWN0ZWQgdG8gcGFzcyBhIG1p ZGRsZWJveCwgdG8gYXZvaWQgdGhlDQo+ICAgIGltcGFjdCwgdGhlIG9wZXJhdG9yIGVpdGhlciBk aXNhYmxlIFVEUCBzb3VyY2UgcG9ydCBmb3IgZW50cm9weSBvcg0KPiAgICBjb25maWd1cmUgdGhl IG1pZGRsZWJveCB0byBkZWFsIHdpdGggdGhlIFVEUCBzb3VyY2UgcG9ydCB2YXJpYXRpb24uDQo+ IA0KPiBUaGlzIG9wZXJhdGlvbiBjYW4gYmUgZG9uZSBlYXNpbHkgZm9yIGEgd2VsbC1tYW5hZ2Vk IG9wZXJhdG9yIG5ldHdvcmsuIE1heWJlDQo+IGhhcmQgaW4gZ2VuZXJhbCBJbnRlcm5ldC4gTGlr ZSB0byBnZXQgdGhlIGNvbW11bml0eSBmZWVkYmFjayBpZiB0aGlzIHdpbGwgYmUgYQ0KPiBjb25j ZXJuIG9yIG5vdC4gSWYgeWVzLCB3aGF0IGlzIHRoZSBiZXR0ZXIgYWx0ZXJuYXRpdmU/DQo+IA0K PiBXZSBsaWtlIHRvIHRoYW5rIERhdmlkIEJsYWNrIGEgbG90IGZvciB0aGUgZGV0YWlsIHJldmll dyBhbmQgc3VnZ2VzdGlvbnMuDQo+IA0KPiBUaGFua3MsDQo+IEx1Y3kNCj4gDQo+IA0KPiANCj4g DQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0 c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5l dC0NCj4gZHJhZnRzQGlldGYub3JnDQo+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjYsIDIwMTYg Nzo0OSBQTQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiB0c3Z3Z0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBbdHN2d2ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHN2d2ctZ3JlLWlu LXVkcC1lbmNhcC0wOS50eHQNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ICBU aGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUcmFuc3BvcnQgQXJlYSBXb3JraW5nIEdy b3VwIFdvcmtpbmcgR3JvdXAgb2YNCj4gdGhlIElFVEYuDQo+IA0KPiAgICAgICAgIFRpdGxlICAg ICAgICAgICA6IEdSRS1pbi1VRFAgRW5jYXBzdWxhdGlvbg0KPiAgICAgICAgIEF1dGhvcnMgICAg ICAgICA6IEVkd2FyZCBDcmFiYmUNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBMdWN5IFlv bmcNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBYaWFvaHUgWHUNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICBUb20gSGVyYmVydA0KPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi10c3Z3Zy1ncmUtaW4tdWRwLWVuY2FwLTA5LnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDogMjQN Cj4gCURhdGUgICAgICAgICAgICA6IDIwMTYtMDEtMjYNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1ldGhvZCBvZiBlbmNhcHN1bGF0aW5nIG5ldHdvcmsg cHJvdG9jb2wNCj4gICAgcGFja2V0cyB3aXRoaW4gR1JFIGFuZCBVRFAgaGVhZGVycy4gSW4gdGhp cyBlbmNhcHN1bGF0aW9uLCB0aGUNCj4gICAgc291cmNlIFVEUCBwb3J0IGNhbiBiZSB1c2VkIGFz IGFuIGVudHJvcHkgZmllbGQgZm9yIHB1cnBvc2VzIG9mIGxvYWQNCj4gICAgYmFsYW5jaW5nLCB3 aGlsZSB0aGUgcHJvdG9jb2wgb2YgdGhlIGVuY2Fwc3VsYXRlZCBwYWNrZXQgaW4gdGhlIEdSRQ0K PiAgICBwYXlsb2FkIGlzIGlkZW50aWZpZWQgYnkgdGhlIEdSRSBQcm90b2NvbCBUeXBlLiBUaGlz IGRvY3VtZW50DQo+ICAgIHNwZWNpZmllcyByZXF1aXJlbWVudHMgZm9yIHR3byBhcHBsaWNhYmls aXR5IHNjZW5hcmlvcyBmb3IgdGhpcw0KPiAgICBlbmNhcHN1bGF0aW9uOiAoMSkgR2VuZXJhbCBJ bnRlcm5ldCBhbmQgKDIpIHdlbGwtbWFuYWdlZCBvcGVyYXRvcg0KPiAgICBuZXR3b3JrczsgbGVz cyByZXN0cmljdGl2ZSByZXF1aXJlbWVudHMgYXBwbHkgdG8gdGhlIGxhdHRlciBzY2VuYXJpbw0K PiAgICBieSBjb21wYXJpc29uIHRvIHRoZSBmb3JtZXIuDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0 YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctZ3JlLWluLXVkcC1lbmNhcC8NCj4g DQo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1ncmUtaW4tdWRwLWVuY2Fw LTA5DQo+IA0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUg YXQ6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRzdndn LWdyZS1pbi11ZHAtZW5jYXAtMDkNCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoN Cg== From nobody Wed Feb 17 15:38:14 2016 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013271A8ADC; Wed, 17 Feb 2016 15:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.307 X-Spam-Level: X-Spam-Status: No, score=-4.307 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_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 JZQjoBduXWlU; Wed, 17 Feb 2016 15:38:06 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 A90531A8A3F; Wed, 17 Feb 2016 15:38:01 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u1HNbxOk016449 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Feb 2016 18:37:59 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u1HNbxOk016449 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1455752280; bh=wQ+6a5uqkuFKjGT7T+AbZrVb11s=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=L8xb51BrdvlifSRt7+NiBie0rFheJSU6s8oE1AGuR2A8IFO/KJDf6rmMlDlEU0pL4 frCEduLGsLDEZaQ/rNuFGDpjMCKF4aVKkMKEsse5Sf6GUPA5DdrCBrPtANDHPbSynT 2r18fg7i2Es3zDcE/+TSsj5sJYIqyHAx9NrlocAo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u1HNbxOk016449 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 17 Feb 2016 18:37:39 -0500 Received: from MXHUB228.corp.emc.com (MXHUB228.corp.emc.com [10.253.68.98]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u1HNbgP6003965 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 17 Feb 2016 18:37:45 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.172]) by MXHUB228.corp.emc.com ([10.253.68.98]) with mapi id 14.03.0266.001; Wed, 17 Feb 2016 18:37:43 -0500 From: "Black, David" To: "Surendra Kumar (smkumar)" , "sfc@ietf.org"