From nobody Tue Apr 1 03:19:55 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8E31A8034 for ; Tue, 1 Apr 2014 03:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 0-aPFUjaWjC8 for ; Tue, 1 Apr 2014 03:19:50 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id CF95D1A7032 for ; Tue, 1 Apr 2014 03:19:49 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 5FDF81A00C5; Tue, 1 Apr 2014 12:19:45 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id n-MtAY-F8ID8; Tue, 1 Apr 2014 12:19:36 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id C7B741A00C3; Tue, 1 Apr 2014 12:19:36 +0200 (CEST) Received: from [10.53.40.204] (port=11028 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WUvfL-000865-Tk; Tue, 01 Apr 2014 12:11:35 +0200 Received: from [10.208.1.57] (10.208.1.57) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 1 Apr 2014 12:19:35 +0200 Message-ID: <533A92B7.1060701@secunet.com> Date: Tue, 1 Apr 2014 12:19:35 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Wes Hardaker References: <20140324120302.7098.2512.idtracker@ietfa.amsl.com> <5330268C.4060002@secunet.com> <009c01cf483f$d57b4980$4001a8c0@gateway.2wire.net> <5331C4D5.8060407@secunet.com> <030601cf49c8$36866d20$4001a8c0@gateway.2wire.net> <533574B1.8090606@secunet.com> <0ltxae9en7.fsf@wjh.hardakers.net> In-Reply-To: <0ltxae9en7.fsf@wjh.hardakers.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.57] Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/y0PJWnVYn6IgQeSFs2lIqS9gynA Cc: Manfred Lochter , "opsawg@ietf.org" , "Blumenthal, Uri - 0558 - MITLL" Subject: Re: [OPSAWG] Fwd: New Version Notification fordraft-hmac-sha-2-usm-snmp-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 10:19:52 -0000 Wes, > I'm not entirely convinced that a 256bit truncation is better than a 384 > bit truncation, so my preference would be to include just two (not 6) > algorithms because I don't think they're all needed and will just make > things more confusing. So I'd pick the best two of the 6 and go with > them, for which my preference would be: > > 1) MUST: usmHMAC192SHA256AuthProtocol > SHOULD: usmHMAC384SHA512AuthProtocol > > 2) MUST: usmHMAC192SHA256AuthProtocol > SHOULD: usmHMAC256SHA512AuthProtocol > Why do you prefer usmHMAC192SHA256AuthProtocol over usmHMAC128SHA256AuthProtocol? Following Preneel and van Oorschots advice, I would prefer the latter. If we feel that we don't have the expertise to come to a clear decision here, we could consult CRFG. -- Johannes From nobody Tue Apr 1 04:41:25 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B431A6FF0 for ; Tue, 1 Apr 2014 04:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] 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 Ns-A3iwaAs6P for ; Tue, 1 Apr 2014 04:41:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 53C481A068C for ; Tue, 1 Apr 2014 04:41:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2C382F63; Tue, 1 Apr 2014 13:41:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BCCWztd5lM-v; Tue, 1 Apr 2014 13:41:15 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 1 Apr 2014 13:41:15 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 569642002F; Tue, 1 Apr 2014 13:41:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id e_Iama3dDm4j; Tue, 1 Apr 2014 13:41:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A05B52002C; Tue, 1 Apr 2014 13:41:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7DFDE2C1E96A; Tue, 1 Apr 2014 13:41:11 +0200 (CEST) Date: Tue, 1 Apr 2014 13:41:10 +0200 From: Juergen Schoenwaelder To: Hannes Tschofenig Message-ID: <20140401114108.GA73782@elstar.local> Mail-Followup-To: Hannes Tschofenig , opsawg@ietf.org References: <53396539.8070408@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53396539.8070408@gmx.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/q9dyOXi-5GZBO5xPKZ3zV8ox020 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] IoT & Network Management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 11:41:22 -0000 On Mon, Mar 31, 2014 at 02:53:13PM +0200, Hannes Tschofenig wrote: > Hi all, > > after I listened to Juergen's presentation in the CORE working group at > the last IETF meeting about 'constrained management' I was wondering > about the following aspect: > > More and more devices (specifically IoT devices) come with a built-in > software update mechanism (even at different levels). For example, you > can see firmware update mechanisms, the ability to update individual > files (if there is a file system), or package managers being used. There is a wide range of different device classes. I do not believe that package managers are generally available on all device classes. In a nutshell, there are the really constrained devices (see LWIG terminology) and then there are devices with sufficient resources to run an embedded Linux or BSD kernels. A file system and package managers sound to me you are assuming the later. > The configuration data and the code is often treated in the same way and > also updated using the same style (to better deal with the constrained > nature of these devices). Reference? > I am wondering what the role of traditional network management protocols > actually is. > > Why would I add, let's say, SNMP to my IoT device to configure the > device or to retrieve sensor information when I anyway have to provide a > software update mechanism together with some application layer protocol > (like CoAP)? What matters most is reuse of data models. How you ship the data depends on many criteria. All I can say (since we did implement SNMP) is that SNMP works reasonably well on constrained devices. But yes, if you live in a CoAP world, you may prefer to ship data via CoAP (once you have worked out the details). What would be a failure in my view is to redo the data models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Apr 1 05:40:08 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21D41A06E6 for ; Tue, 1 Apr 2014 05:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2Bxh9w8AhaPb for ; Tue, 1 Apr 2014 05:39:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0301A06C5 for ; Tue, 1 Apr 2014 05:39:59 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lmr1w-1WyWQw1yRg-00h9gP for ; Tue, 01 Apr 2014 14:39:54 +0200 Message-ID: <533AB1A5.2000102@gmx.net> Date: Tue, 01 Apr 2014 14:31:33 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <53396539.8070408@gmx.net> <20140401114108.GA73782@elstar.local> In-Reply-To: <20140401114108.GA73782@elstar.local> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qeIuA9VWo43OcNndPRIMcrHPlRSpUinCV" X-Provags-ID: V03:K0:v78Tbqjuy6dlHaQm9L/RPdeL4fV4YteGoScEWXLA8MmBQja8Hg0 v/oCth4gicV52EHU7+BLYocYm3vmq9KxvfdgxZVOU67qiHBxpAC29x/cJ38jTF6Y3ef8ZI1 W+olxsi7pKl+VK0NiB56leca5DBkvkPPcU/ICAmwxq1S6K3g14N4a06pIaqk/qUYJBphd2c xiYtUiS56h6cTrm0dN2RA== Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/_a484AInyhetDnlc5YP7HTMDr-I Subject: Re: [OPSAWG] IoT & Network Management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 12:40:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qeIuA9VWo43OcNndPRIMcrHPlRSpUinCV Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Juergen, thanks for your response. On 04/01/2014 01:41 PM, Juergen Schoenwaelder wrote: > On Mon, Mar 31, 2014 at 02:53:13PM +0200, Hannes Tschofenig wrote: >> Hi all, >> >> after I listened to Juergen's presentation in the CORE working group a= t >> the last IETF meeting about 'constrained management' I was wondering >> about the following aspect: >> >> More and more devices (specifically IoT devices) come with a built-in >> software update mechanism (even at different levels). For example, you= >> can see firmware update mechanisms, the ability to update individual >> files (if there is a file system), or package managers being used. >=20 > There is a wide range of different device classes. I do not believe > that package managers are generally available on all device classes. > In a nutshell, there are the really constrained devices (see LWIG > terminology) and then there are devices with sufficient resources to > run an embedded Linux or BSD kernels. A file system and package > managers sound to me you are assuming the later. There are certainly a range of devices. For that reason I have listed a number of techniques used by these devices to provide updates. Many Linux-based IoT devices use a form of package manager. These are more "high-end" devices. > =20 >> The configuration data and the code is often treated in the same way a= nd >> also updated using the same style (to better deal with the constrained= >> nature of these devices). >=20 > Reference? Thinking about some of the products I have seen in the wearable space I might be wrong since there you often have a firmware update mechanism for the core functionality (code & long-term configuration data) but then also a configuration mechanism for short-term data. Since it would require reverse engineering to really find out what these products are doing it raises the question about where interoperability is needed. Many of today's products show a pattern that is very close to what we described in Figure 2 of http://tools.ietf.org/html/draft-iab-smart-object-architecture-03. In that sense it does not really matter whether and how configuration data is attached to the code itself since it is proprietary anyway. >=20 >> I am wondering what the role of traditional network management protoco= ls >> actually is. >> >> Why would I add, let's say, SNMP to my IoT device to configure the >> device or to retrieve sensor information when I anyway have to provide= a >> software update mechanism together with some application layer protoco= l >> (like CoAP)? >=20 > What matters most is reuse of data models. How you ship the data > depends on many criteria. All I can say (since we did implement SNMP) > is that SNMP works reasonably well on constrained devices. Unless you do all your tasks on an embedded device with SNMP (or a similar protocol) it seems to be the wrong choice to me since you are adding one additional protocol to implement with functionality that overlaps the other protocol. You might have some experience that I have not yet understood though (which caused me to start a discussion about it= ). > But yes, if > you live in a CoAP world, you may prefer to ship data via CoAP (once > you have worked out the details). What would be a failure in my view > is to redo the data models. That's an interesting perspective. What data models from the network management community do you see most valuable? (Of course, I am not married to CoAP and there is a lot of HTTP usage out there as well. I have only seen one product that used SNMP in the lighting space and I was asking myself why didn't they use CoAP or HTTP.)= Ciao Hannes >=20 > /js >=20 --qeIuA9VWo43OcNndPRIMcrHPlRSpUinCV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTOrGlAAoJEGhJURNOOiAtwCIH/0ar4Tx0ZJ2k/iQ58Hs6LE/M ZQPOr6tGWyGu86PZkathVsIkytmQ7rOA8ha0DTAVlbJTu26zVEVtvW6Z/AD+n4u+ VasltD1In0t+ftaQbgrWf0Y9Bu2HizvS6+a0HEwhLHFCfeuH7x9oAAQNm+waBo++ czEfppgeG7paDV6xsCRntK3Yddxe+yECz7mruwYvctj03VL2+rt86HN2zOb/wSfU c3tVceiQsLZrlN9JJo0qe7HiGLmCaibS0d0NyIOPr9TTMV+KbvaPBUSU9msRL5s4 lzSb8a3d5yhMFaP+VmQSFmLJBHj3G4WL6BXrepcGyIeI5skNKs7yKVaqIeyiubQ= =phDO -----END PGP SIGNATURE----- --qeIuA9VWo43OcNndPRIMcrHPlRSpUinCV-- From nobody Tue Apr 1 08:48:12 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256F41A09A6 for ; Tue, 1 Apr 2014 08:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 N927iX2XJL5o for ; Tue, 1 Apr 2014 08:48:09 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id CEC8B1A09A3 for ; Tue, 1 Apr 2014 08:48:08 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ik5so10409741vcb.28 for ; Tue, 01 Apr 2014 08:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=i7toU2rMDjyY8hFm/UZOXV138YxNpeq275ajXHVTbD4=; b=qfP0c9o/A7K/KUapxx6/skGsNwOv7vmAJJVrAO2DQO5+tnyRYTGlrAu8PTi08zqsWf 3pidud/y6FyoG4YrGkNS7Vcvye+jMvASbe5UsrDhb/8DwTalOj3YTGoHbjuCo8+ivyC3 0ExngCt8LqxL9HBF2lfgs7yBD2ItuzKdI+4/E= 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:content-type; bh=i7toU2rMDjyY8hFm/UZOXV138YxNpeq275ajXHVTbD4=; b=ggcKkVbvkYU4syX1UFKtaQkRaclDeM2zVTARfWjS1CgwzfgSMWt4c8z8kVqMfN9u1k 9ak1BhoWkuqQcAKF+z9w4kenXR4SK60JRofni0M5KYFafFIJRFL6yebMVTxCEim11b1l EDT+ft/xLXHTxCR284tr5jqORJGz07JlYy+b7sH3NYU8JJMI5XREQRIX4v+mLr6RQaNz t20OWmhQIDLaTLagxZMgH7Md2Iu5AypWCzKpNtTH5WrVZWix98vwKk5cdrN2yGi2SVSF Aoof5Exixuj1BfKqaZIflfArKdJzyZToaT1keyeMveMeH0Slyed8YHuYb7Yl0Sskp+BY OyXg== X-Gm-Message-State: ALoCoQlU1v/fNxDwyuiiVMzTt1vaDKvKPO/I2QGGIRq2A4OGnpvykOdwGXkw/p60n8cE7RVbaPdT MIME-Version: 1.0 X-Received: by 10.221.55.199 with SMTP id vz7mr722604vcb.40.1396367284932; Tue, 01 Apr 2014 08:48:04 -0700 (PDT) Received: by 10.221.21.129 with HTTP; Tue, 1 Apr 2014 08:48:04 -0700 (PDT) In-Reply-To: <20140401114108.GA73782@elstar.local> References: <53396539.8070408@gmx.net> <20140401114108.GA73782@elstar.local> Date: Tue, 1 Apr 2014 18:48:04 +0300 Message-ID: From: Ulrich Herberg To: Juergen Schoenwaelder , Hannes Tschofenig , opsawg@ietf.org Content-Type: multipart/alternative; boundary=001a1133ae6afea97a04f5fd1777 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/k-_DhfZjJCYu5FDL961sQ93n8WU Subject: Re: [OPSAWG] IoT & Network Management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 15:48:11 -0000 --001a1133ae6afea97a04f5fd1777 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with J=FCrgen that it would be useful to maintain currently defined data models (in SMI and YANG). The protocol exchanging the actual data could be a different one if we conclude that SNMP/NETCONF are unsuitable for constrained environments. I remember that in one of the unofficial COMAN meetings, we discussed the possibility to port RESTCONF (draft-bierman-netconf-restconf-04) to COAP instead of HTTP. That would be one option to reuse existing Yang models. And possibly MIB modules via RFC 6643. Best regards Ulrich On Tue, Apr 1, 2014 at 2:41 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Mar 31, 2014 at 02:53:13PM +0200, Hannes Tschofenig wrote: > > Hi all, > > > > after I listened to Juergen's presentation in the CORE working group at > > the last IETF meeting about 'constrained management' I was wondering > > about the following aspect: > > > > More and more devices (specifically IoT devices) come with a built-in > > software update mechanism (even at different levels). For example, you > > can see firmware update mechanisms, the ability to update individual > > files (if there is a file system), or package managers being used. > > There is a wide range of different device classes. I do not believe > that package managers are generally available on all device classes. > In a nutshell, there are the really constrained devices (see LWIG > terminology) and then there are devices with sufficient resources to > run an embedded Linux or BSD kernels. A file system and package > managers sound to me you are assuming the later. > > > The configuration data and the code is often treated in the same way an= d > > also updated using the same style (to better deal with the constrained > > nature of these devices). > > Reference? > > > I am wondering what the role of traditional network management protocol= s > > actually is. > > > > Why would I add, let's say, SNMP to my IoT device to configure the > > device or to retrieve sensor information when I anyway have to provide = a > > software update mechanism together with some application layer protocol > > (like CoAP)? > > What matters most is reuse of data models. How you ship the data > depends on many criteria. All I can say (since we did implement SNMP) > is that SNMP works reasonably well on constrained devices. But yes, if > you live in a CoAP world, you may prefer to ship data via CoAP (once > you have worked out the details). What would be a failure in my view > is to redo the data models. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --001a1133ae6afea97a04f5fd1777 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with J=FCrgen that it would be useful to main= tain currently defined data models (in SMI and YANG). The protocol exchangi= ng the actual data could be a different one if we conclude that SNMP/NETCON= F are unsuitable for constrained environments. I remember that in one of th= e unofficial COMAN meetings, we discussed the possibility to port RESTCONF = (draft-bierman-netconf-restconf-04) to COAP instead of HTTP. That would be = one option to reuse existing Yang models. And possibly MIB modules via RFC = 6643.

Best regards
Ulrich

<= br>
On Tue, Apr 1, 2014 at 2:41 PM, Juergen Schoe= nwaelder <j.schoenwaelder@jacobs-university.de><= /span> wrote:
On Mon, Mar 31, 2014 at 02:5= 3:13PM +0200, Hannes Tschofenig wrote:
> Hi all,
>
> after I listened to Juergen's presentation in the CORE working gro= up at
> the last IETF meeting about 'constrained management' I was won= dering
> about the following aspect:
>
> More and more devices (specifically IoT devices) come with a built-in<= br> > software update mechanism (even at different levels). For example, you=
> can see firmware update mechanisms, the ability to update individual > files (if there is a file system), or package managers being used.

There is a wide range of different device classes. I do not believe that package managers are generally available on all device classes.
In a nutshell, there are the really constrained devices (see LWIG
terminology) and then there are devices with sufficient resources to
run an embedded Linux or BSD kernels. A file system and package
managers sound to me you are assuming the later.

> The configuration data and the code is often treated in the same way a= nd
> also updated using the same style (to better deal with the constrained=
> nature of these devices).

Reference?

> I am wondering what the role of traditional network management protoco= ls
> actually is.
>
> Why would I add, let's say, SNMP to my IoT device to configure the=
> device or to retrieve sensor information when I anyway have to provide= a
> software update mechanism together with some application layer protoco= l
> (like CoAP)?

What matters most is reuse of data models. How you ship the data
depends on many criteria. All I can say (since we did implement SNMP)
is that SNMP works reasonably well on constrained devices. But yes, if
you live in a CoAP world, you may prefer to ship data via CoAP (once
you have worked out the details). What would be a failure in my view
is to redo the data models.

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49= 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

--001a1133ae6afea97a04f5fd1777-- From nobody Wed Apr 2 00:27:17 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A981A006E for ; Wed, 2 Apr 2014 00:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] 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 fEt_DzlEA9lu for ; Wed, 2 Apr 2014 00:27:10 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC3B1A00F4 for ; Wed, 2 Apr 2014 00:27:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 42C6F6F7; Wed, 2 Apr 2014 09:27:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id j7d5OwFMMEDA; Wed, 2 Apr 2014 09:27:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 2 Apr 2014 09:27:05 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 525FE2002F; Wed, 2 Apr 2014 09:27:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CiTw7rUnv9YF; Wed, 2 Apr 2014 09:27:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F35F320034; Wed, 2 Apr 2014 09:27:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 559042C20C8D; Wed, 2 Apr 2014 09:27:02 +0200 (CEST) Date: Wed, 2 Apr 2014 09:27:01 +0200 From: Juergen Schoenwaelder To: Hannes Tschofenig Message-ID: <20140402072701.GA76148@elstar.local> Mail-Followup-To: Hannes Tschofenig , opsawg@ietf.org References: <53396539.8070408@gmx.net> <20140401114108.GA73782@elstar.local> <533AB1A5.2000102@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533AB1A5.2000102@gmx.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/o-ZAAc9jwD_SOQEW7uIsXrAkshc Cc: opsawg@ietf.org Subject: Re: [OPSAWG] IoT & Network Management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 07:27:14 -0000 On Tue, Apr 01, 2014 at 02:31:33PM +0200, Hannes Tschofenig wrote: > > > > What matters most is reuse of data models. How you ship the data > > depends on many criteria. All I can say (since we did implement SNMP) > > is that SNMP works reasonably well on constrained devices. > > Unless you do all your tasks on an embedded device with SNMP (or a > similar protocol) it seems to be the wrong choice to me since you are > adding one additional protocol to implement with functionality that > overlaps the other protocol. You might have some experience that I have > not yet understood though (which caused me to start a discussion about it). Yes, on our constrained devices, we actually do everything via SNMP (since reading some energy sensors is pretty straight-forward to do with SNMP). And yes, if you life in a CoAP world, you likely want to do as much as possible with CoAP. (But then I must admit that we also did implement mDNS since since it is just so cool to see your sensors popping up in your mDNS enables applications. Sometimes it is the ease of reuse of existing stuff that compensates some extra implementation costs.) > > But yes, if > > you live in a CoAP world, you may prefer to ship data via CoAP (once > > you have worked out the details). What would be a failure in my view > > is to redo the data models. > > That's an interesting perspective. What data models from the network > management community do you see most valuable? If you want to expose basic counters related to your network interfaces or your IP stack or you want to expose your IP configuration, then I think we should try to reuse what we have and not reinvent the wheel. If RESTCONF can be mapped well to CoAP and constrained devices, this may be an interesting option. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Apr 2 00:52:21 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377CB1A015F for ; Wed, 2 Apr 2014 00:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lao5GP_wzzAL for ; Wed, 2 Apr 2014 00:52:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFB01A010C for ; Wed, 2 Apr 2014 00:52:14 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mcyxq-1WmEt10QzK-00IF8D for ; Wed, 02 Apr 2014 09:52:09 +0200 Message-ID: <533BC105.1040804@gmx.net> Date: Wed, 02 Apr 2014 09:49:25 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <53396539.8070408@gmx.net> <20140401114108.GA73782@elstar.local> <533AB1A5.2000102@gmx.net> <20140402072701.GA76148@elstar.local> In-Reply-To: <20140402072701.GA76148@elstar.local> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9MduDfPTLuCIbl6OxpboCkAvc1n5r4agN" X-Provags-ID: V03:K0:xWDhny7IadU3dejqbP/A+eOFCiouiQ/Tt9iGpQKrpgpSfiynD/4 neQjg5dADyTQGPnCKtwHS33OqRLWg1VjixkLT6r1TUKOmfHrP7xDGB2KMjc6szLLKAG4ZbT gVfZmx+BWCEm+56AU1NdrrQKTjIdMP5/mSxu2caqihsvdEgk3pM7kpEPscGdcl/VfrG/qHC E9Hcat74GrhAff7s77bFg== Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/A9Th3-8TrwwsSlO_XNFfXhyzooU Subject: Re: [OPSAWG] IoT & Network Management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 07:52:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9MduDfPTLuCIbl6OxpboCkAvc1n5r4agN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Juergen, On 04/02/2014 09:27 AM, Juergen Schoenwaelder wrote: > On Tue, Apr 01, 2014 at 02:31:33PM +0200, Hannes Tschofenig wrote: >>> >>> What matters most is reuse of data models. How you ship the data >>> depends on many criteria. All I can say (since we did implement SNMP)= >>> is that SNMP works reasonably well on constrained devices. >> >> Unless you do all your tasks on an embedded device with SNMP (or a >> similar protocol) it seems to be the wrong choice to me since you are >> adding one additional protocol to implement with functionality that >> overlaps the other protocol. You might have some experience that I ha= ve >> not yet understood though (which caused me to start a discussion about= it). >=20 > Yes, on our constrained devices, we actually do everything via SNMP > (since reading some energy sensors is pretty straight-forward to do > with SNMP). And yes, if you life in a CoAP world, you likely want to > do as much as possible with CoAP. (But then I must admit that we also > did implement mDNS since since it is just so cool to see your sensors > popping up in your mDNS enables applications. Sometimes it is the ease > of reuse of existing stuff that compensates some extra implementation > costs.) >=20 Did you document that work somewhere? (an IETF draft or so?) >>> But yes, if >>> you live in a CoAP world, you may prefer to ship data via CoAP (once >>> you have worked out the details). What would be a failure in my view >>> is to redo the data models. >> >> That's an interesting perspective. What data models from the network >> management community do you see most valuable? >=20 > If you want to expose basic counters related to your network > interfaces or your IP stack or you want to expose your IP > configuration, then I think we should try to reuse what we have and > not reinvent the wheel. If RESTCONF can be mapped well to CoAP and > constrained devices, this may be an interesting option. I could see this data being of interest for a router/switch but not necessarily for an end device. Would you agree? Ciao Hannes >=20 > /js >=20 --9MduDfPTLuCIbl6OxpboCkAvc1n5r4agN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTO8EFAAoJEGhJURNOOiAt1PoH/i7mbHQTDJlvSlPzGBl3Vvtt 08+GPFOmmrox33VFAglNJCz2v8uL1uRC47TWTF2h3s+LoUtXHKGVJFn2fZbHCB4i J0cpf2GGukjeyiQprHsgkn8QpeLI9qiW6UGs6PgfDr/R590htxHG4Kyy0t7zdyNi w0eDL13gtVhJ79nHhyC0+SHOFpfqmJl4YMfxagmZc9pdVMLTu22mfB/sjyTgCQCz u5zqDZImX1ffvXePWMI5138eEapyXT+U9isa6LZGfUvVuJFtqLWrKa3OOaD7XqqJ Q8NkKfpRTi6ly+rY638IJ2xf1SJi/yV5Hxcsv/TAjPxLXLotiVgHnn7KkC/ax90= =bOW3 -----END PGP SIGNATURE----- --9MduDfPTLuCIbl6OxpboCkAvc1n5r4agN-- From nobody Wed Apr 2 09:05:30 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2AE1A01FB for ; Wed, 2 Apr 2014 09:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 n1SbIFiVh6ZU for ; Wed, 2 Apr 2014 09:05:10 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 40AC81A030E for ; Wed, 2 Apr 2014 09:04:52 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 970C228373; Wed, 2 Apr 2014 09:04:48 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 914C6B1100; Wed, 2 Apr 2014 09:04:48 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP id 82E64E0048; Wed, 2 Apr 2014 09:04:48 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP; Wed, 2 Apr 2014 09:04:48 -0700 (PDT) Date: Wed, 2 Apr 2014 09:04:48 -0700 (PDT) From: Michael MacFaden To: Hannes Tschofenig Message-ID: <1787407935.62259792.1396454688224.JavaMail.root@vmware.com> In-Reply-To: <533BC105.1040804@gmx.net> References: <53396539.8070408@gmx.net> <20140401114108.GA73782@elstar.local> <533AB1A5.2000102@gmx.net> <20140402072701.GA76148@elstar.local> <533BC105.1040804@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: IoT & Network Management Thread-Index: oDr5/pEgk1cq2pXq82cGlz/Ed+3tOg== Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/tkTenCMN3cf0o3xLP_puf5Xp_ck Cc: opsawg@ietf.org Subject: Re: [OPSAWG] IoT & Network Management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:05:16 -0000 > >> That's an interesting perspective. What data models from the network > >> management community do you see most valuable? > > > > If you want to expose basic counters related to your network > > interfaces or your IP stack or you want to expose your IP > > configuration, then I think we should try to reuse what we have and > > not reinvent the wheel. If RESTCONF can be mapped well to CoAP and > > constrained devices, this may be an interesting option. > > I could see this data being of interest for a router/switch but not > necessarily for an end device. > > Would you agree? Often times it is because there are differing technologies that the network operations team stop at the edge switch and not at the nic/ip stack on the end device. Yet this is one of the most common areas for failure for any number of reasons. In my experience working with Fortune 50 enterprises I keep hearing this common refrain, it goes like this: "Company X is taking a holistic view of their data center and wish to treat all assets in a uniform manner." And why is that? because it lowers the cost of doing business. If adapters to convert one technology to another are needed they cost time and money. So while I agree its not fun to have to implement overlapping technologies from the developers point of view, at least if one of the technologies is snmp at least it didn't suck up all the devices remaining resources and is highly likely to be used to good effect. Mike From nobody Wed Apr 2 10:37:52 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6041A02EA for ; Wed, 2 Apr 2014 10:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] 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 d_nIa9r9qQKB for ; Wed, 2 Apr 2014 10:37:45 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 4869E1A0318 for ; Wed, 2 Apr 2014 10:37:45 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta14.westchester.pa.mail.comcast.net with comcast id l0uZ1n0061HzFnQ5E5dhcw; Wed, 02 Apr 2014 17:37:41 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta14.westchester.pa.mail.comcast.net with comcast id l5dg1n00p2yZEBF3a5dgSY; Wed, 02 Apr 2014 17:37:41 +0000 From: "ietfdbh" To: "'Michael MacFaden'" , "'Hannes Tschofenig'" References: <53396539.8070408@gmx.net> <20140401114108.GA73782@elstar.local> <533AB1A5.2000102@gmx.net> <20140402072701.GA76148@elstar.local> <533BC105.1040804@gmx.net> <1787407935.62259792.1396454688224.JavaMail.root@vmware.com> In-Reply-To: <1787407935.62259792.1396454688224.JavaMail.root@vmware.com> Date: Wed, 2 Apr 2014 13:37:21 -0400 Message-ID: <046a01cf4e9a$3407a4c0$9c16ee40$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKT5N9xP66jxfAN/w6M6G9YE2O3/AEn/A3iAmQLgFoCM3O4rgJhUeihAn1BOzGZIHg3sA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396460261; bh=VVie6oY5wU+LHXagZyl1zL55pDWsR2Pv0wbvN18gMRE=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=B+VjiWmWMEPFRb+oMB6MIN/DUQBjjlD0xy396yrcWg6JARLeXQVHQf1LpsWWjTt05 jApubPy9/0Hq62B0CWQnqdw2ooHT+E96wTeVTHpxO8XghZ+krexebEUZYKLS1vhBra RN/qZAlERXyOPsaXefDt9veQh6gLK5mPs1hYZ8cneJ4BKg1eyGV2FlAkCSGsW+k58y k7OBrev2+2pjL8mhJatAPOzlhWtCOESpPj2+boKmkBQ3bQhnXmlENBQPZXRSVrQk0O LVXpFz0B+GaodymQnK9wppw55CqPhKqVpIoT5U6ty1bFr6BBk2XA2Tme5BpIOpFyvU RMI5pWbabsKpA== Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/_aFrrPrMlsdyfRtowkVJtQjZd04 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] IoT & Network Management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 17:37:50 -0000 > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Michael > MacFaden > Sent: Wednesday, April 02, 2014 12:05 PM > To: Hannes Tschofenig > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] IoT & Network Management > > > >> That's an interesting perspective. What data models from the network > > >> management community do you see most valuable? > > > > > > If you want to expose basic counters related to your network > > > interfaces or your IP stack or you want to expose your IP > > > configuration, then I think we should try to reuse what we have and > > > not reinvent the wheel. If RESTCONF can be mapped well to CoAP and > > > constrained devices, this may be an interesting option. > > > > I could see this data being of interest for a router/switch but not > > necessarily for an end device. > > > > Would you agree? > Assuming "this data" in your question refers to the network interfaces and/or IP stack, I wouldn't agree that this is only interesting for a router/switch. The network ends at the endpoint, not at the forwarding device. Troubleshooting a networking problem often requires troubleshooting the endpoint configuration of the relevant interfaces (and interface-using applications), not just the router/switch. David Harrington ietfdbh@comcast.net +1-603-828-1401 From nobody Wed Apr 2 12:19:01 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19CB1A0326 for ; Wed, 2 Apr 2014 12:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 hr92VsskRoJO for ; Wed, 2 Apr 2014 12:18:54 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D0D601A0389 for ; Wed, 2 Apr 2014 12:18:54 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id p10so610001pdj.31 for ; Wed, 02 Apr 2014 12:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IcIGorUZo+8qG+j0zH0rUD4t10cWuX9whrMv8n8i3iU=; b=lx4T8VVYHw9J2GH9ZzA3dwBuqoUsNC+qOT5ya0jSxKiGRT3l8Neo1/4uHs8aMq/puK dG3Rg6TVjQSv0VRl/nu/yS+6Y9Rbb5+5zfdI2dVWIE2qHDyZibZhfv6Hr/NYOc1lFcju TJthWuIRS+TmrLlIztvVAaEUlTeVG7h3kZjr3zc1yc5pnb3o8jqwgrVG2w8dXEVJHBr8 5BS0jNfXHJ2OqWjst3OxmukBQ9bAMiP8mqi4uGBSTHI6OI51igRr2QhMpR89NWCmNRtP hE3eZsbNeTcbXoucrYeztJVcNWMZ3LxTunbV3v6zvsgKHQG8nySUWEz/jROSZpehUP/n D+XQ== X-Received: by 10.66.228.201 with SMTP id sk9mr2051641pac.134.1396466331029; Wed, 02 Apr 2014 12:18:51 -0700 (PDT) Received: from [192.168.178.23] (89.195.69.111.dynamic.snap.net.nz. [111.69.195.89]) by mx.google.com with ESMTPSA id yx3sm6149175pbb.6.2014.04.02.12.18.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 12:18:50 -0700 (PDT) Message-ID: <533C629F.4010601@gmail.com> Date: Thu, 03 Apr 2014 08:18:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig References: <53396539.8070408@gmx.net> <20140401114108.GA73782@elstar.local> <533AB1A5.2000102@gmx.net> <20140402072701.GA76148@elstar.local> <533BC105.1040804@gmx.net> In-Reply-To: <533BC105.1040804@gmx.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/JpuxT9CumbU5KoT2-PWL0NHSJvw Cc: opsawg@ietf.org Subject: Re: [OPSAWG] IoT & Network Management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 19:19:00 -0000 On 02/04/2014 20:49, Hannes Tschofenig wrote: >> not reinvent the wheel. If RESTCONF can be mapped well to CoAP and >> constrained devices, this may be an interesting option. Please explain what you mean by mapping RESTCONF to CoAP. Do you mean some sort of RESTCONF/CoAP gateway box? I can't imagine RESTCONF itself on a constrained device. Brian From nobody Wed Apr 2 18:36:12 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D075F1A004E for ; Wed, 2 Apr 2014 18:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 oyxcxMXCG1s0 for ; Wed, 2 Apr 2014 18:36:05 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1415B1A0043 for ; Wed, 2 Apr 2014 18:36:04 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id i13so989641qae.19 for ; Wed, 02 Apr 2014 18:36:00 -0700 (PDT) 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=B84RIl2RbTsPC4UP/KHB35D8mb7GrYkMX+brVt5+Mn4=; b=SYwT3T2YYFXkTaj0jlDfA54xlCl49DUvB+m5WWMxfM+JKw56Gwj3Jl5lbb/UyLRILA CYfiWfPtQTGlY7XmAFvVJiPjxFSshI8X+Pep6hhDPrrDcuddS5DkNz9Zga/6C6+U/Ff1 yvKbKgA90KcBN3RAUJvdepNM65gCoLJwLksor8BuGVFc6NyUd8un6rr2+nTMsPNN7K6E 63m/CTIUrtMX+p4FS5TAQg5IN1Pgbj0YKZTw8994dyCZvR3lEVlENmx1zAr6HYmwFYWF 0pBQuPtvoBaHhlgCCMZFTFsDdSrNJCQ3Ray8A4cF1DlWn5rt5kowZuNWwN6HieA7oZJC lbnw== X-Gm-Message-State: ALoCoQnCFXiCCiKoaq0h4LZzwipUyVHpTTrb53KKHSdVEDWSsPGo3HBMIZhHYbw0TOsVZYNBIIUf MIME-Version: 1.0 X-Received: by 10.224.122.202 with SMTP id m10mr4217557qar.87.1396488960540; Wed, 02 Apr 2014 18:36:00 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Wed, 2 Apr 2014 18:36:00 -0700 (PDT) In-Reply-To: <533C629F.4010601@gmail.com> References: <53396539.8070408@gmx.net> <20140401114108.GA73782@elstar.local> <533AB1A5.2000102@gmx.net> <20140402072701.GA76148@elstar.local> <533BC105.1040804@gmx.net> <533C629F.4010601@gmail.com> Date: Wed, 2 Apr 2014 18:36:00 -0700 Message-ID: From: Andy Bierman To: Brian E Carpenter Content-Type: multipart/alternative; boundary=089e0149c5e86fe0cc04f6196c0b Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/1BEMGY8HcBVfknC-KaBBPBBEdTI Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] IoT & Network Management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 01:36:10 -0000 --089e0149c5e86fe0cc04f6196c0b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 2, 2014 at 12:18 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 02/04/2014 20:49, Hannes Tschofenig wrote: > > >> not reinvent the wheel. If RESTCONF can be mapped well to CoAP and > >> constrained devices, this may be an interesting option. > > Please explain what you mean by mapping RESTCONF to CoAP. Do you > mean some sort of RESTCONF/CoAP gateway box? I can't imagine > RESTCONF itself on a constrained device. > > I think HTTP and TCP are more problematic than RESTCONF. The concept of CRUD operations on a datastore scales down to constrained devices. CoAP defines an HTTP <--> CoAP proxy server, so the CoAP translation could be used. The direct translation may not be optimal, so there might be a "native CoAP mode" between CoAP client and CoAP server that was more efficient. > Brian > Andy --089e0149c5e86fe0cc04f6196c0b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 2, 2014 at 12:18 PM, Brian E Carpenter <bria= n.e.carpenter@gmail.com> wrote:
On 02/04/2014 20:49, Hannes Tschofenig wrote= :

>> not reinvent the wheel. If RESTCONF can be mapped well to CoAP and=
>> constrained devices, this may be an interesting option.

Please explain what you mean by mapping RESTCONF to CoAP. Do you
mean some sort of RESTCONF/CoAP gateway box? I can't imagine
RESTCONF itself on a constrained device.


I think HTTP and TCP are more problema= tic than RESTCONF.
The concept of CRUD operations on a datastore = scales down
to constrained devices.

CoAP defines an HTTP <--> CoAP proxy server, so the CoAP translation<= /div>
could be used. =A0The direct translation may not be optimal, so t= here might
be a "native CoAP mode" between CoAP client = and CoAP server
that was more efficient.

=A0
=A0 =A0 Brian

Andy

=
--089e0149c5e86fe0cc04f6196c0b-- From nobody Sun Apr 6 16:39:41 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58151A05E5; Sun, 6 Apr 2014 16:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 5_a_iDtrD2kQ; Sun, 6 Apr 2014 16:39:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B88B1A05C3; Sun, 6 Apr 2014 16:39:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140406233933.15725.60979.idtracker@ietfa.amsl.com> Date: Sun, 06 Apr 2014 16:39:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/iDUUViRHtUy9dHhiUq3FOHEUTtI Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-large-flow-load-balancing-08.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 23:39:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Mechanisms for Optimizing LAG/ECMP Component Link Utilization in Networks Authors : Ram Krishnan Lucy Yong Anoop Ghanwani Ning So Bhumip Khasnabish Filename : draft-ietf-opsawg-large-flow-load-balancing-08.txt Pages : 25 Date : 2014-04-06 Abstract: Demands on networking infrastructure are growing exponentially due to bandwidth hungry applications such as rich media applications and inter-data center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal cost multi-paths as techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-large-flow-load-balancing-08 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 Sun Apr 6 16:42:59 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7241A00EC for ; Sun, 6 Apr 2014 16:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, 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 TTYpXNJV7jsk for ; Sun, 6 Apr 2014 16:42:52 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) by ietfa.amsl.com (Postfix) with ESMTP id F19641A05D3 for ; Sun, 6 Apr 2014 16:42:48 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s36MaWwX014950; Sun, 6 Apr 2014 16:42:40 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1k2krrh6v7-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 06 Apr 2014 16:42:39 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 6 Apr 2014 16:42:38 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Sun, 6 Apr 2014 16:42:38 -0700 From: ramki Krishnan To: Benoit Claise , Anoop Ghanwani Date: Sun, 6 Apr 2014 16:42:33 -0700 Thread-Topic: AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response) Thread-Index: Ac9KeEM9GtBoZWaIT1aJLON66fQzBAHeVk2g Message-ID: References: <531AF602.5070400@cisco.com> <53355BD8.2030106@cisco.com> In-Reply-To: <53355BD8.2030106@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C00372A95BHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-04-06_02:2014-04-04,2014-04-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404060261 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/F5JVQ9UN-J5VxX9IDhWP8E4WLEE Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 23:42:57 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C00372A95BHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benoit, Thanks for your patience. We have addressed all your comments in the latest= version. Additionally, we have done some editorial. http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing= / Thanks, Ramki From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Friday, March 28, 2014 4:24 AM To: Anoop Ghanwani Cc: ramki Krishnan; opsawg@ietf.org Subject: Re: AD review of draft-ietf-opsawg-large-flow-load-balancing (draf= t response) Hi Anoop, Ramki, A gentle reminder. Regards, Benoit Hi Anoop, Please post a new draft version, and I'll review the diffs. Some more answers in-line. Regards, Benoit Hi Benoit, Thanks for the detailed and careful review. Comments inline. Anoop =3D=3D=3D=3D On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise > wrote: Dear authors, Here is my AD review of draft-ietf-opsawg-large-flow-load-balancing - Section 1: Networks extensively use link aggregation groups (LAG) [802.1AX] and equal cost multi-paths (ECMP) [RFC 2991] as techniques for capacity scaling. For the problems addressed by this document, network traffic can be predominantly categorized into two traffic types: long-lived large flows and other flows. ... This draft describes mechanisms for optimal LAG/ECMP component link utilization while using hash-based techniques. The mechanisms comprise the following steps -- recognizing large flows in a router; and assigning the large flows to specific LAG/ECMP component links or redistributing the small flows when a component link on the router is congested. It is useful to keep in mind that in typical use cases for this mechanism the large flows are those that consume a significant amount of bandwidth on a link, e.g. greater than 5% of link bandwidth. The number of such flows would necessarily be fairly small, e.g. on the order of 10's or 100's per LAG/ECMP. In other words, the number of large flows is NOT expected to be on the order of millions of flows. Examples of such large flows would be IPsec tunnels in service provider backbone networks or storage backup traffic in data center networks. 3 instances of "large flows": do you mean "long-lived large flows"? If not, why do you make a distinction between long-lived large flows and ot= her flows in the first paragraph? I eventually understood the source of confusion when I read the terminology= section: Large flow(s): long-lived large flow(s) Either use capitalized term in the Intro section (actually throughout the d= oc.) so that we understand that the term is defined somewhere, or make it c= lear in the intro that large flow(s) =3D long-lived large flow(s) Yes, they are all referring to long-lived large flows. We will change the = early part of Section 1 to clarify that long-lived large flows are, thereaf= ter in the document, referred to as large flows. Or replace large flow by long-lived flow were it makes sense in the draft. - This document presents improved load distribution techniques based on the large flow awareness. Improved compared to? Improved compared to static hash-based distribution techniques that do not = account for the bandwidth of the flows. Will reword as follows: "This document presents mechanisms for improving the load distribution prob= lem resulting from stateless hashing as seen in the above example." ok - In several places, starting with the title and abstract, you speak about me= chanisms (plural). However, looking at section 4.2, it seems that you propose a single mechani= sm? Or maybe you consider 4.1, 4.2, 4.3 as different mechanisms? The title of 4.2 is perhaps misleading and should just be "Operational Over= view." ok Otherwise the rest of the draft discusses several mechanisms (multiple cho= ices for large flow identification, and multiple choices for rebalancing). - Step 3) On receiving the alert about the congested component link, the operator, through a central management entity, finds the large flows mapped to that component link and the LAG/ECMP group to which the component link belongs. Step 4) The operator can choose to rebalance the large flows on lightly loaded component links of the LAG/ECMP group or redistribute the small flows on the congested link to other component links of the group. The operator, through a central management entity, can choose one of the following actions: 1) Indicate specific large flows to rebalance; 2) Have the router decide the best large flows to rebalance; 3) Have the router redistribute all the small flows on the congested link to other component links in the group. "Indicate specific large flows to rebalance", "through a central management= entity", what you describe is basically traffic engineering. Other the other hand, for 2) and 3), why do you need a central management e= ntity? The assumption was that the router is controlled by a central management en= tity for the purpose of this function, but that is clearly not a requiremen= t. The text will be modified to mention that a central management entity m= ay be used (i.e. not required). Ok. - A number of routers support sampling techniques such as sFlow [sFlow- v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954]. For the purpose of large flow identification, sampling must be enabled on all of the egress ports in the router where such measurements are desired. I don't understand the second sentence. One way to read this is: sampling must be enabled on all of the egress por= ts where such measurements are desired. Ok, this is an obvious statement. If the measurements are desired, enab= le them Yes, ok please clarify the text. Or maybe you want to say: sampling must be enabled on all of the egress por= ts where such measurements are desired. This is a false statement: if you have the choice between sampling and = non sampling, use non sampling measurements. Or maybe you want to say: sampling must be enabled on all of the egress por= ts where such measurements are desired. This is a false statement: if I have ECMP on 2 links, and only one of t= hem can't do non sampling, then we should not force sampling on both links. You see, I'm confused. You miss a couple of key messages: - if unsampled measurements are available, use those. - egress means where LAG/ECMP are enabled (this is important for the paragr= aph starting with "If egress sampling is not available, ingress sampling ca= n suffice since the central management entity use") We were not intending to discuss a mix sampling and non-sampling interfaces= in the same router, but this is a reasonable point and it will be clarifie= d (i.e. we will state that it's possible to mix sampled and non sampled int= erfaces as long as the function of large flow detection/identification can = be performed). - If egress sampling is not available, ingress sampling can suffice since the central management entity used by the sampling technique typically has multi-node visibility and can use the samples from an immediately downstream node to make measurements for egress traffic at the local node. It's not clear if "ingress" means the ingress interface of the router itsel= f, or the ingress interface of the downstream router. A drawing is required. Both options are possible: 1. ingress interfaces on the router where LAG/ECMP is initiated flow monitoring must be enabled on all ingress interfaces flow monitoring must have a way to know the egress interfaces 2. ingress interfaces of the downstream router only work for LAG or ECMP single hop ingress interfaces =3D all components from LAG/ECMP (multiple ifInd= ex, typically) What we meant here was that ingress sampling would have to be enable on the= downstream device (hence the central management entity must come into play= to identify large flows). I still believe that a drawing would clarify things. this entire section 4.3.3 needs some improvements - On one side, you wrote "Specific algorithms for placement of large flows ar= e out of scope of this document.". On the other side, "The following parame= ters are required the configuration of this feature". It seems contradictor= y. It's unclear why you need the following parameter: . Imbalance threshold: the difference between the utilization of the least utilized and most utilized component links. Expressed as a percentage of link speed. Also, does ECMP/LAG always require equivalent link speed for their componen= ts? The imbalance threshold is a measure of how much imbalance one is willing t= o tolerate before taking the hit of potential packet reordering in some flo= ws. Will clarify. Thanks for catching the issue with link speed. While in most cases speeds = are consistent, there may be the case of composite links which combine link= s of different speeds (actually permitted by 802.1AX), so we will provide a= generalized formula for the imbalance threshold which takes into account t= he individual speeds of each of the component links. - 5.2. System Configuration and Identification Parameters . IP address: The IP address of a specific router that the feature is being configured on, or that the large flow placement is being applied to. . LAG ID: Identifies the LAG. The LAG ID may be required when configuring this feature (to apply a specific set of large flow identification parameters to the LAG) and will be required when specifying flow placement to achieve the desired rebalancing. . Component Link ID: Identifies the component link within a LAG. This is required when specifying flow placement to achieve the desired rebalancing. Nothing regarding ECMP? Initially we were more focused on getting this done for LAG, but then we co= mpletely overlooked ECMP. 5.2, 5.3, and 5.4 would probably benefit from a = bit of clean-up as follows: Add the following to 5.2: ECMP group: Identifies a particular ECMP group. ECMP nexthop: Identifies a particular nexthop within an ECMP group. Add the following line to the end of section 5.3. When using ECMP, the nexthop within an ECMP group is used to identify the c= omponent link for placing the large flow. Add the following to the end of Section 5.4. When using ECMP, the ECMP group and the corresponding Nexthops along with t= he percentage of traffic to be assigned to each Nexthop is required. Final= ly it is also possible that an ECMP Nexthop itself comprises a LAG in which= case both the Nexthop and the LAG Component ID would need to be specified,= and the weights of both the Nexthop's within the ECMP Group and the Compon= ent Links within the LAG would need to be adjusted. Ok. Regards, Benoit - For high speed links, the etherStatsHighCapacityTable MIB [RFC 3273] can be used. Well, only for ethernet. Will clarify that. EDITORIAL: - figure 2 OLD: +-----------+ -> +-----------+ | | -> | | | | =3D=3D=3D> | | | (1)|--------|(1) | | | -> | | | | -> | | | (R1) | -> | (R2) | NEW: +-----------+ -> +-----------+ | | -> | | | | =3D=3D=3D> | | | (1)|--------|(1) | | | -> | | | | -> | | | (R1) | -> | (R2) | Will fix. - The indentation in section 2 is not correct Will fix. - "For tunneling protocols like GRE, VXLAN, NVGRE, STT, etc.," You need to expand and provide references. Will provide references. What do mean by expand -- just expand the acronym= s (already in the acronym section) or something else? - a PBR rule Expand. OK - OLD: +-----------+ -> +-----------+ | | -> | | | | =3D=3D=3D> | | | (1)|--------|(1) | | | | | | | =3D=3D=3D> | | | | -> | | | | -> | | | (R1) | -> | (R2) | | (2)|--------|(2) | NEW: +-----------+ -> +-----------+ | | -> | | | | =3D=3D=3D> | | | (1)|--------|(1) | | | | | | | =3D=3D=3D> | | | | -> | | | | -> | | | (R1) | -> | (R2) | | (2)|--------|(2) | Will fix. - OLD: The IPFIX information model [RFC 7011] NEW: The IPFIX information model [RFC 7012] Will fix. Regards, Benoit --_000_C7634EB63EFD984A978DFB46EA5174F2C00372A95BHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Benoit,

&nb= sp;

Thanks for your patience. W= e have addressed all your comments in the latest version. Additionally, we = have done some editorial.

=  

http:= //datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/=

 <= /p>

Thanks,

Ramki

&n= bsp;

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Friday, March 28, 2014 4:24 AM
To: Anoop Ghanwani
Cc:= ramki Krishnan; opsawg@ietf.org
Subject: Re: AD review of draft-= ietf-opsawg-large-flow-load-balancing (draft response)

 

Hi Anoop, Ramki,

A gentle reminder.

Regards, Benoit

Hi Anoop,

Please post a new draft version= , and I'll review the diffs.
Some more answers in-line.

Regards, = Benoit

 

Hi Benoit= ,

 

=

Thanks for the detailed and careful review.  = ;Comments inline.

 =

Anoop

<= div>

 

=3D=3D=3D=3D

 

On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise <bclaise@cisco.com&= gt; wrote:

Dear authors,
=
 
Here is my AD review of draft-ietf-opsawg-large-flow=
-load-balancing
 
- Section =
1:
   Networks extensively use link aggregat=
ion groups (LAG) [802.1AX] and
   equal cost=
 multi-paths (ECMP) [RFC 2991] as techniques for capacity
<= pre>   scaling. For the problems addressed by this document, netw= ork traffic
   can be predominantly categori=
zed into two traffic types: long-lived
   la=
rge flows and other flows. 
 
   ...
 
 &=
nbsp; This draft describes mechanisms for optimal LAG/ECMP component link
   utilization while using hash-based techniq=
ues. The mechanisms
   comprise the followin=
g steps -- recognizing large flows in a router;
   and assigning the large flows to specific LAG/ECMP component = links or
   redistributing the small flows w=
hen a component link on the router is
   con=
gested.
 
   It is=
 useful to keep in mind that in typical use cases for this
= 
   mechanism the large flows are those that consume a=
 significant amount
   of bandwidth on a lin=
k, e.g. greater than 5% of link bandwidth.  The
&=
nbsp;  number of such flows would necessarily be fairly small, e.g. on=
 the
   order of 10's or 100's per LAG/ECMP.=
  In other words, the number of
   l=
arge flows is NOT expected to be on the order of millions of flows.
   Examples of such large flows would be IPsec =
tunnels in service
   provider backbone netw=
orks or storage backup traffic in data center
 &n=
bsp; networks.
 

3 instances of "large flows": do you mean "long-lived l= arge flows"?
If not, why do you make a distinction between long-liv= ed large flows and other flows in the first paragraph?
I eventually unde= rstood the source of confusion when I read the terminology section:
&nbs= p;   Large flow(s): long-lived large flow(s)

Either use ca= pitalized term in the Intro section (actually throughout the doc.) so that = we understand that the term is defined somewhere, or make it clear in the i= ntro that large flow(s) =3D long-lived large flow(s)

 

Yes, they are all referring to long-lived large flows.  We will chan= ge the early part of Section 1 to clarify that long-lived large flows are, = thereafter in the document, referred to as large flows.

Or replace large flow by long-lived f= low were it makes sense in the draft.

=

 

-

   This docum=
ent presents improved load distribution techniques based on
   the large flow awareness. 
Improved compared to?

 

Improved= compared to static hash-based distribution techniques that do not account = for the bandwidth of the flows.  Will reword as follows:

 

"This document presents mechanisms for improving the load distri= bution problem resulting from stateless hashing as seen in the above exampl= e."

ok

 

-
In several places, starting= with the title and abstract, you speak about mechanisms (plural).
Howev= er, looking at section 4.2, it seems that you propose a single mechanism? O= r maybe you consider 4.1, 4.2, 4.3 as different mechanisms?

<= /div>

 

The title of 4.2 is perhaps misleading an= d should just be "Operational Overview."

ok

<= div>

 Otherwise the rest of the dra= ft discusses several mechanisms (multiple choices for large flow identifica= tion, and multiple choices for rebalancing).

 

-<= o:p>

Step 3) On receiving the alert about the congested compo=
nent link,
   the operator, through a centra=
l management entity, finds the large
   flow=
s mapped to that component link and the LAG/ECMP group to which<=
/pre>
   the component link belongs.
 
   Step 4) The operator can choose to re=
balance the large flows on
   lightly loaded=
 component links of the LAG/ECMP group or redistribute
   the small flows on the congested link to other component link=
s of the
   group. The operator, through a c=
entral management entity, can choose
   one =
of the following actions:
 
=
      1) Indicate specific large flows to rebalanc=
e;
 
    =
;  2) Have the router decide the best large flows to rebalance;
 
      3=
) Have the router redistribute all the small flows on the
<= pre>   congested link to other component links in the group.= 
 

"Indicate= specific large flows to rebalance", "through a central managemen= t entity", what you describe is basically traffic engineering.
Oth= er the other hand, for 2) and 3), why do you need a central management enti= ty?

 <= /o:p>

The assumption was tha= t the router is controlled by a central management entity for the purpose o= f this function, but that is clearly not a requirement.  The text will= be modified to mention that a central management entity may be used (i.e. = not required).

Ok.

 <= o:p>

-

 

   A number of routers support sampli=
ng techniques such as sFlow [sFlow-
   v5, s=
Flow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954].
   For the purpose of large flow identification, sampling =
must be
   enabled on all of the egress port=
s in the router where such
   measurements a=
re desired.
I don't understand the sec=
ond sentence.
One way to read this is:  sampling must be enabled=
 on all of the egress ports where such measurements are desired. 
&n=
bsp;   Ok, this is an obvious statement. If the measurements are =
desired, enable them

 

Yes,

ok please clarify the text.

  

Or maybe you want to say: = sampling must be enabled on all of the egress ports where such measu= rements are desired.
    This is a false statement: if y= ou have the choice between sampling and non sampling, use non sampling meas= urements.
Or maybe you want to say: sampling must be enabled on all <= /u>of the egress ports where such measurements are desired.
  = ;  This is a false statement: if I have ECMP on 2 links, and only one = of them can't do non sampling, then we should not force
  &nbs= p; sampling on both links.
You see, I'm confused.

You miss a coup= le of key messages:
- if unsampled measurements are available, use those= .
- egress means where LAG/ECMP are enabled (this is important for the p= aragraph starting with "If egress sampling is not available, ingress s= ampling can suffice since the central management entity use")

 

We were not intending to discuss a= mix sampling and non-sampling interfaces in the same router, but this is a= reasonable point and it will be clarified (i.e. we will state that it's po= ssible to mix sampled and non sampled interfaces as long as the function of= large flow detection/identification can be performed).

 

<= blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in= 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'>


-

   If egress sampling is not available=
, ingress sampling can suffice
   since the =
central management entity used by the sampling technique
   typically has multi-node visibility and can use the samples= from an
   immediately downstream node to m=
ake measurements for egress traffic
   at th=
e local node.  
 

It's not clear if "ingress" means the ingress interf= ace of the router itself, or the ingress interface of the downstream router= .
A drawing is required.
Both options are possible:
  &n= bsp; 1. ingress interfaces on the router where LAG/ECMP is initiated
&nb= sp;       flow monitoring must be enabled on all i= ngress interfaces
        flow monitoring = must have a way to know the egress interfaces
2. ingress interfaces of t= he downstream router
        only work for= LAG or ECMP single hop
        ingress in= terfaces =3D all components from LAG/ECMP (multiple ifIndex, typically) &nb= sp;

 <= /o:p>

What we meant here was that ingres= s sampling would have to be enable on the downstream device (hence the cent= ral management entity must come into play to identify large flows).  <= o:p>

<= /div>

I still believe that a drawing = would clarify things.

<= div>

 


this entire section 4.3.3 needs some improvements

 

<= /div>


-
On one side, you wrote &quo= t;Specific algorithms for placement of large flows are out of scope of this= document.". On the other side, "The following parameters are req= uired the configuration of this feature". It seems contradictor= y.
It's unclear why you need the following parameter:

     .  Imbalance threshold: the difference betwe= en the utilization of
     &n=
bsp;  the least utilized and most utilized component links.  Expr=
essed
        as a =
percentage of link speed.
 
=
Also, does ECMP/LAG always require equivalent link speed for their componen=
ts?

The imbala= nce threshold is a measure of how much imbalance one is willing to tolerate= before taking the hit of potential packet reordering in some flows.  = Will clarify.  

&nb= sp;

Thanks for ca= tching the issue with link speed.  While in most cases speeds are cons= istent, there may be the case of composite links which combine links of dif= ferent speeds (actually permitted by 802.1AX), so we will provide a general= ized formula for the imbalance threshold which takes into account the indiv= idual speeds of each of the component links. 

= 
 
-
5.2. System Configuratio=
n and Identification Parameters
 
     .  IP address: The IP address of a spec=
ific router that the
     &nb=
sp;  feature is being configured on, or that the large flow placement<=
o:p>
        is being ap=
plied to.
 
  &nbs=
p;  .  LAG ID: Identifies the LAG. The LAG ID may be required whe=
n
        configuri=
ng this feature (to apply a specific set of large flow
        identification parameters to th=
e LAG) and will be required when
   &nb=
sp;    specifying flow placement to achieve the desired reba=
lancing.
 
   =
;  .  Component Link ID: Identifies the component link within a L=
AG.
        This is=
 required when specifying flow placement to achieve the
        desired rebalancing.
 

Nothing regarding E= CMP?

 = ;

Initially we were more foc= used on getting this done for LAG, but then we completely overlooked ECMP. =  5.2, 5.3, and 5.4 would probably benefit from a bit of clean-up as fo= llows:

 

<= /div>

Add the following to 5.2:

 

ECMP group: Identifies a particular ECMP group.

<= div>

 

ECMP nexthop: Identifies a particular nexthop within an ECMP group.=

 

<= p class=3DMsoNormal>Add the following line to the end of section 5.3.<= /o:p>

 

When using ECMP, the nexthop within an ECMP group is use= d to identify the component link for placing the large flow.

=

 

Add the following to the end of Section 5.4.

=

 

When using ECMP, the ECMP group and the corresponding Nexthops along wi= th the percentage of traffic to be assigned to each Nexthop is required. &n= bsp;Finally it is also possible that an ECMP Nexthop itself comprises a LAG= in which case both the Nexthop and the LAG Component ID would need to be s= pecified, and the weights of both the Nexthop's within the ECMP Group and t= he Component Links within the LAG would need to be adjusted.

=

Ok.

Regards, Benoit

 


-

  =
 For high speed links, the etherStatsHighCapacityTable MIB [RFC 3273]<=
/o:p>
   can be used.
 <=
/o:p>
Well, only for ethernet.

Will clarify that. 

=


EDITORIAL:
-
figure 2

OLD:

&nb=
sp;            =
     +-----------+ ->     +-----=
------+
       &nbs=
p;          |   =
;        | ->     =
;|           |=

          &nbs=
p;       |      =
;     | =3D=3D=3D>   |   &n=
bsp;       |
  =
;            &n=
bsp;   |        (1)|--------|(=
1)        |
 &=
nbsp;           &nbs=
p;    |         =
;  | ->     |     &nbs=
p;     |
    &=
nbsp;           &nbs=
p; |           | ->&nb=
sp;    |        &nbs=
p;  |
       &=
nbsp;          |  (R1)&nb=
sp;   | ->     |   (R2)  |<=
o:p>

NEW:

  &n=
bsp;            =
;   +-----------+ ->     +-----------+
         &nb=
sp;        |    &nbs=
p;      | ->     | &nb=
sp;         |
=
            &nb=
sp;     |       &nbs=
p;   | =3D=3D=3D>   |     &=
nbsp;     |
   &nbs=
p;            &=
nbsp; |        (1)|--------|(1) &nb=
sp;      |
   =
            &nb=
sp;  |           | -=
>     |       &nb=
sp;   |
      =
            | &=
nbsp;         | ->  &n=
bsp;  |           |<=
o:p>
         =
         |  (R1)  &n=
bsp;  | ->     |   (R2)  &n=
bsp; |

=  

Will fix.=

 

<= blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in= 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'>


-  The indentation in section 2 is not correct

 

<= p class=3DMsoNormal>Will fix. 


- "For tunneling protocols like GRE, VXLAN, NVGRE= , STT, etc.,"
You need to expand and provide references.=

Will provide references. &= nbsp;What do mean by expand -- just expand the acronyms (already in the acr= onym section) or something else? 

- a PBR rule
= 
Expand.

OK

-
OLD:

            =       +-----------+ ->     = +-----------+
      &nbs=
p;           |  =
;         | ->   =
  |           |=

         &nbs=
p;        |     =
;      | =3D=3D=3D>   |  &n=
bsp;        |
 =
;            &n=
bsp;    |        (1)|----=
----|(1)        |
&=
nbsp;           &nbs=
p;     |        =
;   |        |  &nbs=
p;        |
 &=
nbsp;            &nb=
sp;   |         =
;  | =3D=3D=3D>   |      &n=
bsp;    |
     =
;             |=
           | -> &=
nbsp;   |         &n=
bsp; |
        =
;          |   =
        | ->     =
|           |<=
/pre>
           =
;       |  (R1)    | ->=
;     |   (R2)  |
&=
nbsp;           &nbs=
p;     |        (2)|=
--------|(2)        |
 
NEW:
   =
            &nb=
sp;  +-----------+ ->     +-----------+
          &=
nbsp;       |     &n=
bsp;     | ->     |  &=
nbsp;        |
&nbs=
p;            &=
nbsp;    |        &n=
bsp;  | =3D=3D=3D>   |      =
;     |
    &n=
bsp;            =
; |        (1)|--------|(1)  &=
nbsp;     |
   &nbs=
p;            &=
nbsp; |           | =
       |       =
    |
    &nbs=
p;             =
|           | =3D=3D=3D&g=
t;   |          =
; |
        &n=
bsp;         |   &nb=
sp;       | ->     |&n=
bsp;          |
           &n=
bsp;      |      &nb=
sp;    | ->     |   &n=
bsp;       |
  =
;            &n=
bsp;   |  (R1)     | ->  &n=
bsp;  |   (R2)    |
&nbs=
p;            &=
nbsp;    |        (2)|---=
-----|(2)        |
=
 

Will fi= x. 

-
OLD:
The IPFIX =
information model [RFC 7011] 
NEW:
The IPFIX information model [RFC 7012]  

Will fix. 

Re= gards, Benoit

 

 

 

 

 

&= nbsp;

= --_000_C7634EB63EFD984A978DFB46EA5174F2C00372A95BHQ1EXCH01corp_-- From nobody Sun Apr 6 19:48:42 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2549F1A066A; Sun, 6 Apr 2014 19:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 SEc_GEFan6ij; Sun, 6 Apr 2014 19:48:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1571A0661; Sun, 6 Apr 2014 19:48:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140407024833.4704.68196.idtracker@ietfa.amsl.com> Date: Sun, 06 Apr 2014 19:48:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/62t8jd-WF7g4ktG9xHFrdrjcwas Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-large-flow-load-balancing-09.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 02:48:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Mechanisms for Optimizing LAG/ECMP Component Link Utilization in Networks Authors : Ram Krishnan Lucy Yong Anoop Ghanwani Ning So Bhumip Khasnabish Filename : draft-ietf-opsawg-large-flow-load-balancing-09.txt Pages : 25 Date : 2014-04-06 Abstract: Demands on networking infrastructure are growing exponentially due to bandwidth hungry applications such as rich media applications and inter-data center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal cost multi-paths as techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-large-flow-load-balancing-09 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 Mon Apr 7 05:58:18 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42A61A0702 for ; Mon, 7 Apr 2014 05:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Ysl_dmQLVeyf for ; Mon, 7 Apr 2014 05:58:11 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 34C691A0701 for ; Mon, 7 Apr 2014 05:58:07 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id hl10so3559884igb.6 for ; Mon, 07 Apr 2014 05:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=0tl7z1yLOHXEJN6a2HL1n0zko5bDcneSGLki7HWL20I=; b=W5s0un4h058YunYJKTJHHpxQRgLvO8SEN+LHxcvKWuSceCsdFkMeKpmLr+2wFnuqNN Eqyt/1bDHjkKENJUBrYZNpPJsfYIfR3kHCRqV6l55LiShRhUX0d2d/TsCKLjQa3fEhCI gC5QROpHuDJ8+Cam9Q/W2kYnE1TxzSfyDKZp+Wi49Ei0+nh4EWTuhv6F9IIr320IQkNR UVfzWYRtgHF4pgXnt4BhOA6bVHBmcWhD3xbvBl7N3JKe8v6HaRi5ERz9pOxwOJ3C6aKr bp2bd0ANSjh4pDAVyJbRbSUFkaAiuHIVEwBpV9zLVcbXoOta+WPu3dXN7gnIFyC6KkTG qgXw== X-Received: by 10.43.50.65 with SMTP id vd1mr971048icb.79.1396875481596; Mon, 07 Apr 2014 05:58:01 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-145-184.tor.primus.ca. [173.206.145.184]) by mx.google.com with ESMTPSA id vk7sm10567346igb.1.2014.04.07.05.58.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 05:58:00 -0700 (PDT) Message-ID: <5342A0D8.5070306@gmail.com> Date: Mon, 07 Apr 2014 08:58:00 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/S0KIDPoBL9cxL9CIeeMD2XJVZlo Subject: [OPSAWG] SYSLOG control MIB? (was Interest in a YANG module to manage SYSLOG?) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 12:58:17 -0000 My proposal for a Yang module for SYSLOG control (at the end of this message) drew no replies. Would people at least be interested in an SNMP MIB that allowed monitoring of the controls? What I have in mind is two tables, a basic SYSLOG control table and a rate-limited event report table. The contents of the tables would be as follows. The field names are taken from RFC 5424. Basic SYSLOG Control Table: -------------------------- Key: combination of APP-NAME (general class of logs) and MSGID (specific event type). Assigned PRI value Index into rate-limited table, or nil if not rate-limited Suppressed (TRUE/FALSE) If an event type is suppressed, the associated events are totally ignored by the log system, so the assigned PRI value is not meaningful and rate-limit value should be nil. Rate Limited Log Control Table: ------------------------------ Key: table index APP-NAME MSGID Reporting interval time units: seconds, hours, days, busy period. Reporting interval value: integer Maximum reports per reporting interval: integer Count of observed events Count of reported events Comments? Tom Taylor Message previously sent (28 March) ================================== While working on draft-ietf-behave-syslog-nat-logging, I noted a number of management requirements for SYSLOG that are really independent of the particular application being logged. These include, for example, a list of events for which the operator wants logging suppressed, or specifications for rate-limiting specific event reports. For more details see Section 6, particularly sub-section 6.1.3 of the draft cited above. Would there be any interest in implementing or deploying a YANG module to provide the necessary controls if I created one? Tom Taylor From nobody Mon Apr 7 06:27:35 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D361A0708 for ; Mon, 7 Apr 2014 06:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] 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 hq90Tda-X69L for ; Mon, 7 Apr 2014 06:27:28 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id D4C1D1A03F5 for ; Mon, 7 Apr 2014 06:27:27 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B9D3BFD3; Mon, 7 Apr 2014 15:27:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id uwq3Ujp8STxJ; Mon, 7 Apr 2014 15:27:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 7 Apr 2014 15:27:20 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E621220038; Mon, 7 Apr 2014 15:27:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14AlEq9e_OKq; Mon, 7 Apr 2014 15:27:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 324CC2002F; Mon, 7 Apr 2014 15:27:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6A84F2C2A155; Mon, 7 Apr 2014 15:27:18 +0200 (CEST) Date: Mon, 7 Apr 2014 15:27:18 +0200 From: Juergen Schoenwaelder To: Tom Taylor Message-ID: <20140407132717.GA606@elstar.local> Mail-Followup-To: Tom Taylor , "opsawg@ietf.org" References: <5342A0D8.5070306@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5342A0D8.5070306@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/ZCdDx5QWOxqWuDOH8oyGUnk7Z94 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] SYSLOG control MIB? (was Interest in a YANG module to manage SYSLOG?) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 13:27:32 -0000 Tom, I believe the problem here is that syslog configurations tend to be rather implementation specific and finding a common core will be a non-trivial exercise. Sure, some of the complexity is on relays and collectors that filter / store / fowards syslog messages based on a number of rules, so probably there is a more well scoped problem for implementations that essentially are only syslog originators. There was some MIB work [1] in the syslog working group but as far as I can tell this work did not get much traction - only some common type definitions have been published as RFC 5427. /js [1] http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17 On Mon, Apr 07, 2014 at 08:58:00AM -0400, Tom Taylor wrote: > My proposal for a Yang module for SYSLOG control (at the end of this > message) drew no replies. Would people at least be interested in an > SNMP MIB that allowed monitoring of the controls? What I have in > mind is two tables, a basic SYSLOG control table and a rate-limited > event report table. The contents of the tables would be as follows. > The field names are taken from RFC 5424. > > Basic SYSLOG Control Table: > -------------------------- > > Key: combination of APP-NAME (general class of logs) and MSGID > (specific event type). > > Assigned PRI value > > Index into rate-limited table, or nil if not rate-limited > > Suppressed (TRUE/FALSE) > > If an event type is suppressed, the associated events are totally > ignored by the log system, so the assigned PRI value is not > meaningful and rate-limit value should be nil. > > Rate Limited Log Control Table: > ------------------------------ > > Key: table index > > APP-NAME > > MSGID > > Reporting interval time units: seconds, hours, days, busy period. > > Reporting interval value: integer > > Maximum reports per reporting interval: integer > > Count of observed events > > Count of reported events > > Comments? > > Tom Taylor > > > > Message previously sent (28 March) > ================================== > > While working on draft-ietf-behave-syslog-nat-logging, I noted a > number of management requirements for SYSLOG that are really > independent of the particular application being logged. These > include, for example, a list of events for which the operator wants > logging suppressed, or specifications for rate-limiting specific > event reports. For more details see Section 6, particularly > sub-section 6.1.3 of the draft cited above. > > Would there be any interest in implementing or deploying a YANG > module to provide the necessary controls if I created one? > > Tom Taylor > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Apr 7 07:14:57 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AA41A079D for ; Mon, 7 Apr 2014 07:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 xu59H75wx6z1 for ; Mon, 7 Apr 2014 07:14:45 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D15CC1A0791 for ; Mon, 7 Apr 2014 07:14:45 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id hn18so3648382igb.5 for ; Mon, 07 Apr 2014 07:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=hMc2yGaStjJAFuwmyNxX3B1e1ZS16zN0IsP0s6SfOqU=; b=sGiThX2b1Dom2ItS4ruR39eAI44cZuyG9nDyb50Ijja6fuIG5b/fHIuMXl/B21NneP UHjmqf5LVoW7b2kHD12iE2eg7CyGmEbGstq7mQYC93nCjliuB0HsT7l2bKmnVKPRIeGV 4jFksZAmNvmyLJpMFSxgxVVsZAOGqQjls7O95GRhvU/g70N9RwqbiavMraylYuqWz48+ mR+h2FLHH1KIl8ujcvi/MD6sKDHLe2O3fzVtAz2B16B8tEvdjBK32kmPh7erQDKUMAM+ AqvULzXe81Zp2a5Sj1occEk+QzJFPZmKmYoEB9+TPVoFeTI2qOtKtH7VIMvLlJF9vGnv LlVA== X-Received: by 10.50.43.135 with SMTP id w7mr20387673igl.12.1396880080135; Mon, 07 Apr 2014 07:14:40 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-145-184.tor.primus.ca. [173.206.145.184]) by mx.google.com with ESMTPSA id l7sm29971796igv.4.2014.04.07.07.14.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 07:14:38 -0700 (PDT) Message-ID: <5342B2CE.1080303@gmail.com> Date: Mon, 07 Apr 2014 10:14:38 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "opsawg@ietf.org" , Juergen Schoenwaelder References: <5342A0D8.5070306@gmail.com> <20140407132717.GA606@elstar.local> In-Reply-To: <20140407132717.GA606@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/mwkrl7vijDjEuCo5bDNF0m3UioE Subject: Re: [OPSAWG] SYSLOG control MIB? (was Interest in a YANG module to manage SYSLOG?) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 14:14:52 -0000 We can see if any operators endorse this as a set of requirements. I did look at RFC 5427 once upon a time and was rather disappointed. Tom On 07/04/2014 9:27 AM, Juergen Schoenwaelder wrote: > Tom, > > I believe the problem here is that syslog configurations tend to be > rather implementation specific and finding a common core will be a > non-trivial exercise. Sure, some of the complexity is on relays and > collectors that filter / store / fowards syslog messages based on a > number of rules, so probably there is a more well scoped problem for > implementations that essentially are only syslog originators. > > There was some MIB work [1] in the syslog working group but as far as > I can tell this work did not get much traction - only some common type > definitions have been published as RFC 5427. > > /js > > [1] http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17 > > > On Mon, Apr 07, 2014 at 08:58:00AM -0400, Tom Taylor wrote: >> My proposal for a Yang module for SYSLOG control (at the end of this >> message) drew no replies. Would people at least be interested in an >> SNMP MIB that allowed monitoring of the controls? What I have in >> mind is two tables, a basic SYSLOG control table and a rate-limited >> event report table. The contents of the tables would be as follows. >> The field names are taken from RFC 5424. >> >> Basic SYSLOG Control Table: >> -------------------------- >> >> Key: combination of APP-NAME (general class of logs) and MSGID >> (specific event type). >> >> Assigned PRI value >> >> Index into rate-limited table, or nil if not rate-limited >> >> Suppressed (TRUE/FALSE) >> >> If an event type is suppressed, the associated events are totally >> ignored by the log system, so the assigned PRI value is not >> meaningful and rate-limit value should be nil. >> >> Rate Limited Log Control Table: >> ------------------------------ >> >> Key: table index >> >> APP-NAME >> >> MSGID >> >> Reporting interval time units: seconds, hours, days, busy period. >> >> Reporting interval value: integer >> >> Maximum reports per reporting interval: integer >> >> Count of observed events >> >> Count of reported events >> >> Comments? >> >> Tom Taylor >> ... From nobody Mon Apr 7 08:14:19 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0085D1A0453 for ; Mon, 7 Apr 2014 08:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] 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 qzQ8gmrUt71u for ; Mon, 7 Apr 2014 08:14:12 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 670BE1A0442 for ; Mon, 7 Apr 2014 08:14:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8F107A91; Mon, 7 Apr 2014 17:14:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zKgTM32YeCH5; Mon, 7 Apr 2014 17:14:06 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 7 Apr 2014 17:14:06 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17C522002F; Mon, 7 Apr 2014 17:14:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9sqvXZj2a5NM; Mon, 7 Apr 2014 17:14:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC7A02002C; Mon, 7 Apr 2014 17:14:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2A1F32C2A942; Mon, 7 Apr 2014 17:14:04 +0200 (CEST) Date: Mon, 7 Apr 2014 17:14:03 +0200 From: Juergen Schoenwaelder To: Hannes Tschofenig Message-ID: <20140407151403.GA2336@elstar.local> Mail-Followup-To: Hannes Tschofenig , opsawg@ietf.org References: <53396539.8070408@gmx.net> <20140401114108.GA73782@elstar.local> <533AB1A5.2000102@gmx.net> <20140402072701.GA76148@elstar.local> <533BC105.1040804@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533BC105.1040804@gmx.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/JvfJUvS2jeN3kGS7g9bVe_IFI1Y Cc: opsawg@ietf.org Subject: Re: [OPSAWG] IoT & Network Management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 15:14:17 -0000 On Wed, Apr 02, 2014 at 09:49:25AM +0200, Hannes Tschofenig wrote: > > Did you document that work somewhere? (an IETF draft or so?) > We published performance and resource usage numbers for our SNMP implementation and we share the code (so people can compare to it even if they run on different platforms). http://dx.doi.org/10.1109/MCOM.2012.6384464 http://dx.doi.org/10.1109/GreenCom.2012.21 http://dx.doi.org/10.1007/978-3-642-21484-4_13 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Apr 7 09:45:10 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126201A01C6 for ; Mon, 7 Apr 2014 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 eY4cjOvyrt7C for ; Mon, 7 Apr 2014 09:45:01 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id E494D1A0471 for ; Mon, 7 Apr 2014 09:45:00 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id z2so5464418wiv.0 for ; Mon, 07 Apr 2014 09:44:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=I6AFmgb6rvR5YW+Mmq9lbuzg7kc70bpOsfrNwNcvJlg=; b=J7KBCaE410YEyGA3X/krXtnuN+sPoAeUVy3Wf6XzHQL4gcUehkH2kwzuBZwYHWpacU NSYL/hgvRCH6S5UMri2Z2xgKFbfFgcpQq7xhigSSNqogh5wmyQlo5Lvf0vgKbFQvK/K1 zpRGZjCFwCUYshXZacCUdWCf6dCo2FrSEg8Y/uvMZRM2HdnjljurCqxblDi6Lk+5Vd+a 9WvDpvqnNhCv6RoX7CuhM22FIKFOnFeCg+h64f7Z7L4hIOXlQzayaBWnf//PDx7kBhiI WW5QHlUY3Z/fXgml08aJWwZgUEWBRHgFbuJXSC5TWwqqrNM/F6mkfEIo53ArT/E/XB48 hvmQ== X-Gm-Message-State: ALoCoQl14OFNBGGqYByxY8l+4LDXTPjquXmLS9INpzjdUW077ZlOXcrPpMl68O6ZclHyrqxKJtEG MIME-Version: 1.0 X-Received: by 10.194.175.70 with SMTP id by6mr43223241wjc.3.1396889094568; Mon, 07 Apr 2014 09:44:54 -0700 (PDT) Received: by 10.194.54.162 with HTTP; Mon, 7 Apr 2014 09:44:54 -0700 (PDT) X-Originating-IP: [98.244.98.35] Date: Tue, 8 Apr 2014 00:44:54 +0800 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/ZMSmShyG98TDUo_CC7QnnSGTIX8 Subject: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 16:45:06 -0000 Dear opsawg WG, The authors of draft-ietf-opsawg-capwap-hybridmac have indicated that they believe that the document is ready, and have asked for Working Group Last Call. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ Please review this draft to see if you think it is ready for publication and send comments to the list, clearly stating your view. This WGLC ends Mon 21-Apr-2014. Thanks, Warren Kumari (as opsawg WG co-chair) From nobody Mon Apr 7 10:31:52 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E111A0488 for ; Mon, 7 Apr 2014 10:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 v4kdaZhQ_IDU for ; Mon, 7 Apr 2014 10:31:46 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4423F1A07C1 for ; Mon, 7 Apr 2014 10:31:35 -0700 (PDT) Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.0.913.9; Mon, 7 Apr 2014 17:31:28 +0000 Message-ID: <028101cf5286$f923c500$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder , Tom Taylor References: <5342A0D8.5070306@gmail.com> <20140407132717.GA606@elstar.local> Date: Mon, 7 Apr 2014 15:29:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AM3PR07CA002.eurprd07.prod.outlook.com (10.242.16.42) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Forefront-PRVS: 0174BD4BDA X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(3577400?= =?iso-8859-1?Q?3)(377454003)(13464003)(199002)(189002)(51704005)(47446002?= =?iso-8859-1?Q?)(74502001)(93516002)(74662001)(92566001)(81342001)(927260?= =?iso-8859-1?Q?01)(93136001)(81542001)(74366001)(74706001)(83072002)(7487?= =?iso-8859-1?Q?6001)(85852003)(50466002)(93916002)(86362001)(90146001)(94?= =?iso-8859-1?Q?946001)(69226001)(56816005)(76786001)(94316002)(61296002)(?= =?iso-8859-1?Q?80976001)(89996001)(97336001)(76796001)(31966008)(77156001?= =?iso-8859-1?Q?)(97186001)(62966002)(59766001)(561944002)(77982001)(87976?= =?iso-8859-1?Q?001)(83322001)(19580405001)(33646001)(14496001)(87286001)(?= =?iso-8859-1?Q?87266001)(19580395003)(47776003)(20776003)(23756003)(63696?= =?iso-8859-1?Q?002)(66066001)(80022001)(65816001)(44716002)(62236002)(791?= =?iso-8859-1?Q?02001)(15975445006)(95416001)(50226001)(44736004)(99396002?= =?iso-8859-1?Q?)(88136002)(77096001)(85306002)(42186004)(51856001)(543160?= =?iso-8859-1?Q?02)(76482001)(98676001)(49866001)(47736001)(56776001)(5098?= =?iso-8859-1?Q?6001)(47976001)(84392001)(15202345003)(53806001)(46102001)?= =?iso-8859-1?Q?(4396001)(95666003)(74416001)(7726001);DIR:OUT;SFP:1101;SC?= =?iso-8859-1?Q?L:1;SRVR:DBXPR07MB064;H:AMXPRD0310HT004.eurprd03.prod.outl?= =?iso-8859-1?Q?ook.com;FPR:1CECFD7F.AFFA9FC2.33F03DBF.42E4D1D1.20465;MLV:?= =?iso-8859-1?Q?nov;PTR:InfoNoRecords;A:0;MX:1;LANG:en;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/QthD7LhEPmtOY47hJoNRDovpWGk Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SYSLOG control MIB? (was Interest in a YANG module to manage SYSLOG?) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:31:51 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Tom Taylor" Cc: Sent: Monday, April 07, 2014 2:27 PM > Tom, > > I believe the problem here is that syslog configurations tend to be > rather implementation specific and finding a common core will be a > non-trivial exercise. Sure, some of the complexity is on relays and > collectors that filter / store / fowards syslog messages based on a > number of rules, so probably there is a more well scoped problem for > implementations that essentially are only syslog originators. > > There was some MIB work [1] in the syslog working group but as far as > I can tell this work did not get much traction - only some common type > definitions have been published as RFC 5427. Tom The syslog WG was chartered to produce a MIB module and that stayed in the charter until 2008 but then got dropped - as Juergen says, there was not much enthusiasm for it. The WG was closed in 2010. Tom Petch > > /js > > [1] http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17 > > > On Mon, Apr 07, 2014 at 08:58:00AM -0400, Tom Taylor wrote: > > My proposal for a Yang module for SYSLOG control (at the end of this > > message) drew no replies. Would people at least be interested in an > > SNMP MIB that allowed monitoring of the controls? What I have in > > mind is two tables, a basic SYSLOG control table and a rate-limited > > event report table. The contents of the tables would be as follows. > > The field names are taken from RFC 5424. > > > > Basic SYSLOG Control Table: > > -------------------------- > > > > Key: combination of APP-NAME (general class of logs) and MSGID > > (specific event type). > > > > Assigned PRI value > > > > Index into rate-limited table, or nil if not rate-limited > > > > Suppressed (TRUE/FALSE) > > > > If an event type is suppressed, the associated events are totally > > ignored by the log system, so the assigned PRI value is not > > meaningful and rate-limit value should be nil. > > > > Rate Limited Log Control Table: > > ------------------------------ > > > > Key: table index > > > > APP-NAME > > > > MSGID > > > > Reporting interval time units: seconds, hours, days, busy period. > > > > Reporting interval value: integer > > > > Maximum reports per reporting interval: integer > > > > Count of observed events > > > > Count of reported events > > > > Comments? > > > > Tom Taylor > > > > > > > > Message previously sent (28 March) > > ================================== > > > > While working on draft-ietf-behave-syslog-nat-logging, I noted a > > number of management requirements for SYSLOG that are really > > independent of the particular application being logged. These > > include, for example, a list of events for which the operator wants > > logging suppressed, or specifications for rate-limiting specific > > event reports. For more details see Section 6, particularly > > sub-section 6.1.3 of the draft cited above. > > > > Would there be any interest in implementing or deploying a YANG > > module to provide the necessary controls if I created one? > > > > Tom Taylor > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Apr 7 10:41:24 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6EB1A081F for ; Mon, 7 Apr 2014 10:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 mvDU8_SFa69p for ; Mon, 7 Apr 2014 10:41:15 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5354D1A081E for ; Mon, 7 Apr 2014 10:40:41 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n12so7297737wgh.24 for ; Mon, 07 Apr 2014 10:40:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=VEFiP/SypHDDQ0NLMrgrKRPUIc46q8O0GY68LtEI4Ng=; b=i64j277yT2ci4rVVDFtmIc0urBEixU2MB8cz6Oxte0iQLDRfbwBjixdlURTcRHAS4X uljrMawlnKm/ykQer6qbC09QV2I8GjuWWB8fmAnHpbmjelP7nTPg8vXPZTigaLPUIl4B z1/2wfdDi/1AOAE/+znkFufeRSfsEF857sTMJf7ZiFLuRM1B6ZIYN03w1BkSmiIgHo51 lHkjtke0NwJhoLe3NMHPg7SxBiVLcZwKgpxyh1SmNMLZszR7rUpti7hx+2LU7NaL2Xbn /wJ5mnMfh5Idf+2sdFi/l8WpnTyT2wKElqa2YbnkhHqyrKBzj/WQwwSGJxZzEjSicpKF oYpw== X-Gm-Message-State: ALoCoQmkhyP9R+pYK7OPZzeOEROi/oOXZzqI4jf+1wT1o2GL461hGExzdLhoQkICumtth3L4xw5M MIME-Version: 1.0 X-Received: by 10.180.7.198 with SMTP id l6mr26985465wia.52.1396892434970; Mon, 07 Apr 2014 10:40:34 -0700 (PDT) Received: by 10.194.54.162 with HTTP; Mon, 7 Apr 2014 10:40:34 -0700 (PDT) X-Originating-IP: [98.244.98.35] Date: Tue, 8 Apr 2014 01:40:34 +0800 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/WCwpNBAuRwe0JhNx0BMKWTr4p8Y Subject: [OPSAWG] Update on draft-zhang-opsawg-capwap-cds (not stepping on IEEE toes). X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:41:20 -0000 Hi there all, The document draft-zhang-opsawg-capwap-cds was discussed in London, and the authors requested WG adoption. Dan (and others) noted that we work on the CAPWAP stuff with the IEEE, and should make sure that our work is not in conflict with theirs. We had some discussions with our ADs and sent a liaison type note over to IEEE folk: https://datatracker.ietf.org/liaison/1312/ The IEEE responded (around 2 weeks ago, sorry for the delay in reporting): "Subject: Alternate Tunnel Encapsulation for Data Frames in CAPWAP Thank you for the opportunity to review the "Alternate Tunnel Encapsulation for Data Frames in CAPWAP'"http://www.ietf.org/id/draft-zhang-opsawg-capwap-cds-02.txt document. The Alternate Tunnel Encapsulation draft appears to address implementation of the IEEE 802.11 Distribution System (DS). Implementation of the DS is outside the scope of the IEEE 802.11 standard. We will inform IEEE 802.11 members of this work, and welcome further requests from the OPSAWG for information or clarification of the IEEE 802.11 standard. Thank you, Bruce Kraemer (outgoing chair 802.11, March 2014) Adrian P Stephens (incoming chair 802.11, March 2014) Chair, IEEE 802.11" We will be initiating a call for adoption soon. W From nobody Mon Apr 7 10:42:19 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1111A081F for ; Mon, 7 Apr 2014 10:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 rsNvob-Op6qc for ; Mon, 7 Apr 2014 10:42:10 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id D3A901A0815 for ; Mon, 7 Apr 2014 10:41:53 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so5557399wiv.13 for ; Mon, 07 Apr 2014 10:41:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=hcQDtamabrSZAHJVATm+8ehhXM6rms9zCfI/n2z9lCk=; b=gUh9goS6sUtImbUBViUMu22CywqwB+zoZnP0bv+e5Dk6foyjzESViHhHD5L/ErGp/P 4YV3vA0lBaUdKmyPUAcfP3DbE5pqbjXDXRK/IZyZsRylv+V7js4GkXBB78ELe2Ksq6sN blJ3FN9x0SArCWKT3+rqIf3kiP5vY+UFZFoOsKFOLgSyYsPbr9c/IazGn0blzm0d/hC3 BWM61HsG5j9TEaOfMZjPerzGiyV2YZoBgcvbOE2V2jZqT8/ilwguvRnTXDHjfnIAldH4 em/ZzsaCZVfq0k4svMKKqyzLiF/4bZmtL+4WakvoVqbrZPWyOXp/p2WJ1b9nKvZmwRe6 6vQw== X-Gm-Message-State: ALoCoQkes5nBQwgu9rcx9+cXHhGwTZHOsUHFaetm8cwno0HFKjoOZuOChAYHVzVlmp5moNwLs9hK MIME-Version: 1.0 X-Received: by 10.180.37.110 with SMTP id x14mr26597874wij.52.1396892507732; Mon, 07 Apr 2014 10:41:47 -0700 (PDT) Received: by 10.194.54.162 with HTTP; Mon, 7 Apr 2014 10:41:47 -0700 (PDT) X-Originating-IP: [98.244.98.35] Date: Tue, 8 Apr 2014 01:41:47 +0800 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/C6hOJP-D0R2xd5m-l5aMJsN0DDY Subject: [OPSAWG] Reminder about IPR relating to draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:42:15 -0000 Dear opsawg WG, Be not alarmed. This email was created to satisfy RFC 6702 "Promoting Compliance with Intellectual Property Rights (IPR)" (http://tools.ietf.org/rfc/rfc6702.txt). The authors of draft-ietf-opsawg-capwap-hybridmac have asked for a Working Group Last Call. While running the Working Group Last Call, we would like to check whether any claims of Intellectual Property Rights (IPR) on the document have not yet been disclosed. Are you personally aware of any IPR that applies to draft-ietf-opsawg-capwap-hybridmac? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please reply to this email regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor. If you are on the opsawg WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79. Please do not reply unless you want to make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Thanks, Warren Kumari (as opsawg WG co-chair) From nobody Mon Apr 7 10:52:23 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7251A081D for ; Mon, 7 Apr 2014 10:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.51 X-Spam-Level: X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 QxTXB1LndOg4 for ; Mon, 7 Apr 2014 10:52:14 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6931A079D for ; Mon, 7 Apr 2014 10:52:14 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 1840128204; Mon, 7 Apr 2014 10:52:08 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 0B70618326; Mon, 7 Apr 2014 10:52:08 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP id EA0EBE004B; Mon, 7 Apr 2014 10:52:07 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP; Mon, 7 Apr 2014 10:52:07 -0700 (PDT) Date: Mon, 7 Apr 2014 10:52:07 -0700 (PDT) From: Michael MacFaden To: tom.taylor.stds@gmail.com Message-ID: <654390994.66695781.1396893127570.JavaMail.root@vmware.com> In-Reply-To: <028101cf5286$f923c500$4001a8c0@gateway.2wire.net> References: <5342A0D8.5070306@gmail.com> <20140407132717.GA606@elstar.local> <028101cf5286$f923c500$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: SYSLOG control MIB? (was Interest in a YANG module to manage SYSLOG?) Thread-Index: zHTtIyuPut1zCUHX23HHojM2Uvlw6w== Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/9_i64dOyF7p_R8teIgJ5arNcL3c Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SYSLOG control MIB? (was Interest in a YANG module to manage SYSLOG?) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:52:19 -0000 Hi Tom, I asked this question back in April 2012 on this list and as well and went as far as contacting the draft authors. Here is Glenn's reply: I'd certainly be interested in seeing a standardized monitoring mib module as its being used in industry. The use of syslog and volume of traffic apps are now sending over this protocol I believe is growing. I see syslog often used instead of or in conjunction with SNMP. > From: Glenn M. Keeni > Date: April, 11, 2012 > Subject: what happened to syslog-mib? > Hi Mike, > Thanks for the mail. > If you are going to implement the MIB, I would say it is a good candidate. > It has some nice design features which may be helpful. There > are not-nice parts too. > Feel free to let me know if I can be of any help. >Cheers, >Glenn From: Michael MacFaden Date: April 10, 2012 >Hi Mr Keeni, > >I was just looking to implement syslog-mib and its apparent >you put alot of work into http://tools.ietf.org/id/draft-ietf-syslog-device-mib-17.txt >Mike MacFaden Cheers, Mike From nobody Mon Apr 7 10:54:21 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355491A047A for ; Mon, 7 Apr 2014 10:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 NsG3_-9PDjqf for ; Mon, 7 Apr 2014 10:54:12 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8302F1A079D for ; Mon, 7 Apr 2014 10:54:05 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id l18so7232983wgh.7 for ; Mon, 07 Apr 2014 10:53:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=j3xleyWJ+IQbbshPZTqVgreo+PbCSniXQSxKvlxhonM=; b=J+GGqTeJSvtH80k+HzY8R4PM1p/kbpkLC7N+mw2GVBGGBzS0zsBpzYS8gJNe9VFgUZ sr7sCgXcF3hjsRGQ6N7hofC2FueDp8G0wYgSAuCPSvVwkZE6aKJny3cVZj9dMdNn3kAD XY8Y7x2XJcRdrsqXhhxu03Mmq3+AILfflEwomjCEn7slTDRVnuhsPXAYgvS5qDIs9QXP 7MZQsoZjukxIVClWCEXar4pyKWGMs5PrkeqO9hvu/fdCfxldI/t6QBpAGCsyCR/FkKsZ 3y1z4wXVLIKCoYmGtrrqgxmZI/eOwV8GcS4dMzFf7AjYsma0HXt9kjqDaL4LPJpySoTo m93g== X-Gm-Message-State: ALoCoQmaIg0nzCOOJMpce05jKr1PHAqPW8f46Y5uvACldrSmTjh/4qN89Y19Cq6vybgUwbhj/73M MIME-Version: 1.0 X-Received: by 10.194.242.4 with SMTP id wm4mr100610wjc.88.1396893238878; Mon, 07 Apr 2014 10:53:58 -0700 (PDT) Received: by 10.194.54.162 with HTTP; Mon, 7 Apr 2014 10:53:58 -0700 (PDT) X-Originating-IP: [98.244.98.35] Date: Tue, 8 Apr 2014 01:53:58 +0800 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , "draft-zhang-opsawg-capwap-cds@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/oWewsMKqjSQbhWCVF8DUD4avbA8 Subject: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:54:17 -0000 Dear opsawg WG, This starts a Call for Adoption for draft-zhang-opsawg-capwap-cds. The draft is available here: https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/ Please review this draft to see if you think it is suitable for adoption by opsawg, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends Mon 21-Apr-2014. Thanks, Warren Kumari (as opsawg WG co-chair) From nobody Mon Apr 7 10:55:04 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4266A1A0806 for ; Mon, 7 Apr 2014 10:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 Jps76jqv6sKQ for ; Mon, 7 Apr 2014 10:54:49 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9491A01AE for ; Mon, 7 Apr 2014 10:54:49 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u57so7019693wes.22 for ; Mon, 07 Apr 2014 10:54:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=J2RUGg1TMOjWy1ZRcsIYa4JJFZAbRFFznOArsSUpgTs=; b=lDNqSJCRCioc6mlDA/QGZRRMhrb0WuTJJBsJ6KyesITx62VGeOm2MD8eR8uvWIqT+J PbtSxDLW5c2g6SH9DpGQ8xV4QI3Fki/Q10eOzQTZP9DtTNGnwsoDN4zxKPHw3Gw3wRbj GR3mQ8ifwLf1Jv1dC+4TxMP1Swu5RZQR6iAt3zUl7VmH82esyf8LsOq/AET4txBV6aeH TrUtDesUFlf3LYfrt+LPmJe+CokS9ECshGPGwyC/+UX0Qd5j/Hi2Ek5T0XQjv9JWlaP4 P0GHIo0PZSudQGP157UdWJ8ZAI84WRAInvy78sh0y4+eDuf+8GvVqavrX6DBnFmnNVTs ywTg== X-Gm-Message-State: ALoCoQlcxoMA/+V3StjWogEIa9Ln9mC0gEEqks/HOV1llPzFjhTbR+XjMXKwahgEyISMhZ9tChbf MIME-Version: 1.0 X-Received: by 10.181.5.6 with SMTP id ci6mr5766751wid.39.1396893275463; Mon, 07 Apr 2014 10:54:35 -0700 (PDT) Received: by 10.194.54.162 with HTTP; Mon, 7 Apr 2014 10:54:35 -0700 (PDT) X-Originating-IP: [98.244.98.35] Date: Tue, 8 Apr 2014 01:54:35 +0800 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , "draft-zhang-opsawg-capwap-cds@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/SWoGSjxIXiUbHGQslZ7D3IDfUVg Subject: [OPSAWG] Reminder about IPR relating to draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:54:54 -0000 Dear opsawg WG, Be not alarmed. The authors of draft-zhang-opsawg-capwap-cds have asked for it to be adopted as a opsawg document -- we would like to check whether any claims of Intellectual Property Rights (IPR) on the document have not yet been disclosed. Are you personally aware of any IPR that applies to draft-zhang-opsawg-capwap-cds? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please reply to this email regardless of whether or not you are personally aware of any relevant IPR. If you are on the opsawg WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79. Please do not reply unless you want to make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . From nobody Tue Apr 8 00:36:03 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CD51A014B for ; Tue, 8 Apr 2014 00:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 EDZfYT7-Z_sF for ; Tue, 8 Apr 2014 00:35:57 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C66441A0143 for ; Tue, 8 Apr 2014 00:35:56 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lg15so427439vcb.2 for ; Tue, 08 Apr 2014 00:35:50 -0700 (PDT) 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=fL57qmQds0i9PGWe5ysHlbV3EynBxvEGYvfOpOzWbTk=; b=am7UP3JQQE2Le4OorqS54k6gUVQchfZwoSEvXXisdcCy8J5NT7gLpGZQyR62whMvc8 uIHt4EeRI8pL6C8ULztxvNuHm3UWBrx+7pWEFFX0dqSdhLhQt0KqL/Z9qZJkkoa30ob8 e0o3xS+i+VZaidS+YI3OVXddFLjln0do3KuxeVsyoJvIWNDHoCyWT4xPYUuibbCzqKet hRWNeJrQoHtcjNyclZJVH7S2p8oPgN/FV6L0fS2XpUVvSiP1wrY2UFiM57XBFBHzwx+n ycV5TWa1w+rI2HZqT4qk13unBwUxqmgO/IMV1YJ7GkncvbaoPRcWUHkDux5mnTkW/hIA wBgw== MIME-Version: 1.0 X-Received: by 10.58.187.78 with SMTP id fq14mr1792701vec.9.1396942550706; Tue, 08 Apr 2014 00:35:50 -0700 (PDT) Received: by 10.220.252.132 with HTTP; Tue, 8 Apr 2014 00:35:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Apr 2014 15:35:50 +0800 Message-ID: From: Hui Deng To: Warren Kumari Content-Type: multipart/alternative; boundary=047d7b6dbb6a81af9a04f68308f0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/6PsLrNLMwylaEBQmezXyvQ7tIDY Cc: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org Subject: Re: [OPSAWG] Reminder about IPR relating to draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 07:36:01 -0000 --047d7b6dbb6a81af9a04f68308f0 Content-Type: text/plain; charset=ISO-8859-1 Hello all I am not aware of any IPR about this, thanks -Hui 2014-04-08 1:41 GMT+08:00 Warren Kumari : > Dear opsawg WG, > > Be not alarmed. > This email was created to satisfy RFC 6702 "Promoting Compliance with > Intellectual Property Rights (IPR)" > (http://tools.ietf.org/rfc/rfc6702.txt). > > > The authors of draft-ietf-opsawg-capwap-hybridmac have asked for a > Working Group Last Call. While running the Working Group Last Call, we > would like to check whether any claims of Intellectual Property Rights > (IPR) on the document have not yet been disclosed. > > Are you personally aware of any IPR that applies to > draft-ietf-opsawg-capwap-hybridmac? If so, has this IPR been > disclosed in compliance with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > If you are a document author or listed contributor on this document, > please reply to this email regardless of whether or not you are > personally aware of any relevant IPR. We might not be able to advance > this document to the next stage until we have received a reply from > each author and listed contributor. > > If you are on the opsawg WG email list but are not an author or listed > contributor for this document, you are reminded of your opportunity > for a voluntary IPR disclosure under BCP 79. Please do not reply > unless you want to make such a voluntary disclosure. > > Online tools for filing IPR disclosures can be found at > . > > Thanks, > Warren Kumari > (as opsawg WG co-chair) > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --047d7b6dbb6a81af9a04f68308f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all

I am not aware of any IPR abo= ut this,
thanks

-Hui


2014-04-08 1:41 GMT+0= 8:00 Warren Kumari <warren@kumari.net>:
Dear opsawg WG,

Be not alarmed.
This email was created to satisfy RFC 6702 "Promoting Compliance with<= br> Intellectual Property Rights (IPR)"
(http:/= /tools.ietf.org/rfc/rfc6702.txt).


The authors of draft-ietf-opsawg-capwap-hybridmac have asked for a
Working Group Last Call. While running the Working Group Last Call, we
would like to check whether any claims of Intellectual Property Rights
(IPR) on the document have not yet been disclosed.

Are you personally aware of any IPR that applies to
draft-ietf-opsawg-capwap-hybridmac? =A0If so, has this IPR been
disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)

If you are a document author or listed contributor on this document,
please reply to this email regardless of whether or not you are
personally aware of any relevant IPR. =A0We might not be able to advance this document to the next stage until we have received a reply from
each author and listed contributor.

If you are on the opsawg WG email list but are not an author or listed
contributor for this document, you are reminded of your opportunity
for a voluntary IPR disclosure under BCP 79. =A0Please do not reply
unless you want to make such a voluntary disclosure.

Online tools for filing IPR disclosures can be found at
<h= ttp://www.ietf.org/ipr/file-disclosure>.

Thanks,
Warren Kumari
(as opsawg WG co-chair)

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

--047d7b6dbb6a81af9a04f68308f0-- From nobody Tue Apr 8 00:36:32 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11481A0143 for ; Tue, 8 Apr 2014 00:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 zQ9C-8YAfEfC for ; Tue, 8 Apr 2014 00:36:24 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id EAA591A014B for ; Tue, 8 Apr 2014 00:36:22 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id oy12so427007veb.26 for ; Tue, 08 Apr 2014 00:36:16 -0700 (PDT) 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=+yJJGj1YpD3qx4bjpQUNV90agXhobLA0bq+x0YRPO/k=; b=y3toBYmX/I/G9krVcrU52uySepMw9P+HgUvGmkiRb5pGoQvLuMtQz/53/0rfldQb6W gLDQsWFYJBU7pxS8FQ+f10isee5wkvDGWMIPAHbL94ambybVuCaPq+0YLX5baboqEXdf l1eAJp8eb1IbLlbxVbu4OPpEGrgQS8EQNV7OxmeJ0mCWsc8gjuYhib1T/ry1+hMLKBq8 JnV/dYcSKjLuPcbBDRCOEcY5Qv4RGYHCn1r9Mf+eDv60jGXVFhXVrwuXvDwM7JJCiZTM dBfVIJmWSrYY0dmVDvzYYu22cXFwaz70JQpDFYOGOIpvdZw27c6Y2q1YqFgmKD0JwOtG 7Raw== MIME-Version: 1.0 X-Received: by 10.52.173.165 with SMTP id bl5mr1539101vdc.13.1396942576869; Tue, 08 Apr 2014 00:36:16 -0700 (PDT) Received: by 10.220.252.132 with HTTP; Tue, 8 Apr 2014 00:36:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Apr 2014 15:36:16 +0800 Message-ID: From: Hui Deng To: Warren Kumari Content-Type: multipart/alternative; boundary=bcaec51b9cfd10e58804f6830abf Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/jZssiwDVsHbLo0wgEFTszBASCf0 Cc: "draft-zhang-opsawg-capwap-cds@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] Reminder about IPR relating to draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 07:36:28 -0000 --bcaec51b9cfd10e58804f6830abf Content-Type: text/plain; charset=ISO-8859-1 Hello all I am not aware of any IPR about this, thanks -Hui 2014-04-08 1:54 GMT+08:00 Warren Kumari : > Dear opsawg WG, > > Be not alarmed. > > The authors of draft-zhang-opsawg-capwap-cds have asked for it to be > adopted as a opsawg document -- we would like to check whether any > claims of Intellectual Property Rights (IPR) on the document have not > yet been disclosed. > > Are you personally aware of any IPR that applies to > draft-zhang-opsawg-capwap-cds? If so, has this IPR been disclosed in > compliance with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > If you are a document author or listed contributor on this document, > please reply to this email regardless of whether or not you are > personally aware of any relevant IPR. > > If you are on the opsawg WG email list but are not an author or listed > contributor for this document, you are reminded of your opportunity > for a voluntary IPR disclosure under BCP 79. Please do not reply > unless you want to make such a voluntary disclosure. > > Online tools for filing IPR disclosures can be found at > . > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --bcaec51b9cfd10e58804f6830abf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all

I am not aware of any IPR abo= ut this,
thanks

-Hui


2014-04-08 1:54 GMT+0= 8:00 Warren Kumari <warren@kumari.net>:
Dear opsawg WG,

Be not alarmed.

The authors of draft-zhang-opsawg-capwap-cds have asked for it to be
adopted as a opsawg document -- we would like to check whether any
claims of Intellectual Property Rights (IPR) on the document have not
yet been disclosed.

Are you personally aware of any IPR that applies to
draft-zhang-opsawg-capwap-cds? =A0If so, has this IPR been disclosed in
compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)

If you are a document author or listed contributor on this document,
please reply to this email regardless of whether or not you are
personally aware of any relevant IPR.

If you are on the opsawg WG email list but are not an author or listed
contributor for this document, you are reminded of your opportunity
for a voluntary IPR disclosure under BCP 79. =A0Please do not reply
unless you want to make such a voluntary disclosure.

Online tools for filing IPR disclosures can be found at
<h= ttp://www.ietf.org/ipr/file-disclosure>.

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

--bcaec51b9cfd10e58804f6830abf-- From nobody Tue Apr 8 00:45:13 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CAB1A0173 for ; Tue, 8 Apr 2014 00:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 P4q1uQQ02_CZ for ; Tue, 8 Apr 2014 00:45:06 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5711A014B for ; Tue, 8 Apr 2014 00:45:06 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so548015qcx.27 for ; Tue, 08 Apr 2014 00:45:00 -0700 (PDT) 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=1TKZsJhLcwDAOXwDUsayZ5FO6xYKDMHDLXYnT5EALzY=; b=WE8tPI7lKI+7e5l/8V87ayNcdl1d/mnW37Zxgeun4GrGve1ByAU3CpmMB5fy5ZcD6k g6T1Z/qrJenRBlF6q7r19QjB2WHiKmfgf9qSgdbMzculga02YmOy5RJlZTj4aTt1N7U1 34Jv2sk07YXY5o+7gmYec191f2ssV9KO6TtfQbyeorx+0TVd/CenuqwfGCAhh5btoCKK 1GA1ZsTwiRy8whC+HOiNbJq8EW+dJusBLxlbGXv6gtp7z/+ER6R81Qu4IGPZjbbBQMxl MZ1rFaqKoEyg9W4mniali9pd5fCxPCxVcFdwvnjC+CGd54tIHQhu3h2dWD+jutomRGNk eXjA== MIME-Version: 1.0 X-Received: by 10.140.86.168 with SMTP id p37mr2235712qgd.23.1396943100198; Tue, 08 Apr 2014 00:45:00 -0700 (PDT) Received: by 10.96.66.234 with HTTP; Tue, 8 Apr 2014 00:45:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Apr 2014 15:45:00 +0800 Message-ID: From: Zhen Cao To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/B_1q5gNJlfP-v-9voQ2idjRR52A Cc: "draft-zhang-opsawg-capwap-cds@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] Reminder about IPR relating to draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 07:45:10 -0000 Hello, Speaking as one of the listed authors, I am not aware of any IPR about this draft. Many thanks, zhen On Tue, Apr 8, 2014 at 1:54 AM, Warren Kumari wrote: > Dear opsawg WG, > > Be not alarmed. > > The authors of draft-zhang-opsawg-capwap-cds have asked for it to be > adopted as a opsawg document -- we would like to check whether any > claims of Intellectual Property Rights (IPR) on the document have not > yet been disclosed. > > Are you personally aware of any IPR that applies to > draft-zhang-opsawg-capwap-cds? If so, has this IPR been disclosed in > compliance with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > If you are a document author or listed contributor on this document, > please reply to this email regardless of whether or not you are > personally aware of any relevant IPR. > > If you are on the opsawg WG email list but are not an author or listed > contributor for this document, you are reminded of your opportunity > for a voluntary IPR disclosure under BCP 79. Please do not reply > unless you want to make such a voluntary disclosure. > > Online tools for filing IPR disclosures can be found at > . > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Apr 8 01:33:10 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12A41A0176 for ; Tue, 8 Apr 2014 01:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jCPVrS_NuiO5 for ; Tue, 8 Apr 2014 01:33:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C185A1A0178 for ; Tue, 8 Apr 2014 01:32:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFJ72163; Tue, 08 Apr 2014 08:32:52 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Apr 2014 09:31:45 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Apr 2014 09:32:44 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.47]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 8 Apr 2014 16:32:38 +0800 From: Xueli To: Warren Kumari , "opsawg@ietf.org" , "draft-zhang-opsawg-capwap-cds@tools.ietf.org" Thread-Topic: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds Thread-Index: AQHPUopqMyJQ+PXlO0Cq6QSjpN9RV5sHX+/w Date: Tue, 8 Apr 2014 08:32:37 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448F8760F@nkgeml504-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/IWRxskyTGIGaztHRAbbKXcpIjWY Subject: Re: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 08:33:04 -0000 Hello=20 According to my knowledge, I am not aware of any IPR related to this draft. Regards Li Xue >-----Original Message----- >From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari >Sent: Tuesday, April 08, 2014 1:54 AM >To: opsawg@ietf.org; draft-zhang-opsawg-capwap-cds@tools.ietf.org >Subject: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds > >Dear opsawg WG, > >This starts a Call for Adoption for draft-zhang-opsawg-capwap-cds. > >The draft is available here: >https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/ > >Please review this draft to see if you think it is suitable for >adoption by opsawg, >and comments to the list, clearly stating your view. > >Please also indicate if you are willing to contribute text, review, etc. > > >This call for adoption ends Mon 21-Apr-2014. > >Thanks, >Warren Kumari >(as opsawg WG co-chair) > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Apr 8 03:07:31 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257EF1A02C4 for ; Tue, 8 Apr 2014 03:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 cQ-vadzXJsGV for ; Tue, 8 Apr 2014 03:07:25 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0010.outbound.protection.outlook.com [213.199.154.10]) by ietfa.amsl.com (Postfix) with ESMTP id A60FD1A02BE for ; Tue, 8 Apr 2014 03:07:24 -0700 (PDT) Received: from DBXPRD0610HT003.eurprd06.prod.outlook.com (157.56.252.181) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.0.913.9; Tue, 8 Apr 2014 10:07:17 +0000 Message-ID: <018101cf5312$15a0a500$4001a8c0@gateway.2wire.net> From: t.petch To: Michael MacFaden , References: <5342A0D8.5070306@gmail.com> <20140407132717.GA606@elstar.local> <028101cf5286$f923c500$4001a8c0@gateway.2wire.net> <654390994.66695781.1396893127570.JavaMail.root@vmware.com> Date: Tue, 8 Apr 2014 10:01:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: DB3PR07CA003.eurprd07.prod.outlook.com (10.242.134.43) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Forefront-PRVS: 017589626D X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(3?= =?iso-8859-1?Q?77454003)(51914003)(52044002)(13464003)(51704005)(74662001?= =?iso-8859-1?Q?)(15202345003)(42186004)(87976001)(93136001)(44736004)(568?= =?iso-8859-1?Q?16005)(95416001)(88136002)(99396002)(93516002)(98676001)(8?= =?iso-8859-1?Q?5306002)(23756003)(31966008)(50466002)(89996001)(53806001)?= =?iso-8859-1?Q?(74502001)(47446002)(76786001)(14496001)(47976001)(4773600?= =?iso-8859-1?Q?1)(76796001)(4396001)(77096001)(49866001)(95666003)(901460?= =?iso-8859-1?Q?01)(50226001)(69226001)(77156001)(50986001)(15975445006)(5?= =?iso-8859-1?Q?9766001)(81542001)(74876001)(80022001)(47776003)(66066001)?= =?iso-8859-1?Q?(63696002)(20776003)(46102001)(79102001)(44716002)(7436600?= =?iso-8859-1?Q?1)(62236002)(94316002)(54316002)(56776001)(74706001)(83322?= =?iso-8859-1?Q?001)(33646001)(87266001)(92726001)(80976001)(81342001)(629?= =?iso-8859-1?Q?66002)(97336001)(65816001)(94946001)(84392001)(19580395003?= =?iso-8859-1?Q?)(92566001)(77982001)(85852003)(87286001)(76482001)(939160?= =?iso-8859-1?Q?02)(86362001)(83072002)(19580405001)(97186001)(61296002)(7?= =?iso-8859-1?Q?4416001)(7726001);DIR:OUT;SFP:1101;SCL:1;SRVR:AMXPR07MB055?= =?iso-8859-1?Q?;H:DBXPRD0610HT003.eurprd06.prod.outlook.com;FPR:DCF4F91C.?= =?iso-8859-1?Q?A6F284A9.F3F1BD8B.46A1DFC8.2039D;MLV:sfv;PTR:InfoNoRecords?= =?iso-8859-1?Q?;MX:1;A:0;LANG:en;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/krbeAmLb6v5LFkSi4ThXd0q81RA Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SYSLOG control MIB? (was Interest in a YANG module to manage SYSLOG?) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 10:07:30 -0000 ----- Original Message ----- From: "Michael MacFaden" To: Cc: Sent: Monday, April 07, 2014 6:52 PM > Hi Tom, > > I asked this question back in April 2012 on this list and as well and > went as far as contacting the draft authors. Here is Glenn's reply: > > I'd certainly be interested in seeing a standardized monitoring mib module > as its being used in industry. The use of syslog and volume of traffic apps > are now sending over this protocol I believe is growing. I see syslog > often used instead of or in conjunction with SNMP. Indeed, if there was one name I would associate with the syslog MIB module it would be Glenn's but there were not many more. I have long supported SNMP and so tend to notice, and get involved with, MIB modules just because they are MIB modules, even when they are not something I am likely to encounter in anger. Hence my comments on this list on draft-hmac-sha-2-usm-snmp but whereas I would expect that to advance to an RFC, I am less sanguine about the propects for a syslog MIB module - it lacks a hook to today's hot buttons such as security, yang etc. Incidentally, I notice that Tom has a gmail address and I read on the main IETF list that Yahoo has, in effect, unwittingly launched a DoS attack on mailing lists that could also impact gmail users, so I hope that we are still communicating. Tom Petch > > From: Glenn M. Keeni > > Date: April, 11, 2012 > > Subject: what happened to syslog-mib? > > Hi Mike, > > Thanks for the mail. > > If you are going to implement the MIB, I would say it is a good candidate. > > It has some nice design features which may be helpful. There > > are not-nice parts too. > > Feel free to let me know if I can be of any help. > > >Cheers, > >Glenn > > From: Michael MacFaden > Date: April 10, 2012 > >Hi Mr Keeni, > > > >I was just looking to implement syslog-mib and its apparent > >you put alot of work into http://tools.ietf.org/id/draft-ietf-syslog-device-mib-17.txt > > >Mike MacFaden > > Cheers, > Mike > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Apr 8 09:36:59 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9841A055D for ; Tue, 8 Apr 2014 09:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 IxwgWLnyS0UR for ; Tue, 8 Apr 2014 09:36:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3891A04A6 for ; Tue, 8 Apr 2014 09:36:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFK25422; Tue, 08 Apr 2014 16:36:12 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Apr 2014 17:35:10 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Apr 2014 17:36:10 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 9 Apr 2014 00:36:00 +0800 From: "Zhulei (MBB Research)" To: Xueli , Warren Kumari , "opsawg@ietf.org" , "draft-zhang-opsawg-capwap-cds@tools.ietf.org" Thread-Topic: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds Thread-Index: AQHPUopqIbykw+RIrU6fsfwa2zPkgZsG3wCAgAEMzUA= Date: Tue, 8 Apr 2014 16:35:59 +0000 Message-ID: <470F27D1263A1B4EB73491ED995DE625258C34D7@NKGEML512-MBS.china.huawei.com> References: , <01FE63842C181246BBE4CF183BD159B448F8760F@nkgeml504-mbx.china.huawei.com> In-Reply-To: <01FE63842C181246BBE4CF183BD159B448F8760F@nkgeml504-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.65.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/aKQil1zg7XrFrXUkdeKi82IaucM Subject: Re: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:36:52 -0000 Hi all, I would say that I support to adopt this draft to WG adoption. Br, Zhu Lei _ _______________________________________ >-----Original Message----- >From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari >Sent: Tuesday, April 08, 2014 1:54 AM >To: opsawg@ietf.org; draft-zhang-opsawg-capwap-cds@tools.ietf.org >Subject: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds > >Dear opsawg WG, > >This starts a Call for Adoption for draft-zhang-opsawg-capwap-cds. > >The draft is available here: >https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/ > >Please review this draft to see if you think it is suitable for >adoption by opsawg, >and comments to the list, clearly stating your view. > >Please also indicate if you are willing to contribute text, review, etc. > > >This call for adoption ends Mon 21-Apr-2014. > >Thanks, >Warren Kumari >(as opsawg WG co-chair) > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg= From nobody Tue Apr 8 14:45:05 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC2B1A0696; Tue, 8 Apr 2014 14:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 bqpKNXRj9GDR; Tue, 8 Apr 2014 14:44:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC3E1A0300; Tue, 8 Apr 2014 14:44:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140408214457.29055.76754.idtracker@ietfa.amsl.com> Date: Tue, 08 Apr 2014 14:44:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/hBqNQ5GUUex-WzDjxGf2KSmV_Ow Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-large-flow-load-balancing-10.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 21:45:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Mechanisms for Optimizing LAG/ECMP Component Link Utilization in Networks Authors : Ram Krishnan Lucy Yong Anoop Ghanwani Ning So Bhumip Khasnabish Filename : draft-ietf-opsawg-large-flow-load-balancing-10.txt Pages : 25 Date : 2014-04-08 Abstract: Demands on networking infrastructure are growing exponentially due to bandwidth hungry applications such as rich media applications and inter-data center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal cost multi-paths as techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-large-flow-load-balancing-10 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 Apr 8 16:50:51 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A85B1A02F6 for ; Tue, 8 Apr 2014 16:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, 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 dBEJyrynqyIC for ; Tue, 8 Apr 2014 16:50:45 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E1DE91A04A6 for ; Tue, 8 Apr 2014 16:50:44 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id ur14so5775255igb.14 for ; Tue, 08 Apr 2014 16:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=avQsxokVu77s+MZO/98Xh9VJKIL6T2kEu8XpTIuVAl0=; b=caeJWQ3dJiu1ZTH93w91kyqtJhyk6GXQJcwoafhWvtFStdxap+1xF0rpACEikq8f4h PQI7v4V+97cg5fzhzJQ4V+4dUk0Nv9gKr+1c5eI9oauvuBjyS0GPWrJxWFOh456/JB9K QR0Ny4doKP2uAG8114dZ4OhwqNX8OSmE3XQGLRXoH8FzuaGYRIVzKeTbc+mVt+4NslDZ dm5KBATrW1j+K6fD8/nd28CbGt3cs0rwocD6YtAQGy2l+yPic+m3hjqcZS/0vn7IqaVt cX5PTjpPk6XMwCiBCSRpcZ4AmDLUskXRFa8uk5rGC5HA1W5LbDp7EaUNXiBN91XPUOn2 AT0g== X-Received: by 10.51.15.195 with SMTP id fq3mr7252799igd.5.1397001044589; Tue, 08 Apr 2014 16:50:44 -0700 (PDT) Received: from [192.168.97.161] ([67.210.160.130]) by mx.google.com with ESMTPSA id s3sm6871291igr.14.2014.04.08.16.50.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Apr 2014 16:50:44 -0700 (PDT) Message-ID: <53448B52.4030507@gmail.com> Date: Tue, 08 Apr 2014 19:50:42 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "t.petch" , Michael MacFaden References: <5342A0D8.5070306@gmail.com> <20140407132717.GA606@elstar.local> <028101cf5286$f923c500$4001a8c0@gateway.2wire.net> <654390994.66695781.1396893127570.JavaMail.root@vmware.com> <018101cf5312$15a0a500$4001a8c0@gateway.2wire.net> In-Reply-To: <018101cf5312$15a0a500$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/NmmFCEBipcpOh_RpALVWlWQr980 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SYSLOG control MIB? (was Interest in a YANG module to manage SYSLOG?) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 23:50:48 -0000 I'm still here and following the conversation with interest, but I've had preoccupations for the last day. I was unexpectedly admitted to hospital this morning (transplanted immune system is rejecting me once again) and it took a while to get my laptop from home and get it set up. I'll read the old drafts you referred to. Maybe among us we amount to sufficient critical mass. Tom Taylor On 08/04/2014 5:01 AM, t.petch wrote: > ----- Original Message ----- > From: "Michael MacFaden" > To: > Cc: > Sent: Monday, April 07, 2014 6:52 PM >> Hi Tom, >> ... > > Incidentally, I notice that Tom has a gmail address and I read on the > main IETF list that Yahoo has, in effect, unwittingly launched a DoS > attack on mailing lists that could also impact gmail users, so I hope > that we are still communicating. > > Tom Petch > >>> From: Glenn M. Keeni >>> Date: April, 11, 2012 >>> Subject: what happened to syslog-mib? >>> Hi Mike, ... From nobody Thu Apr 10 01:50:42 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F80C1A0188 for ; Thu, 10 Apr 2014 01:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 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, MIME_CHARSET_FARAWAY=2.45, 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 I5vBUYVrZ3JL for ; Thu, 10 Apr 2014 01:50:35 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 996521A0183 for ; Thu, 10 Apr 2014 01:50:35 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id rr13so3703668pbb.15 for ; Thu, 10 Apr 2014 01:50:34 -0700 (PDT) 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=CVw+vUBzhwQRvgqQTAjy09Td+L4m1l02L4MdqBtKzRo=; b=HFsFZLjP9eMMc9kbJyA3+Ohj7FsZ5GWEV/Any2SaMxgRDw4ycPYDSTywRwKZ+4IJVV 7pdm5vWSQI1W02LOBBnUrz692Es0exA4BQ2HIzaEeJos4KXPBiEVsI72FjitFHD4foQb r6ocQT/9GX6SKO7HqLMGhDxEZI+YQk5tWBBmgDeear1aEbKUNaaxZUkJWdv+y3EtvYDc GlWuQdnCJK00H4zNBhzTgCEPqEDO2dVT75kUUX1o5i8wn416FTZveCrXNhA3J7xE/bkf F5tjQKOQ2GgpL6bj+wrWWfKNRxRoQ104K0UWlcX2nc6oRNMf/WgHyiJtBYrGvy3hv7Dq OSfw== MIME-Version: 1.0 X-Received: by 10.67.5.131 with SMTP id cm3mr18235414pad.92.1397119834868; Thu, 10 Apr 2014 01:50:34 -0700 (PDT) Received: by 10.70.124.133 with HTTP; Thu, 10 Apr 2014 01:50:34 -0700 (PDT) Received: by 10.70.124.133 with HTTP; Thu, 10 Apr 2014 01:50:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Apr 2014 16:50:34 +0800 Message-ID: From: lingli deng To: Warren Kumari Content-Type: multipart/alternative; boundary=047d7b1600b177527e04f6ac4f29 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/iI7bzivL1oZk6GeNvbuYZVJodhU Cc: draft-zhang-opsawg-capwap-cds@tools.ietf.org, opsawg@ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 08:50:40 -0000 --047d7b1600b177527e04f6ac4f29 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi all, i think this draft is ready to be adopted, and would like to offer my help in further review. lingli 2014-4-8 =C9=CF=CE=E71:54=D3=DA "Warren Kumari" =D0=B4= =B5=C0=A3=BA > Dear opsawg WG, > > This starts a Call for Adoption for draft-zhang-opsawg-capwap-cds. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/ > > Please review this draft to see if you think it is suitable for > adoption by opsawg, > and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > > This call for adoption ends Mon 21-Apr-2014. > > Thanks, > Warren Kumari > (as opsawg WG co-chair) > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --047d7b1600b177527e04f6ac4f29 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable


hi all,

i think this draft is ready to be adopted, and would like to= offer my help in further review.

lingli

2014-4-8 =C9=CF=CE=E71:54=D3=DA "Warren Kum= ari" <warren@kumari.net>= ;=D0=B4=B5=C0=A3=BA
Dear opsawg WG,

This starts a Call for Adoption for draft-zhang-opsawg-capwap-cds.

The draft is available here:
https://datatracker.ietf.org/doc/draft-zhang-opsawg-capw= ap-cds/

Please review this draft to see if you think it is suitable for
adoption by opsawg,
and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends Mon 21-Apr-2014.

Thanks,
Warren Kumari
(as opsawg WG co-chair)

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg
--047d7b1600b177527e04f6ac4f29-- From nobody Sat Apr 12 18:15:20 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF0C1A0178; Sat, 12 Apr 2014 18:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4OQtD9jbTNXx; Sat, 12 Apr 2014 18:15:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B8E1A0267; Sat, 12 Apr 2014 18:15:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140413011510.30493.3798.idtracker@ietfa.amsl.com> Date: Sat, 12 Apr 2014 18:15:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/JWj4d7Za_iitgtFcxocMErCdGsg Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-lsn-deployment-06.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 01:15:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : CGN Deployment with BGP/MPLS IP VPNs Authors : Victor Kuarsingh John Cianfarani Filename : draft-ietf-opsawg-lsn-deployment-06.txt Pages : 20 Date : 2014-04-12 Abstract: This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model which allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs which allow for virtual routing separation helping ease the CGNs impact on the network. This document does not intend to defend the merits of CGN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-lsn-deployment-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-lsn-deployment-06 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 Mon Apr 14 05:28:32 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE6B1A01CE for ; Mon, 14 Apr 2014 05:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 JtA7h-WTMKWx for ; Mon, 14 Apr 2014 05:28:25 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1F13A1A01E6 for ; Mon, 14 Apr 2014 05:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16366; q=dns/txt; s=iport; t=1397478503; x=1398688103; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=9jz8DnjXSQSixJfxt2bvHoFl8WZih5UoQAGku48I9/Y=; b=V3x9CcJvaPAp+w9aek90yW9vHrh2eVjmdl46qGk7Sz27rAtUSCBte5gm ADEhYbr3IY8idf+opY8nSy1CBFz1STdhHcMCD6m9yKJ7ZkZKlZVfiM/P1 TDt5lN08kvWgA5l/rGpwwl0T2tR/xrV20nrKiaObRb3c8KnKg/vG16ANX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EACXTS1OtJssW/2dsb2JhbABYDoMziUS6MIE7dIIlAQEBBHgBEAsYCRYIBwkDAgECATQRBg0BBQIBAYd4DcsWEwSObgeEOAEDmGGGVItvgnFCOw X-IronPort-AV: E=Sophos; i="4.97,856,1389744000"; d="scan'208,217"; a="13170235" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 14 Apr 2014 12:28:22 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3ECSLY6014303; Mon, 14 Apr 2014 12:28:21 GMT Message-ID: <534BD465.4090503@cisco.com> Date: Mon, 14 Apr 2014 14:28:21 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Anoop Ghanwani References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010902020207030602080105" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/OiLLP0rIXvfH81gqqWdfTJj9MY4 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 12:28:30 -0000 This is a multi-part message in MIME format. --------------010902020207030602080105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Anoop, Thanks for the new draft version. I removed some of the points > > > On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise > wrote: > > - > > A number of routers support sampling techniques such as sFlow [sFlow- > v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954]. > For the purpose of large flow identification, sampling must be > enabled on all of the egress ports in the router where such > measurements are desired. > > I don't understand the second sentence. > One way to read this is: sampling must be _enabled _on all of the > egress ports where such measurements are desired. > Ok, this is an obvious statement. If the measurements are > desired, enable them > > > Yes, > > Or maybe you want to say: _sampling _must be enabled on all of the > egress ports where such measurements are desired. > This is a false statement: if you have the choice between > sampling and non sampling, use non sampling measurements. > Or maybe you want to say: sampling must be enabled on _all _of the > egress ports where such measurements are desired. > This is a false statement: if I have ECMP on 2 links, and only > one of them can't do non sampling, then we should not force > sampling on both links. > You see, I'm confused. > > You miss a couple of key messages: > - if unsampled measurements are available, use those. > - egress means where LAG/ECMP are enabled (this is important for > the paragraph starting with "If egress sampling is not available, > ingress sampling can suffice since the central management entity use") > > > We were not intending to discuss a mix sampling and non-sampling > interfaces in the same router, but this is a reasonable point and it > will be clarified (i.e. we will state that it's possible to mix > sampled and non sampled interfaces as long as the function of large > flow detection/identification can be performed). You're still missing the point that unsampled measurements is better than sampled ones. Is this what you mean by: It is possible that a router may have line cards that support a sampling technique while other line cards support automatic hardware detection of large flows. It's not very clear. > > > > > > > - The indentation in section 2 is not correct > > > Will fix. > > > - "For tunneling protocols like GRE, VXLAN, NVGRE, STT, etc.," > You need to expand and provide references. > > Will provide references. Still to be provided > What do mean by expand -- just expand the acronyms (already in the > acronym section) or something else? Acceptable acronyms are https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > > - a PBR rule > Expand. > > OK to be done. Regards, Benoit --------------010902020207030602080105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Anoop,

Thanks for the new draft version.
I removed some of the points
 


On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise <bclaise@cisco.com> wrote:
- 

   A number of routers support sampling techniques such as sFlow [sFlow-
   v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954].
   For the purpose of large flow identification, sampling must be
   enabled on all of the egress ports in the router where such
   measurements are desired.
I don't understand the second sentence.
One way to read this is:  sampling must be enabled on all of the egress ports where such measurements are desired.
    Ok, this is an obvious statement. If the measurements are desired, enable them

Yes,
  
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
    This is a false statement: if you have the choice between sampling and non sampling, use non sampling measurements.
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
    This is a false statement: if I have ECMP on 2 links, and only one of them can't do non sampling, then we should not force
    sampling on both links.
You see, I'm confused.

You miss a couple of key messages:
- if unsampled measurements are available, use those.
- egress means where LAG/ECMP are enabled (this is important for the paragraph starting with "If egress sampling is not available, ingress sampling can suffice since the central management entity use")

We were not intending to discuss a mix sampling and non-sampling interfaces in the same router, but this is a reasonable point and it will be clarified (i.e. we will state that it's possible to mix sampled and non sampled interfaces as long as the function of large flow detection/identification can be performed).
You're still missing the point that unsampled measurements is better than sampled ones.

Is this what you mean by:
It is possible that a router may have line cards that support a
sampling technique while other line cards support automatic hardware
detection of large flows.
It's not very clear.






 

-  The indentation in section 2 is not correct

Will fix. 

- "For tunneling protocols like GRE, VXLAN, NVGRE, STT, etc.,"
You need to expand and provide references.

Will provide references. 
Still to be provided
What do mean by expand -- just expand the acronyms (already in the acronym section) or something else?
Acceptable acronyms are https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
- a PBR rule
Expand.
OK
to be done.

Regards, Benoit
--------------010902020207030602080105-- From nobody Mon Apr 14 10:09:19 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBC01A04C1 for ; Mon, 14 Apr 2014 10:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 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, HTML_MESSAGE=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 KQJh36yb9zju for ; Mon, 14 Apr 2014 10:09:13 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id E4D581A0564 for ; Mon, 14 Apr 2014 10:09:12 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id k14so8302432wgh.34 for ; Mon, 14 Apr 2014 10:09:10 -0700 (PDT) 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=g0ZSvCy5cdobNilP+OWBRCmvd/3pMcSwAv0xvSwtKgA=; b=ITLKfndMYAtNCLcEwI6fywM03GXImlT7IvgeD8NRPU/yb7tRd10CMjhgQDvLEFuSLZ 0x2cuOLjpbnKqG6cLQc5qjIz9hPYa22HICFHUeMjER6fvgUpzdKpdRqkFAuLUD0MDCn2 UuYT4TuskKaRS5TJV76HQpCawH1DZxqddN4NUBwxdf480RumR35ImuoeQgpJ4Y8G/EeA PIQLP+zngIF1aUYSSR4F3OketbrZWwCcNBCg4v25D+fH16+fe70MYjDTYW19MirFzg3p yKlcNskPyymu1OKY+5Mlf4mO893MA2Jv0y4krqiOgcwyEt5o05pD81dVj6B+dzKpavcm HKyg== MIME-Version: 1.0 X-Received: by 10.194.84.144 with SMTP id z16mr33908765wjy.23.1397495349835; Mon, 14 Apr 2014 10:09:09 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.73.138 with HTTP; Mon, 14 Apr 2014 10:09:09 -0700 (PDT) In-Reply-To: <534BD465.4090503@cisco.com> References: <534BD465.4090503@cisco.com> Date: Mon, 14 Apr 2014 10:09:09 -0700 X-Google-Sender-Auth: aqBcUggO-g8Byl2U5E1ruQS6LQU Message-ID: From: Anoop Ghanwani To: Benoit Claise Content-Type: multipart/alternative; boundary=089e0102ddaee6fe3e04f703bd95 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/oQKMJhlSChSZ50drXgd4zX1b_Do Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:09:17 -0000 --089e0102ddaee6fe3e04f703bd95 Content-Type: text/plain; charset=ISO-8859-1 Hi Benoit, I will work on the editorials shortly and I'm removing those from the discussion. See below: On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise wrote: > Hi Anoop, > > Thanks for the new draft version. > I removed some of the points > > > > > On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise wrote: > >> - >> >> A number of routers support sampling techniques such as sFlow [sFlow- >> v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954]. >> For the purpose of large flow identification, sampling must be >> enabled on all of the egress ports in the router where such >> measurements are desired. >> >> I don't understand the second sentence. >> One way to read this is: sampling must be * enabled *on all of the >> egress ports where such measurements are desired. >> Ok, this is an obvious statement. If the measurements are desired, >> enable them >> > > Yes, > > >> Or maybe you want to say: *sampling *must be enabled on all of the >> egress ports where such measurements are desired. >> This is a false statement: if you have the choice between sampling >> and non sampling, use non sampling measurements. >> Or maybe you want to say: sampling must be enabled on *all *of the >> egress ports where such measurements are desired. >> This is a false statement: if I have ECMP on 2 links, and only one of >> them can't do non sampling, then we should not force >> sampling on both links. >> You see, I'm confused. >> >> You miss a couple of key messages: >> - if unsampled measurements are available, use those. >> - egress means where LAG/ECMP are enabled (this is important for the >> paragraph starting with "If egress sampling is not available, ingress >> sampling can suffice since the central management entity use") >> > > We were not intending to discuss a mix sampling and non-sampling > interfaces in the same router, but this is a reasonable point and it will > be clarified (i.e. we will state that it's possible to mix sampled and non > sampled interfaces as long as the function of large flow > detection/identification can be performed). > > You're still missing the point that unsampled measurements is better than > sampled ones. > We do point this out in Section 4.3.4. http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#section-4.3.4 >>> As link speeds get higher, sampling rates are typically reduced to keep the number of samples manageable which places a lower bound on the detection time. With automatic hardware recognition, large flows can be detected in shorter windows on higher link speeds since every packet is accounted for in hardware [NDTM ]. >>> > Is this what you mean by: > > It is possible that a router may have line cards that support a > sampling technique while other line cards support automatic hardware > detection of large flows. > > It's not very clear. > > No, this does not address your point. This is talking about the case where line cards have different capabilities, rather than a line card that supports both. Since we already have the advantages and disadvantages listed in 4.3.4, do you still see a need for explicitly mentioning that automatic hardware detection is to be preferred over sampling if both are available? We did debate the point about accuracy quite a bit among the authors. The question is -- does that level of accuracy really matter for the large flow case? Since we are dealing with flows that need to consume a certain percent of the link bandwidth, sampling, if configured correctly, will catch anything that is important. Anoop --089e0102ddaee6fe3e04f703bd95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Benoit,

I will work on the editorial= s shortly and I'm removing those from the discussion. =A0 See below:


On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise <bclaise@cisco.com>= wrote:
=20 =20 =20
Hi Anoop,

Thanks for the new draft version.
I removed some of the points
=A0


On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise <bclaise@cisco.com> wrote:
- 

   A number of routers support samplin=
g techniques such as sFlow [sFlow-
   v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954].
   For the purpose of large flow identification, sampling must be
   enabled on all of the egress ports in the router where such
   measurements are desired.
I don't understand the second sentence.=
One way to read this is:=A0 sampling must be enabled on all of the egress ports where such measurements are desired.
=A0=A0=A0 Ok, this is an obvious statement.= If the measurements are desired, enable them

Yes,
=A0=A0
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
=A0=A0=A0 This is a false statement: if you have the choice between sampling and non sampling, use non sampling measurements. Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
=A0=A0=A0 This is a false statement: if I h= ave ECMP on 2 links, and only one of them can't do non sampling, then we should not force
=A0=A0=A0 sampling on both links.
You see, I'm confused.

You miss a couple of key messages:
- if unsampled measurements are available, use those.
- egress means where LAG/ECMP are enabled (this is important for the paragraph starting with "If egress sampling is not available, ingress sampling can suffice since the central management entity use")

We were not intending to discuss a mix sampling and non-sampling interfaces in the same router, but this is a reasonable point and it will be clarified (i.e. we will state that it's possible to mix sampled and non sampled interfaces as long as the function of large flow detection/identification can be performed).
You're still missing the point that unsampled measurements is bette= r than sampled ones.

We do poin= t this out in Section 4.3.4.
>>>
        As link speeds get=
 higher, sampling rates are typically reduced
        to keep the number of samples manageable which places a lower
        bound on the detection time.  With automatic hardware
        recognition, large flows can be detected in shorter windows on
        higher link speeds since every packet is accounted for in
        hardware [NDTM].
>>&= gt;


Is this what you mean by:
It is possible that a router may have line cards that support a
sampling technique while other line cards support automatic hardware
detection of large flows.
It's not very clear.


No, this does not address your point. =A0This is talking = about the case where line cards have different capabilities, rather than a = line card that supports both.

Since we already have the advantages and disadvantages = listed in 4.3.4, do you still see a need for explicitly mentioning that aut= omatic hardware detection is to be preferred over sampling if both are avai= lable?

We did debate the point about accuracy quite a bit amon= g the authors. =A0The question is -- does that level of accuracy really mat= ter for the large flow case? =A0Since we are dealing with flows that need t= o consume a certain percent of the link bandwidth, sampling, if configured = correctly, will catch anything that is important.

Anoop


--089e0102ddaee6fe3e04f703bd95-- From nobody Mon Apr 14 14:18:46 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2AA1A06E1 for ; Mon, 14 Apr 2014 14:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 jyhOKMVFsC_o for ; Mon, 14 Apr 2014 14:18:41 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 40A921A064D for ; Mon, 14 Apr 2014 14:18:41 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so4729742wib.2 for ; Mon, 14 Apr 2014 14:18:38 -0700 (PDT) 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:content-type; bh=Hp02pV8S4jZ96AkdlJfZM8QAvnoyI98fktOCw/ivfqk=; b=FI+bmg8cTX7uad/1l5v8A6QAskFqQplByyTPthAQ3TQtbWa53H5Dt1b+eIZ3PJqpxn VxAlwtt71qoj8cf+Fn+X7yovgmJTSbsipjmv9EOe1xLbmzBkP7bA8IiE3UMmDUk8kdwX eBHcJsh3yjQ/D8sVONuFMN1NREUAhWupnQ+TE5kxXOTmmkDAJ05I3Ty42YKaU2RFlFW3 NgelUXC16NPJ2HLECVSKAGUsVKJ3G1RW/YTx/oOeSV8WxZgwHZYIG89u4k+x7sOL9Eyt eOuRU7BHgx5qIMeHpKboZHx8voKWiQB6Q+YJmGtAM7VF/yXaLu9WkRe7mQ2yuEdtT1Xx 9K2g== X-Gm-Message-State: ALoCoQk4d4asNowYiOmyrKifMF0UB2jzr2erG4bovI54Lj0/kYNKQu3sWmnNLVcGwF+xWFo7AvJD MIME-Version: 1.0 X-Received: by 10.180.37.110 with SMTP id x14mr11363015wij.52.1397510318200; Mon, 14 Apr 2014 14:18:38 -0700 (PDT) Received: by 10.194.54.162 with HTTP; Mon, 14 Apr 2014 14:18:38 -0700 (PDT) X-Originating-IP: [98.244.98.35] In-Reply-To: References: Date: Mon, 14 Apr 2014 17:18:38 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , "draft-zhang-opsawg-capwap-cds@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/U-gZzIfEexu7foG5oqzlSPeTWYU Subject: Re: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:18:45 -0000 On Mon, Apr 7, 2014 at 1:53 PM, Warren Kumari wrote: > Dear opsawg WG, > > This starts a Call for Adoption for draft-zhang-opsawg-capwap-cds. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/ > > Please review this draft to see if you think it is suitable for > adoption by opsawg, > and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > > This call for adoption ends Mon 21-Apr-2014. Just a reminder -- we are 1/2 way through the Call for Adoption on this draft -- please comment if you'd like OpsAWG to adopt this document, and if you are willing to review, contribute, etc. W > > Thanks, > Warren Kumari > (as opsawg WG co-chair) From nobody Tue Apr 15 01:15:10 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FC51A03F1 for ; Tue, 15 Apr 2014 01:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 6mlaoVMvvFy6 for ; Tue, 15 Apr 2014 01:15:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9890D1A0393 for ; Tue, 15 Apr 2014 01:15:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDC68100; Tue, 15 Apr 2014 08:15:00 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 09:13:27 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 09:14:59 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.206]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 15 Apr 2014 16:14:49 +0800 From: Sheng Jiang To: "opsawg@ietf.org" , "draft-zhang-opsawg-capwap-cds@tools.ietf.org" Thread-Topic: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds Thread-Index: AQHPUoprhKliwaZyVUeb2klO7+wGBJsRIwIAgAE9FVA= Date: Tue, 15 Apr 2014 08:14:48 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE38EDC@nkgeml512-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/-wMIlCWWir3OzQwHKXWjx61lE3U Subject: Re: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 08:15:06 -0000 VGhpcyBpcyBhIHJlYWwgb3BlcmF0aW9uIHJlcXVpcmVtZW50cyBmcm9tIG9wZXJhdG9ycy4gU3Vw cG9ydCB0byBhZG9wdCB0aGlzIGRvY3VtZW50Lg0KDQpSZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBPUFNBV0cgW21haWx0bzpvcHNhd2ctYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdhcnJlbg0KPkt1bWFyaQ0KPlNlbnQ6IFR1ZXNk YXksIEFwcmlsIDE1LCAyMDE0IDU6MTkgQU0NCj5Ubzogb3BzYXdnQGlldGYub3JnOyBkcmFmdC16 aGFuZy1vcHNhd2ctY2Fwd2FwLWNkc0B0b29scy5pZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbT1BT QVdHXSBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQtemhhbmctb3BzYXdnLWNhcHdhcC1jZHMNCj4N Cj5PbiBNb24sIEFwciA3LCAyMDE0IGF0IDE6NTMgUE0sIFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBr dW1hcmkubmV0Pg0KPndyb3RlOg0KPj4gRGVhciBvcHNhd2cgV0csDQo+Pg0KPj4gVGhpcyBzdGFy dHMgYSBDYWxsIGZvciBBZG9wdGlvbiBmb3IgZHJhZnQtemhhbmctb3BzYXdnLWNhcHdhcC1jZHMu DQo+Pg0KPj4gVGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSBoZXJlOg0KPj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctb3BzYXdnLWNhcHdhcC1jZHMvDQo+Pg0KPj4g UGxlYXNlIHJldmlldyB0aGlzIGRyYWZ0IHRvIHNlZSBpZiB5b3UgdGhpbmsgaXQgaXMgc3VpdGFi bGUgZm9yDQo+PiBhZG9wdGlvbiBieSBvcHNhd2csDQo+PiBhbmQgY29tbWVudHMgdG8gdGhlIGxp c3QsIGNsZWFybHkgc3RhdGluZyB5b3VyIHZpZXcuDQo+Pg0KPj4gUGxlYXNlIGFsc28gaW5kaWNh dGUgaWYgeW91IGFyZSB3aWxsaW5nIHRvIGNvbnRyaWJ1dGUgdGV4dCwgcmV2aWV3LCBldGMuDQo+ Pg0KPj4NCj4+IFRoaXMgY2FsbCBmb3IgYWRvcHRpb24gZW5kcyBNb24gMjEtQXByLTIwMTQuDQo+ DQo+SnVzdCBhIHJlbWluZGVyIC0tIHdlIGFyZSAxLzIgd2F5IHRocm91Z2ggdGhlIENhbGwgZm9y IEFkb3B0aW9uIG9uDQo+dGhpcyBkcmFmdCAtLSBwbGVhc2UgY29tbWVudCBpZiB5b3UnZCBsaWtl IE9wc0FXRyB0byBhZG9wdCB0aGlzDQo+ZG9jdW1lbnQsIGFuZCBpZiB5b3UgYXJlIHdpbGxpbmcg dG8gcmV2aWV3LCBjb250cmlidXRlLCBldGMuDQo+DQo+Vw0KPg0KPg0KPg0KPj4NCj4+IFRoYW5r cywNCj4+IFdhcnJlbiBLdW1hcmkNCj4+IChhcyBvcHNhd2cgV0cgY28tY2hhaXIpDQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5PUFNBV0cgbWFp bGluZyBsaXN0DQo+T1BTQVdHQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vcHNhd2cNCg== From nobody Tue Apr 15 05:04:18 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4681A03D6 for ; Tue, 15 Apr 2014 05:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.873 X-Spam-Level: X-Spam-Status: No, score=-7.873 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 IolUMLlDxRyn for ; Tue, 15 Apr 2014 05:04:09 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id D09681A02BB for ; Tue, 15 Apr 2014 05:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20099; q=dns/txt; s=iport; t=1397563442; x=1398773042; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=IUvpUK3F81Rzvu+e8Ghq8J8NoZ9tjwwrabRGmzb29so=; b=auGNovm/HmsEulxeQWtFqddJk+W6eNOE9LjxCSxDz4/J4Ij5+Wrq9JTK VpivP+uh/9kHJWvJcth10VH2HfQWJonpyTc+IOjzSs6NmiLmKFNmGK8/D pD0+PNusIo+/UV/oJfjIcKEHX04vkFYYxRSWt1891TaMHIJelSurxdQwq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEANYeTVOtJssW/2dsb2JhbABYDoMzw3+BOHSCJQEBAQMBeAEQCxgJFggHCQMCAQIBNBEGDQEFAgEBh3AIDcw8F44MVweEOAEDmGKBNoUei3GCcUI7gS0 X-IronPort-AV: E=Sophos; i="4.97,863,1389744000"; d="scan'208,217"; a="13587513" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 15 Apr 2014 12:04:01 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3FC40i2002826; Tue, 15 Apr 2014 12:04:00 GMT Message-ID: <534D2030.3020809@cisco.com> Date: Tue, 15 Apr 2014 14:04:00 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Anoop Ghanwani References: <534BD465.4090503@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060700050403020900090803" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/pFPWtDsQ81C0CglBa0gxwKfZS1I Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 12:04:14 -0000 This is a multi-part message in MIME format. --------------060700050403020900090803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 14/04/2014 19:09, Anoop Ghanwani wrote: > Hi Benoit, > > I will work on the editorials shortly and I'm removing those from the > discussion. See below: > > > On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise > wrote: > > Hi Anoop, > > Thanks for the new draft version. > I removed some of the points >> >> >> On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise > > wrote: >> >> - >> >> A number of routers support sampling techniques such as sFlow [sFlow- >> v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954]. >> For the purpose of large flow identification, sampling must be >> enabled on all of the egress ports in the router where such >> measurements are desired. >> >> I don't understand the second sentence. >> One way to read this is: sampling must be _enabled _on all of >> the egress ports where such measurements are desired. >> Ok, this is an obvious statement. If the measurements are >> desired, enable them >> >> >> Yes, >> >> Or maybe you want to say: _sampling _must be enabled on all >> of the egress ports where such measurements are desired. >> This is a false statement: if you have the choice between >> sampling and non sampling, use non sampling measurements. >> Or maybe you want to say: sampling must be enabled on _all >> _of the egress ports where such measurements are desired. >> This is a false statement: if I have ECMP on 2 links, and >> only one of them can't do non sampling, then we should not force >> sampling on both links. >> You see, I'm confused. >> >> You miss a couple of key messages: >> - if unsampled measurements are available, use those. >> - egress means where LAG/ECMP are enabled (this is important >> for the paragraph starting with "If egress sampling is not >> available, ingress sampling can suffice since the central >> management entity use") >> >> >> We were not intending to discuss a mix sampling and non-sampling >> interfaces in the same router, but this is a reasonable point and >> it will be clarified (i.e. we will state that it's possible to >> mix sampled and non sampled interfaces as long as the function of >> large flow detection/identification can be performed). > You're still missing the point that unsampled measurements is > better than sampled ones. > > > We do point this out in Section 4.3.4. > http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#section-4.3.4 > >>> > As link speeds get higher, sampling rates are typically reduced > to keep the number of samples manageable which places a lower > bound on the detection time. With automatic hardware > recognition, large flows can be detected in shorter windows on > higher link speeds since every packet is accounted for in > hardware [NDTM ]. > >>> I've seen that, but why do you equate automatic _hardware _recognition to unsampled measurements. Whether it's done in hardware of software is orthogonal. > > > Is this what you mean by: > > It is possible that a router may have line cards that support a > sampling technique while other line cards support automatic hardware > detection of large flows. > > It's not very clear. > > > No, this does not address your point. This is talking about the case > where line cards have different capabilities, rather than a line card > that supports both. > > Since we already have the advantages and disadvantages listed in > 4.3.4, do you still see a need for explicitly mentioning that > automatic hardware detection is to be preferred over sampling if both > are available? > > We did debate the point about accuracy quite a bit among the authors. > The question is -- does that level of accuracy really matter for the > large flow case? Maybe not (for the details: http://dl.acm.org/citation.cfm?id=1791959), but I don't understand why you want to limit this mechanism to sampling only. Simply telling that sampled data could be good enough, but if you have unsampled data, you will get a better accuracy. > Since we are dealing with flows that need to consume a certain percent > of the link bandwidth, sampling, if configured correctly, And you don't go in the details of "sampling, if configured correctly"... Regards, B. > will catch anything that is important. > > Anoop > > --------------060700050403020900090803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 14/04/2014 19:09, Anoop Ghanwani wrote:
Hi Benoit,

I will work on the editorials shortly and I'm removing those from the discussion.   See below:


On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise <bclaise@cisco.com> wrote:
Hi Anoop,

Thanks for the new draft version.
I removed some of the points
 


On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise <bclaise@cisco.com> wrote:
- 

   A number of routers support sampling techniques such as sFlow [sFlow-
   v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954].
   For the purpose of large flow identification, sampling must be
   enabled on all of the egress ports in the router where such
   measurements are desired.
I don't understand the second sentence.
One way to read this is:  sampling must be enabled on all of the egress ports where such measurements are desired.
    Ok, this is an obvious statement. If the measurements are desired, enable them

Yes,
  
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
    This is a false statement: if you have the choice between sampling and non sampling, use non sampling measurements.
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
    This is a false statement: if I have ECMP on 2 links, and only one of them can't do non sampling, then we should not force
    sampling on both links.
You see, I'm confused.

You miss a couple of key messages:
- if unsampled measurements are available, use those.
- egress means where LAG/ECMP are enabled (this is important for the paragraph starting with "If egress sampling is not available, ingress sampling can suffice since the central management entity use")

We were not intending to discuss a mix sampling and non-sampling interfaces in the same router, but this is a reasonable point and it will be clarified (i.e. we will state that it's possible to mix sampled and non sampled interfaces as long as the function of large flow detection/identification can be performed).
You're still missing the point that unsampled measurements is better than sampled ones.

We do point this out in Section 4.3.4.
>>>
        As link speeds get higher, sampling rates are typically reduced
        to keep the number of samples manageable which places a lower
        bound on the detection time.  With automatic hardware
        recognition, large flows can be detected in shorter windows on
        higher link speeds since every packet is accounted for in
        hardware [NDTM].
>>>
I've seen that, but why do you equate automatic hardware recognition to unsampled measurements.
Whether it's done in hardware of software is orthogonal.



Is this what you mean by:
It is possible that a router may have line cards that support a
sampling technique while other line cards support automatic hardware
detection of large flows.
It's not very clear.


No, this does not address your point.  This is talking about the case where line cards have different capabilities, rather than a line card that supports both.

Since we already have the advantages and disadvantages listed in 4.3.4, do you still see a need for explicitly mentioning that automatic hardware detection is to be preferred over sampling if both are available?

We did debate the point about accuracy quite a bit among the authors.  The question is -- does that level of accuracy really matter for the large flow case?
Maybe not (for the details: http://dl.acm.org/citation.cfm?id=1791959), but I don't understand why you want to limit this mechanism to sampling only. Simply telling that sampled data could be good enough, but if you have unsampled data, you will get a better accuracy.
Since we are dealing with flows that need to consume a certain percent of the link bandwidth, sampling, if configured correctly,
And you don't go in the details of "sampling, if configured correctly"...

Regards, B.
will catch anything that is important.

Anoop



--------------060700050403020900090803-- From nobody Tue Apr 15 17:55:58 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DB01A009E for ; Tue, 15 Apr 2014 17:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 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, HTML_MESSAGE=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 ZCJ1gIrLwbze for ; Tue, 15 Apr 2014 17:55:53 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 39F201A0097 for ; Tue, 15 Apr 2014 17:55:53 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a1so10490427wgh.32 for ; Tue, 15 Apr 2014 17:55:49 -0700 (PDT) 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=+p8TNRaMPgjNvC5kaNoz0T0/566ioUqfYRjsOEpo70U=; b=WUO76VWXfrjxiXZagHZmhNPfWhaTeHxbguefxQJv0qs28XSGrblZS86bhBnua/CY/Q kHg2nnhuGo4YnfIDI7/TIOPbFMLR7YSeO7ImYedX6QG5CG574xvTuZquH0ZlbWLOXHnN msx5+nt/4B0FNz9twPUHb79hVxAt2Q9VC0Y9OfwixTeBfYrJqlyV5c/fShjxvo7B7Cgb 7eL5+VDqWSOBEO6P75APhNkgrczp105IZzSCNI9IUNt8V64w4Yfws8rTRVqtcNQkFq+n cToqr73j0x1HJJ3XC3ty7J9jWmIbHa0e9PItWBIWIFexJ+m7rMUwSSdElQikl7Qlcc0B BbtA== MIME-Version: 1.0 X-Received: by 10.180.188.66 with SMTP id fy2mr4842882wic.45.1397609749733; Tue, 15 Apr 2014 17:55:49 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.73.138 with HTTP; Tue, 15 Apr 2014 17:55:49 -0700 (PDT) In-Reply-To: <534D2030.3020809@cisco.com> References: <534BD465.4090503@cisco.com> <534D2030.3020809@cisco.com> Date: Tue, 15 Apr 2014 17:55:49 -0700 X-Google-Sender-Auth: eM4HexTurnrB8dW4BZdkrpucK2o Message-ID: From: Anoop Ghanwani To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11c383beaae75504f71e6084 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/OnguBVRdUeF1uq1ju-RSYO-MUvU Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 00:55:57 -0000 --001a11c383beaae75504f71e6084 Content-Type: text/plain; charset=ISO-8859-1 Benoit, Please see inline. On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise wrote: > On 14/04/2014 19:09, Anoop Ghanwani wrote: > > Hi Benoit, > > I will work on the editorials shortly and I'm removing those from the > discussion. See below: > > > On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise wrote: > >> Hi Anoop, >> >> Thanks for the new draft version. >> I removed some of the points >> >> >> >> >> On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise wrote: >> >>> - >>> >>> A number of routers support sampling techniques such as sFlow [sFlow- >>> v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954]. >>> For the purpose of large flow identification, sampling must be >>> enabled on all of the egress ports in the router where such >>> measurements are desired. >>> >>> I don't understand the second sentence. >>> One way to read this is: sampling must be * enabled *on all of the >>> egress ports where such measurements are desired. >>> Ok, this is an obvious statement. If the measurements are desired, >>> enable them >>> >> >> Yes, >> >> >>> Or maybe you want to say: *sampling *must be enabled on all of the >>> egress ports where such measurements are desired. >>> This is a false statement: if you have the choice between sampling >>> and non sampling, use non sampling measurements. >>> Or maybe you want to say: sampling must be enabled on *all *of the >>> egress ports where such measurements are desired. >>> This is a false statement: if I have ECMP on 2 links, and only one >>> of them can't do non sampling, then we should not force >>> sampling on both links. >>> You see, I'm confused. >>> >>> You miss a couple of key messages: >>> - if unsampled measurements are available, use those. >>> - egress means where LAG/ECMP are enabled (this is important for the >>> paragraph starting with "If egress sampling is not available, ingress >>> sampling can suffice since the central management entity use") >>> >> >> We were not intending to discuss a mix sampling and non-sampling >> interfaces in the same router, but this is a reasonable point and it will >> be clarified (i.e. we will state that it's possible to mix sampled and non >> sampled interfaces as long as the function of large flow >> detection/identification can be performed). >> >> You're still missing the point that unsampled measurements is better than >> sampled ones. >> > > We do point this out in Section 4.3.4. > > http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#section-4.3.4 > >>> > > As link speeds get higher, sampling rates are typically reduced > to keep the number of samples manageable which places a lower > bound on the detection time. With automatic hardware > recognition, large flows can be detected in shorter windows on > higher link speeds since every packet is accounted for in > hardware [NDTM ]. > > >>> > > I've seen that, but why do you equate automatic *hardware *recognition to > unsampled measurements. > Whether it's done in hardware of software is orthogonal. > > OK, I think I see the reason for the disconnect. In the draft we only talked about automatic hardware recognition and sampling as methods for large flow recognition. It seems you're suggesting there's a third way -- unsampled measurements (likely in hardware) but use of software for the actual recognition of large flows from those measurements? Can you confirm? If so, we can add that to the draft as well. > >> Is this what you mean by: >> >> It is possible that a router may have line cards that support a >> sampling technique while other line cards support automatic hardware >> detection of large flows. >> >> It's not very clear. >> >> > No, this does not address your point. This is talking about the case > where line cards have different capabilities, rather than a line card that > supports both. > > Since we already have the advantages and disadvantages listed in 4.3.4, > do you still see a need for explicitly mentioning that automatic hardware > detection is to be preferred over sampling if both are available? > > We did debate the point about accuracy quite a bit among the authors. > The question is -- does that level of accuracy really matter for the large > flow case? > > Maybe not (for the details: http://dl.acm.org/citation.cfm?id=1791959), > but I don't understand why you want to limit this mechanism to sampling > only. Simply telling that sampled data could be good enough, but if you > have unsampled data, you will get a better accuracy. > > Thanks for the reference. > Since we are dealing with flows that need to consume a certain percent > of the link bandwidth, sampling, if configured correctly, > > And you don't go in the details of "sampling, if configured correctly"... > There are suggestions in some of the references (e.g. the DevoFlow paper), but there are also other references, e.g. http://www.sflow.org/packetSamplingBasics/index.htm. This is a general sampling problem, rather than something that was introduced by this draft. If you think it would be useful to add something (or maybe just pointers to the references), that can be done. Anoop --001a11c383beaae75504f71e6084 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Benoit,

Please see inline.


On Tue, Apr 15, 2014 a= t 5:04 AM, Benoit Claise <bclaise@cisco.com> wrote:
=20 =20 =20
On 14/04/2014 19:09, Anoop Ghanwani wrote:
=20
Hi Benoit,

I will work on the editorials shortly and I'm removing those from the discussion. =A0 See below:


On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise <bclaise@cisco.com> wrote:
Hi Anoop,

Thanks for the new draft version.
I removed some of the points
=A0


On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise <bcla= ise@cisco.com> wrote:
- 

   A number of routers s=
upport sampling techniques such as sFlow [sFlow-
   v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954].
   For the purpose of large flow identification, sampling must be
   enabled on all of the egress ports in the router where such
   measurements are desired.
I don't understand the second sentence.
One way to read this is:=A0 sampling must be enabled on all of the egress ports where such measurements are desired.
=A0=A0=A0 Ok, this is an obvi= ous statement. If the measurements are desired, enable them

Yes,
=A0=A0
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
=A0=A0=A0 This is a false statement: if you have the choice between sampling and non sampling, use non sampling measurements.
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
=A0=A0=A0 This is a false statement: if I have ECMP on 2 links, and only one of them can't do non sampling, then we should not force
=A0=A0=A0 sampling on both links.
You see, I'm confused.
You miss a couple of key messages:
- if unsampled measurements are available, use those.
- egress means where LAG/ECMP are enabled (this is important for the paragraph starting with "If egress sampling is n= ot available, ingress sampling can suffice since the central management entity use")

We were not intending to discuss a mix sampling and non-sampling interfaces in the same router, but this is a reasonable point and it will be clarified (i.e. we will state that it's possible to mix sampled and non sampled interfaces as long as the function of large flow detection/identification can be performed).
You're still missing the point that unsampled measurements is better than sampled ones.

We do point this out in Section 4.3.4.
>>>
>>>
I've seen that, but why do you equate automatic hardware rec= ognition to unsampled measurements.
Whether it's done in hardware of software is orthogonal.


OK, I think I see th= e reason for the disconnect. =A0In the draft we only talked about automatic= hardware recognition and sampling as methods for large flow recognition. = =A0It seems you're suggesting there's a third way -- unsampled meas= urements (likely in hardware) but use of software for the actual recognitio= n of large flows from those measurements? =A0Can you confirm? =A0If so, we = can add that to the draft as well.
=A0
=20

Is this what you mean by:
It is possible that a router may have line cards tha=
t support a
sampling technique while other line cards support automatic hardware
detection of large flows.
It's not very clear.


No, this does not address your point. =A0This is talking about the case where line cards have different capabilities, rather than a line card that supports both.

Since we already have the advantages and disadvantages listed in 4.3.4, do you still see a need for explicitly mentioning that automatic hardware detection is to be preferred over sampling if both are available?

We did debate the point about accuracy quite a bit among the authors. =A0The question is -- does that level of accuracy really matter for the large flow case?
Maybe not (for the details: http://dl.acm.org/citation.cfm?id=3D1791959), but I don't unders= tand why you want to limit this mechanism to sampling only. Simply telling that sampled data could be good enough, but if you have unsampled data, you will get a better accuracy.


Thanks for the reference.=A0
=
Since we are dealing with flows that need to consume a certain percent of the link bandwidth, sampling, if configured correctly,
And you don't go in the details of "sampling, if configured correctly"...

There are = suggestions in some of the references (e.g. the DevoFlow paper), but there = are also other references, e.g.
http://www.sflow.org/packetSamplingBasics/in= dex.htm. =A0 This is a general sampling problem, rather than something = that was introduced by this draft. =A0If you think it would be useful to ad= d something (or maybe just pointers to the references), that can be done.

Anoop
--001a11c383beaae75504f71e6084-- From nobody Wed Apr 16 00:55:53 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61201A00F4 for ; Wed, 16 Apr 2014 00:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_45=0.6, 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 aMJlLLPAfsLy for ; Wed, 16 Apr 2014 00:55:45 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4874D1A00EC for ; Wed, 16 Apr 2014 00:55:45 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i7so12004986oag.37 for ; Wed, 16 Apr 2014 00:55:42 -0700 (PDT) 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=XTkSpgjNbQqzJM6EoRga4StGSpN+qkcPw2T7pBPy6WU=; b=SjhIkicTPXTnMlT0mNIpZkYIXE5Fj5g6T/BUYWFIc8XzZOJsZnzSOhfu3OKc6UGYzO KFm9ATa/A44JAyhsfScz1AwEYI+fwOIsYTTYb35KsdpZ3/8xSqCxZDqw1fmfDSqnblXx bKauPeUWIqHjR8fDcWn7tE5GSjl38b2QsHtclf4m4g3bXaSH91vHjG4QCx0RroNdPp1u DO5dPMpB4sI1D8vfUgBl28f7/tayySYIa0apR/iRDpzws5KJ/5899Rksfl7YaDT5kPc4 ah/UnnNs+7yzlPAg9yUEA8/LB9nkapBVzkIw5ZXNjZXOQMKAN6fsWkIZ6M0ilAIHfTTN EDhw== MIME-Version: 1.0 X-Received: by 10.60.93.168 with SMTP id cv8mr5424588oeb.21.1397634942147; Wed, 16 Apr 2014 00:55:42 -0700 (PDT) Received: by 10.76.0.108 with HTTP; Wed, 16 Apr 2014 00:55:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Apr 2014 15:55:42 +0800 Message-ID: From: Rong Zhang To: Zhen Cao Content-Type: multipart/alternative; boundary=047d7b33d3c040a08804f7243e2e Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/C8mOPgooS-9RMP0HA-nrt6bSLX0 Cc: "draft-zhang-opsawg-capwap-cds@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] Reminder about IPR relating to draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 07:55:49 -0000 --047d7b33d3c040a08804f7243e2e Content-Type: text/plain; charset=UTF-8 Hello all, My gsta(china telecom) email doesn't work out, so I resend again and conform that I am not awared of any IPR on this document Cheers. Rong Zhang On Tue, Apr 8, 2014 at 3:45 PM, Zhen Cao wrote: > Hello, > > Speaking as one of the listed authors, I am not aware of any IPR about > this draft. > > Many thanks, > zhen > > On Tue, Apr 8, 2014 at 1:54 AM, Warren Kumari wrote: > > Dear opsawg WG, > > > > Be not alarmed. > > > > The authors of draft-zhang-opsawg-capwap-cds have asked for it to be > > adopted as a opsawg document -- we would like to check whether any > > claims of Intellectual Property Rights (IPR) on the document have not > > yet been disclosed. > > > > Are you personally aware of any IPR that applies to > > draft-zhang-opsawg-capwap-cds? If so, has this IPR been disclosed in > > compliance with IETF IPR rules? > > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > > > If you are a document author or listed contributor on this document, > > please reply to this email regardless of whether or not you are > > personally aware of any relevant IPR. > > > > If you are on the opsawg WG email list but are not an author or listed > > contributor for this document, you are reminded of your opportunity > > for a voluntary IPR disclosure under BCP 79. Please do not reply > > unless you want to make such a voluntary disclosure. > > > > Online tools for filing IPR disclosures can be found at > > . > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --047d7b33d3c040a08804f7243e2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,
=C2=A0
My gsta(china telecom) email doe= sn't work out, so I resend=C2=A0again and conform that I am not awared = of any IPR on this document
=C2=A0
Cheers.
= =C2=A0
Rong Zhang

On Tue, Apr 8, 2014 at 3:45 PM, Zhen C= ao <zehn.cao@gmail.com> wrote:
Hello,

Speaking as one of the listed authors, I am not aware of any IPR about
this draft.

Many thanks,
zhen

On Tue, Apr 8, 2014 at 1:54 AM, Warren Kumari <warren@kumari.net> wrote:
> Dear opsawg WG,
>
> Be not alarmed.
>
> The authors of draft-zhang-opsawg-capwap-cds have asked for it to be > adopted as a opsawg document -- we would like to check whether any
> claims of Intellectual Property Rights (IPR) on the document have not<= br> > yet been disclosed.
>
> Are you personally aware of any IPR that applies to
> draft-zhang-opsawg-capwap-cds? =C2=A0If so, has this IPR been disclose= d in
> compliance with IETF IPR rules?
> (See RFCs 3979, 4879, 3669, and 5378 for more details.)
>
> If you are a document author or listed contributor on this document, > please reply to this email regardless of whether or not you are
> personally aware of any relevant IPR.
>
> If you are on the opsawg WG email list but are not an author or listed=
> contributor for this document, you are reminded of your opportunity > for a voluntary IPR disclosure under BCP 79. =C2=A0Please do not reply=
> unless you want to make such a voluntary disclosure.
>
> Online tools for filing IPR disclosures can be found at
> <http://www.ietf.org/ipr/file-disclosure>.
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

--047d7b33d3c040a08804f7243e2e-- From nobody Wed Apr 16 00:57:02 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6751A0087 for ; Wed, 16 Apr 2014 00:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, 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 Hylu1b04e1BQ for ; Wed, 16 Apr 2014 00:56:56 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 05B801A00E4 for ; Wed, 16 Apr 2014 00:56:55 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id i4so11954309oah.24 for ; Wed, 16 Apr 2014 00:56:52 -0700 (PDT) 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=Vc50t5fPhcIzzbTdiv7jqSdCt1v7Qa5dMIktku4dAMc=; b=oGPWIeJ7qOEsv8ExFEbKBEyPQVLvjjCReM4srtcHHjdUSAMCfOBpPcpxHHEO9Zxsck ZIpBMbBoh8oaes1pWqJfWnPQKDucNyBSbN1rM9dfoQaqiuBAbDqwtbeGVEyOhx3U/LZJ cmmsElSRppbA4qN1w/nFPGj0wRp8atEWTX02qyUfXExQzFuBf/QKQbDFT1udwJKkiRFm UoFLF+YXP174+o+e4/PRIFPKAOM+WEEPC1JltA5vhHAt2+KxpTch9REzTELTTM8CNHbw znUOO+iemjGeDKpCzbK9ROGWrECREL9w9J8C1eV2yzGnmThZpj/0zlV+XoaDd/z8pK84 LX8A== MIME-Version: 1.0 X-Received: by 10.182.55.65 with SMTP id q1mr184560obp.70.1397635012887; Wed, 16 Apr 2014 00:56:52 -0700 (PDT) Received: by 10.76.0.108 with HTTP; Wed, 16 Apr 2014 00:56:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Apr 2014 15:56:52 +0800 Message-ID: From: Rong Zhang To: Hui Deng Content-Type: multipart/alternative; boundary=089e0153884878116e04f7244207 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/zMZNANxSJjeRDOy6ET8JSG493Vs Cc: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org Subject: Re: [OPSAWG] Reminder about IPR relating to draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 07:56:58 -0000 --089e0153884878116e04f7244207 Content-Type: text/plain; charset=UTF-8 Hello all, My gsta(china telecom) email doesn't work out as well, so I resend again and conform that I am not awared of any IPR on this document Cheers. Rong Zhang On Tue, Apr 8, 2014 at 3:35 PM, Hui Deng wrote: > Hello all > > I am not aware of any IPR about this, > thanks > > -Hui > > > 2014-04-08 1:41 GMT+08:00 Warren Kumari : > > Dear opsawg WG, >> >> Be not alarmed. >> This email was created to satisfy RFC 6702 "Promoting Compliance with >> Intellectual Property Rights (IPR)" >> (http://tools.ietf.org/rfc/rfc6702.txt). >> >> >> The authors of draft-ietf-opsawg-capwap-hybridmac have asked for a >> Working Group Last Call. While running the Working Group Last Call, we >> would like to check whether any claims of Intellectual Property Rights >> (IPR) on the document have not yet been disclosed. >> >> Are you personally aware of any IPR that applies to >> draft-ietf-opsawg-capwap-hybridmac? If so, has this IPR been >> disclosed in compliance with IETF IPR rules? >> (See RFCs 3979, 4879, 3669, and 5378 for more details.) >> >> If you are a document author or listed contributor on this document, >> please reply to this email regardless of whether or not you are >> personally aware of any relevant IPR. We might not be able to advance >> this document to the next stage until we have received a reply from >> each author and listed contributor. >> >> If you are on the opsawg WG email list but are not an author or listed >> contributor for this document, you are reminded of your opportunity >> for a voluntary IPR disclosure under BCP 79. Please do not reply >> unless you want to make such a voluntary disclosure. >> >> Online tools for filing IPR disclosures can be found at >> . >> >> Thanks, >> Warren Kumari >> (as opsawg WG co-chair) >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > --089e0153884878116e04f7244207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello all,<= /p>

=C2=A0

<= font size=3D"3" face=3D"=E5=AE=8B=E4=BD=93">

My gsta(china telecom) em= ail doesn't work out as well, so I resend=C2=A0again and conform that I am not awared of any= IPR on this document

=C2=A0

<= font size=3D"3" face=3D"=E5=AE=8B=E4=BD=93">

Cheers.

=

=C2=A0

<= font size=3D"3" face=3D"=E5=AE=8B=E4=BD=93">

Rong Zhang=



On Tue, Apr 8, 2014 at 3:35 PM, H= ui Deng <denghui02@gmail.com> wrote:
Hello all

I am not aware of any IPR abo= ut this,
thanks

-Hui


2014-04-08 1:41 GMT+0= 8:00 Warren Kumari <warren@kumari.net>:

Dear opsawg WG,

Be not alarmed.
This email was created to satisfy RFC 6702 "Promoting Compliance with<= br> Intellectual Property Rights (IPR)"
(http:/= /tools.ietf.org/rfc/rfc6702.txt).


The authors of draft-ietf-opsawg-capwap-hybridmac have asked for a
Working Group Last Call. While running the Working Group Last Call, we
would like to check whether any claims of Intellectual Property Rights
(IPR) on the document have not yet been disclosed.

Are you personally aware of any IPR that applies to
draft-ietf-opsawg-capwap-hybridmac? =C2=A0If so, has this IPR been
disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)

If you are a document author or listed contributor on this document,
please reply to this email regardless of whether or not you are
personally aware of any relevant IPR. =C2=A0We might not be able to advance=
this document to the next stage until we have received a reply from
each author and listed contributor.

If you are on the opsawg WG email list but are not an author or listed
contributor for this document, you are reminded of your opportunity
for a voluntary IPR disclosure under BCP 79. =C2=A0Please do not reply
unless you want to make such a voluntary disclosure.

Online tools for filing IPR disclosures can be found at
<h= ttp://www.ietf.org/ipr/file-disclosure>.

Thanks,
Warren Kumari
(as opsawg WG co-chair)

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org = https://www.ietf.org/mailman/listinfo/opsawg


_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg


--089e0153884878116e04f7244207-- From nobody Wed Apr 16 01:08:37 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5070A1A0095 for ; Wed, 16 Apr 2014 01:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 nRRVuwFz11Rg for ; Wed, 16 Apr 2014 01:08:27 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 42C7D1A0087 for ; Wed, 16 Apr 2014 01:08:27 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id i8so11664061qcq.3 for ; Wed, 16 Apr 2014 01:08:24 -0700 (PDT) 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=KBEwwT/X1K3crNFduzRJinauhzMQckuJpq+RBR7YffE=; b=QJEc96VuowQM4LOvUGItwkuuS8xnBp8zTOjN/3yUB7Z6wleKzXScHl848ukxYpB+8d FpdV2YdPDgBEueWNOdM1xv+BwIo+FFSA688+pbf5LpTZU1gsbI7zkVaXGF4Grckmwvy2 iCjzhGyXV0GPNq01Nf3L8/yLIElfKb2z+ZMLot4tWpijz3YIWM8rHGS4z0dEb5gzWHv3 s7zmkcGGaQ6LcLboV6eR1ifUtALsqIEZ9U5F2N12u7hSS4aKKrH1xdFb6BoREc9Ck/h9 qJJdx6rZLJTZ6kgSYsZtPI8LXOMVatMwTUZ6GPtfiDlRoOxSHZnff/MAzrUSdoURuonu ApPw== MIME-Version: 1.0 X-Received: by 10.229.216.72 with SMTP id hh8mr1077621qcb.9.1397635704056; Wed, 16 Apr 2014 01:08:24 -0700 (PDT) Received: by 10.96.66.234 with HTTP; Wed, 16 Apr 2014 01:08:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Apr 2014 16:08:23 +0800 Message-ID: From: Zhen Cao To: Warren Kumari Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/zWkb-prEEAqUnl_E1C7xTK2Un20 Cc: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 08:08:32 -0000 Dear ALL, I think this draft is ready for WGLC. Some editorial comments: 1. In abstract and the last paragraph of section 1, there is a typo. 'unambigous --> unambiguous 2. In the line before Figure 3, 'rofile' must be 'profile' Best regards, zhen On Tue, Apr 8, 2014 at 12:44 AM, Warren Kumari wrote: > Dear opsawg WG, > > The authors of draft-ietf-opsawg-capwap-hybridmac have indicated that > they believe that the document is ready, and have asked for Working > Group Last Call. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ > > Please review this draft to see if you think it is ready for publication > and send comments to the list, clearly stating your view. > > This WGLC ends Mon 21-Apr-2014. > > Thanks, > Warren Kumari > (as opsawg WG co-chair) > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Apr 16 01:53:38 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30DB1A0041 for ; Wed, 16 Apr 2014 01:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 84k7tViODAr8 for ; Wed, 16 Apr 2014 01:53:31 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 854EE1A0022 for ; Wed, 16 Apr 2014 01:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32477; q=dns/txt; s=iport; t=1397638407; x=1398848007; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=u1HnS0/8VimmdT3z5VnHE8d4b4GdkHpG8GjhI+BHNAI=; b=YDPWvbW24aduCuWvZdTzUekxiEpnuHxLLUdNw/MhsLjBSohS6rMVtaA/ P9K9WziXQJlgjemW4tkT7JirZBSp1Z/86V5kBiDzcdGdHjXgpCOTKbxg1 4vjWmEJdwpvOhYDSqx6Hn6hR4Qpat7nzpUzpU/m060ZR72RZXJFHKyXob k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAAlETlOQ/khN/2dsb2JhbABZDoJ4O8QHgR4WdIIlAQEBBHgBEAsYCRYBAQYHCQMCAQIBNBEGDQEFAgEBBYdzDccLF44LVweEOASYZoE3hR+Lc4JxQjuBLQ X-IronPort-AV: E=Sophos; i="4.97,870,1389744000"; d="scan'208,217"; a="19017248" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 16 Apr 2014 08:53:25 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3G8rPNC009566; Wed, 16 Apr 2014 08:53:25 GMT Message-ID: <534E4505.9080806@cisco.com> Date: Wed, 16 Apr 2014 10:53:25 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Anoop Ghanwani References: <534BD465.4090503@cisco.com> <534D2030.3020809@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070904090700080802080408" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/xIg3WC9s9PTslTkyhMqQrw8KHZI Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 08:53:36 -0000 This is a multi-part message in MIME format. --------------070904090700080802080408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Anoop, > Benoit, > > Please see inline. > > > On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise > wrote: > > On 14/04/2014 19:09, Anoop Ghanwani wrote: >> Hi Benoit, >> >> I will work on the editorials shortly and I'm removing those from >> the discussion. See below: >> >> >> On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise > > wrote: >> >> Hi Anoop, >> >> Thanks for the new draft version. >> I removed some of the points >>> >>> >>> On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise >>> > wrote: >>> >>> - >>> >>> A number of routers support sampling techniques such as sFlow [sFlow- >>> v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954]. >>> For the purpose of large flow identification, sampling must be >>> enabled on all of the egress ports in the router where such >>> measurements are desired. >>> >>> I don't understand the second sentence. >>> One way to read this is: sampling must be _enabled _on >>> all of the egress ports where such measurements are >>> desired. >>> Ok, this is an obvious statement. If the >>> measurements are desired, enable them >>> >>> >>> Yes, >>> >>> Or maybe you want to say: _sampling _must be enabled on >>> all of the egress ports where such measurements are >>> desired. >>> This is a false statement: if you have the choice >>> between sampling and non sampling, use non sampling >>> measurements. >>> Or maybe you want to say: sampling must be enabled on >>> _all _of the egress ports where such measurements are >>> desired. >>> This is a false statement: if I have ECMP on 2 >>> links, and only one of them can't do non sampling, then >>> we should not force >>> sampling on both links. >>> You see, I'm confused. >>> >>> You miss a couple of key messages: >>> - if unsampled measurements are available, use those. >>> - egress means where LAG/ECMP are enabled (this is >>> important for the paragraph starting with "If egress >>> sampling is not available, ingress sampling can suffice >>> since the central management entity use") >>> >>> >>> We were not intending to discuss a mix sampling and >>> non-sampling interfaces in the same router, but this is a >>> reasonable point and it will be clarified (i.e. we will >>> state that it's possible to mix sampled and non sampled >>> interfaces as long as the function of large flow >>> detection/identification can be performed). >> You're still missing the point that unsampled measurements is >> better than sampled ones. >> >> >> We do point this out in Section 4.3.4. >> http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#section-4.3.4 >> >>> >> As link speeds get higher, sampling rates are typically reduced >> to keep the number of samples manageable which places a lower >> bound on the detection time. With automatic hardware >> recognition, large flows can be detected in shorter windows on >> higher link speeds since every packet is accounted for in >> hardware [NDTM ]. >> >>> > I've seen that, but why do you equate automatic _hardware > _recognition to unsampled measurements. > Whether it's done in hardware of software is orthogonal. > > > OK, I think I see the reason for the disconnect. In the draft we only > talked about automatic hardware recognition and sampling as methods > for large flow recognition. It seems you're suggesting there's a > third way -- unsampled measurements (likely in hardware) but use of > software for the actual recognition of large flows from those > measurements? Can you confirm? If so, we can add that to the draft > as well. I see two only ways: sampled and unsampled. Both could be done in hardware (most likely on router; This is what you called automatic hardware recognition, AFAICT) or software. Whether it's done in hardware of software is orthogonal to the mechanism in this document. I hope this clarifies Regards, Benoit > >> >> Is this what you mean by: >> >> It is possible that a router may have line cards that support a >> sampling technique while other line cards support automatic hardware >> detection of large flows. >> >> It's not very clear. >> >> >> No, this does not address your point. This is talking about the >> case where line cards have different capabilities, rather than a >> line card that supports both. >> >> Since we already have the advantages and disadvantages listed in >> 4.3.4, do you still see a need for explicitly mentioning that >> automatic hardware detection is to be preferred over sampling if >> both are available? >> >> We did debate the point about accuracy quite a bit among the >> authors. The question is -- does that level of accuracy really >> matter for the large flow case? > Maybe not (for the details: > http://dl.acm.org/citation.cfm?id=1791959), but I don't understand > why you want to limit this mechanism to sampling only. Simply > telling that sampled data could be good enough, but if you have > unsampled data, you will get a better accuracy. > > > Thanks for the reference. > >> Since we are dealing with flows that need to consume a certain >> percent of the link bandwidth, sampling, if configured correctly, > And you don't go in the details of "sampling, if configured > correctly"... > > > There are suggestions in some of the references (e.g. the DevoFlow > paper), but there are also other references, e.g. > http://www.sflow.org/packetSamplingBasics/index.htm. This is a > general sampling problem, rather than something that was introduced by > this draft. If you think it would be useful to add something (or > maybe just pointers to the references), that can be done. > > Anoop --------------070904090700080802080408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Anoop,
Benoit,

Please see inline.


On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise <bclaise@cisco.com> wrote:
On 14/04/2014 19:09, Anoop Ghanwani wrote:
Hi Benoit,

I will work on the editorials shortly and I'm removing those from the discussion.   See below:


On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise <bclaise@cisco.com> wrote:
Hi Anoop,

Thanks for the new draft version.
I removed some of the points
 


On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise <bclaise@cisco.com> wrote:
- 

   A number of routers support sampling techniques such as sFlow [sFlow-
   v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954].
   For the purpose of large flow identification, sampling must be
   enabled on all of the egress ports in the router where such
   measurements are desired.
I don't understand the second sentence.
One way to read this is:  sampling must be enabled on all of the egress ports where such measurements are desired.
    Ok, this is an obvious statement. If the measurements are desired, enable them

Yes,
  
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
    This is a false statement: if you have the choice between sampling and non sampling, use non sampling measurements.
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
    This is a false statement: if I have ECMP on 2 links, and only one of them can't do non sampling, then we should not force
    sampling on both links.
You see, I'm confused.

You miss a couple of key messages:
- if unsampled measurements are available, use those.
- egress means where LAG/ECMP are enabled (this is important for the paragraph starting with "If egress sampling is not available, ingress sampling can suffice since the central management entity use")

We were not intending to discuss a mix sampling and non-sampling interfaces in the same router, but this is a reasonable point and it will be clarified (i.e. we will state that it's possible to mix sampled and non sampled interfaces as long as the function of large flow detection/identification can be performed).
You're still missing the point that unsampled measurements is better than sampled ones.

We do point this out in Section 4.3.4.
>>>
        As link speeds get higher, sampling rates are typically reduced
        to keep the number of samples manageable which places a lower
        bound on the detection time.  With automatic hardware
        recognition, large flows can be detected in shorter windows on
        higher link speeds since every packet is accounted for in
        hardware [NDTM].
>>>
I've seen that, but why do you equate automatic hardware recognition to unsampled measurements.
Whether it's done in hardware of software is orthogonal.


OK, I think I see the reason for the disconnect.  In the draft we only talked about automatic hardware recognition and sampling as methods for large flow recognition.  It seems you're suggesting there's a third way -- unsampled measurements (likely in hardware) but use of software for the actual recognition of large flows from those measurements?  Can you confirm?  If so, we can add that to the draft as well.
I see two only ways: sampled and unsampled.
Both could be done in hardware (most likely on router; This is what you called automatic hardware recognition, AFAICT) or software.
Whether it's done in hardware of software is orthogonal to the mechanism in this document.

I hope this clarifies

Regards, Benoit
 

Is this what you mean by:
It is possible that a router may have line cards that support a
sampling technique while other line cards support automatic hardware
detection of large flows.
It's not very clear.


No, this does not address your point.  This is talking about the case where line cards have different capabilities, rather than a line card that supports both.

Since we already have the advantages and disadvantages listed in 4.3.4, do you still see a need for explicitly mentioning that automatic hardware detection is to be preferred over sampling if both are available?

We did debate the point about accuracy quite a bit among the authors.  The question is -- does that level of accuracy really matter for the large flow case?
Maybe not (for the details: http://dl.acm.org/citation.cfm?id=1791959), but I don't understand why you want to limit this mechanism to sampling only. Simply telling that sampled data could be good enough, but if you have unsampled data, you will get a better accuracy.


Thanks for the reference. 
Since we are dealing with flows that need to consume a certain percent of the link bandwidth, sampling, if configured correctly,
And you don't go in the details of "sampling, if configured correctly"...

There are suggestions in some of the references (e.g. the DevoFlow paper), but there are also other references, e.g.
http://www.sflow.org/packetSamplingBasics/index.htm.   This is a general sampling problem, rather than something that was introduced by this draft.  If you think it would be useful to add something (or maybe just pointers to the references), that can be done.

Anoop

--------------070904090700080802080408-- From nobody Wed Apr 16 02:38:50 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C797F1A0102 for ; Wed, 16 Apr 2014 01:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 RLD0g2MyZD3I for ; Wed, 16 Apr 2014 01:05:14 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with SMTP id D73E21A00E6 for ; Wed, 16 Apr 2014 01:05:13 -0700 (PDT) Received: from mail-oa0-f51.google.com ([209.85.219.51]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKU045tuYRjxeQmfbWiJfAPE8V6hy2nEiH@postini.com; Wed, 16 Apr 2014 01:05:11 PDT Received: by mail-oa0-f51.google.com with SMTP id i4so12050728oah.38 for ; Wed, 16 Apr 2014 01:05:10 -0700 (PDT) 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=d3UdON6j4Ho2I30jkmFGKQjFykEFzRpR9SXZSU2eTuw=; b=LqoxZYhWne/AaAycQuGmQ9BH67yTs8fb+a1aObOyXv/3h7H7tmWrIcU3AKAFMAWAuC JsM3gE/KIETITOicDFuwWsTLnSoxdTuh9Mc4FwcGMDxRKL8PEOJgPF8Qf8tjLZbouFUx 1W3hZnuUOnIWfYIHZfNx8nNBdHA44jrNdcZE0MtDqxoaPha8Z7NBzZbtbhkvY1yG1bQO T8+CVs+14gA/Dev6eYuzuuiu6G/gF4rJZ0gEQCqSC3xTYduUT0xwzdFJsfY5ULDMiKRV 7ShMGRaZk1GqePUvoUzJZfKLTUuIcllBN/BlLfWY7ASrZnWFs1BARC6PIavc+/mYnaFU 4ltg== X-Gm-Message-State: ALoCoQnGh7Qk8DvlUkF7dNRrhB2vFSdRoLvPTcgVRb69if4u3RBMuu3zq5tjtrXYCdkxhWeME0n4/h0kUUebRfDO1ClvbA8xWM9veluLNUQdk8d8g/DVbVjKuBRwOX8CX6VYX06J2eMX X-Received: by 10.60.15.38 with SMTP id u6mr5436551oec.26.1397635510343; Wed, 16 Apr 2014 01:05:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.15.38 with SMTP id u6mr5436542oec.26.1397635510240; Wed, 16 Apr 2014 01:05:10 -0700 (PDT) Received: by 10.76.11.9 with HTTP; Wed, 16 Apr 2014 01:05:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Apr 2014 17:05:10 +0900 Message-ID: From: Matsushima Satoru To: Warren Kumari Content-Type: multipart/alternative; boundary=089e013cc0241d1ecf04f72460c2 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Pl2W_X07pJfG3hU2eyfRDeXP1-w X-Mailman-Approved-At: Wed, 16 Apr 2014 02:38:48 -0700 Cc: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org Subject: Re: [OPSAWG] Reminder about IPR relating to draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 08:05:19 -0000 --089e013cc0241d1ecf04f72460c2 Content-Type: text/plain; charset=ISO-8859-1 Hello Warren, all, I'm not aware of any IPR regarding this document. regards, --satoru On Tue, Apr 8, 2014 at 2:41 AM, Warren Kumari wrote: > Dear opsawg WG, > > Be not alarmed. > This email was created to satisfy RFC 6702 "Promoting Compliance with > Intellectual Property Rights (IPR)" > (http://tools.ietf.org/rfc/rfc6702.txt). > > > The authors of draft-ietf-opsawg-capwap-hybridmac have asked for a > Working Group Last Call. While running the Working Group Last Call, we > would like to check whether any claims of Intellectual Property Rights > (IPR) on the document have not yet been disclosed. > > Are you personally aware of any IPR that applies to > draft-ietf-opsawg-capwap-hybridmac? If so, has this IPR been > disclosed in compliance with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > If you are a document author or listed contributor on this document, > please reply to this email regardless of whether or not you are > personally aware of any relevant IPR. We might not be able to advance > this document to the next stage until we have received a reply from > each author and listed contributor. > > If you are on the opsawg WG email list but are not an author or listed > contributor for this document, you are reminded of your opportunity > for a voluntary IPR disclosure under BCP 79. Please do not reply > unless you want to make such a voluntary disclosure. > > Online tools for filing IPR disclosures can be found at > . > > Thanks, > Warren Kumari > (as opsawg WG co-chair) > --089e013cc0241d1ecf04f72460c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Warren, all,

I'm not aware of any IPR regarding this document.

= regards,
--satoru


On Tue, Apr 8, 2014 at 2:41 AM, Warren Kumari &= lt;warren@kumari.net= > wrote:
Dear opsawg WG,

Be not alarmed.
This email was created to satisfy RFC 6702 "Promoting Compliance with<= br> Intellectual Property Rights (IPR)"
(http:/= /tools.ietf.org/rfc/rfc6702.txt).


The authors of draft-ietf-opsawg-capwap-hybridmac have asked for a
Working Group Last Call. While running the Working Group Last Call, we
would like to check whether any claims of Intellectual Property Rights
(IPR) on the document have not yet been disclosed.

Are you personally aware of any IPR that applies to
draft-ietf-opsawg-capwap-hybridmac? =A0If so, has this IPR been
disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)

If you are a document author or listed contributor on this document,
please reply to this email regardless of whether or not you are
personally aware of any relevant IPR. =A0We might not be able to advance this document to the next stage until we have received a reply from
each author and listed contributor.

If you are on the opsawg WG email list but are not an author or listed
contributor for this document, you are reminded of your opportunity
for a voluntary IPR disclosure under BCP 79. =A0Please do not reply
unless you want to make such a voluntary disclosure.

Online tools for filing IPR disclosures can be found at
<h= ttp://www.ietf.org/ipr/file-disclosure>.

Thanks,
Warren Kumari
(as opsawg WG co-chair)

--089e013cc0241d1ecf04f72460c2-- From nobody Wed Apr 16 07:12:32 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E7A1A01B2 for ; Wed, 16 Apr 2014 07:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 4275om1pU051 for ; Wed, 16 Apr 2014 07:12:21 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 16F2C1A019B for ; Wed, 16 Apr 2014 07:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6997; q=dns/txt; s=iport; t=1397657538; x=1398867138; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Dm50LQZZp/99AybTGowU8++hkqEEJMtK6DypQwGMJYc=; b=e1fTGHV9h3cC+aQQ1OGMHNkqZAUEXcW8ZQpViK4QfPyWTV3+O1ec7abx Ghzepj2/iKo0ifDapUmfuZeMaJb+X1KhW+i6bwAsKdJo9aincnO5A439e O3C7xMc1uI08djxEJH9XBtTj5GKkFPssHrU6WMB1IabFXNZ0A38rAWihn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FANCOTlOtJV2c/2dsb2JhbABZgkJEO1e6Poh3gSAWdIImAQEELUcFEAIBCCIdBzIUEQIEDgUIAYdyAQ3IFReOABEBHzEHgySBFASaHZESgzGBcjk X-IronPort-AV: E=Sophos; i="4.97,872,1389744000"; d="scan'208,217"; a="36311050" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 16 Apr 2014 14:12:17 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3GECHVB002340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 14:12:17 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 09:12:17 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Warren Kumari Thread-Topic: Reminder about IPR relating to draft-ietf-opsawg-capwap-hybridmac Thread-Index: AQHPWUrL+EU4e3AHTEGBLPsExvJAFZsUSPBQ Date: Wed, 16 Apr 2014 14:12:17 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F74DE7@xmb-aln-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.133.9] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F74DE7xmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Fage8_SroqRuPpTkmw0UK4HYx4A Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org" Subject: Re: [OPSAWG] Reminder about IPR relating to draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:12:29 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F74DE7xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Warren I am not aware of any IPR regarding this document. Regards Rajesh On Tue, Apr 8, 2014 at 2:41 AM, Warren Kumari > wrote: Dear opsawg WG, Be not alarmed. This email was created to satisfy RFC 6702 "Promoting Compliance with Intellectual Property Rights (IPR)" (http://tools.ietf.org/rfc/rfc6702.txt). The authors of draft-ietf-opsawg-capwap-hybridmac have asked for a Working Group Last Call. While running the Working Group Last Call, we would like to check whether any claims of Intellectual Property Rights (IPR) on the document have not yet been disclosed. Are you personally aware of any IPR that applies to draft-ietf-opsawg-capwap-hybridmac? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please reply to this email regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor. If you are on the opsawg WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79. Please do not reply unless you want to make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Thanks, Warren Kumari (as opsawg WG co-chair) --_000_4ED2E36A22261145861BAB2C24088B4320F74DE7xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Warren

 

I am not aware of any IPR regarding this d= ocument.

 

Regards

 

Rajesh

 

 

On Tue, Apr 8, 2014 at 2:41 AM, Warren Kumari <warren@kumari.net&= gt; wrote:

Dear opsawg WG,

Be not alarmed.
This email was created to satisfy RFC 6702 "Promoting Compliance with<= br> Intellectual Property Rights (IPR)"
(http:/= /tools.ietf.org/rfc/rfc6702.txt).


The authors of draft-ietf-opsawg-capwap-hybridmac have asked for a
Working Group Last Call. While running the Working Group Last Call, we
would like to check whether any claims of Intellectual Property Rights
(IPR) on the document have not yet been disclosed.

Are you personally aware of any IPR that applies to
draft-ietf-opsawg-capwap-hybridmac?  If so, has this IPR been
disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)

If you are a document author or listed contributor on this document,
please reply to this email regardless of whether or not you are
personally aware of any relevant IPR.  We might not be able to advance=
this document to the next stage until we have received a reply from
each author and listed contributor.

If you are on the opsawg WG email list but are not an author or listed
contributor for this document, you are reminded of your opportunity
for a voluntary IPR disclosure under BCP 79.  Please do not reply
unless you want to make such a voluntary disclosure.

Online tools for filing IPR disclosures can be found at
<h= ttp://www.ietf.org/ipr/file-disclosure>.

Thanks,
Warren Kumari
(as opsawg WG co-chair)

 

--_000_4ED2E36A22261145861BAB2C24088B4320F74DE7xmbalnx09ciscoc_-- From nobody Wed Apr 16 07:13:41 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FEB1A01CF for ; Wed, 16 Apr 2014 07:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 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.272, 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 EBG_Kwy6hBTw for ; Wed, 16 Apr 2014 07:13:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 33B381A01C0 for ; Wed, 16 Apr 2014 07:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1566; q=dns/txt; s=iport; t=1397657609; x=1398867209; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=UFqYZxxSDvvj+v0VuEt2gMqK3gDfvUfj/TIxUIdSpNc=; b=BdBFzbaysdJSTMvkSxF+kScNdw+hGZ+uqDMPrIglrLNt1umZrnnh3XPN OXbFUrMa307dvUumsgqZVh+rgToeBciOEgijZFms8+bCqTeZhIxXfuKZb yqxcnywvD5JENesxwQjSwm3QdiL1RtUiP97IZb7/ZFBiEbKagr+DYURN8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAAWPTlOtJA2B/2dsb2JhbABZgwY7V7t9hmdRgSAWdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQBEggBh3IBDcgVF44AEQEfOAaDHoEUBKsvgzGBcjk X-IronPort-AV: E=Sophos;i="4.97,872,1389744000"; d="scan'208";a="318150699" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP; 16 Apr 2014 14:13:13 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s3GEDDfm009375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 14:13:13 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 09:13:13 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Warren Kumari , "opsawg@ietf.org" , "draft-zhang-opsawg-capwap-cds@tools.ietf.org" Thread-Topic: [OPSAWG] Reminder about IPR relating to draft-zhang-opsawg-capwap-cds Thread-Index: AQHPUoqAqnjHMlMXLESOzfUOqrl1UZsUVtfw Date: Wed, 16 Apr 2014 14:13:12 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F74DFC@xmb-aln-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.133.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/sJK762f1Zq0CTGc8nYd6c8LkoyA Subject: Re: [OPSAWG] Reminder about IPR relating to draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:13:36 -0000 Hello Warren I am not aware of any IPR related to this document. Regards Rajesh -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Monday, April 07, 2014 10:55 AM To: opsawg@ietf.org; draft-zhang-opsawg-capwap-cds@tools.ietf.org Subject: [OPSAWG] Reminder about IPR relating to draft-zhang-opsawg-capwap-= cds Dear opsawg WG, Be not alarmed. The authors of draft-zhang-opsawg-capwap-cds have asked for it to be adopte= d as a opsawg document -- we would like to check whether any claims of Inte= llectual Property Rights (IPR) on the document have not yet been disclosed. Are you personally aware of any IPR that applies to draft-zhang-opsawg-capw= ap-cds? If so, has this IPR been disclosed in compliance with IETF IPR rul= es? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please= reply to this email regardless of whether or not you are personally aware = of any relevant IPR. If you are on the opsawg WG email list but are not an author or listed cont= ributor for this document, you are reminded of your opportunity for a volun= tary IPR disclosure under BCP 79. Please do not reply unless you want to m= ake such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Apr 17 11:11:24 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33631A02AD for ; Thu, 17 Apr 2014 11:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 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, HTML_MESSAGE=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 g4igSaCxnr-G for ; Thu, 17 Apr 2014 11:11:15 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 95A1C1A02A0 for ; Thu, 17 Apr 2014 11:11:14 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so760138wes.4 for ; Thu, 17 Apr 2014 11:11:10 -0700 (PDT) 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=VqvgftIF5nlixZSIbRwle9sHJwc9v8embyC6vHl9rjs=; b=NXrVRNC97NdNOgMLt6p+NkdeM/b9cv/5kddK0Jvl+8iqnnjkuxH/F1GppjFauvHVCK 6I/xdnvYqYWO5fMWaJhXV78oaaEJMmH99nLJnwIO9xMbEhcT3D00PAIN7GH1IBxtdTdE pWCqIzPukl+Dnudmootj47Y8c3n1yK5TVpqthCo3h4zTI/U9GL9B8zH4NbscFsvMoXTj QUyacbn1IOy8UJvhGtTqU4q3HV9aaw8Ai+/Nobk/caR0mR2HvOiwvbR2P9XU3gT7hLBk YSPLTuHpuTGyOAMlY7iBWO81d+kCbHPtZc+jaO2QndCkl2ctb2SL1MunIVInuClAMEpS qvcw== MIME-Version: 1.0 X-Received: by 10.180.91.197 with SMTP id cg5mr13289405wib.35.1397758270531; Thu, 17 Apr 2014 11:11:10 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.73.138 with HTTP; Thu, 17 Apr 2014 11:11:10 -0700 (PDT) In-Reply-To: <534E4505.9080806@cisco.com> References: <534BD465.4090503@cisco.com> <534D2030.3020809@cisco.com> <534E4505.9080806@cisco.com> Date: Thu, 17 Apr 2014 11:11:10 -0700 X-Google-Sender-Auth: qXsmj38OiOuNq9o01NpZTJECjLg Message-ID: From: Anoop Ghanwani To: Benoit Claise Content-Type: multipart/alternative; boundary=14dae9d2fa3a326d3a04f740f5e0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/CnJwwBkm1gohppSrazj9n-v3u_E Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 18:11:21 -0000 --14dae9d2fa3a326d3a04f740f5e0 Content-Type: text/plain; charset=ISO-8859-1 Thanks Benoit. We'll figure out how to account for this in the draft and will have the update posted in the next few days. Anoop On Wed, Apr 16, 2014 at 1:53 AM, Benoit Claise wrote: > Anoop, > > Benoit, > > Please see inline. > > > On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise wrote: > >> On 14/04/2014 19:09, Anoop Ghanwani wrote: >> >> Hi Benoit, >> >> I will work on the editorials shortly and I'm removing those from the >> discussion. See below: >> >> >> On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise wrote: >> >>> Hi Anoop, >>> >>> Thanks for the new draft version. >>> I removed some of the points >>> >>> >>> >>> >>> On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise wrote: >>> >>>> - >>>> >>>> A number of routers support sampling techniques such as sFlow [sFlow- >>>> v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954]. >>>> For the purpose of large flow identification, sampling must be >>>> enabled on all of the egress ports in the router where such >>>> measurements are desired. >>>> >>>> I don't understand the second sentence. >>>> One way to read this is: sampling must be * enabled *on all of the >>>> egress ports where such measurements are desired. >>>> Ok, this is an obvious statement. If the measurements are desired, >>>> enable them >>>> >>> >>> Yes, >>> >>> >>>> Or maybe you want to say: *sampling *must be enabled on all of the >>>> egress ports where such measurements are desired. >>>> This is a false statement: if you have the choice between sampling >>>> and non sampling, use non sampling measurements. >>>> Or maybe you want to say: sampling must be enabled on *all *of the >>>> egress ports where such measurements are desired. >>>> This is a false statement: if I have ECMP on 2 links, and only one >>>> of them can't do non sampling, then we should not force >>>> sampling on both links. >>>> You see, I'm confused. >>>> >>>> You miss a couple of key messages: >>>> - if unsampled measurements are available, use those. >>>> - egress means where LAG/ECMP are enabled (this is important for the >>>> paragraph starting with "If egress sampling is not available, ingress >>>> sampling can suffice since the central management entity use") >>>> >>> >>> We were not intending to discuss a mix sampling and non-sampling >>> interfaces in the same router, but this is a reasonable point and it will >>> be clarified (i.e. we will state that it's possible to mix sampled and non >>> sampled interfaces as long as the function of large flow >>> detection/identification can be performed). >>> >>> You're still missing the point that unsampled measurements is better >>> than sampled ones. >>> >> >> We do point this out in Section 4.3.4. >> >> http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#section-4.3.4 >> >>> >> >> As link speeds get higher, sampling rates are typically reduced >> to keep the number of samples manageable which places a lower >> bound on the detection time. With automatic hardware >> recognition, large flows can be detected in shorter windows on >> higher link speeds since every packet is accounted for in >> hardware [NDTM ]. >> >> >>> >> >> I've seen that, but why do you equate automatic *hardware *recognition >> to unsampled measurements. >> Whether it's done in hardware of software is orthogonal. >> >> > OK, I think I see the reason for the disconnect. In the draft we only > talked about automatic hardware recognition and sampling as methods for > large flow recognition. It seems you're suggesting there's a third way -- > unsampled measurements (likely in hardware) but use of software for the > actual recognition of large flows from those measurements? Can you > confirm? If so, we can add that to the draft as well. > > I see two only ways: sampled and unsampled. > Both could be done in hardware (most likely on router; This is what you > called automatic hardware recognition, AFAICT) or software. > Whether it's done in hardware of software is orthogonal to the mechanism > in this document. > > I hope this clarifies > > Regards, Benoit > > > >> >>> Is this what you mean by: >>> >>> It is possible that a router may have line cards that support a >>> sampling technique while other line cards support automatic hardware >>> detection of large flows. >>> >>> It's not very clear. >>> >>> >> No, this does not address your point. This is talking about the case >> where line cards have different capabilities, rather than a line card that >> supports both. >> >> Since we already have the advantages and disadvantages listed in 4.3.4, >> do you still see a need for explicitly mentioning that automatic hardware >> detection is to be preferred over sampling if both are available? >> >> We did debate the point about accuracy quite a bit among the authors. >> The question is -- does that level of accuracy really matter for the large >> flow case? >> >> Maybe not (for the details: http://dl.acm.org/citation.cfm?id=1791959), >> but I don't understand why you want to limit this mechanism to sampling >> only. Simply telling that sampled data could be good enough, but if you >> have unsampled data, you will get a better accuracy. >> >> > Thanks for the reference. > >> Since we are dealing with flows that need to consume a certain >> percent of the link bandwidth, sampling, if configured correctly, >> >> And you don't go in the details of "sampling, if configured correctly"... >> > > There are suggestions in some of the references (e.g. the DevoFlow > paper), but there are also other references, e.g. > http://www.sflow.org/packetSamplingBasics/index.htm. This is a general > sampling problem, rather than something that was introduced by this draft. > If you think it would be useful to add something (or maybe just pointers > to the references), that can be done. > > Anoop > > > --14dae9d2fa3a326d3a04f740f5e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Benoit. =A0We'll figure out how to account for = this in the draft and will have the update posted in the next few days.
Anoop


On Wed, Apr 16, 2014 at 1:53 AM, Benoit Claise <bclaise@cisco.com><= /span> wrote:
=20 =20 =20
Anoop,
=20
Benoit,

Please see inline.


On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise <bclaise@cisco.com> wrote:
On 14/04/2014 19:09, Anoop Ghanwani wrote:
Hi Benoit,

I will work on the editorials shortly and I'm removing those from the discussion. =A0 See below:


On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise <bclaise@cisc= o.com> wrote:
Hi Anoop,

Thanks for the new draft version.
I removed some of the points
=A0


On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise <bclaise@cisco.c= om> wrote:
- 

   A number =
of routers support sampling techniques such as sFlow [sFlow-
   v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954].
   For the purpose of large flow identification, sampling must be
   enabled on all of the egress ports in the router where such
   measurements are desired.
I don't understand the second sentence.
One way to read this is:=A0 sampling must be enabled on all of the egress ports where such measurements are desired.
=A0=A0=A0 Ok, thi= s is an obvious statement. If the measurements are desired, enable them

Yes,
=A0=A0
Or maybe you want to say: s= ampling must be enabled on all of the egress ports where such measurements are desired.
=A0=A0=A0 This is= a false statement: if you have the choice between sampling and non sampling, use non sampling measurements.
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
=A0=A0=A0 This is= a false statement: if I have ECMP on 2 links, and only one of them can't do non sampling, then we should not force
=A0=A0=A0 samplin= g on both links. You see, I'm confused.

You miss a couple of key messages:
- if unsampled measurements are available, use those.
- egress means where LAG/ECMP are enabled (this is important for the paragraph starting with "If egress sampling is not available, ingress sampling can suffice since the central management entity use")=

We were not intending to discuss a mix sampling and non-sampling interfaces in the same router, but this is a reasonable point and it will be clarified (i.e. we will state that it's possible to mix sampled and non sampled interfaces as long as the function of large flow detection/identif= ication can be performed).
You're still missing the point that unsampled measurements is better than sampled ones.

We do point this out in Section 4.3.4.
>>>
        As link speeds get higher, sampling rates are ty=
pically reduced
        to keep the number of samples manageable which places a lower
        bound on the detection time.  With automatic hardware
        recognition, large flows can be detected in shorter windows on
        higher link speeds since every packet is accounted for in
        hardware [NDTM].
>>>
I've seen that, but why do you equate automatic ha= rdware recognition to unsampled measurements.
Whether it's done in hardware of software is orthogonal.


OK, I think I see the reason for the disconnect. =A0In the draft we only talked about automatic hardware recognition and sampling as methods for large flow recognition. =A0It seems you're suggesting there's = a third way -- unsampled measurements (likely in hardware) but use of software for the actual recognition of large flows from those measurements? =A0Can you confirm? =A0If so= , we can add that to the draft as well.
I see two only ways: sampled and unsampled.
Both could be done in hardware (most likely on router; This is what you called automatic hardware recognition, AFAICT) or software.
Whether it's done in hardware of software is orthogonal to the mechanism in this document.

I hope this clarifies

Regards, Benoit

=A0
Is this what you mean by:
It is possible that a router may hav=
e line cards that support a
sampling technique while other line cards support automatic hardware
detection of large flows.
It's not very clear.


No, this does not address your point. =A0This is talking about the case where line cards have different capabilities, rather than a line card that supports both.

Since we already have the advantages and disadvantages listed in 4.3.4, do you still see a need for explicitly mentioning that automatic hardware detection is to be preferred over sampling if both are available?

We did debate the point about accuracy quite a bit among the authors. =A0The question is -- does that level of accuracy really matter for the large flow case?
Maybe not (for the details: http://dl.acm.org/citation.cfm= ?id=3D1791959), but I don't understand why you want to limit this mechanism to sampling only. Simply telling that sampled data could be good enough, but if you have unsampled data, you will get a better accuracy.


Thanks for the reference.=A0
Since we are dealing with flows that need to consume a certain percent of the link bandwidth, sampling, if configured correctly,
And you don't go in the details of "sampling, if configured correctly"...

There are suggestions in some of the references (e.g. the DevoFlow paper), but there are also other references, e.g.
http://www.sflow.org/packetSamplingBasics/index.h= tm. =A0 This is a general sampling problem, rather than something that was introduced by this draft. =A0If you think it would be useful to add something (or maybe just pointers to the references), that can be done.

Anoop


--14dae9d2fa3a326d3a04f740f5e0-- From nobody Thu Apr 17 20:26:19 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929CB1A0269 for ; Thu, 17 Apr 2014 20:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 WXyEzPdlxDRD for ; Thu, 17 Apr 2014 20:26:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 248161A00CB for ; Thu, 17 Apr 2014 20:26:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFU71135; Fri, 18 Apr 2014 03:26:09 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 04:24:42 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 04:26:08 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.206]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 18 Apr 2014 11:26:03 +0800 From: Sheng Jiang To: Warren Kumari , "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org" Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac Thread-Index: AQHPUoDKTK2WXo7lGkep+DDcRLYAq5sWw5zg Date: Fri, 18 Apr 2014 03:26:02 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE3A984@nkgeml512-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/9pg1wryVeb2796HpA6T756xmcpQ Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 03:26:16 -0000 SSByZXZpZXdlZCB0aGlzIGRyYWZ0LiBJdCBpcyB3ZWxsLXdyaXR0ZW4uIEl0IHRhcmdldHMgdGhl IGludGVyb3BlcmFiaWxpdHkgaXNzdWUgd2hlbiBBQyBhbmQgV1RQIGNvbWUgZnJvbSBkaWZmZXJl bnQgdmVuZG9ycywgYW5kIHNvbHZlcyBpdCB3ZWxsLg0KDQpJIHN1cHBvcnQgdG8gYWR2YW5jZSB0 aGlzIGRvY3VtZW50LiBUaGVyZSBhcmUgYSBjb3VwbGUgb2YgaWRuaXRzIHNob3VsZCBiZSBmaXhl ZC4NCg0KPT0gVGhlIGRvY3VtZW50IGRvZXNuJ3QgdXNlIGFueSBSRkMgMjExOSBrZXl3b3Jkcywg eWV0IGhhcyB0ZXh0IHJlc2VtYmxpbmcNCiAgICAgUkZDIDIxMTkgYm9pbGVycGxhdGUgdGV4dC4N Cj09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkM0NTY0Jw0KKiogRG93bnJlZjogTm9ybWF0aXZlIHJl ZmVyZW5jZSB0byBhbiBJbmZvcm1hdGlvbmFsIFJGQzogUkZDIDQ1NjQNCg0KUmVnYXJkcywNCg0K U2hlbmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogT1BTQVdHIFttYWls dG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXYXJyZW4NCj5LdW1hcmkN Cj5TZW50OiBUdWVzZGF5LCBBcHJpbCAwOCwgMjAxNCAxMjo0NSBBTQ0KPlRvOiBvcHNhd2dAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWNAdG9vbHMuaWV0Zi5vcmcN Cj5TdWJqZWN0OiBbT1BTQVdHXSBTdGFydCBvZiBXR0xDIGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1j YXB3YXAtaHlicmlkbWFjDQo+DQo+RGVhciBvcHNhd2cgV0csDQo+DQo+VGhlIGF1dGhvcnMgb2Yg ZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1hYyBoYXZlIGluZGljYXRlZCB0aGF0DQo+ dGhleSBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50IGlzIHJlYWR5LCBhbmQgaGF2ZSBhc2tlZCBm b3IgV29ya2luZw0KPkdyb3VwIExhc3QgQ2FsbC4NCj4NCj5UaGUgZHJhZnQgaXMgYXZhaWxhYmxl IGhlcmU6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNh d2ctY2Fwd2FwLWh5YnJpZG1hYy8NCj4NCj5QbGVhc2UgcmV2aWV3IHRoaXMgZHJhZnQgdG8gc2Vl IGlmIHlvdSB0aGluayBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24NCj5hbmQgc2VuZCBjb21t ZW50cyB0byB0aGUgbGlzdCwgY2xlYXJseSBzdGF0aW5nIHlvdXIgdmlldy4NCj4NCj5UaGlzIFdH TEMgZW5kcyBNb24gMjEtQXByLTIwMTQuDQo+DQo+VGhhbmtzLA0KPldhcnJlbiBLdW1hcmkNCj4o YXMgb3BzYXdnIFdHIGNvLWNoYWlyKQ0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+T1BTQVdHIG1haWxpbmcgbGlzdA0KPk9QU0FXR0BpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnDQo= From nobody Sun Apr 20 18:30:45 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FB51A0102 for ; Sun, 20 Apr 2014 18:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 h4yZV4i-GbKS for ; Sun, 20 Apr 2014 18:30:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EBDE61A00FE for ; Sun, 20 Apr 2014 18:30:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFW53901; Mon, 21 Apr 2014 01:30:35 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 02:29:01 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 02:30:34 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.47]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 21 Apr 2014 09:30:31 +0800 From: Xueli To: Warren Kumari , "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org" Thread-Topic: [OPSAWG] Reminder about IPR relating to draft-ietf-opsawg-capwap-hybridmac Thread-Index: AQHPUojDwXHWtRFchUyd9TkWfAYODpsbVSbQ Date: Mon, 21 Apr 2014 01:30:30 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448F887F9@nkgeml504-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/YHyXBd2811L3uwq5SvAO6VDF8YM Subject: Re: [OPSAWG] Reminder about IPR relating to draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 01:30:44 -0000 Hi all I read this draft, I think it is ready for WGLC. Some editor comments should be fixed. 1 section 3.3, last sentence of the first paragraph, "the configures" -> "c= onfigures" 2 section 4.1 "Messaage"->"Message" Regards Li Xue >-----Original Message----- >From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari >Sent: Tuesday, April 08, 2014 1:42 AM >To: opsawg@ietf.org; draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org >Subject: [OPSAWG] Reminder about IPR relating to >draft-ietf-opsawg-capwap-hybridmac > >Dear opsawg WG, > >Be not alarmed. >This email was created to satisfy RFC 6702 "Promoting Compliance with >Intellectual Property Rights (IPR)" >(http://tools.ietf.org/rfc/rfc6702.txt). > > >The authors of draft-ietf-opsawg-capwap-hybridmac have asked for a >Working Group Last Call. While running the Working Group Last Call, we >would like to check whether any claims of Intellectual Property Rights >(IPR) on the document have not yet been disclosed. > >Are you personally aware of any IPR that applies to >draft-ietf-opsawg-capwap-hybridmac? If so, has this IPR been >disclosed in compliance with IETF IPR rules? >(See RFCs 3979, 4879, 3669, and 5378 for more details.) > >If you are a document author or listed contributor on this document, >please reply to this email regardless of whether or not you are >personally aware of any relevant IPR. We might not be able to advance >this document to the next stage until we have received a reply from >each author and listed contributor. > >If you are on the opsawg WG email list but are not an author or listed >contributor for this document, you are reminded of your opportunity >for a voluntary IPR disclosure under BCP 79. Please do not reply >unless you want to make such a voluntary disclosure. > >Online tools for filing IPR disclosures can be found at >. > >Thanks, >Warren Kumari >(as opsawg WG co-chair) > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From nobody Sun Apr 20 18:37:28 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCECB1A00FE for ; Sun, 20 Apr 2014 18:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 c_Z3ZOJCdCp6 for ; Sun, 20 Apr 2014 18:37:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 68F8E1A0106 for ; Sun, 20 Apr 2014 18:37:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDH74956; Mon, 21 Apr 2014 01:37:14 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 02:36:26 +0100 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 02:37:14 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.143]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Mon, 21 Apr 2014 09:37:08 +0800 From: "Liushucheng (Will)" To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds Thread-Index: AQHPUoprC2iTsdfjekSIGJhKIv7szZsTZ2+AgAf1Q+A= Date: Mon, 21 Apr 2014 01:37:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/1K63sRu4qpWM7GI_Tr8iTOY1nTI Cc: "draft-zhang-opsawg-capwap-cds@tools.ietf.org" Subject: Re: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 01:37:24 -0000 VGhlIHNwZWNpZmljYXRpb24gc291bmRzIHJlYXNvbmFibGUgYW5kIHRoZSByZXF1aXJlbWVudHMg YXJlIG1lYW5pbmdmdWwuIEkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC4NCg0K UmVnYXJkcywNCldpbGwgDQoNCj4gLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0t LS0tDQo+IEZyb206IFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0Pg0KPiBEYXRlOiBU dWUsIEFwciA4LCAyMDE0IGF0IDE6NTMgQU0NCj4gU3ViamVjdDogW09QU0FXR10gQ2FsbCBmb3Ig QWRvcHRpb246IGRyYWZ0LXpoYW5nLW9wc2F3Zy1jYXB3YXAtY2RzDQo+IFRvOiAib3BzYXdnQGll dGYub3JnIiA8b3BzYXdnQGlldGYub3JnPiwgImRyYWZ0LXpoYW5nLW9wc2F3Zy1jYXB3YXAtDQo+ IGNkc0B0b29scy5pZXRmLm9yZyINCj4gPGRyYWZ0LXpoYW5nLW9wc2F3Zy1jYXB3YXAtY2RzQHRv b2xzLmlldGYub3JnPg0KPiANCj4gDQo+IERlYXIgb3BzYXdnIFdHLA0KPiANCj4gVGhpcyBzdGFy dHMgYSBDYWxsIGZvciBBZG9wdGlvbiBmb3IgZHJhZnQtemhhbmctb3BzYXdnLWNhcHdhcC1jZHMu DQo+IA0KPiBUaGUgZHJhZnQgaXMgYXZhaWxhYmxlIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLW9wc2F3Zy1jYXB3YXAtY2RzLw0KPiANCj4gUGxl YXNlIHJldmlldyB0aGlzIGRyYWZ0IHRvIHNlZSBpZiB5b3UgdGhpbmsgaXQgaXMgc3VpdGFibGUg Zm9yDQo+IGFkb3B0aW9uIGJ5IG9wc2F3ZywgYW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBjbGVh cmx5IHN0YXRpbmcgeW91ciB2aWV3Lg0KPiANCj4gUGxlYXNlIGFsc28gaW5kaWNhdGUgaWYgeW91 IGFyZSB3aWxsaW5nIHRvIGNvbnRyaWJ1dGUgdGV4dCwgcmV2aWV3LCBldGMuDQo+IA0KPiANCj4g VGhpcyBjYWxsIGZvciBhZG9wdGlvbiBlbmRzIE1vbiAyMS1BcHItMjAxNC4NCj4gDQo+IFRoYW5r cywNCj4gV2FycmVuIEt1bWFyaQ0KPiAoYXMgb3BzYXdnIFdHIGNvLWNoYWlyKQ0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT1BTQVdHIG1h aWxpbmcgbGlzdA0KPiBPUFNBV0dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vcHNhd2cNCg== From nobody Sun Apr 20 20:22:40 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7351A0197 for ; Sun, 20 Apr 2014 20:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 4N3TSVg_6DdT for ; Sun, 20 Apr 2014 20:22:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 138311A0194 for ; Sun, 20 Apr 2014 20:22:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFW60975; Mon, 21 Apr 2014 03:22:29 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 04:20:47 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Apr 2014 04:22:21 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.47]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 21 Apr 2014 11:22:17 +0800 From: Xueli To: Warren Kumari , "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org" Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac Thread-Index: AQHPUoDJ3x6Gmt5OSk6sVGJqXJT8/JsbfJxQ Date: Mon, 21 Apr 2014 03:22:17 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448F88840@nkgeml504-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/x4hOxWIyTPN8YDpw98QfoZPFtEc Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 03:22:37 -0000 Hi all I read this draft, I think it is ready for WGLC. Some editor comments should be fixed. 1 section 3.3, last sentence of the first paragraph, "the configures" -> "c= onfigures" 2 section 4.1 "Messaage"->"Message" Regards Li Xue >-----Original Message----- >From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari >Sent: Tuesday, April 08, 2014 12:45 AM >To: opsawg@ietf.org; draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org >Subject: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac > >Dear opsawg WG, > >The authors of draft-ietf-opsawg-capwap-hybridmac have indicated that >they believe that the document is ready, and have asked for Working >Group Last Call. > >The draft is available here: >https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ > >Please review this draft to see if you think it is ready for publication >and send comments to the list, clearly stating your view. > >This WGLC ends Mon 21-Apr-2014. > >Thanks, >Warren Kumari >(as opsawg WG co-chair) > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Apr 21 01:06:49 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9A71A01B1 for ; Mon, 21 Apr 2014 01:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 2B_0xMGs4wP5 for ; Mon, 21 Apr 2014 01:06:39 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA001A01BB for ; Mon, 21 Apr 2014 01:06:38 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id pa12so7757502veb.28 for ; Mon, 21 Apr 2014 01:06:33 -0700 (PDT) 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=3KJPGgDO/djZw++grjuIFtdG6AvbXe3oT9nn61REaG0=; b=H+P7rx64IcuOr6W7CBN7pnH9qes0nTO1Z74ktTfgj4kofaXWXsiqFXZ9OxlcwP48// YXCyPsGzV9L0OVce4Ctwz7RGoUnpwFd2+4G6GAech+ySV2mSWer/ML6xfk2C6Ldw6orb eCT8Ff8jEfIdkuDDyzKd6ZkgcWTabIFHXHUCY60wrMlA8oGPZXOOfnT1GpHa6dZqYfhg cPoHzhAgs+a8n0hUk3S6JUGd6F76n3Kxz9qn4bGq32Ge7cB84R755zDxgc+qaOmWU9IM ZF/r99gZqtWIWa7nikqXROr7HOKZo+4zNTKFOQpH67Qafj8UFDxLdcXQD//nY6ocZDAO PWSA== MIME-Version: 1.0 X-Received: by 10.52.253.75 with SMTP id zy11mr25568862vdc.10.1398067592966; Mon, 21 Apr 2014 01:06:32 -0700 (PDT) Received: by 10.220.88.204 with HTTP; Mon, 21 Apr 2014 01:06:32 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Apr 2014 16:06:32 +0800 Message-ID: From: Liu Dapeng To: Warren Kumari Content-Type: multipart/alternative; boundary=001a1135ef1640376304f788fa43 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/8Xu0quHcAZkCj2II2w7QSK6sX8s Cc: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 08:06:44 -0000 --001a1135ef1640376304f788fa43 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I reviewed this draft and think it is ready for WGLC. Some editorial comments: 1. The secend paragraph in page 3: "Figure 1 quoted..." -> "Figure 1 which is quoted..." 2. Section 3 : "IEEE MAC profile" -> "IEEE 802.11 MAC profile" Cheers, Dapeng Liu 2014-04-08 0:44 GMT+08:00 Warren Kumari : > Dear opsawg WG, > > The authors of draft-ietf-opsawg-capwap-hybridmac have indicated that > they believe that the document is ready, and have asked for Working > Group Last Call. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ > > Please review this draft to see if you think it is ready for publication > and send comments to the list, clearly stating your view. > > This WGLC ends Mon 21-Apr-2014. > > Thanks, > Warren Kumari > (as opsawg WG co-chair) > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > -- ------ Best Regards, Dapeng Liu --001a1135ef1640376304f788fa43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,

I reviewed this draft and think= it is ready for WGLC.

Some editorial comments:
1. The secend paragraph in page 3: =A0"Figure 1 quoted..." -> "Figure 1 which is quoted...= "
2. Section 3 : "IEEE MAC profile" -> &quo= t;IEEE 802.11 MAC profile"

Cheers,
Dapeng Liu


2014-04-08 0:44 GMT+08:00 Warren Kumari <wa= rren@kumari.net>:
Dear opsawg WG,

The authors of draft-ietf-opsawg-capwap-hybridmac have indicated that
they believe that the document is ready, and have asked for Working
Group Last Call.

The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-= capwap-hybridmac/

Please review this draft to see if you think it is ready for publication and send comments to the list, clearly stating your view.

This WGLC ends Mon 21-Apr-2014.

Thanks,
Warren Kumari
(as opsawg WG co-chair)

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg



--

------Best Regards,
Dapeng Liu
--001a1135ef1640376304f788fa43-- From nobody Mon Apr 21 12:56:45 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028901A0276 for ; Mon, 21 Apr 2014 12:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 F3tFm1SkJaGF for ; Mon, 21 Apr 2014 12:56:39 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 57AB31A0262 for ; Mon, 21 Apr 2014 12:56:39 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s3LJuX6I021424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Apr 2014 19:56:33 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s3LJuUw7020577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 21:56:32 +0200 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 21 Apr 2014 21:56:30 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.36]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0181.006; Mon, 21 Apr 2014 21:56:30 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Warren Kumari , "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org" Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac Thread-Index: AQHPUoC8RS5Cb79BsEiGMfqIG2DD5pscjQMQ Date: Mon, 21 Apr 2014 19:56:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1570 X-purgate-ID: 151667::1398110193-00001564-93FB30D4/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/ti8Zl-AnoKvFbxcd0ruT3SdPweQ Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:56:42 -0000 Hi, I read draft-ietf-opsawg-capwap-hybridmac-02.txt.=20 I think it is well-written and addresses the issue described. There are a few minor editorial issues: s/the the/the/ s/unamabigously/unambigously/ s/Figure 1 quoted/Figure 1 is quoted/ s/in Figure 1/in Figure 1./ s/regsitered/registered/ I would write in section 5. Security Considerations following: "This document does not introduce any new security risks compared to=20 [RFC5416]. The security considerations described in [RFC5416] apply=20 here as well." Regards,=20 Mehmet=20 > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of ext Warren > Kumari > Sent: Monday, April 07, 2014 6:45 PM > To: opsawg@ietf.org; draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org > Subject: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac >=20 > Dear opsawg WG, >=20 > The authors of draft-ietf-opsawg-capwap-hybridmac have indicated that > they believe that the document is ready, and have asked for Working > Group Last Call. >=20 > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ >=20 > Please review this draft to see if you think it is ready for > publication > and send comments to the list, clearly stating your view. >=20 > This WGLC ends Mon 21-Apr-2014. >=20 > Thanks, > Warren Kumari > (as opsawg WG co-chair) >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Apr 21 13:19:06 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1451A02A0 for ; Mon, 21 Apr 2014 13:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 CuOmJQGo6heJ for ; Mon, 21 Apr 2014 13:18:58 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3971C1A0298 for ; Mon, 21 Apr 2014 13:18:58 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id w7so3562863lbi.34 for ; Mon, 21 Apr 2014 13:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ulwkw0hBBctPoUQ1QN1NiFeIi948+NDQlJOKa7BJr+o=; b=cbb3BN4SMqYPa6aqe4TC6NrrkQrrplWDwQ/QgpnUF7UnTWSA4qHNzIIrG1DsAhtoZH nuSUCXOeo53TUfXX2czdM7y7a/5hthtanIKSidldQoHcyVFbaPGRY+oOUxXdWQvIi3aS JHO7jqzq3iM0SXeBNOMFFiQs8R/ATFkS5T9H3WjbYd89Rd10u329OhaNdX0Qt+RKS3/E 9Q/KT+woMWkw3GL9QxwiHFwVlAlw5CbG0F4A+RW8U6t6lCXgoH5poT/m3qVO/fxX07xd N/yZaLaqUpKcMoyRw8kxlpb1B8j5SfUXtkerVkzjMysF90ZEGwVYUi+yqYg8xYA2tWA/ sePg== MIME-Version: 1.0 X-Received: by 10.152.44.234 with SMTP id h10mr46979lam.68.1398111532563; Mon, 21 Apr 2014 13:18:52 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Mon, 21 Apr 2014 13:18:52 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Apr 2014 15:18:52 -0500 Message-ID: From: Behcet Sarikaya To: Warren Kumari Content-Type: multipart/alternative; boundary=089e0158c62e413f4e04f7933534 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/hvDd1M4ugVa-3yVMRJBoJ0je60Q Cc: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:19:02 -0000 --089e0158c62e413f4e04f7933534 Content-Type: text/plain; charset=UTF-8 Hi all, I have problem in the Hybrid MAC terminology used in this draft. The draft basically describes an improved split MAC profile as such it should be named accordingly. The draft does not define a new thing such as local MAC or split MAC as in CAPWAP documents to deserve to be called defining "hybrid MAC". If the above concern is handled, I am ready to support the adoption. Regards, Behcet On Mon, Apr 7, 2014 at 11:44 AM, Warren Kumari wrote: > Dear opsawg WG, > > The authors of draft-ietf-opsawg-capwap-hybridmac have indicated that > they believe that the document is ready, and have asked for Working > Group Last Call. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ > > Please review this draft to see if you think it is ready for publication > and send comments to the list, clearly stating your view. > > This WGLC ends Mon 21-Apr-2014. > > Thanks, > Warren Kumari > (as opsawg WG co-chair) > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --089e0158c62e413f4e04f7933534 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I have = problem in the Hybrid MAC terminology used in this draft.
The draf= t basically describes an improved split MAC profile as such it should be na= med accordingly.

The draft does not define a new thing such as local MAC or split = MAC as in CAPWAP documents to deserve to be called defining "hybrid MA= C".

If the above concern is handled, I am ready to suppor= t the adoption.

Regards,

Behcet


On Mon, Apr= 7, 2014 at 11:44 AM, Warren Kumari <warren@kumari.net> wrot= e:
Dear opsawg WG,

The authors of draft-ietf-opsawg-capwap-hybridmac have indicated that
they believe that the document is ready, and have asked for Working
Group Last Call.

The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-= capwap-hybridmac/

Please review this draft to see if you think it is ready for publication and send comments to the list, clearly stating your view.

This WGLC ends Mon 21-Apr-2014.

Thanks,
Warren Kumari
(as opsawg WG co-chair)

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

--089e0158c62e413f4e04f7933534-- From nobody Tue Apr 22 10:58:26 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF881A069F for ; Tue, 22 Apr 2014 10:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 3wVEZUBkWyoM for ; Tue, 22 Apr 2014 10:58:19 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 61C261A00E8 for ; Tue, 22 Apr 2014 10:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11294; q=dns/txt; s=iport; t=1398189486; x=1399399086; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=G04Q0vPXWsO0ViwtjN7Uw2SvtEEitA9Fj5CFRRqJbQk=; b=NgBDrGVrwPKdEOXEqg5nx+XocWfuH3C+seWPx+HjImq4e6xgVZgwZ98z Aa5Pc9BHi2zSh8roHwcX9SA6JSPeFhRdRiwWWpCahcA+mKCX3I/xWbTnY i/whFSJQglgLXFVpPn3wug7EJVHpQH4iVekgcWP3t1qVaG57zR0YvZWkD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAI6sVlOtJA2N/2dsb2JhbABZgkJET1eDD7lUhmlRGX0WdIIlAQEBBAEBASAKQQsQAgEIEQQBAQsdAwICAiULFAkIAgQBDQUIiDgBDakroyQTBI4lLQQGAYJvNYEUBKtCgzGCKw X-IronPort-AV: E=Sophos; i="4.97,905,1389744000"; d="scan'208,217"; a="37810345" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP; 22 Apr 2014 17:58:05 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s3MHw5KS003349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 17:58:05 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 12:58:05 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: "sarikaya@ieee.org" , Warren Kumari Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac Thread-Index: AQHPUoC8MFNDHyh8Kkuo/cfmgAemqJsc7KMAgAEWC+A= Date: Tue, 22 Apr 2014 17:58:04 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F76104@xmb-aln-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.133.94] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F76104xmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/70Pb7Z5u59X2nGIeTU1XmJNz-xs Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 17:58:24 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F76104xmbalnx09ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVoY2V0DQoNClRoZSBwb2ludCB5b3UgcmFpc2UgaGFkIGJlZW4gYnJvdWdodCB1cCBlYXJsaWVy IGJ5IERvcm90aHkgUy4gYW5kIHRoZSB0ZXh0IHdhcyB1cGRhdGVkIGFwcHJvcHJpYXRlbHkuDQpJ IGJlbGlldmUgaXQgd2FzIGRpZmZpY3VsdCB0byBjaGFuZ2UgdGhlIHRpdGxlIHdpdGhvdXQgcmVz dGFydGluZyB0aGUgdmVyc2lvbmluZyBwcm9jZXNzLiBBcyBhIHJlc3VsdCwgdGhlIHRpdGxlIHN0 aWxsIGhhcyBIeWJyaWQtTUFDIGluIHRoZSBuYW1lLg0KU28sIGJlc2lkZXMgdGhlIHRpdGxlIOKA nGh5YnJpZOKAnSBkb2VzIG5vdCBhcHBlYXIgYW55d2hlcmUgZWxzZSBhbmQgdGhlIHRpdGxlIHdp bGwgZ28gYXdheSBvbmNlIHRoaXMgYmVjb21lcyBhIFJGQy4NCg0KUmVnYXJkcw0KDQpSYWplc2gN CkZyb206IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQmVoY2V0IFNhcmlrYXlhDQpTZW50OiBNb25kYXksIEFwcmlsIDIxLCAyMDE0IDE6MTkgUE0N ClRvOiBXYXJyZW4gS3VtYXJpDQpDYzogb3BzYXdnQGlldGYub3JnOyBkcmFmdC1pZXRmLW9wc2F3 Zy1jYXB3YXAtaHlicmlkbWFjQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW09QU0FXR10g U3RhcnQgb2YgV0dMQyBmb3IgZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1hYw0KDQpI aSBhbGwsDQpJIGhhdmUgcHJvYmxlbSBpbiB0aGUgSHlicmlkIE1BQyB0ZXJtaW5vbG9neSB1c2Vk IGluIHRoaXMgZHJhZnQuDQpUaGUgZHJhZnQgYmFzaWNhbGx5IGRlc2NyaWJlcyBhbiBpbXByb3Zl ZCBzcGxpdCBNQUMgcHJvZmlsZSBhcyBzdWNoIGl0IHNob3VsZCBiZSBuYW1lZCBhY2NvcmRpbmds eS4NClRoZSBkcmFmdCBkb2VzIG5vdCBkZWZpbmUgYSBuZXcgdGhpbmcgc3VjaCBhcyBsb2NhbCBN QUMgb3Igc3BsaXQgTUFDIGFzIGluIENBUFdBUCBkb2N1bWVudHMgdG8gZGVzZXJ2ZSB0byBiZSBj YWxsZWQgZGVmaW5pbmcgImh5YnJpZCBNQUMiLg0KSWYgdGhlIGFib3ZlIGNvbmNlcm4gaXMgaGFu ZGxlZCwgSSBhbSByZWFkeSB0byBzdXBwb3J0IHRoZSBhZG9wdGlvbi4NClJlZ2FyZHMsDQpCZWhj ZXQNCg0KT24gTW9uLCBBcHIgNywgMjAxNCBhdCAxMTo0NCBBTSwgV2FycmVuIEt1bWFyaSA8d2Fy cmVuQGt1bWFyaS5uZXQ8bWFpbHRvOndhcnJlbkBrdW1hcmkubmV0Pj4gd3JvdGU6DQpEZWFyIG9w c2F3ZyBXRywNCg0KVGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJp ZG1hYyBoYXZlIGluZGljYXRlZCB0aGF0DQp0aGV5IGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQg aXMgcmVhZHksIGFuZCBoYXZlIGFza2VkIGZvciBXb3JraW5nDQpHcm91cCBMYXN0IENhbGwuDQoN ClRoZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWMvDQoNClBsZWFzZSByZXZp ZXcgdGhpcyBkcmFmdCB0byBzZWUgaWYgeW91IHRoaW5rIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNh dGlvbg0KYW5kIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QsIGNsZWFybHkgc3RhdGluZyB5b3Vy IHZpZXcuDQoNClRoaXMgV0dMQyBlbmRzIE1vbiAyMS1BcHItMjAxNC4NCg0KVGhhbmtzLA0KV2Fy cmVuIEt1bWFyaQ0KKGFzIG9wc2F3ZyBXRyBjby1jaGFpcikNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9QU0FXRyBtYWlsaW5nIGxpc3QNCk9QU0FX R0BpZXRmLm9yZzxtYWlsdG86T1BTQVdHQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg0K --_000_4ED2E36A22261145861BAB2C24088B4320F76104xmbalnx09ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0 eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlaGNldDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgcG9pbnQgeW91IHJhaXNlIGhhZCBiZWVuIGJyb3Vn aHQgdXAgZWFybGllciBieSBEb3JvdGh5IFMuIGFuZCB0aGUgdGV4dCB3YXMgdXBkYXRlZCBhcHBy b3ByaWF0ZWx5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGJlbGlldmUgaXQgd2FzIGRpZmZpY3VsdCB0byBj aGFuZ2UgdGhlIHRpdGxlIHdpdGhvdXQgcmVzdGFydGluZyB0aGUgdmVyc2lvbmluZyBwcm9jZXNz LiBBcyBhIHJlc3VsdCwgdGhlIHRpdGxlIHN0aWxsIGhhcyBIeWJyaWQtTUFDIGluIHRoZSBuYW1l LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+U28sIGJlc2lkZXMgdGhlIHRpdGxlIOKAnGh5YnJpZOKAnSBkb2VzIG5v dCBhcHBlYXIgYW55d2hlcmUgZWxzZSBhbmQgdGhlIHRpdGxlIHdpbGwgZ28gYXdheSBvbmNlIHRo aXMgYmVjb21lcyBhIFJGQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJk czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SYWplc2g8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT1BTQVdHIFtt YWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJlaGNl dCBTYXJpa2F5YTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDIxLCAyMDE0IDE6MTkg UE08YnI+DQo8Yj5Ubzo8L2I+IFdhcnJlbiBLdW1hcmk8YnI+DQo8Yj5DYzo8L2I+IG9wc2F3Z0Bp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1hY0B0b29scy5pZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09QU0FXR10gU3RhcnQgb2YgV0dMQyBmb3IgZHJh ZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1hYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgcHJvYmxlbSBpbiB0aGUgSHlicmlkIE1BQyB0 ZXJtaW5vbG9neSB1c2VkIGluIHRoaXMgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIGRyYWZ0 IGJhc2ljYWxseSBkZXNjcmliZXMgYW4gaW1wcm92ZWQgc3BsaXQgTUFDIHByb2ZpbGUgYXMgc3Vj aCBpdCBzaG91bGQgYmUgbmFtZWQgYWNjb3JkaW5nbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIGRy YWZ0IGRvZXMgbm90IGRlZmluZSBhIG5ldyB0aGluZyBzdWNoIGFzIGxvY2FsIE1BQyBvciBzcGxp dCBNQUMgYXMgaW4gQ0FQV0FQIGRvY3VtZW50cyB0byBkZXNlcnZlIHRvIGJlIGNhbGxlZCBkZWZp bmluZyAmcXVvdDtoeWJyaWQgTUFDJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPklmIHRoZSBhYm92 ZSBjb25jZXJuIGlzIGhhbmRsZWQsIEkgYW0gcmVhZHkgdG8gc3VwcG9ydCB0aGUgYWRvcHRpb24u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QmVoY2V0PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBcHIgNywgMjAxNCBhdCAxMTo0NCBBTSwg V2FycmVuIEt1bWFyaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhcnJlbkBrdW1hcmkubmV0IiB0YXJn ZXQ9Il9ibGFuayI+d2FycmVuQGt1bWFyaS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgb3BzYXdnIFdHLDxicj4NCjxicj4NClRoZSBh dXRob3JzIG9mIGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWMgaGF2ZSBpbmRpY2F0 ZWQgdGhhdDxicj4NCnRoZXkgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFkeSwgYW5k IGhhdmUgYXNrZWQgZm9yIFdvcmtpbmc8YnI+DQpHcm91cCBMYXN0IENhbGwuPGJyPg0KPGJyPg0K VGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSBoZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWMvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1hYy88L2E+PGJyPg0KPGJyPg0KUGxlYXNlIHJldmlldyB0 aGlzIGRyYWZ0IHRvIHNlZSBpZiB5b3UgdGhpbmsgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9u PGJyPg0KYW5kIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QsIGNsZWFybHkgc3RhdGluZyB5b3Vy IHZpZXcuPGJyPg0KPGJyPg0KVGhpcyBXR0xDIGVuZHMgTW9uIDIxLUFwci0yMDE0Ljxicj4NCjxi cj4NClRoYW5rcyw8YnI+DQpXYXJyZW4gS3VtYXJpPGJyPg0KKGFzIG9wc2F3ZyBXRyBjby1jaGFp cik8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCk9QU0FXRyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T1BTQVdH QGlldGYub3JnIj5PUFNBV0dAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2ciIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZzwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4ED2E36A22261145861BAB2C24088B4320F76104xmbalnx09ciscoc_-- From nobody Tue Apr 22 11:19:09 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53631A06A9 for ; Tue, 22 Apr 2014 11:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 eyl4PWSs8gbY for ; Tue, 22 Apr 2014 11:18:56 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 99FBF1A0698 for ; Tue, 22 Apr 2014 11:18:56 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hm4so5410wib.2 for ; Tue, 22 Apr 2014 11:18:50 -0700 (PDT) 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:content-type; bh=eKA5mtFK5+W0vCl/7GVCQ+CFfUya689/tV4XW+A0LdM=; b=ffJCM4vGWRcqTpPpRPHfdIPBndteqZbFJZoVphs321t6Q98ZmwWX3OaXjUQBU1NF9r ZVXV4tO2+agicLm5ZzlPOAqEdowecuRwiV+TRE4TumQV15UxR9oBBK+ObKdi0c8bHLiK yC/zsMWR5tihLDe2SuZCsIocS2zkErB12UMCoxR1drTVQy0jjur46EWzKULU99RcFWrG gsgv69qStrwl7ByWEgBycNJxZgf+Q4oi0iK705h+2+ixj0hZxaaA6IOYYRr141bRNofN p8f8mpVa6E64o2alxv39zknQ92xJysQAEfjxvOKqMi4nrsZQkZJZZCJoDnaeWOpIoauF Em7g== X-Gm-Message-State: ALoCoQkpHlcj8pQvwGU509CmtThTDrkuDtnPmXL9hzsGQH4XV3v2g3LdpC8jNzatjWiVzax5U5a3 MIME-Version: 1.0 X-Received: by 10.194.190.42 with SMTP id gn10mr35835678wjc.9.1398190730609; Tue, 22 Apr 2014 11:18:50 -0700 (PDT) Received: by 10.194.54.162 with HTTP; Tue, 22 Apr 2014 11:18:50 -0700 (PDT) X-Originating-IP: [98.244.98.35] In-Reply-To: References: Date: Tue, 22 Apr 2014 14:18:50 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/akD56ukBl6vmPra6PV5z8wVpEus Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 18:19:05 -0000 On Mon, Apr 7, 2014 at 12:44 PM, Warren Kumari wrote: > Dear opsawg WG, > > The authors of draft-ietf-opsawg-capwap-hybridmac have indicated that > they believe that the document is ready, and have asked for Working > Group Last Call. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ > > Please review this draft to see if you think it is ready for publication > and send comments to the list, clearly stating your view. > > This WGLC ends Mon 21-Apr-2014. This WGLC has concluded, thanks to everyone for the feedback. The chairs just met, and have decided that there is sufficient support to progress this. Authors, please spin another version with the nits addressed (some typo's, the nits checker made grumpyface, etc) -- this will help speed it through the IESG. Once you resubmit with these done, please poke me / us to submit to the IESG. Thanks for all the hard work. W > > Thanks, > Warren Kumari > (as opsawg WG co-chair) From nobody Tue Apr 22 11:37:15 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6571A06AD; Tue, 22 Apr 2014 11:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3XghQb_0zxfo; Tue, 22 Apr 2014 11:37:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F41F1A025D; Tue, 22 Apr 2014 11:37:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140422183712.23487.73760.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 11:37:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/qJPHXyrXFr0ISHgAI6k4v7jeh40 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-large-flow-load-balancing-11.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 18:37:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Mechanisms for Optimizing LAG/ECMP Component Link Utilization in Networks Authors : Ram Krishnan Lucy Yong Anoop Ghanwani Ning So Bhumip Khasnabish Filename : draft-ietf-opsawg-large-flow-load-balancing-11.txt Pages : 26 Date : 2014-04-22 Abstract: Demands on networking infrastructure are growing exponentially due to bandwidth hungry applications such as rich media applications and inter-data center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal cost multi-paths as techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-large-flow-load-balancing-11 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 Apr 22 11:40:52 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55C91A024D for ; Tue, 22 Apr 2014 11:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 lpoTJpcphvmE for ; Tue, 22 Apr 2014 11:40:46 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 60E941A0226 for ; Tue, 22 Apr 2014 11:40:46 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so3775654wiv.13 for ; Tue, 22 Apr 2014 11:40:40 -0700 (PDT) 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:content-type; bh=8cn6HGngIRLJhN2OyOQU/CkPMddCw50hQ3EoBxU0uR8=; b=Qf6E9jLIRnB8OyhCDh1IABthPbyfQcEg3eAqk9nN3SABav2AYjJnT0IR8kThxjyxTL V2eiTk5ZXjeVWPjjxcbnBrVRiFzm10rTGm5rcylKBk8f3PVdlr0re/xSOCYzC+T4NyJ+ 9BcmZ/sTfkUTV26aqk4sQsTl3RlkOdmL4tXALO5fvL+kXJ5797zWDhjj8wUgm64+ZjAz XbJRImwSXOa+r0C/QXmnE/GIEr0y8uFcUzB9X6r/1Ls0DPhZNL8TCYFbQ1zQFTIwjn9x BuRmeW/9mPfe+78hp4LiY4RkEHjBzIqGMJCEEys8+Ug8n3dEWQ2QsmHJ4g0DA8GfVP1R 6xCA== X-Gm-Message-State: ALoCoQnG47TvRcqumt6lNDm8QT70QGYkOJG7Pnld9G88SqEAzf/wWGtAv//JvXfg5an4QZ6vxEa8 MIME-Version: 1.0 X-Received: by 10.194.175.70 with SMTP id by6mr35097153wjc.3.1398192040509; Tue, 22 Apr 2014 11:40:40 -0700 (PDT) Received: by 10.194.54.162 with HTTP; Tue, 22 Apr 2014 11:40:40 -0700 (PDT) X-Originating-IP: [98.244.98.35] In-Reply-To: References: Date: Tue, 22 Apr 2014 14:40:40 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , "draft-zhang-opsawg-capwap-cds@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/uNP4iBGl-ccOP1wuJgtO6RmMb3k Subject: Re: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 18:40:50 -0000 On Mon, Apr 7, 2014 at 1:53 PM, Warren Kumari wrote: > Dear opsawg WG, > > This starts a Call for Adoption for draft-zhang-opsawg-capwap-cds. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/ > > Please review this draft to see if you think it is suitable for > adoption by opsawg, > and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > > This call for adoption ends Mon 21-Apr-2014. This CfA concluded and we see support for adopting this work. Dear Authors, please resubmit as draft-ietf-opsawg- Thanks all for commenting, etc. W > > Thanks, > Warren Kumari > (as opsawg WG co-chair) From nobody Tue Apr 22 11:42:06 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070771A022B for ; Tue, 22 Apr 2014 11:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 A9Fsn3tiBLuT for ; Tue, 22 Apr 2014 11:41:59 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EA31A0226 for ; Tue, 22 Apr 2014 11:41:59 -0700 (PDT) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s3MIaLSD017899; Tue, 22 Apr 2014 11:41:51 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1kcht71j2m-16 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Apr 2014 11:41:50 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 22 Apr 2014 11:41:46 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::a540:dc22:25c4:398e]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Tue, 22 Apr 2014 11:41:20 -0700 From: ramki Krishnan To: Anoop Ghanwani , Benoit Claise Date: Tue, 22 Apr 2014 11:41:22 -0700 Thread-Topic: AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response) Thread-Index: Ac9aaI+ydEulVKu3RbamnRbG8THj+wD8V79g Message-ID: References: <534BD465.4090503@cisco.com> <534D2030.3020809@cisco.com> <534E4505.9080806@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C004004482HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-22_06:2014-04-22,2014-04-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404220260 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/GwvC-9NCHoFnH7Y5mstqJoH455s Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 18:42:05 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C004004482HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benoit, Please find updated draft below. We have addressed all your comments. http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing= / Thanks, Anoop & Ramki From: ghanwani@gmail.com [mailto:ghanwani@gmail.com] On Behalf Of Anoop Gha= nwani Sent: Thursday, April 17, 2014 11:11 AM To: Benoit Claise Cc: ramki Krishnan; opsawg@ietf.org Subject: Re: AD review of draft-ietf-opsawg-large-flow-load-balancing (draf= t response) Thanks Benoit. We'll figure out how to account for this in the draft and w= ill have the update posted in the next few days. Anoop On Wed, Apr 16, 2014 at 1:53 AM, Benoit Claise > wrote: Anoop, Benoit, Please see inline. On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise > wrote: On 14/04/2014 19:09, Anoop Ghanwani wrote: Hi Benoit, I will work on the editorials shortly and I'm removing those from the discu= ssion. See below: On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise > wrote: Hi Anoop, Thanks for the new draft version. I removed some of the points On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise > wrote: - A number of routers support sampling techniques such as sFlow [sFlow- v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954]. For the purpose of large flow identification, sampling must be enabled on all of the egress ports in the router where such measurements are desired. I don't understand the second sentence. One way to read this is: sampling must be enabled on all of the egress por= ts where such measurements are desired. Ok, this is an obvious statement. If the measurements are desired, enab= le them Yes, Or maybe you want to say: sampling must be enabled on all of the egress por= ts where such measurements are desired. This is a false statement: if you have the choice between sampling and = non sampling, use non sampling measurements. Or maybe you want to say: sampling must be enabled on all of the egress por= ts where such measurements are desired. This is a false statement: if I have ECMP on 2 links, and only one of t= hem can't do non sampling, then we should not force sampling on both links. You see, I'm confused. You miss a couple of key messages: - if unsampled measurements are available, use those. - egress means where LAG/ECMP are enabled (this is important for the paragr= aph starting with "If egress sampling is not available, ingress sampling ca= n suffice since the central management entity use") We were not intending to discuss a mix sampling and non-sampling interfaces= in the same router, but this is a reasonable point and it will be clarifie= d (i.e. we will state that it's possible to mix sampled and non sampled int= erfaces as long as the function of large flow detection/identification can = be performed). You're still missing the point that unsampled measurements is better than s= ampled ones. We do point this out in Section 4.3.4. http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#s= ection-4.3.4 >>> As link speeds get higher, sampling rates are typically reduced to keep the number of samples manageable which places a lower bound on the detection time. With automatic hardware recognition, large flows can be detected in shorter windows on higher link speeds since every packet is accounted for in hardware [NDTM]. >>> I've seen that, but why do you equate automatic hardware recognition to uns= ampled measurements. Whether it's done in hardware of software is orthogonal. OK, I think I see the reason for the disconnect. In the draft we only talk= ed about automatic hardware recognition and sampling as methods for large f= low recognition. It seems you're suggesting there's a third way -- unsampl= ed measurements (likely in hardware) but use of software for the actual rec= ognition of large flows from those measurements? Can you confirm? If so, = we can add that to the draft as well. I see two only ways: sampled and unsampled. Both could be done in hardware (most likely on router; This is what you cal= led automatic hardware recognition, AFAICT) or software. Whether it's done in hardware of software is orthogonal to the mechanism in= this document. I hope this clarifies Regards, Benoit Is this what you mean by: It is possible that a router may have line cards that support a sampling technique while other line cards support automatic hardware detection of large flows. It's not very clear. No, this does not address your point. This is talking about the case where= line cards have different capabilities, rather than a line card that suppo= rts both. Since we already have the advantages and disadvantages listed in 4.3.4, do = you still see a need for explicitly mentioning that automatic hardware dete= ction is to be preferred over sampling if both are available? We did debate the point about accuracy quite a bit among the authors. The = question is -- does that level of accuracy really matter for the large flow= case? Maybe not (for the details: http://dl.acm.org/citation.cfm?id=3D1791959), b= ut I don't understand why you want to limit this mechanism to sampling only= . Simply telling that sampled data could be good enough, but if you have un= sampled data, you will get a better accuracy. Thanks for the reference. Since we are dealing with flows that need to consume a certain percent of t= he link bandwidth, sampling, if configured correctly, And you don't go in the details of "sampling, if configured correctly"... There are suggestions in some of the references (e.g. the DevoFlow paper), = but there are also other references, e.g. http://www.sflow.org/packetSamplingBasics/index.htm. This is a general sa= mpling problem, rather than something that was introduced by this draft. I= f you think it would be useful to add something (or maybe just pointers to = the references), that can be done. Anoop --_000_C7634EB63EFD984A978DFB46EA5174F2C004004482HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Benoit= ,

 =

Please find updated draft below. We have ad= dressed all your comments.

http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow= -load-balancing/

 

Thanks,

Anoop & Ramki

 

= From:= ghanwani@gmail.com [mailto:ghanwani@gmail.com] On Behalf Of Anoo= p Ghanwani
Sent: Thursday, April 17, 2014 11:11 AM
To: = Benoit Claise
Cc: ramki Krishnan; opsawg@ietf.org
Subject:<= /b> Re: AD review of draft-ietf-opsawg-large-flow-load-balancing (draft res= ponse)

 

=

Thanks Benoit.  We'll figure out how to account f= or this in the draft and will have the update posted in the next few days.<= o:p>

 

Anoop

 

On Wed, Apr 16, 2014 at 1:53 AM, Benoit Claise <bclaise@cisco.com> wrote:

Anoop,

=

Benoit,

 

Please see inline.

=

 

On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise <= bclaise@cisco.com> wrote:

 

On Mon, Apr 14, 2014 at 5:28 AM= , Benoit Claise <= bclaise@cisco.com> wrote:

Hi= Anoop,

Thanks for the new draft version.
I removed some of the p= oints

 

<= o:p> 

On T= ue, Feb 18, 2014 at 7:55 AM, Benoit Claise <bclaise@cisco.com> wrote:

<= /div>

-

 

   A number of routers suppor=
t sampling techniques such as sFlow [sFlow-
 &nbs=
p; v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954].
   For the purpose of large flow identification, s=
ampling must be
   enabled on all of the egr=
ess ports in the router where such
   measur=
ements are desired.

I don't understand= the second sentence.
One way to read this is:  sampling must be enabled on all of the egress ports where such measurements are desired= .
    Ok, this is an obvious statement. If the measureme= nts are desired, enable them

 

Yes,

  

Or maybe you want to say: sampling must be enabled on = all of the egress ports where such measurements are desired.
 &nbs= p;  This is a false statement: if you have the choice between sampling= and non sampling, use non sampling measurements.
Or maybe you want to s= ay: sampling must be enabled on all of the egress ports where such m= easurements are desired.
    This is a false statement: = if I have ECMP on 2 links, and only one of them can't do non sampling, then= we should not force
    sampling on both links.
You s= ee, I'm confused.

You miss a couple of key messages:
- if unsampl= ed measurements are available, use those.
- egress means where LAG/ECMP = are enabled (this is important for the paragraph starting with "If egr= ess sampling is not available, ingress sampling can suffice since the centr= al management entity use")

 

We were not intending to discuss a mix sampling and non-sampling inte= rfaces in the same router, but this is a reasonable point and it will be cl= arified (i.e. we will state that it's possible to mix sampled and non sampl= ed interfaces as long as the function of large flow detection/identificatio= n can be performed).

You're still mi= ssing the point that unsampled measurements is better than sampled ones.

 

We do point this out in Section 4.3.4.

=

>>>=  

 =
;       As link speeds get higher, sampling r=
ates are typically reduced
        to keep the number =
of samples manageable which places a lower
        bou=
nd on the detection time.  With automatic hardware
     &nb=
sp;  recognition, large flows can be detected in shorter windows on
  &nbs=
p;     higher link speeds since every packet is account=
ed for in
&nbs=
p;       hardware [NDTM].

>>> 

<= /div>

I've seen that, but why do you equate autom= atic hardware recognition to unsampled measurements.
Whether it's= done in hardware of software is orthogonal.

 

 

OK, I think I see the rea= son for the disconnect.  In the draft we only talked about automatic h= ardware recognition and sampling as methods for large flow recognition. &nb= sp;It seems you're suggesting there's a third way -- unsampled measurements= (likely in hardware) but use of software for the actual recognition of lar= ge flows from those measurements?  Can you confirm?  If so, we ca= n add that to the draft as well.

I see two only ways: sample= d and unsampled.
Both could be done in hardware (most likely on router; = This is what you called automatic hardware recognition, AFAICT) or software= .
Whether it's done in hardware of software is orthogonal to the mechani= sm in this document.

I hope this clarifies

Regards, Benoit



 


Is this what you mean b= y:

It is possible that a router may have line cards that=
 support a
sampling technique while other line cards s=
upport automatic hardware
detection of large flows.

It's not very clear.

 

<= p class=3DMsoNormal> 

No= , this does not address your point.  This is talking about the case wh= ere line cards have different capabilities, rather than a line card that su= pports both.

 

Since we already have the advantages a= nd disadvantages listed in 4.3.4, do you still see a need for explicitly me= ntioning that automatic hardware detection is to be preferred over sampling= if both are available?

=  

We did debate the point abo= ut accuracy quite a bit among the authors.  The question is -- does th= at level of accuracy really matter for the large flow case?

=

Maybe not (= for the details: http://dl.acm.org/citation.cfm?id=3D1791959), but I don= 't understand why you want to limit this mechanism to sampling only. Simply= telling that sampled data could be good enough, but if you have unsampled = data, you will get a better accuracy.

 

 

Thanks for the refere= nce. 

Since we are dealing with flows = that need to consume a certain percent of the link bandwidth, sampling, if = configured correctly,

<= /div>

And you don't go in the details of "sampling= , if configured correctly"...

 

The= re are suggestions in some of the references (e.g. the DevoFlow paper), but= there are also other references, e.g.

http://www.sflow.org/packetSamplingBasics/index.htm. &= nbsp; This is a general sampling problem, rather than something that was in= troduced by this draft.  If you think it would be useful to add someth= ing (or maybe just pointers to the references), that can be done.

 

Anoop

 

 

= --_000_C7634EB63EFD984A978DFB46EA5174F2C004004482HQ1EXCH01corp_-- From nobody Tue Apr 22 14:49:47 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1CF1A027C for ; Tue, 22 Apr 2014 14:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 EVoriUdKhB5V for ; Tue, 22 Apr 2014 14:49:38 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCFA1A0278 for ; Tue, 22 Apr 2014 14:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48603; q=dns/txt; s=iport; t=1398203371; x=1399412971; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=tXNsbbzQ3K7Y4NtfHIlprfwTLdd8rmpWn34S4MrIhk8=; b=NeupyQfy5ib90lDle4hDEukI4sg634UIJECRCReZDB/sdIwWL+zjmD5R 6QvZnum0YfE13p5xGrHnsboaK8vUWbe3czHRemOZy56/lshczaSweZTnL rA6AXnTqisBwWfRrsJFK51VWJlFqXS3RMldN1TtR5EXzaT51exDt7kO+r Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAHLiVlOQ/khL/2dsb2JhbABZDoI0RE/EdoEWFnSCJQEBAQQtSwEQCxEEAQEBCQwKAQEGBwkDAgECAQ8lCQgGAQwBBQIBAQWIJAMRDcgiDYVqF4w+gUFXBgEKhC4ElwKBboE3hSKGJ4VSgnFCO4Et X-IronPort-AV: E=Sophos; i="4.97,906,1389744000"; d="scan'208,217"; a="19511811" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-4.cisco.com with ESMTP; 22 Apr 2014 21:49:29 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3MLnSvs025826; Tue, 22 Apr 2014 21:49:28 GMT Message-ID: <5356E3E8.9060106@cisco.com> Date: Tue, 22 Apr 2014 23:49:28 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ramki Krishnan , Anoop Ghanwani References: <534BD465.4090503@cisco.com> <534D2030.3020809@cisco.com> <534E4505.9080806@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000001080505080609000803" Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/SG4PTGuwn1DbBOIQsP5np1XOzKg Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 21:49:44 -0000 This is a multi-part message in MIME format. --------------000001080505080609000803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks. The IETF LC has been requested. Regards, Benoit > > Hi Benoit, > > Please find updated draft below. We have addressed all your comments. > > http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/ > > Thanks, > > Anoop & Ramki > > *From:*ghanwani@gmail.com [mailto:ghanwani@gmail.com] *On Behalf Of > *Anoop Ghanwani > *Sent:* Thursday, April 17, 2014 11:11 AM > *To:* Benoit Claise > *Cc:* ramki Krishnan; opsawg@ietf.org > *Subject:* Re: AD review of > draft-ietf-opsawg-large-flow-load-balancing (draft response) > > Thanks Benoit. We'll figure out how to account for this in the draft > and will have the update posted in the next few days. > > Anoop > > On Wed, Apr 16, 2014 at 1:53 AM, Benoit Claise > wrote: > > Anoop, > > Benoit, > > Please see inline. > > On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise > wrote: > > On 14/04/2014 19:09, Anoop Ghanwani wrote: > > Hi Benoit, > > I will work on the editorials shortly and I'm removing those > from the discussion. See below: > > On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise > > wrote: > > Hi Anoop, > > Thanks for the new draft version. > I removed some of the points > > On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise > > wrote: > > - > > A number of routers support sampling techniques such as sFlow [sFlow- > > v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954]. > > For the purpose of large flow identification, sampling must be > > enabled on all of the egress ports in the router where such > > measurements are desired. > > I don't understand the second sentence. > One way to read this is: sampling must be _enabled _on > all of the egress ports where such measurements are > desired. > Ok, this is an obvious statement. If the > measurements are desired, enable them > > Yes, > > Or maybe you want to say: _sampling _must be enabled > on all of the egress ports where such measurements are > desired. > This is a false statement: if you have the choice > between sampling and non sampling, use non sampling > measurements. > Or maybe you want to say: sampling must be enabled on > _all _of the egress ports where such measurements are > desired. > This is a false statement: if I have ECMP on 2 > links, and only one of them can't do non sampling, > then we should not force > sampling on both links. > You see, I'm confused. > > You miss a couple of key messages: > - if unsampled measurements are available, use those. > - egress means where LAG/ECMP are enabled (this is > important for the paragraph starting with "If egress > sampling is not available, ingress sampling can > suffice since the central management entity use") > > We were not intending to discuss a mix sampling and > non-sampling interfaces in the same router, but this is a > reasonable point and it will be clarified (i.e. we will > state that it's possible to mix sampled and non sampled > interfaces as long as the function of large flow > detection/identification can be performed). > > You're still missing the point that unsampled measurements is > better than sampled ones. > > We do point this out in Section 4.3.4. > > http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-10#section-4.3.4 > > >>> > > As link speeds get higher, sampling rates are typically reduced > > to keep the number of samples manageable which places a lower > > bound on the detection time. With automatic hardware > > recognition, large flows can be detected in shorter windows on > > higher link speeds since every packet is accounted for in > > hardware [NDTM ]. > > >>> > > I've seen that, but why do you equate automatic _hardware > _recognition to unsampled measurements. > Whether it's done in hardware of software is orthogonal. > > OK, I think I see the reason for the disconnect. In the draft we > only talked about automatic hardware recognition and sampling as > methods for large flow recognition. It seems you're suggesting > there's a third way -- unsampled measurements (likely in hardware) > but use of software for the actual recognition of large flows from > those measurements? Can you confirm? If so, we can add that to > the draft as well. > > I see two only ways: sampled and unsampled. > Both could be done in hardware (most likely on router; This is what > you called automatic hardware recognition, AFAICT) or software. > Whether it's done in hardware of software is orthogonal to the > mechanism in this document. > > I hope this clarifies > > Regards, Benoit > > > > > Is this what you mean by: > > It is possible that a router may have line cards that support a > > sampling technique while other line cards support automatic hardware > > detection of large flows. > > It's not very clear. > > No, this does not address your point. This is talking about > the case where line cards have different capabilities, rather > than a line card that supports both. > > Since we already have the advantages and disadvantages listed > in 4.3.4, do you still see a need for explicitly mentioning > that automatic hardware detection is to be preferred over > sampling if both are available? > > We did debate the point about accuracy quite a bit among the > authors. The question is -- does that level of accuracy > really matter for the large flow case? > > Maybe not (for the details: > http://dl.acm.org/citation.cfm?id=1791959), but I don't understand > why you want to limit this mechanism to sampling only. Simply > telling that sampled data could be good enough, but if you have > unsampled data, you will get a better accuracy. > > Thanks for the reference. > > Since we are dealing with flows that need to consume a certain > percent of the link bandwidth, sampling, if configured correctly, > > And you don't go in the details of "sampling, if configured > correctly"... > > There are suggestions in some of the references (e.g. the DevoFlow > paper), but there are also other references, e.g. > > http://www.sflow.org/packetSamplingBasics/index.htm. This is a > general sampling problem, rather than something that was introduced by > this draft. If you think it would be useful to add something (or > maybe just pointers to the references), that can be done. > > Anoop > --------------000001080505080609000803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thanks.
The IETF LC has been requested.

Regards, Benoit

Hi Benoit,

 

Please find updated draft below. We have addressed all your comments.

http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/

 

Thanks,

Anoop & Ramki

 

From: ghanwani@gmail.com [mailto:ghanwani@gmail.com] On Behalf Of Anoop Ghanwani
Sent: Thursday, April 17, 2014 11:11 AM
To: Benoit Claise
Cc: ramki Krishnan; opsawg@ietf.org
Subject: Re: AD review of draft-ietf-opsawg-large-flow-load-balancing (draft response)

 

Thanks Benoit.  We'll figure out how to account for this in the draft and will have the update posted in the next few days.

 

Anoop

 

On Wed, Apr 16, 2014 at 1:53 AM, Benoit Claise <bclaise@cisco.com> wrote:

Anoop,

Benoit,

 

Please see inline.

 

On Tue, Apr 15, 2014 at 5:04 AM, Benoit Claise <bclaise@cisco.com> wrote:

On 14/04/2014 19:09, Anoop Ghanwani wrote:

Hi Benoit,

 

I will work on the editorials shortly and I'm removing those from the discussion.   See below:

 

 

On Mon, Apr 14, 2014 at 5:28 AM, Benoit Claise <bclaise@cisco.com> wrote:

Hi Anoop,

Thanks for the new draft version.
I removed some of the points

 

 

On Tue, Feb 18, 2014 at 7:55 AM, Benoit Claise <bclaise@cisco.com> wrote:

-

 

   A number of routers support sampling techniques such as sFlow [sFlow-
   v5, sFlow-LAG], PSAMP [RFC 5475] and NetFlow Sampling [RFC 3954].
   For the purpose of large flow identification, sampling must be
   enabled on all of the egress ports in the router where such
   measurements are desired.

I don't understand the second sentence.
One way to read this is:  sampling must be enabled on all of the egress ports where such measurements are desired.
    Ok, this is an obvious statement. If the measurements are desired, enable them

 

Yes,

  

Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
    This is a false statement: if you have the choice between sampling and non sampling, use non sampling measurements.
Or maybe you want to say: sampling must be enabled on all of the egress ports where such measurements are desired.
    This is a false statement: if I have ECMP on 2 links, and only one of them can't do non sampling, then we should not force
    sampling on both links.
You see, I'm confused.

You miss a couple of key messages:
- if unsampled measurements are available, use those.
- egress means where LAG/ECMP are enabled (this is important for the paragraph starting with "If egress sampling is not available, ingress sampling can suffice since the central management entity use")

 

We were not intending to discuss a mix sampling and non-sampling interfaces in the same router, but this is a reasonable point and it will be clarified (i.e. we will state that it's possible to mix sampled and non sampled interfaces as long as the function of large flow detection/identification can be performed).

You're still missing the point that unsampled measurements is better than sampled ones.

 

We do point this out in Section 4.3.4.

>>> 

        As link speeds get higher, sampling rates are typically reduced
        to keep the number of samples manageable which places a lower
        bound on the detection time.  With automatic hardware
        recognition, large flows can be detected in shorter windows on
        higher link speeds since every packet is accounted for in
        hardware [NDTM].

>>> 

I've seen that, but why do you equate automatic hardware recognition to unsampled measurements.
Whether it's done in hardware of software is orthogonal.

 

 

OK, I think I see the reason for the disconnect.  In the draft we only talked about automatic hardware recognition and sampling as methods for large flow recognition.  It seems you're suggesting there's a third way -- unsampled measurements (likely in hardware) but use of software for the actual recognition of large flows from those measurements?  Can you confirm?  If so, we can add that to the draft as well.

I see two only ways: sampled and unsampled.
Both could be done in hardware (most likely on router; This is what you called automatic hardware recognition, AFAICT) or software.
Whether it's done in hardware of software is orthogonal to the mechanism in this document.

I hope this clarifies

Regards, Benoit



 


Is this what you mean by:

It is possible that a router may have line cards that support a
sampling technique while other line cards support automatic hardware
detection of large flows.

It's not very clear.

 

 

No, this does not address your point.  This is talking about the case where line cards have different capabilities, rather than a line card that supports both.

 

Since we already have the advantages and disadvantages listed in 4.3.4, do you still see a need for explicitly mentioning that automatic hardware detection is to be preferred over sampling if both are available?

 

We did debate the point about accuracy quite a bit among the authors.  The question is -- does that level of accuracy really matter for the large flow case?

Maybe not (for the details: http://dl.acm.org/citation.cfm?id=1791959), but I don't understand why you want to limit this mechanism to sampling only. Simply telling that sampled data could be good enough, but if you have unsampled data, you will get a better accuracy.

 

 

Thanks for the reference. 

Since we are dealing with flows that need to consume a certain percent of the link bandwidth, sampling, if configured correctly,

And you don't go in the details of "sampling, if configured correctly"...

 

There are suggestions in some of the references (e.g. the DevoFlow paper), but there are also other references, e.g.

http://www.sflow.org/packetSamplingBasics/index.htm.   This is a general sampling problem, rather than something that was introduced by this draft.  If you think it would be useful to add something (or maybe just pointers to the references), that can be done.

 

Anoop

 

 


--------------000001080505080609000803-- From nobody Tue Apr 22 15:25:17 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1874A1A0283; Tue, 22 Apr 2014 15:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 j9hFCsJvfvkb; Tue, 22 Apr 2014 15:25:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 160D91A0216; Tue, 22 Apr 2014 15:25:10 -0700 (PDT) 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: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140422222510.11334.73185.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 15:25:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/FTHiZdTLuMotDpwgEakCsqKzLAI Cc: opsawg@ietf.org Subject: [OPSAWG] Last Call: (Mechanisms for Optimizing LAG/ECMP Component Link Utilization in Networks) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 22:25:15 -0000 The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Mechanisms for Optimizing LAG/ECMP Component Link Utilization in Networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-05-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Demands on networking infrastructure are growing exponentially due to bandwidth hungry applications such as rich media applications and inter-data center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal cost multi-paths as techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Apr 22 21:15:24 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31841A0034 for ; Tue, 22 Apr 2014 21:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 dEY3-mSrSqU2 for ; Tue, 22 Apr 2014 21:15:18 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id EF92D1A004C for ; Tue, 22 Apr 2014 21:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1347; q=dns/txt; s=iport; t=1398226512; x=1399436112; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BRJJ7D/6ROSwn9GUieZSFL8meCsJvot1lMb2txwxtmU=; b=a7LfclawvD6JqaMNNPclnaIup+8kwdtVwwDwLktkBgIWasse2YTPbn3e VnUs2xoTaDIt2uwGS5pGHD3bJhxxaRhEYV2M7uj1VktlmrTUh1PUbs//9 Pa52cjeUZ6NIrqZc423nWYsgHOEUNt1PfgrVqCbocFWpOkYuZl5cfhRhj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAA8+V1OtJV2Y/2dsb2JhbABZgwZPV70ChmlRgRYWdIIlAQEBAwEBAQEaHTQXBAIBCBEEAQEBChQJBycLFAkIAgQBEgiIMQgNzy0TBI4nOAaDHoEVBKtKgzGCKw X-IronPort-AV: E=Sophos;i="4.97,909,1389744000"; d="scan'208";a="37968655" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP; 23 Apr 2014 04:14:50 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3N4EovM000584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 04:14:50 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 23:14:50 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Warren Kumari , "opsawg@ietf.org" , "draft-zhang-opsawg-capwap-cds@tools.ietf.org" Thread-Topic: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds Thread-Index: AQHPUopoTVzdFWt2DUOz9/u42eQw/ZseY3QAgABMdTA= Date: Wed, 23 Apr 2014 04:14:50 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F7631B@xmb-aln-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/SHkWN947siQbgkQfCKGfainFw3I Subject: Re: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 04:15:23 -0000 Hello Warren Thanks for shepherding this through.=20 I will do the needful with regards to creating a new draft.=20 Regards Rajesh -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Tuesday, April 22, 2014 11:41 AM To: opsawg@ietf.org; draft-zhang-opsawg-capwap-cds@tools.ietf.org Subject: Re: [OPSAWG] Call for Adoption: draft-zhang-opsawg-capwap-cds On Mon, Apr 7, 2014 at 1:53 PM, Warren Kumari wrote: > Dear opsawg WG, > > This starts a Call for Adoption for draft-zhang-opsawg-capwap-cds. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/ > > Please review this draft to see if you think it is suitable for=20 > adoption by opsawg, and comments to the list, clearly stating your=20 > view. > > Please also indicate if you are willing to contribute text, review, etc. > > > This call for adoption ends Mon 21-Apr-2014. This CfA concluded and we see support for adopting this work. Dear Authors, please resubmit as draft-ietf-opsawg- Thanks all for commenting, etc. W > > Thanks, > Warren Kumari > (as opsawg WG co-chair) _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Apr 22 21:16:24 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A0B1A004C for ; Tue, 22 Apr 2014 21:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 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.272, 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 ZOxSKe6XrYy9 for ; Tue, 22 Apr 2014 21:16:17 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 86E121A003B for ; Tue, 22 Apr 2014 21:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1461; q=dns/txt; s=iport; t=1398226572; x=1399436172; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Ci1E/HaUnx2YY4mxansLqbd8ifN2NibESjMEO70JrWo=; b=LfGTzcYk+UYdwbSiEJFltz4y4oB7sl8+KpobQSgRiEy7PTsZJ7nkE2R/ 7WKEqwVRU0TQIXl0y3aaYZPfiV2uqWF+jUbj/MH0v06R7SpiR2DSoUXoW GbFaAnKVB/vnjGDstFJjaXddIhVPqUDaEQqwZfAwd85A7K291kZuiNBhA M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAF09V1OtJV2d/2dsb2JhbABZgwZPV8Q8gRYWdIIlAQEBAwE6SwQCAQgRBAEBAQoUCQcyFAkIAgQBEgiIMQgNzzkTBI4nOAaDHoEVBKtKgzGCKw X-IronPort-AV: E=Sophos;i="4.97,909,1389744000"; d="scan'208";a="319682276" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 23 Apr 2014 04:16:12 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3N4GBTC014804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 04:16:11 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 23:16:11 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Warren Kumari , "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org" Thread-Topic: Start of WGLC for draft-ietf-opsawg-capwap-hybridmac Thread-Index: AQHPXldbf6pywHaTjUaLzQO/xUI3SpsemJhQ Date: Wed, 23 Apr 2014 04:16:11 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F7632B@xmb-aln-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Jl3U92Bqh8YYdNEclnFGuK61dI0 Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 04:16:22 -0000 Hello Warren,=20 I will address the nits and submit a new version.=20 Thanks for shepherding this through.=20 Regards Rajesh -----Original Message----- From: Warren Kumari [mailto:warren@kumari.net]=20 Sent: Tuesday, April 22, 2014 11:19 AM To: opsawg@ietf.org; draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org Subject: Re: Start of WGLC for draft-ietf-opsawg-capwap-hybridmac On Mon, Apr 7, 2014 at 12:44 PM, Warren Kumari wrote: > Dear opsawg WG, > > The authors of draft-ietf-opsawg-capwap-hybridmac have indicated that=20 > they believe that the document is ready, and have asked for Working=20 > Group Last Call. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ > > Please review this draft to see if you think it is ready for=20 > publication and send comments to the list, clearly stating your view. > > This WGLC ends Mon 21-Apr-2014. This WGLC has concluded, thanks to everyone for the feedback. The chairs just met, and have decided that there is sufficient support to p= rogress this. Authors, please spin another version with the nits addressed (some typo's, = the nits checker made grumpyface, etc) -- this will help speed it through t= he IESG. Once you resubmit with these done, please poke me / us to submit to the IES= G. Thanks for all the hard work. W > > Thanks, > Warren Kumari > (as opsawg WG co-chair) From nobody Wed Apr 23 01:39:33 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB0C1A00DD for ; Wed, 23 Apr 2014 01:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.871 X-Spam-Level: X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] 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 qHpZDdQnFGLz for ; Wed, 23 Apr 2014 01:39:27 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 43EEF1A0113 for ; Wed, 23 Apr 2014 01:39:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUKAMl6V1OHCzIm/2dsb2JhbABZgkIjIU9Xgw+nOJIWG4ZpURl+FnSCJQEBAQEDAQEBDxEKQQsQAgEIDQQEAQELHQMCAgIlCxQJCAIEAQ0FCBqIHwEMoT+KRqMuEwSOJy0EBgGCbzWBFQSfd4tTgzGCKw X-IronPort-AV: E=Sophos; i="4.97,910,1389762000"; d="scan'208,217"; a="51616225" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Apr 2014 04:39:19 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 23 Apr 2014 04:38:24 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Wed, 23 Apr 2014 04:39:16 -0400 From: "Romascanu, Dan (Dan)" To: "Rajesh Pazhyannur (rpazhyan)" , "sarikaya@ieee.org" , Warren Kumari Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac Thread-Index: AQHPXZ7pTK2WXo7lGkep+DDcRLYAq5sdzAwAgAEXOHA= Date: Wed, 23 Apr 2014 08:39:16 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7C4E09@AZ-FFEXMB04.global.avaya.com> References: <4ED2E36A22261145861BAB2C24088B4320F76104@xmb-aln-x09.cisco.com> In-Reply-To: <4ED2E36A22261145861BAB2C24088B4320F76104@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C7C4E09AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/47k0PmRJbgcVvq-k5NT-cq2ZYZk Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 08:39:31 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7C4E09AZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCB0byBiZSBjbGVhciDigJMgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIG5hbWUgb2YgdGhl IEktRCBmaWxlIHdoaWNoIHdpbGwgYW55d2F5IGJlIGxvc3QgYXQgdGhlIHB1YmxpY2F0aW9uIG9m IHRoZSBmdXR1cmUgUkZDIChpZiBhcHByb3ZlZCkuIFRoZSBuYW1lIG9mIHRoZSBkb2N1bWVudCBy ZWZsZWN0cyBjb3JyZWN0bHkgdGhlIGNvbnRlbnQgSU1PLg0KDQpSZWdhcmRzLA0KDQpEYW4NCg0K DQpGcm9tOiBPUFNBV0cgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFJhamVzaCBQYXpoeWFubnVyIChycGF6aHlhbikNClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDIy LCAyMDE0IDg6NTggUE0NClRvOiBzYXJpa2F5YUBpZWVlLm9yZzsgV2FycmVuIEt1bWFyaQ0KQ2M6 IG9wc2F3Z0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1hY0B0b29s cy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPUFNBV0ddIFN0YXJ0IG9mIFdHTEMgZm9yIGRyYWZ0 LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWMNCg0KQmVoY2V0DQoNClRoZSBwb2ludCB5b3Ug cmFpc2UgaGFkIGJlZW4gYnJvdWdodCB1cCBlYXJsaWVyIGJ5IERvcm90aHkgUy4gYW5kIHRoZSB0 ZXh0IHdhcyB1cGRhdGVkIGFwcHJvcHJpYXRlbHkuDQpJIGJlbGlldmUgaXQgd2FzIGRpZmZpY3Vs dCB0byBjaGFuZ2UgdGhlIHRpdGxlIHdpdGhvdXQgcmVzdGFydGluZyB0aGUgdmVyc2lvbmluZyBw cm9jZXNzLiBBcyBhIHJlc3VsdCwgdGhlIHRpdGxlIHN0aWxsIGhhcyBIeWJyaWQtTUFDIGluIHRo ZSBuYW1lLg0KU28sIGJlc2lkZXMgdGhlIHRpdGxlIOKAnGh5YnJpZOKAnSBkb2VzIG5vdCBhcHBl YXIgYW55d2hlcmUgZWxzZSBhbmQgdGhlIHRpdGxlIHdpbGwgZ28gYXdheSBvbmNlIHRoaXMgYmVj b21lcyBhIFJGQy4NCg0KUmVnYXJkcw0KDQpSYWplc2gNCkZyb206IE9QU0FXRyBbbWFpbHRvOm9w c2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVoY2V0IFNhcmlrYXlhDQpTZW50 OiBNb25kYXksIEFwcmlsIDIxLCAyMDE0IDE6MTkgUE0NClRvOiBXYXJyZW4gS3VtYXJpDQpDYzog b3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW9wc2F3 Zy1jYXB3YXAtaHlicmlkbWFjQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9wc2F3 Zy1jYXB3YXAtaHlicmlkbWFjQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPUFNBV0dd IFN0YXJ0IG9mIFdHTEMgZm9yIGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWMNCg0K SGkgYWxsLA0KSSBoYXZlIHByb2JsZW0gaW4gdGhlIEh5YnJpZCBNQUMgdGVybWlub2xvZ3kgdXNl ZCBpbiB0aGlzIGRyYWZ0Lg0KVGhlIGRyYWZ0IGJhc2ljYWxseSBkZXNjcmliZXMgYW4gaW1wcm92 ZWQgc3BsaXQgTUFDIHByb2ZpbGUgYXMgc3VjaCBpdCBzaG91bGQgYmUgbmFtZWQgYWNjb3JkaW5n bHkuDQpUaGUgZHJhZnQgZG9lcyBub3QgZGVmaW5lIGEgbmV3IHRoaW5nIHN1Y2ggYXMgbG9jYWwg TUFDIG9yIHNwbGl0IE1BQyBhcyBpbiBDQVBXQVAgZG9jdW1lbnRzIHRvIGRlc2VydmUgdG8gYmUg Y2FsbGVkIGRlZmluaW5nICJoeWJyaWQgTUFDIi4NCklmIHRoZSBhYm92ZSBjb25jZXJuIGlzIGhh bmRsZWQsIEkgYW0gcmVhZHkgdG8gc3VwcG9ydCB0aGUgYWRvcHRpb24uDQpSZWdhcmRzLA0KQmVo Y2V0DQoNCk9uIE1vbiwgQXByIDcsIDIwMTQgYXQgMTE6NDQgQU0sIFdhcnJlbiBLdW1hcmkgPHdh cnJlbkBrdW1hcmkubmV0PG1haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldD4+IHdyb3RlOg0KRGVhciBv cHNhd2cgV0csDQoNClRoZSBhdXRob3JzIG9mIGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJy aWRtYWMgaGF2ZSBpbmRpY2F0ZWQgdGhhdA0KdGhleSBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50 IGlzIHJlYWR5LCBhbmQgaGF2ZSBhc2tlZCBmb3IgV29ya2luZw0KR3JvdXAgTGFzdCBDYWxsLg0K DQpUaGUgZHJhZnQgaXMgYXZhaWxhYmxlIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjLw0KDQpQbGVhc2UgcmV2 aWV3IHRoaXMgZHJhZnQgdG8gc2VlIGlmIHlvdSB0aGluayBpdCBpcyByZWFkeSBmb3IgcHVibGlj YXRpb24NCmFuZCBzZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBjbGVhcmx5IHN0YXRpbmcgeW91 ciB2aWV3Lg0KDQpUaGlzIFdHTEMgZW5kcyBNb24gMjEtQXByLTIwMTQuDQoNClRoYW5rcywNCldh cnJlbiBLdW1hcmkNCihhcyBvcHNhd2cgV0cgY28tY2hhaXIpDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFNBV0cgbWFpbGluZyBsaXN0DQpPUFNB V0dAaWV0Zi5vcmc8bWFpbHRvOk9QU0FXR0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb3BzYXdnDQoNCg== --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7C4E09AZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDsNCglm b250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9u Om5vbmUgbm9uZTt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkp1 c3QgdG8gYmUgY2xlYXIg4oCTIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBuYW1lIG9mIHRoZSBJ LUQgZmlsZSB3aGljaCB3aWxsIGFueXdheSBiZSBsb3N0IGF0IHRoZSBwdWJsaWNhdGlvbiBvZiB0 aGUgZnV0dXJlIFJGQyAoaWYgYXBwcm92ZWQpLiBUaGUgbmFtZSBvZiB0aGUNCiBkb2N1bWVudCBy ZWZsZWN0cyBjb3JyZWN0bHkgdGhlIGNvbnRlbnQgSU1PLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9QU0FXRyBbbWFpbHRvOm9wc2F3 Zy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5SYWplc2ggUGF6aHlhbm51 ciAocnBhemh5YW4pPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDIyLCAyMDE0IDg6 NTggUE08YnI+DQo8Yj5Ubzo8L2I+IHNhcmlrYXlhQGllZWUub3JnOyBXYXJyZW4gS3VtYXJpPGJy Pg0KPGI+Q2M6PC9iPiBvcHNhd2dAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1o eWJyaWRtYWNAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPUFNBV0dd IFN0YXJ0IG9mIFdHTEMgZm9yIGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkJlaGNldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUg cG9pbnQgeW91IHJhaXNlIGhhZCBiZWVuIGJyb3VnaHQgdXAgZWFybGllciBieSBEb3JvdGh5IFMu IGFuZCB0aGUgdGV4dCB3YXMgdXBkYXRlZCBhcHByb3ByaWF0ZWx5Lg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IGJlbGlldmUgaXQgd2FzIGRpZmZpY3VsdCB0byBjaGFuZ2UgdGhlIHRpdGxlIHdpdGhvdXQgcmVz dGFydGluZyB0aGUgdmVyc2lvbmluZyBwcm9jZXNzLiBBcyBhIHJlc3VsdCwgdGhlIHRpdGxlIHN0 aWxsIGhhcyBIeWJyaWQtTUFDIGluIHRoZSBuYW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28sIGJlc2lkZXMg dGhlIHRpdGxlIOKAnGh5YnJpZOKAnSBkb2VzIG5vdCBhcHBlYXIgYW55d2hlcmUgZWxzZSBhbmQg dGhlIHRpdGxlIHdpbGwgZ28gYXdheSBvbmNlIHRoaXMgYmVjb21lcyBhIFJGQy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5SYWplc2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT1BTQVdHIFs8YSBocmVmPSJtYWlsdG86b3BzYXdnLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkJlaGNldCBTYXJpa2F5YTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFw cmlsIDIxLCAyMDE0IDE6MTkgUE08YnI+DQo8Yj5Ubzo8L2I+IFdhcnJlbiBLdW1hcmk8YnI+DQo8 Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0Zi5vcmciPm9wc2F3Z0BpZXRmLm9y ZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFj QHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWNAdG9v bHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT1BTQVdHXSBTdGFydCBv ZiBXR0xDIGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBhbGwsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBwcm9ibGVtIGluIHRo ZSBIeWJyaWQgTUFDIHRlcm1pbm9sb2d5IHVzZWQgaW4gdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5UaGUgZHJhZnQgYmFzaWNhbGx5IGRlc2NyaWJlcyBhbiBpbXByb3ZlZCBzcGxpdCBNQUMg cHJvZmlsZSBhcyBzdWNoIGl0IHNob3VsZCBiZSBuYW1lZCBhY2NvcmRpbmdseS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5UaGUgZHJhZnQgZG9lcyBub3QgZGVmaW5lIGEgbmV3IHRoaW5nIHN1Y2ggYXMgbG9j YWwgTUFDIG9yIHNwbGl0IE1BQyBhcyBpbiBDQVBXQVAgZG9jdW1lbnRzIHRvIGRlc2VydmUgdG8g YmUgY2FsbGVkIGRlZmluaW5nICZxdW90O2h5YnJpZCBNQUMmcXVvdDsuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+SWYgdGhlIGFib3ZlIGNvbmNlcm4gaXMgaGFuZGxlZCwgSSBhbSByZWFkeSB0byBzdXBwb3J0 IHRoZSBhZG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWhjZXQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEFwciA3LCAyMDE0 IGF0IDExOjQ0IEFNLCBXYXJyZW4gS3VtYXJpICZsdDs8YSBocmVmPSJtYWlsdG86d2FycmVuQGt1 bWFyaS5uZXQiIHRhcmdldD0iX2JsYW5rIj53YXJyZW5Aa3VtYXJpLm5ldDwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBvcHNhd2cgV0csPGJy Pg0KPGJyPg0KVGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1h YyBoYXZlIGluZGljYXRlZCB0aGF0PGJyPg0KdGhleSBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50 IGlzIHJlYWR5LCBhbmQgaGF2ZSBhc2tlZCBmb3IgV29ya2luZzxicj4NCkdyb3VwIExhc3QgQ2Fs bC48YnI+DQo8YnI+DQpUaGUgZHJhZnQgaXMgYXZhaWxhYmxlIGhlcmU6PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2Fw LWh5YnJpZG1hYy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjLzwvYT48YnI+DQo8YnI+DQpQ bGVhc2UgcmV2aWV3IHRoaXMgZHJhZnQgdG8gc2VlIGlmIHlvdSB0aGluayBpdCBpcyByZWFkeSBm b3IgcHVibGljYXRpb248YnI+DQphbmQgc2VuZCBjb21tZW50cyB0byB0aGUgbGlzdCwgY2xlYXJs eSBzdGF0aW5nIHlvdXIgdmlldy48YnI+DQo8YnI+DQpUaGlzIFdHTEMgZW5kcyBNb24gMjEtQXBy LTIwMTQuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCldhcnJlbiBLdW1hcmk8YnI+DQooYXMgb3Bz YXdnIFdHIGNvLWNoYWlyKTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KT1BTQVdHIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpPUFNBV0dAaWV0Zi5vcmciPk9QU0FXR0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7C4E09AZFFEXMB04globa_-- From nobody Wed Apr 23 07:30:26 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5C71A03D5 for ; Wed, 23 Apr 2014 07:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 WogT4aPtHE1z for ; Wed, 23 Apr 2014 07:30:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3F31A03C8 for ; Wed, 23 Apr 2014 07:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19834; q=dns/txt; s=iport; t=1398263411; x=1399473011; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sESYu+63+a6eFwFIx8MjmEGK0TnK04hy/uEVUEss1q0=; b=FQhFY77nmZjRz9R7FbLQO/IO3sVc1S9oV1TfALO/rBQ6TvTU89SvXx1N QG8F5/W7JBy8HvURMbNxvi0SIgozAdgNIBSjzJnxiz4Gi515g8B2QXNqI PDbs+YEP3FOQNkv3EuPfFZ/t7jytnEoAXqYxxG6C2E3Ug1SMc1joaLVej A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAMHNV1OtJA2H/2dsb2JhbABZgkJET1eDD7lqhmlRGYEBFnSCJQEBAQQBAQEgCkELEAIBCBEEAQELHQMCAgIlCxQJCAIEAQ0FCIg4AQ2sEqMfEwSOJy0EBgGCbzWBFQSrSoMxgis X-IronPort-AV: E=Sophos;i="4.97,912,1389744000"; d="scan'208,217";a="319729519" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP; 23 Apr 2014 14:30:10 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3NEUAPE026717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 14:30:10 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 23 Apr 2014 09:30:09 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: "Romascanu, Dan (Dan)" , "sarikaya@ieee.org" , Warren Kumari Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac Thread-Index: AQHPUoC8MFNDHyh8Kkuo/cfmgAemqJsc7KMAgAEWC+CAAUsnAIAADe+Q Date: Wed, 23 Apr 2014 14:30:09 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F76469@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B4320F76104@xmb-aln-x09.cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA5C7C4E09@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C7C4E09@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.133.94] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F76469xmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/mxN7v3wIuqL2D5Ut7VAeVbB1HeE Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 14:30:22 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F76469xmbalnx09ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGFuDQoNClRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uIFlvdSBhcmUgYWJzb2x1dGVseSBy aWdodC4gV2hhdCBJIG1lYW4gYnkg4oCcdGl0bGXigJ0gYmVsb3cgd2FzIHRoZSBuYW1lIG9mIHRo ZSBJLUQgZmlsZS4NCg0KUmVnYXJkcw0KDQpSYWplc2gNCg0KRnJvbTogUm9tYXNjYW51LCBEYW4g KERhbikgW21haWx0bzpkcm9tYXNjYUBhdmF5YS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEFwcmls IDIzLCAyMDE0IDE6MzkgQU0NClRvOiBSYWplc2ggUGF6aHlhbm51ciAocnBhemh5YW4pOyBzYXJp a2F5YUBpZWVlLm9yZzsgV2FycmVuIEt1bWFyaQ0KQ2M6IG9wc2F3Z0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1hY0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6 IFtPUFNBV0ddIFN0YXJ0IG9mIFdHTEMgZm9yIGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJy aWRtYWMNCg0KSnVzdCB0byBiZSBjbGVhciDigJMgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIG5h bWUgb2YgdGhlIEktRCBmaWxlIHdoaWNoIHdpbGwgYW55d2F5IGJlIGxvc3QgYXQgdGhlIHB1Ymxp Y2F0aW9uIG9mIHRoZSBmdXR1cmUgUkZDIChpZiBhcHByb3ZlZCkuIFRoZSBuYW1lIG9mIHRoZSBk b2N1bWVudCByZWZsZWN0cyBjb3JyZWN0bHkgdGhlIGNvbnRlbnQgSU1PLg0KDQpSZWdhcmRzLA0K DQpEYW4NCg0KDQpGcm9tOiBPUFNBV0cgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFJhamVzaCBQYXpoeWFubnVyIChycGF6aHlhbikNClNlbnQ6IFR1ZXNkYXks IEFwcmlsIDIyLCAyMDE0IDg6NTggUE0NClRvOiBzYXJpa2F5YUBpZWVlLm9yZzxtYWlsdG86c2Fy aWtheWFAaWVlZS5vcmc+OyBXYXJyZW4gS3VtYXJpDQpDYzogb3BzYXdnQGlldGYub3JnPG1haWx0 bzpvcHNhd2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjQHRv b2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjQHRv b2xzLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPUFNBV0ddIFN0YXJ0IG9mIFdHTEMgZm9yIGRy YWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWMNCg0KQmVoY2V0DQoNClRoZSBwb2ludCB5 b3UgcmFpc2UgaGFkIGJlZW4gYnJvdWdodCB1cCBlYXJsaWVyIGJ5IERvcm90aHkgUy4gYW5kIHRo ZSB0ZXh0IHdhcyB1cGRhdGVkIGFwcHJvcHJpYXRlbHkuDQpJIGJlbGlldmUgaXQgd2FzIGRpZmZp Y3VsdCB0byBjaGFuZ2UgdGhlIHRpdGxlIHdpdGhvdXQgcmVzdGFydGluZyB0aGUgdmVyc2lvbmlu ZyBwcm9jZXNzLiBBcyBhIHJlc3VsdCwgdGhlIHRpdGxlIHN0aWxsIGhhcyBIeWJyaWQtTUFDIGlu IHRoZSBuYW1lLg0KU28sIGJlc2lkZXMgdGhlIHRpdGxlIOKAnGh5YnJpZOKAnSBkb2VzIG5vdCBh cHBlYXIgYW55d2hlcmUgZWxzZSBhbmQgdGhlIHRpdGxlIHdpbGwgZ28gYXdheSBvbmNlIHRoaXMg YmVjb21lcyBhIFJGQy4NCg0KUmVnYXJkcw0KDQpSYWplc2gNCkZyb206IE9QU0FXRyBbbWFpbHRv Om9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVoY2V0IFNhcmlrYXlhDQpT ZW50OiBNb25kYXksIEFwcmlsIDIxLCAyMDE0IDE6MTkgUE0NClRvOiBXYXJyZW4gS3VtYXJpDQpD Yzogb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW9w c2F3Zy1jYXB3YXAtaHlicmlkbWFjQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9w c2F3Zy1jYXB3YXAtaHlicmlkbWFjQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPUFNB V0ddIFN0YXJ0IG9mIFdHTEMgZm9yIGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWMN Cg0KSGkgYWxsLA0KSSBoYXZlIHByb2JsZW0gaW4gdGhlIEh5YnJpZCBNQUMgdGVybWlub2xvZ3kg dXNlZCBpbiB0aGlzIGRyYWZ0Lg0KVGhlIGRyYWZ0IGJhc2ljYWxseSBkZXNjcmliZXMgYW4gaW1w cm92ZWQgc3BsaXQgTUFDIHByb2ZpbGUgYXMgc3VjaCBpdCBzaG91bGQgYmUgbmFtZWQgYWNjb3Jk aW5nbHkuDQpUaGUgZHJhZnQgZG9lcyBub3QgZGVmaW5lIGEgbmV3IHRoaW5nIHN1Y2ggYXMgbG9j YWwgTUFDIG9yIHNwbGl0IE1BQyBhcyBpbiBDQVBXQVAgZG9jdW1lbnRzIHRvIGRlc2VydmUgdG8g YmUgY2FsbGVkIGRlZmluaW5nICJoeWJyaWQgTUFDIi4NCklmIHRoZSBhYm92ZSBjb25jZXJuIGlz IGhhbmRsZWQsIEkgYW0gcmVhZHkgdG8gc3VwcG9ydCB0aGUgYWRvcHRpb24uDQpSZWdhcmRzLA0K QmVoY2V0DQoNCk9uIE1vbiwgQXByIDcsIDIwMTQgYXQgMTE6NDQgQU0sIFdhcnJlbiBLdW1hcmkg PHdhcnJlbkBrdW1hcmkubmV0PG1haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldD4+IHdyb3RlOg0KRGVh ciBvcHNhd2cgV0csDQoNClRoZSBhdXRob3JzIG9mIGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1o eWJyaWRtYWMgaGF2ZSBpbmRpY2F0ZWQgdGhhdA0KdGhleSBiZWxpZXZlIHRoYXQgdGhlIGRvY3Vt ZW50IGlzIHJlYWR5LCBhbmQgaGF2ZSBhc2tlZCBmb3IgV29ya2luZw0KR3JvdXAgTGFzdCBDYWxs Lg0KDQpUaGUgZHJhZnQgaXMgYXZhaWxhYmxlIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjLw0KDQpQbGVhc2Ug cmV2aWV3IHRoaXMgZHJhZnQgdG8gc2VlIGlmIHlvdSB0aGluayBpdCBpcyByZWFkeSBmb3IgcHVi bGljYXRpb24NCmFuZCBzZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBjbGVhcmx5IHN0YXRpbmcg eW91ciB2aWV3Lg0KDQpUaGlzIFdHTEMgZW5kcyBNb24gMjEtQXByLTIwMTQuDQoNClRoYW5rcywN CldhcnJlbiBLdW1hcmkNCihhcyBvcHNhd2cgV0cgY28tY2hhaXIpDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFNBV0cgbWFpbGluZyBsaXN0DQpP UFNBV0dAaWV0Zi5vcmc8bWFpbHRvOk9QU0FXR0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnDQoNCg== --_000_4ED2E36A22261145861BAB2C24088B4320F76469xmbalnx09ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7 DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsN Cglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLiBZb3UgYXJlIGFic29sdXRl bHkgcmlnaHQuIFdoYXQgSSBtZWFuIGJ5IOKAnHRpdGxl4oCdIGJlbG93IHdhcyB0aGUgbmFtZSBv ZiB0aGUgSS1EIGZpbGUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJk czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SYWplc2g8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9tYXNjYW51LCBE YW4gKERhbikgW21haWx0bzpkcm9tYXNjYUBhdmF5YS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBBcHJpbCAyMywgMjAxNCAxOjM5IEFNPGJyPg0KPGI+VG86PC9iPiBSYWplc2gg UGF6aHlhbm51ciAocnBhemh5YW4pOyBzYXJpa2F5YUBpZWVlLm9yZzsgV2FycmVuIEt1bWFyaTxi cj4NCjxiPkNjOjwvYj4gb3BzYXdnQGlldGYub3JnOyBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAt aHlicmlkbWFjQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbT1BTQVdH XSBTdGFydCBvZiBXR0xDIGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkp1c3QgdG8gYmUgY2xlYXIg4oCTIHdlIGFy ZSB0YWxraW5nIGFib3V0IHRoZSBuYW1lIG9mIHRoZSBJLUQgZmlsZSB3aGljaCB3aWxsIGFueXdh eSBiZSBsb3N0IGF0IHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgZnV0dXJlIFJGQyAoaWYgYXBwcm92 ZWQpLiBUaGUgbmFtZSBvZiB0aGUNCiBkb2N1bWVudCByZWZsZWN0cyBjb3JyZWN0bHkgdGhlIGNv bnRlbnQgSU1PLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IE9QU0FXRyBbPGEgaHJlZj0ibWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYu b3JnIj5tYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5SYWplc2ggUGF6aHlhbm51ciAocnBhemh5YW4pPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNk YXksIEFwcmlsIDIyLCAyMDE0IDg6NTggUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0 bzpzYXJpa2F5YUBpZWVlLm9yZyI+c2FyaWtheWFAaWVlZS5vcmc8L2E+OyBXYXJyZW4gS3VtYXJp PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86b3BzYXdnQGlldGYub3JnIj5vcHNhd2dA aWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5 YnJpZG1hY0B0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlk bWFjQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09QU0FXR10g U3RhcnQgb2YgV0dMQyBmb3IgZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1hYzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QmVoY2V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBw b2ludCB5b3UgcmFpc2UgaGFkIGJlZW4gYnJvdWdodCB1cCBlYXJsaWVyIGJ5IERvcm90aHkgUy4g YW5kIHRoZSB0ZXh0IHdhcyB1cGRhdGVkIGFwcHJvcHJpYXRlbHkuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg YmVsaWV2ZSBpdCB3YXMgZGlmZmljdWx0IHRvIGNoYW5nZSB0aGUgdGl0bGUgd2l0aG91dCByZXN0 YXJ0aW5nIHRoZSB2ZXJzaW9uaW5nIHByb2Nlc3MuIEFzIGEgcmVzdWx0LCB0aGUgdGl0bGUgc3Rp bGwgaGFzIEh5YnJpZC1NQUMgaW4gdGhlIG5hbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbywgYmVzaWRlcyB0 aGUgdGl0bGUg4oCcaHlicmlk4oCdIGRvZXMgbm90IGFwcGVhciBhbnl3aGVyZSBlbHNlIGFuZCB0 aGUgdGl0bGUgd2lsbCBnbyBhd2F5IG9uY2UgdGhpcyBiZWNvbWVzIGEgUkZDLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlJhamVzaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBPUFNBV0cgWzxhIGhyZWY9Im1haWx0bzpvcHNhd2ctYm91bmNl c0BpZXRmLm9yZyI+bWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJl aGFsZiBPZiA8L2I+QmVoY2V0IFNhcmlrYXlhPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXBy aWwgMjEsIDIwMTQgMToxOSBQTTxicj4NCjxiPlRvOjwvYj4gV2FycmVuIEt1bWFyaTxicj4NCjxi PkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyI+b3BzYXdnQGlldGYub3Jn PC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWNA dG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1hY0B0b29s cy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPUFNBV0ddIFN0YXJ0IG9m IFdHTEMgZm9yIGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIGFsbCw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHByb2JsZW0gaW4gdGhl IEh5YnJpZCBNQUMgdGVybWlub2xvZ3kgdXNlZCBpbiB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPlRoZSBkcmFmdCBiYXNpY2FsbHkgZGVzY3JpYmVzIGFuIGltcHJvdmVkIHNwbGl0IE1BQyBw cm9maWxlIGFzIHN1Y2ggaXQgc2hvdWxkIGJlIG5hbWVkIGFjY29yZGluZ2x5LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPlRoZSBkcmFmdCBkb2VzIG5vdCBkZWZpbmUgYSBuZXcgdGhpbmcgc3VjaCBhcyBsb2Nh bCBNQUMgb3Igc3BsaXQgTUFDIGFzIGluIENBUFdBUCBkb2N1bWVudHMgdG8gZGVzZXJ2ZSB0byBi ZSBjYWxsZWQgZGVmaW5pbmcgJnF1b3Q7aHlicmlkIE1BQyZxdW90Oy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5JZiB0aGUgYWJvdmUgY29uY2VybiBpcyBoYW5kbGVkLCBJIGFtIHJlYWR5IHRvIHN1cHBvcnQg dGhlIGFkb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlaGNldDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXByIDcsIDIwMTQg YXQgMTE6NDQgQU0sIFdhcnJlbiBLdW1hcmkgJmx0OzxhIGhyZWY9Im1haWx0bzp3YXJyZW5Aa3Vt YXJpLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPndhcnJlbkBrdW1hcmkubmV0PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIG9wc2F3ZyBXRyw8YnI+ DQo8YnI+DQpUaGUgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFj IGhhdmUgaW5kaWNhdGVkIHRoYXQ8YnI+DQp0aGV5IGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQg aXMgcmVhZHksIGFuZCBoYXZlIGFza2VkIGZvciBXb3JraW5nPGJyPg0KR3JvdXAgTGFzdCBDYWxs Ljxicj4NCjxicj4NClRoZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVyZTo8YnI+DQo8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAt aHlicmlkbWFjLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWMvPC9hPjxicj4NCjxicj4NClBs ZWFzZSByZXZpZXcgdGhpcyBkcmFmdCB0byBzZWUgaWYgeW91IHRoaW5rIGl0IGlzIHJlYWR5IGZv ciBwdWJsaWNhdGlvbjxicj4NCmFuZCBzZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBjbGVhcmx5 IHN0YXRpbmcgeW91ciB2aWV3Ljxicj4NCjxicj4NClRoaXMgV0dMQyBlbmRzIE1vbiAyMS1BcHIt MjAxNC48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KV2FycmVuIEt1bWFyaTxicj4NCihhcyBvcHNh d2cgV0cgY28tY2hhaXIpPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpPUFNBV0cgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk9QU0FXR0BpZXRmLm9yZyI+T1BTQVdHQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2c8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_4ED2E36A22261145861BAB2C24088B4320F76469xmbalnx09ciscoc_--