From ehalep@gmail.com Mon Apr 1 06:17:11 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3138C21E8485 for ; Mon, 1 Apr 2013 06:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf9dtodcgFwO for ; Mon, 1 Apr 2013 06:17:09 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id CCFAE21E8482 for ; Mon, 1 Apr 2013 06:17:08 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id h10so1047091eaj.21 for ; Mon, 01 Apr 2013 06:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=KtsxBMHTVzlOPsVykWIzjurJBIU+xWySfRtsrEFn7a8=; b=isDR/Pq6McKRo22FMVyBFRSH62L9/CeeRZghbRku1E+mzPA44jbwEUl0osAqj3fa4z 0y+vkE+KDWeq4ZSTCHjT0Q2MxSWcEszlXBAxiBzXeiRxeci5q6XpbcFHSejWgYsWbSlO EaW7hiDn7lKOMo2hRKMFP4j7m5P4cUWGv7SmWBsBMAcU8SjrSxa6gVlXEcIByOiFcvLw ApPtg1DNVLUxHCpfp0qw5sUrlmUayORtgT2RXcN8mOCBQrMR3g1jFdRwSObyLdACXhEC HigqFUctiFN+Fi8JbY5tcWv+7Gso9dbewlPOd8r0xIycdda4EoJ2cExD58WgvKLicjgI Yi+g== X-Received: by 10.15.36.67 with SMTP id h43mr37520969eev.5.1364822227908; Mon, 01 Apr 2013 06:17:07 -0700 (PDT) Received: from EhalepXPS (ppp141237169221.access.hol.gr. [141.237.169.221]) by mx.google.com with ESMTPS id bc1sm21052465eeb.11.2013.04.01.06.17.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Apr 2013 06:17:07 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Dave Hood'" , References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4E875@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA6405F4E875@eusaamb105.ericsson.se> Date: Mon, 1 Apr 2013 16:17:04 +0300 Message-ID: <00e601ce2edb$35696c20$a03c4460$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E7_01CE2EF4.5AB6A420" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4jKaoHqZ9bWJwbTxCuci5rYmP6FALrKb4g Content-Language: el Subject: Re: [forces] Comment: draft-haleplidis-forces-model-extension-01 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 13:17:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00E7_01CE2EF4.5AB6A420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings, Thank you very much for the comment - and apologies for the long delay in answering. We have just released a new version of the document where we did some small changes and to incorporate your comments. URL: http://www.ietf.org/internet-drafts/draft-haleplidis-forces-model-extension- 03.txt Status: http://datatracker.ietf.org/doc/draft-haleplidis-forces-model-extension Htmlized: http://tools.ietf.org/html/draft-haleplidis-forces-model-extension-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-haleplidis-forces-model-extension-03 We are looking forward to more comments. In particular, it would be useful to know other's opinion on whether BecomesNotEqualTo is a useful event condition to have or not. Regards, Evangelos Haleplidis. From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of Dave Hood Sent: Sunday, March 17, 2013 6:16 PM To: forces@ietf.org Subject: [forces] Comment: draft-haleplidis-forces-model-extension-01 The abstract and intro say that there are new extensions, but do not give us a clue what they are. Brevity is good, but it is also helpful to know from the beginning what the remainder of a document contains. Present text (introduction): The ForCES Model [RFC5812] presents a formal way to define FEs Logical Function Blocks (LFBs) using XML. [RFC5812] has been published a litlte more than two years and current experience in its use has shown some room for adding new and changing existing modeling concepts. This document extends the ForCES Model by changing and adding new concepts. These extensions do not require any changes on the ForCES protocol [RFC5810] as they are simply changes of the schema definition. Additionally backward compatibility is ensured as xml libraries produced with the earlier schema are still valid with the new one. Proposed text: The ForCES Model [RFC5812] presents a formal way to define FEs Logical Function Blocks (LFBs) using XML. [RFC5812] was published a little more than two years ago. Current experience in its use has shown some room for adding new and changing existing modeling concepts. This document extends the ForCES Model by a) allowing complex metadata and b) allowing optional default values for datatypes. These extensions do not require any changes on the ForCES protocol [RFC5810] as they are simply changes of the schema definition. XML validation is also enhanced. Backward compatibility is ensured, as xml libraries produced with the earlier schema remain valid. The abstract could be updated similarly. Dave ------=_NextPart_000_00E7_01CE2EF4.5AB6A420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings,

 

Thank you = very much for the comment – and apologies for the long delay in = answering.

 

We have = just released a new version of the document where we did some small = changes and to incorporate your comments.

 

URL:         &n= bsp;   http://www.ietf.org/internet-drafts/draft-haleplidis-forces-= model-extension-03.txt

Status:         = ; http://datatracker.ietf.org/doc/draft-haleplidis-forces-mode= l-extension

Htmlized:        = http://tools.ietf.org/html/draft-haleplidis-forces-model-ext= ension-03

Diff:         &= nbsp;  http://www.ietf.org/rfcdiff?url2=3Ddraft-haleplidis-forces-m= odel-extension-03

 

We are = looking forward to more comments.

 

In = particular, it would be useful to know other’s opinion on whether = BecomesNotEqualTo is a useful event condition to have or = not.

 

Regards,

Evangelos = Haleplidis.

 

From:= = forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of = Dave Hood
Sent: Sunday, March 17, 2013 6:16 = PM
To: forces@ietf.org
Subject: [forces] Comment: = draft-haleplidis-forces-model-extension-01

 

The abstract and intro say that there are new = extensions, but do not give us a clue what they are. Brevity is good, = but it is also helpful to know from the beginning what the remainder of = a document contains.

 

Present text (introduction):

 

The ForCES Model = [RFC5812] presents a formal way to define FEs

Logical Function Blocks = (LFBs) using XML. [RFC5812] has been

published a litlte more = than two years and current experience in its

use has shown some room = for adding new and changing existing modeling

concepts.

This = document extends the ForCES Model by changing and adding = new

concepts. These = extensions do not require any changes on the = ForCES

protocol [RFC5810] as = they are simply changes of the schema

definition. Additionally = backward compatibility is ensured as xml

libraries produced with = the earlier schema are still valid with the

new = one.

 

Proposed text:

 

The ForCES Model = [RFC5812] presents a formal way to define FEs

Logical Function Blocks = (LFBs) using XML. [RFC5812] was

published a little more = than two years ago. Current experience in its

use has shown some room = for adding new and changing existing modeling

concepts.

This = document extends the ForCES Model by a) allowing complex metadata and b) = allowing optional default values for datatypes. These extensions do not = require any changes on the ForCES protocol [RFC5810] as they are simply = changes of the schema definition. XML validation is also enhanced. = Backward compatibility is ensured, as xml libraries produced with the = earlier schema remain valid.

 

The abstract could be updated = similarly.

Dave

 

------=_NextPart_000_00E7_01CE2EF4.5AB6A420-- From ehalep@gmail.com Mon Apr 1 07:12:36 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E98011E80A3 for ; Mon, 1 Apr 2013 07:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGtXe3wEmEOQ for ; Mon, 1 Apr 2013 07:12:34 -0700 (PDT) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 762A411E80A2 for ; Mon, 1 Apr 2013 07:12:34 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id c13so1070519eek.40 for ; Mon, 01 Apr 2013 07:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=wu3x4dqj+HCWCfXqWqQrZoxAqgvfoYygF4vhmZYUg3Y=; b=svVrwpj3AVck/N9p4cIl1dB6hG9IemiP5/5NftbxYsBaAKXxhTOf5c0X9onD6E3qUb 5gd//XJaoXMJCfbJwZ2zqiK30bQk+81rdpj1M/JyH/TSx/ibRZVPx03AOpDhom4ecml9 GIZtuNc7wzWS4KCX8Y1+TaV9aAjrSJhCLuue/0ISW5Q2oZAfHELCIVnKe+kuAYs4Y4g0 LG5s70jzZvKq5hyXCN3CCWRrtrT2RAW6aLc8vh46yYtK3EATesnw1R/9X8y9rSgqadCX WC5Pbpo63E6CAgluHhd1jZx/yLmNIedjq3tGUL4clOPtR6vZgvljGm00907OnZE3yGmQ VUxQ== X-Received: by 10.15.36.67 with SMTP id h43mr37989965eev.5.1364825553661; Mon, 01 Apr 2013 07:12:33 -0700 (PDT) Received: from EhalepXPS (ppp141237169221.access.hol.gr. [141.237.169.221]) by mx.google.com with ESMTPS id bc1sm21307665eeb.11.2013.04.01.07.12.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Apr 2013 07:12:32 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Dave Hood'" , References: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EAB3@eusaamb105.ericsson.se> In-Reply-To: <8D15A2BAF93E9C49AB037A0647E5FA6405F4EAB3@eusaamb105.ericsson.se> Date: Mon, 1 Apr 2013 17:12:30 +0300 Message-ID: <010501ce2ee2$f3aa3d70$dafeb850$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0106_01CE2EFC.18F77570" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4jKtgvQjzRSwZSThmMfpjsEo0VuALsGvOw Content-Language: el Subject: Re: [forces] Comments: draft-haleplidis-forces-packet-parallelization-01 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 14:12:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0106_01CE2EFC.18F77570 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Greetings, =20 Thank you for the comments. =20 Please see inline. =20 Regards, Evangelos Haleplidis. =20 From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf = Of Dave Hood Sent: Sunday, March 17, 2013 6:22 PM To: forces@ietf.org Subject: [forces] Comments: draft-haleplidis-forces-packet-parallelization-01 =20 The use case for chunk processing is not obvious, and the references = section does not obviously cite a place where such a use case might be = described. An example would be helpful. =20 Some documentation of cilc (is that correct?) should also appear in the references.=20 =20 [=C5=C7] One use case for chunk processing could be calculating a Hash = list in parallel, we will add this in the references, as well as for cilc. =20 In ParallelLFBType AllowedParallelAfters List of LFB Classes that this parallel LFB class can follow in a parallel pipeline AllowedParallelBefores List of LFB Classes that this LFB class can follow in a parallel pipeline Presumably the first synopsis should read precede, rather than follow? =20 [=C5=C7] Yes, you're right, thank you. =20 Tunneling metadata in case of nested parallelization: this would = presumably require the complex metadata proposed in draft-haleplidis-forces-model-extension-01? . which therefore should = also be cited in the text and listed in the references. Would a tunneledMetadata typedef be needed?=20 =20 [=C5=C7] Not necessarily. Metadata is defined for LFBs that = consume/produce metadata. Since tunneling metadata is not produced/consumed in tunneling = it does not need to be defined. Such an implementation could be done either = by passing metadata along with each packet/chunk as is. However now that = you mention it, in order to identify level of tunneling in case we have = multiple nesting parallelization we could add a nesting level metadata - the = merger should consume the metadata with the larger value of the nesting level. = The splitter when seeing parallel metadata will create metadata with +1 = nesting level. =20 Dave =20 ------=_NextPart_000_0106_01CE2EFC.18F77570 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable

Greetings,

 

Thank you = for the comments.

 

Please see = inline.

 

Regards,

Evangelos = Haleplidis.

 

From:= = forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of = Dave Hood
Sent: Sunday, March 17, 2013 6:22 = PM
To: forces@ietf.org
Subject: [forces] Comments: = draft-haleplidis-forces-packet-parallelization-01

 

The use case for chunk processing is not obvious, and = the references section does not obviously cite a place where such a use = case might be described. An example would be = helpful.

 

Some documentation of cilc (is that correct?) should = also appear in the references.&n= bsp;

 

[=C5=C7] One use case for chunk processing could be = calculating a Hash list in parallel, we will add this in the references, = as well as for cilc.

 

In = ParallelLFBType

<snip />

<component = componentID=3D"5">

<name>AllowedParalle= lAfters</name>

<synopsis>List of = LFB Classes that this parallel LFB

class can = follow in a parallel pipeline</synopsis>

<snip />

<component = componentID=3D"6">

<name>AllowedParalle= lBefores</name>

<synopsis>List of = LFB Classes that this LFB class can

follow in a = parallel pipeline</synopsis>

<snip />

Presumably the first synopsis should read precede, = rather than follow?

 

[=C5=C7] Yes, you’re right, thank = you.

 

Tunneling metadata in case of nested parallelization: = this would presumably require the complex metadata proposed in = draft-haleplidis-forces-model-extension-01? … which = therefore should also be cited in the text and listed in the references. = Would a tunneledMetadata typedef be = needed? 

 

[=C5=C7] Not necessarily. Metadata is defined = for LFBs that consume/produce metadata. Since tunneling metadata is not = produced/consumed in tunneling it does not need to be defined. Such an = implementation could be done either by passing metadata along with each = packet/chunk as is. However now that you mention it, in order to = identify level of tunneling in case we have multiple nesting = parallelization we could add a nesting level metadata – the merger = should consume the metadata with the larger value of the nesting level. = The splitter when seeing parallel metadata will create metadata with +1 = nesting level.

 

Dave

 

------=_NextPart_000_0106_01CE2EFC.18F77570-- From iesg-secretary@ietf.org Mon Apr 1 10:19:30 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7C121F90A5; Mon, 1 Apr 2013 10:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0TcoApXJs6O; Mon, 1 Apr 2013 10:19:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC08921F90CE; Mon, 1 Apr 2013 10:19:28 -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: 4.43 Message-ID: <20130401171928.14187.61003.idtracker@ietfa.amsl.com> Date: Mon, 01 Apr 2013 10:19:28 -0700 Cc: forces mailing list , forces chair , RFC Editor Subject: [forces] Protocol Action: 'ForCES Logical Function Block (LFB) Library' to Proposed Standard (draft-ietf-forces-lfb-lib-12.txt) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:19:30 -0000 The IESG has approved the following document: - 'ForCES Logical Function Block (LFB) Library' (draft-ietf-forces-lfb-lib-12.txt) as Proposed Standard This document is the product of the Forwarding and Control Element Separation Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib/ Technical Summary This document defines basic classes of Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to ForCES FE model and ForCES protocol specifications, and are scoped to meet requirements of typical router functions and considered as the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. Working Group Summary: Standard WG discussions, nothing controversial. The document was returned to the authors after AD review. The issues were addressed in public on the WG mailing list. Document Quality: There are known implementations of this document. Version 00 of this document was published in 2009 and has undergone feedback based on implementation and architecture discussion. Personnel: Jamal Hadi Salim (hadi@mojatatu.com) is the Document Shepherd Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD RFC Editor Note The three unused references may be safely removed. From iesg-secretary@ietf.org Mon Apr 1 10:19:30 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4479C21F90D9 for ; Mon, 1 Apr 2013 10:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ9-FX18TEc8; Mon, 1 Apr 2013 10:19:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C8721F90DF; Mon, 1 Apr 2013 10:19:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43 X-IETF-Draft-string: draft-ietf-forces-lfb-lib X-IETF-Draft-revision: 12 Message-ID: <20130401171929.14187.16150.idtracker@ietfa.amsl.com> Date: Mon, 01 Apr 2013 10:19:29 -0700 Cc: forces mailing list , forces chair , RFC Editor Subject: [forces] Protocol Action: 'ForCES Logical Function Block (LFB) Library' to Proposed Standard (draft-ietf-forces-lfb-lib-12.txt) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:19:30 -0000 The IESG has approved the following document: - 'ForCES Logical Function Block (LFB) Library' (draft-ietf-forces-lfb-lib-12.txt) as Proposed Standard This document is the product of the Forwarding and Control Element Separation Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-forces-lfb-lib/ Technical Summary This document defines basic classes of Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to ForCES FE model and ForCES protocol specifications, and are scoped to meet requirements of typical router functions and considered as the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. Working Group Summary: Standard WG discussions, nothing controversial. The document was returned to the authors after AD review. The issues were addressed in public on the WG mailing list. Document Quality: There are known implementations of this document. Version 00 of this document was published in 2009 and has undergone feedback based on implementation and architecture discussion. Personnel: Jamal Hadi Salim (hadi@mojatatu.com) is the Document Shepherd Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD RFC Editor Note The three unused references may be safely removed. From adrian@olddog.co.uk Mon Apr 1 14:27:10 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBF621E80D6 for ; Mon, 1 Apr 2013 14:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpKB+FIJovOd for ; Mon, 1 Apr 2013 14:27:10 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id AAD2D11E80E2 for ; Mon, 1 Apr 2013 14:27:09 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r31LR8dK027066 for ; Mon, 1 Apr 2013 22:27:08 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r31LR63f027052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 1 Apr 2013 22:27:07 +0100 From: "Adrian Farrel" To: Date: Mon, 1 Apr 2013 22:27:07 +0100 Message-ID: <01ca01ce2f1f$aa478ab0$fed6a010$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4vHvWOIofkQcbRSUqnJTg/BuRFew== Content-Language: en-gb Subject: [forces] Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:27:10 -0000 Hi ForCES, I have entered your proposed charter text at https://datatracker.ietf.org/doc/charter-ietf-forces/ Since the meeting in Orlando I haven't heard a word of disquiet from you about the charter so I am going to assume that you are all happy with what is in/out within the bounds of understanding when you are in the rough. Therefore, please shout loud and clear if that is not the case. I am now going to set about some wordsmithing because the current proposal is about 25 pages too long :-) Cheers, Adrian From adrian@olddog.co.uk Tue Apr 2 06:07:38 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83C021F8E8F for ; Tue, 2 Apr 2013 06:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otCABfsUzEgn for ; Tue, 2 Apr 2013 06:07:34 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id E965A21F8DCF for ; Tue, 2 Apr 2013 06:07:33 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32D7VAS023373; Tue, 2 Apr 2013 14:07:32 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32D7T0E023360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Apr 2013 14:07:30 +0100 From: "Adrian Farrel" To: "'SM'" , , References: <20130401171928.14187.61003.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130402054504.0c041e10@resistor.net> In-Reply-To: <6.2.5.6.2.20130402054504.0c041e10@resistor.net> Date: Tue, 2 Apr 2013 14:07:30 +0100 Message-ID: <036e01ce2fa3$090106c0$1b031440$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgDSeduJZXcZkiRo7B0q0cSWQ6hAHBR47omREg0ZA= Content-Language: en-gb Cc: 'RFC Editor' Subject: Re: [forces] Protocol Action: 'ForCES Logical Function Block (LFB) Library' to Proposed Standard (draft-ietf-forces-lfb-lib-12.txt) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:07:39 -0000 How thoroughly right you are, SM. Glad we have someone with your penetrating technical insight ;-) I added an RFC Editor note. Adrian > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: 02 April 2013 13:54 > To: forces@ietf.org; forces-chairs@tools.ietf.org > Cc: RFC Editor > Subject: Re: Protocol Action: 'ForCES Logical Function Block (LFB) Library' to > Proposed Standard (draft-ietf-forces-lfb-lib-12.txt) > > At 10:19 01-04-2013, The IESG wrote: > >The IESG has approved the following document: > >- 'ForCES Logical Function Block (LFB) Library' > > (draft-ietf-forces-lfb-lib-12.txt) as Proposed Standard > > draft-ietf-forces-lfb-lib-12 is intended to be published as a > Proposed Standard. The RFC 2119 reference in the draft is informative. > > Regards, > -sm From ran@bgu.ac.il Tue Apr 2 06:37:11 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB62621F8908 for ; Tue, 2 Apr 2013 06:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9TKrAFdzQ1t for ; Tue, 2 Apr 2013 06:37:10 -0700 (PDT) Received: from smtp4.bgu.ac.il (smtp4.bgu.ac.il [132.72.126.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5721F88F5 for ; Tue, 2 Apr 2013 06:37:09 -0700 (PDT) Received: from smtp4.bgu.ac.il (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id B65441F8196 for ; Tue, 2 Apr 2013 16:36:57 +0300 (IDT) Received: from RanX200 (unknown [212.235.89.88]) by smtp4.bgu.ac.il (Postfix) with ESMTP id 488001F8173 for ; Tue, 2 Apr 2013 16:36:55 +0300 (IDT) From: "Ran Giladi" To: References: <01ca01ce2f1f$aa478ab0$fed6a010$@olddog.co.uk> In-Reply-To: <01ca01ce2f1f$aa478ab0$fed6a010$@olddog.co.uk> Date: Tue, 2 Apr 2013 16:36:52 +0300 Organization: Ben Gurion University Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQHcg5lWNY4dySKObZcwuXTOz5/papimRKNQ Content-Language: he X-TM-AS-Product-Ver: IMSVA-8.0.0.1450-7.0.0.1014-19762.007 X-TM-AS-Result: No--12.478-9.0-31-10 X-imss-scan-details: No--12.478-9.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-MatchedRID: lRQO0XDtcJlWplQw4MDVZjKH3QldZqKhy1coPxI/+8nu95qA6yOsmfpZ jWQiqBlht3Kc0SR3enXYSHV+bQRFH6ymwCS8VeRuoiN8YTmq+cuOY2fJuO+0eGEORtrscnjUCtR o5dkVT3cTjrodPavy0gMISN0gIPIoL7XvtoFEpRxVTfJWlqPdDBm5G+dSGiboowedxK4WURQ0+Y L7qlbVBP7FzytJ3LGAYHxlqQxfrgbC5KNFPL+ydISvKOGqLLPKNNuh+5zmS68+O9xGEaHQEeO7Q 9MS0NLnbrgUJ4CnqHg5ze2drk/BuRjNRuD6vS9UV9LwT29+rzb2kudi1D33Ejb3PBVULKWuQQ/s 9vEJJneSqSyZXNJIgVRVzWRwtEoOePs/Cx1DJd2WLCkl1lq7BylayzmQ9QV0jNnoU1fopotomtG erDewEtE6fQ2Sd69V5KVkFd6ahn9Kl5uDD6k69iSxIFlMYKvCtOt1ofVlaoJ1CB/tuWL0vA1im+ j3Fb6YjoczmuoPCq2qOqfCWRtLe/F0ihTyL1YRPE8+OaDg2UUrpLBq1nnGTuafvc65asgA Subject: Re: [forces] Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ran@bgu.ac.il List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:37:11 -0000 Hi ForCES, Several years ago, I communicated with some of you, proposing to use ForCES for SDN (not by this name, it was at the beginning of OpenFlow), claiming that in order to stay relevant ForCES should target "SDN". I'd like to use the opportunity and re-propose ForCES-based SDN, as described in a paper I published in PRESTO'09, one of SIGCOM's workshops: http://dl.acm.org/citation.cfm?id=1592637 The main idea, in short, is to dictate (prescribe, force) a set of LFBs and their interconnections (described in XML) on a generic data-plane platform, using ForCES (we added OpenFlow later) LFBs and protocol, thus enabling the generic platform to function as desired. Applications can include OAM functionality, auto-learning, DPI, stateful operations, and more, all (or most) at the data plane. It is a sort of a superset of OpenFlow capabilities, based on ForCES. I was able even to generate a Service Oriented Networking - using various service indicators (in incoming frames) to initiate service functions, most of them were executed at the data-plane. The first system was tested at British Telecom Labs (at Ipswich), running an experimental scalable Ethernet, using Network Processors (EZchip's). Recently my students were able to port the code to plain Linux system. If this is of interest, I can provide more info, including the Linux code. Ran -----Original Message----- From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, April 02, 2013 12:27 AM To: forces@ietf.org Subject: [forces] Your recharter proposal Hi ForCES, I have entered your proposed charter text at https://datatracker.ietf.org/doc/charter-ietf-forces/ Since the meeting in Orlando I haven't heard a word of disquiet from you about the charter so I am going to assume that you are all happy with what is in/out within the bounds of understanding when you are in the rough. Therefore, please shout loud and clear if that is not the case. I am now going to set about some wordsmithing because the current proposal is about 25 pages too long :-) Cheers, Adrian _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces From dmm@1-4-5.net Tue Apr 2 07:09:25 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D2621F86C3 for ; Tue, 2 Apr 2013 07:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIa24b+NUuHQ for ; Tue, 2 Apr 2013 07:09:24 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0862221F86C1 for ; Tue, 2 Apr 2013 07:09:23 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id r11so520864lbv.12 for ; Tue, 02 Apr 2013 07:09:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ER4nutREg+DFaX6Zx8Qk4fda5UMBK4ZkUaX+x2lHjJI=; b=Kwm+sqqDmjflJg4yYpoR2tBfMPX2p1aLBE5viuPDs9Ug5cqk08M7oB7rvIWKKHvp8N bSVK5h4P3wZY1jSSi2cZPERaw76uCL7LRS9789b4lY2ANdpfGx8ee9nKZNGTo2w9AAWB Ne9JOBLPavwRNMcZpih4f8797Ydc+Y8jwBfbaLJ46GopztWZD9f+9/82+YxhoDYorVY+ o+pqpaGlUH22AaVJBfSayt2VRUAuFATKOb9zDKoFWVad1IAkC+au2Ndx/upA/OdgqB3F eac/S7eGk0pbq9OH+WEWTcGezt3buoKixcCQxyRYEXuPFQHAe/EzILAYvREnUKlSHM/u zMow== MIME-Version: 1.0 X-Received: by 10.112.129.2 with SMTP id ns2mr7930386lbb.53.1364911762838; Tue, 02 Apr 2013 07:09:22 -0700 (PDT) Received: by 10.112.8.101 with HTTP; Tue, 2 Apr 2013 07:09:22 -0700 (PDT) X-Originating-IP: [63.145.238.4] In-Reply-To: References: <01ca01ce2f1f$aa478ab0$fed6a010$@olddog.co.uk> Date: Tue, 2 Apr 2013 07:09:22 -0700 Message-ID: From: David Meyer To: ran@bgu.ac.il Content-Type: multipart/alternative; boundary=047d7b3a8ecac6321404d9614850 X-Gm-Message-State: ALoCoQkEhGyhwSnr32p6PDxSX3PUiXexBAfde6y2af0vzJ6kXC3LSOeaaID1rcuM98/OjkDiqb8s Cc: forces@ietf.org Subject: Re: [forces] Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:09:26 -0000 --047d7b3a8ecac6321404d9614850 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 2, 2013 at 6:36 AM, Ran Giladi wrote: > Hi ForCES, > > Several years ago, I communicated with some of you, proposing to use ForCES > for SDN (not by this name, it was at the beginning of OpenFlow), claiming > that in order to stay relevant ForCES should target "SDN". > > I'd like to use the opportunity and re-propose ForCES-based SDN, as > described in a paper I published in PRESTO'09, one of SIGCOM's workshops: > http://dl.acm.org/citation.cfm?id=1592637 For those who don't have ACM credentials, try http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p19.pdf > The main idea, in short, is to dictate (prescribe, force) a set of LFBs and > their interconnections (described in XML) on a generic data-plane platform, > using ForCES (we added OpenFlow later) LFBs and protocol, thus enabling the > generic platform to function as desired. > Applications can include OAM functionality, auto-learning, DPI, stateful > operations, and more, all (or most) at the data plane. It is a sort of a > superset of OpenFlow capabilities, based on ForCES. > > I was able even to generate a Service Oriented Networking - using various > service indicators (in incoming frames) to initiate service functions, most > of them were executed at the data-plane. The first system was tested at > British Telecom Labs (at Ipswich), running an experimental scalable > Ethernet, using Network Processors (EZchip's). Recently my students were > able to port the code to plain Linux system. > > If this is of interest, I can provide more info, including the Linux code. > I have been arguing that if OpenFlow evolves past 1.0 (basically L2 only) and 1.1+ (multi-table 1.0 with additional protocol features and which basically unimplementable on ASIC h/w), then it will wind up looking very similar to ForCES. In fact if you look at the proposal that Google made for what they were calling OF 2.0 at the time, it has quite a bit in common with ForCES (at the very least architecturally). I'm not sure if that proposal is publically available anywhere but will check. I have been spending some time examining the architectural implications of the OF mode (salient features are separation of control and data planes, open interface to the forwarding/data plane (OF), and centralized control). Some of my (controversial) thoughts are on http://www.1-4-5.net/~dmm/talks/upperside_sdn_summit_paris_2013.pdf (this is necessarily abbreviated; see something like http://www.1-4-5.net/~dmm/talks/ncrg86.pdf for the longer form...) --dmm > Ran > > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf > Of > Adrian Farrel > Sent: Tuesday, April 02, 2013 12:27 AM > To: forces@ietf.org > Subject: [forces] Your recharter proposal > > Hi ForCES, > > I have entered your proposed charter text at > https://datatracker.ietf.org/doc/charter-ietf-forces/ > > Since the meeting in Orlando I haven't heard a word of disquiet from you > about the charter so I am going to assume that you are all happy with what > is in/out within the bounds of understanding when you are in the rough. > Therefore, please shout loud and clear if that is not the case. > > I am now going to set about some wordsmithing because the current proposal > is about 25 pages too long :-) > > Cheers, > Adrian > > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > --047d7b3a8ecac6321404d9614850 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 2, 2013 at 6:36 AM, Ran Giladi <ran@bgu.ac.il> wrote:
Hi ForCES,

Several years ago, I communicated with some of you, proposing to use ForCES=
for SDN (not by this name, it was at the beginning of OpenFlow), claiming that in order to stay relevant ForCES should target "SDN".

I'd like to use the opportunity and re-propose ForCES-based SDN, as
described in a paper I published in PRESTO'09, one of SIGCOM's work= shops:
h= ttp://dl.acm.org/citation.cfm?id=3D1592637

<= div style>For those who don't have ACM credentials, try ht= tp://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p19.pdf
=A0
The main idea, in short, is to dictate (prescribe, force) a set of LFBs and=
their interconnections (described in XML) on a generic data-plane platform,=
using ForCES (we added OpenFlow later) LFBs and protocol, thus enabling the=
generic platform to function as desired.
Applications can include OAM functionality, auto-learning, DPI, stateful operations, and more, all (or most) at the data plane. It is a sort of a superset of OpenFlow capabilities, based on ForCES.

I was able even to generate a Service Oriented Networking - using various service indicators (in incoming frames) to initiate service functions, most=
of them were executed at the data-plane. The first system was tested at
British Telecom Labs (at Ipswich), running an experimental scalable
Ethernet, using Network Processors (EZchip's). Recently my students wer= e
able to port the code to plain Linux system.

If this is of interest, I can provide more info, including the Linux code.<= br>

I have been arguing that if OpenF= low evolves past 1.0 (basically L2 only) and 1.1+ (multi-table 1.0 with add= itional protocol features and which basically unimplementable on ASIC h/w),= then it will wind up looking very similar to ForCES. In fact if you look a= t the proposal that Google made for what they were calling OF 2.0 at the ti= me, it has quite a bit in common with ForCES (at the very least architectur= ally). I'm not sure if that proposal is publically available anywhere b= ut will check.=A0


--dmm
=

Ran

-----Original Message-----
From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.or= g] On Behalf Of
Adrian Farrel
Sent: Tuesday, April 02, 2013 12:27 AM
To: forces@ietf.org
Subject: [forces] Your recharter proposal

Hi ForCES,

I have entered your proposed charter text at
https://datatracker.ietf.org/doc/charter-ietf-forces/

Since the meeting in Orlando I haven't heard a word of disquiet from yo= u
about the charter so I am going to assume that you are all happy with what<= br> is in/out within the bounds of understanding when you are in the rough.
Therefore, please shout loud and clear if that is not the case.

I am now going to set about some wordsmithing because the current proposal<= br> is about 25 pages too long :-)

Cheers,
Adrian



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

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

--047d7b3a8ecac6321404d9614850-- From hadi@mojatatu.com Tue Apr 2 07:17:13 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1A921F8AD5 for ; Tue, 2 Apr 2013 07:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjZrZ6qK8idz for ; Tue, 2 Apr 2013 07:17:13 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id F33EE21F8A27 for ; Tue, 2 Apr 2013 07:17:12 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id m17so455707vca.25 for ; Tue, 02 Apr 2013 07:17:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to:cc :content-type:x-gm-message-state; bh=RYCW/Rt+dkcutOfUELIHARUZYQRbX35RSkY7P8h6xvE=; b=R8yXJznUATukCHqk6YmNvh59zzogxYJU0pMm6655kT8A62osE54xj/Sz5o+ELeQijN e0dwcma8IHaf+W6ZIGNhwF6BzNg8byYhM8Vm05V9+eXmY4pAUxx9pCJROEjRWMhNzBIm 7AOFUhl9oBWAQKXha3//wB5QrkKtcadpEvIGChuvqtGfbYpha00rdVkjO55e5Rah7WT7 J38MtH7alVd1DjP0InybWg1ufAwVNKLuqUekJuv4yFt9nfDlhNMqDuzrsrPo7DjprOC6 1mhufmUi0tWdHhuCfpBtxlvbKs4pyLzw01QCGas1i1VBzwlnyg3QCoyBO6BHAsbfOj2X 8dKA== X-Received: by 10.52.164.166 with SMTP id yr6mr10871953vdb.37.1364912232333; Tue, 02 Apr 2013 07:17:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.253.194 with HTTP; Tue, 2 Apr 2013 07:16:52 -0700 (PDT) From: Jamal Hadi Salim Date: Tue, 2 Apr 2013 10:16:52 -0400 Message-ID: To: ran@bgu.ac.il Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn24wJU48wI0tOFWulRRRqJ1OoGTdcL5c22nCkbWvLgDcOpNR59ufAf97BTbwiqJYuP8z89 Cc: forces@ietf.org Subject: [forces] generic forwarding element WAS(Re: Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:17:14 -0000 Hi Ran Changed the subject line to be more appropriate. It would be useful to post a url or something to where people can find more info. The url may not necessarily have the code but more info and how to get access to the code. I plan to re-read your doc (especially since recently i have become interested in ezchip processors). cheers, jamal On Tue, Apr 2, 2013 at 9:36 AM, Ran Giladi wrote: > Hi ForCES, > > Several years ago, I communicated with some of you, proposing to use ForCES > for SDN (not by this name, it was at the beginning of OpenFlow), claiming > that in order to stay relevant ForCES should target "SDN". > > I'd like to use the opportunity and re-propose ForCES-based SDN, as > described in a paper I published in PRESTO'09, one of SIGCOM's workshops: > http://dl.acm.org/citation.cfm?id=1592637 > > The main idea, in short, is to dictate (prescribe, force) a set of LFBs and > their interconnections (described in XML) on a generic data-plane platform, > using ForCES (we added OpenFlow later) LFBs and protocol, thus enabling the > generic platform to function as desired. > Applications can include OAM functionality, auto-learning, DPI, stateful > operations, and more, all (or most) at the data plane. It is a sort of a > superset of OpenFlow capabilities, based on ForCES. > > I was able even to generate a Service Oriented Networking - using various > service indicators (in incoming frames) to initiate service functions, most > of them were executed at the data-plane. The first system was tested at > British Telecom Labs (at Ipswich), running an experimental scalable > Ethernet, using Network Processors (EZchip's). Recently my students were > able to port the code to plain Linux system. > > If this is of interest, I can provide more info, including the Linux code. > > Ran > > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: Tuesday, April 02, 2013 12:27 AM > To: forces@ietf.org > Subject: [forces] Your recharter proposal > > Hi ForCES, > > I have entered your proposed charter text at > https://datatracker.ietf.org/doc/charter-ietf-forces/ > > Since the meeting in Orlando I haven't heard a word of disquiet from you > about the charter so I am going to assume that you are all happy with what > is in/out within the bounds of understanding when you are in the rough. > Therefore, please shout loud and clear if that is not the case. > > I am now going to set about some wordsmithing because the current proposal > is about 25 pages too long :-) > > Cheers, > Adrian > > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From adrian@olddog.co.uk Tue Apr 2 07:30:09 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B161521F883A for ; Tue, 2 Apr 2013 07:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIkUTPOIA+wG for ; Tue, 2 Apr 2013 07:30:08 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 60BB621F8842 for ; Tue, 2 Apr 2013 07:30:07 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32EU2V7010535; Tue, 2 Apr 2013 15:30:02 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32ETx0X010448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Apr 2013 15:30:00 +0100 From: "Adrian Farrel" To: "'David Meyer'" , Date: Tue, 2 Apr 2013 15:30:01 +0100 Message-ID: <039201ce2fae$8fc41390$af4c3ab0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0393_01CE2FB6.F18F5960" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4vrou3vvHgNTQ1RxWO6rvqCu9o6Q== Content-Language: en-gb Cc: forces@ietf.org Subject: [forces] generic forwarding element WAS(Re: Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:30:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0393_01CE2FB6.F18F5960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for the secondary pointer, Dave. There was some interest in the WG in investigating the possible use of ForCES to achieve what OpenFlow sets out to do. There were a couple of different approaches proposed: 1. Replace OF with ForCES 2. Build a parallel mechanism/architecture 3. Model OF with ForCES I don't want to rule any of these in or out except to note that the IETF cannot dictate or control what the ONF does with OF, and we shouldn't try to. Thus, item 1 is only likely to happen through the development of item 2 and the result of market decisions, or through a specific choice by the ONF. At this stage, it seem that any work in the "SDN" sphere may be a bit premature for standardisation. Thus, when discussing this with Jamal, we agreed that the WG should be open to the discussion of such topics, but should not (at this stage) be committing to or taking on milestones or working group drafts on the subject. Hence, the draft charter text says... > In addition to the specific work items described below, it is understood that > there are a number of external activities which may have interactions with the > ForCES work. Discussions of how to use ForCES to model topics of interest to > Network Function Virtualization, I2RS, or OpenFlow may be discussed and > reviewed, although primary responsibility for such documents is likely to live > in other working groups, individual contributions, or other standards bodies. So my advice to people interested in using ForCES for Foo is to write drafts and discuss the topic. Also to write prototype code and demonstrate its utility. Cheers, Adrian From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of David Meyer Sent: 02 April 2013 15:09 To: ran@bgu.ac.il Cc: forces@ietf.org Subject: Re: [forces] Your recharter proposal On Tue, Apr 2, 2013 at 6:36 AM, Ran Giladi wrote: Hi ForCES, Several years ago, I communicated with some of you, proposing to use ForCES for SDN (not by this name, it was at the beginning of OpenFlow), claiming that in order to stay relevant ForCES should target "SDN". I'd like to use the opportunity and re-propose ForCES-based SDN, as described in a paper I published in PRESTO'09, one of SIGCOM's workshops: http://dl.acm.org/citation.cfm?id=1592637 For those who don't have ACM credentials, try http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p19.pdf The main idea, in short, is to dictate (prescribe, force) a set of LFBs and their interconnections (described in XML) on a generic data-plane platform, using ForCES (we added OpenFlow later) LFBs and protocol, thus enabling the generic platform to function as desired. Applications can include OAM functionality, auto-learning, DPI, stateful operations, and more, all (or most) at the data plane. It is a sort of a superset of OpenFlow capabilities, based on ForCES. I was able even to generate a Service Oriented Networking - using various service indicators (in incoming frames) to initiate service functions, most of them were executed at the data-plane. The first system was tested at British Telecom Labs (at Ipswich), running an experimental scalable Ethernet, using Network Processors (EZchip's). Recently my students were able to port the code to plain Linux system. If this is of interest, I can provide more info, including the Linux code. I have been arguing that if OpenFlow evolves past 1.0 (basically L2 only) and 1.1+ (multi-table 1.0 with additional protocol features and which basically unimplementable on ASIC h/w), then it will wind up looking very similar to ForCES. In fact if you look at the proposal that Google made for what they were calling OF 2.0 at the time, it has quite a bit in common with ForCES (at the very least architecturally). I'm not sure if that proposal is publically available anywhere but will check. I have been spending some time examining the architectural implications of the OF mode (salient features are separation of control and data planes, open interface to the forwarding/data plane (OF), and centralized control). Some of my (controversial) thoughts are on http://www.1-4-5.net/~dmm/talks/upperside_sdn_summit_paris_2013.pdf (this is necessarily abbreviated; see something like http://www.1-4-5.net/~dmm/talks/ncrg86.pdf for the longer form...) --dmm Ran -----Original Message----- From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, April 02, 2013 12:27 AM To: forces@ietf.org Subject: [forces] Your recharter proposal Hi ForCES, I have entered your proposed charter text at https://datatracker.ietf.org/doc/charter-ietf-forces/ Since the meeting in Orlando I haven't heard a word of disquiet from you about the charter so I am going to assume that you are all happy with what is in/out within the bounds of understanding when you are in the rough. Therefore, please shout loud and clear if that is not the case. I am now going to set about some wordsmithing because the current proposal is about 25 pages too long :-) Cheers, Adrian _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces ------=_NextPart_000_0393_01CE2FB6.F18F5960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the secondary pointer, Dave.

 

There was some interest in the WG in investigating the possible use = of ForCES to achieve what OpenFlow sets out to do. There were a couple = of different approaches proposed:

1. Replace OF with ForCES

2. Build a parallel mechanism/architecture

3. Model OF with ForCES

 

I don't want to rule any of these in or out except to note that the = IETF cannot dictate or control what the ONF does with OF, and we = shouldn't try to. Thus, item 1 is only likely to happen through the = development of item 2 and the result of market decisions, or through a = specific choice by the ONF.

 

At this stage, it seem that any work in the "SDN" sphere = may be a bit premature for standardisation. Thus, when discussing this = with Jamal, we agreed that the WG should be open to the discussion of = such topics, but should not (at this stage) be committing to or taking = on milestones or working group drafts on the subject. Hence, the draft = charter text says...

 

> In addition to the specific work items described below, it is = understood that

> there are a number of external activities which may have = interactions with the

> ForCES work.  = Discussions of how to use ForCES to model topics of interest = to

> Network Function Virtualization, I2RS, or OpenFlow may be = discussed and

> reviewed, although primary responsibility for such documents is = likely to live

> in other working groups, individual contributions, or other = standards bodies.

 

So my advice to people interested in using ForCES for Foo is to write = drafts and discuss the topic. Also to write prototype code and = demonstrate its utility.

 

Cheers,

Adrian

 

 

 

From: = forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of = David Meyer
Sent: 02 April 2013 15:09
To: = ran@bgu.ac.il
Cc: forces@ietf.org
Subject: Re: = [forces] Your recharter proposal

 

On Tue, Apr 2, 2013 at 6:36 AM, Ran Giladi <ran@bgu.ac.il> = wrote:

Hi ForCES,

Several = years ago, I communicated with some of you, proposing to use = ForCES
for SDN (not by this name, it was at the beginning of = OpenFlow), claiming
that in order to stay relevant ForCES should = target "SDN".

I'd like to use the opportunity and = re-propose ForCES-based SDN, as
described in a paper I published in = PRESTO'09, one of SIGCOM's workshops:
http://dl.acm.org/citation.cfm?id=3D1592637

 

 

The main idea, in short, is to dictate = (prescribe, force) a set of LFBs and
their interconnections = (described in XML) on a generic data-plane platform,
using ForCES (we = added OpenFlow later) LFBs and protocol, thus enabling the
generic = platform to function as desired.
Applications can include OAM = functionality, auto-learning, DPI, stateful
operations, and more, all = (or most) at the data plane. It is a sort of a
superset of OpenFlow = capabilities, based on ForCES.

I was able even to generate a = Service Oriented Networking - using various
service indicators (in = incoming frames) to initiate service functions, most
of them were = executed at the data-plane. The first system was tested at
British = Telecom Labs (at Ipswich), running an experimental scalable
Ethernet, = using Network Processors (EZchip's). Recently my students were
able = to port the code to plain Linux system.

If this is of interest, I = can provide more info, including the Linux = code.

 

I = have been arguing that if OpenFlow evolves past 1.0 (basically L2 only) = and 1.1+ (multi-table 1.0 with additional protocol features and which = basically unimplementable on ASIC h/w), then it will wind up looking = very similar to ForCES. In fact if you look at the proposal that Google = made for what they were calling OF 2.0 at the time, it has quite a bit = in common with ForCES (at the very least architecturally). I'm not sure = if that proposal is publically available anywhere but will = check. 

 

I = have been spending some time examining the architectural implications of = the OF mode (salient features are separation of control and data planes, = open interface to the forwarding/data plane (OF), and centralized = control). Some of my (controversial) thoughts are on http://www.1-4-5.net/~dmm/talks/upperside_sdn_summit_paris_2013.pdf (this is necessarily abbreviated; see something like http://www.1-4-5.net/= ~dmm/talks/ncrg86.pdf for the longer = form...)

 

 

--dmm

 


Ran

-----Original = Message-----
From: forces-bounces@ietf.org = [mailto:forces-bounces@ietf.org] On = Behalf Of
Adrian Farrel
Sent: Tuesday, April 02, 2013 12:27 = AM
To: forces@ietf.org
Subject: [forces] = Your recharter proposal

Hi ForCES,

I have entered your = proposed charter text at
https://datatracker.ietf.org/doc/charter-ietf-forces/

Since the meeting in Orlando I haven't heard a word of = disquiet from you
about the charter so I am going to assume that you = are all happy with what
is in/out within the bounds of understanding = when you are in the rough.
Therefore, please shout loud and clear if = that is not the case.

I am now going to set about some = wordsmithing because the current proposal
is about 25 pages too long = :-)

Cheers,
Adrian



_____________________________= __________________
forces mailing list
forces@ietf.org
https://www.ietf.org/mailman/listinfo/forces
_______________________________________________
forces mailing = list
forces@ietf.org
https://www.ietf.org/mailman/listinfo/forces

 

------=_NextPart_000_0393_01CE2FB6.F18F5960-- From adrian@olddog.co.uk Tue Apr 2 07:35:40 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D3121F8A7B for ; Tue, 2 Apr 2013 07:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO5MWRkf2ftW for ; Tue, 2 Apr 2013 07:35:39 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA2921F8A80 for ; Tue, 2 Apr 2013 07:35:31 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32EZRRj020518 for ; Tue, 2 Apr 2013 15:35:27 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32EZQJa020471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Apr 2013 15:35:26 +0100 From: "Adrian Farrel" To: Date: Tue, 2 Apr 2013 15:35:27 +0100 Message-ID: <03a001ce2faf$5235e890$f6a1b9b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4vr027PSBs2tSxRVyH9H4s5T/qXg== Content-Language: en-gb Subject: [forces] AD's review of charter text X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:35:40 -0000 Hi, I did a review of the text. My edits are: - Cut out most of the preamble - Move the "other business" paragraph to the end - Tweak words - Adjust layout - Split milestones into separate items I posted a new revision at https://datatracker.ietf.org/doc/charter-ietf-forces/ You can see the differences at https://www.ietf.org/rfcdiff?url1=http%3A%2F%2Fwww.ietf.org%2Fcharter%2Fcharter- ietf-forces-03-02.txt&difftype=--html&submit=Go%21&url2=http%3A%2F%2Fwww.ietf.or g%2Fcharter%2Fcharter-ietf-forces-03-04.txt I'd like to carry this forward with a little momentum, so would welcome comments of approval or otherwise. Thanks, Adrian From dmm@1-4-5.net Tue Apr 2 07:35:56 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF5121F8AA8 for ; Tue, 2 Apr 2013 07:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saIOJtAVfLf0 for ; Tue, 2 Apr 2013 07:35:55 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id BE48721F8842 for ; Tue, 2 Apr 2013 07:35:54 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id s10so539743lbi.5 for ; Tue, 02 Apr 2013 07:35:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/yrCJWGPqUu4MP7nGT+QvTZkeuUqcd5UjZlfq43lZYw=; b=STprozmBCQ//L1p4ekOJEiRKgFz0FkPAcFmOEqU8JtqpDlBcp4vcyTMwADjmGZlY8/ /e3hA/GpmV6vp17Yc9zfM18GRjokF0y2sugTWQc+q8KsLSPw5VsL2p6SX57r73S19NTf EnDntnGhEEegzEUlKXCY28hWUbVYbPVYj2REKrTdDPxv5bB2zayPDp2CqHxnpU5xpdMz TjODgWbCoG4ANVaauKx/OFUxWZwDVCtS+TlxwHqMKzZXw/HNiKjGBJOcFB/GX9LAmRcO lQUzm7wADK10dyzU7KsTDnmO6rxRp9nD2CICy2GOwogVKla8HRf0LEC+T9cdJE//CrIW a8fw== MIME-Version: 1.0 X-Received: by 10.112.129.137 with SMTP id nw9mr8052096lbb.56.1364913353557; Tue, 02 Apr 2013 07:35:53 -0700 (PDT) Received: by 10.112.8.101 with HTTP; Tue, 2 Apr 2013 07:35:53 -0700 (PDT) X-Originating-IP: [63.145.238.4] In-Reply-To: <039201ce2fae$8fc41390$af4c3ab0$@olddog.co.uk> References: <039201ce2fae$8fc41390$af4c3ab0$@olddog.co.uk> Date: Tue, 2 Apr 2013 07:35:53 -0700 Message-ID: From: David Meyer To: "adrian@olddog.co.uk Farrel" Content-Type: multipart/alternative; boundary=047d7b3a7f10968fae04d961a73f X-Gm-Message-State: ALoCoQlZwbQVIlmdlEjayKcVdcvj9/+bdn44ODwel816RbOeys0yp2QtE09pXBie0LbKiHD/xbJa Cc: forces@ietf.org Subject: Re: [forces] generic forwarding element WAS(Re: Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:35:56 -0000 --047d7b3a7f10968fae04d961a73f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 2, 2013 at 7:30 AM, Adrian Farrel wrote: > Thanks for the secondary pointer, Dave.**** > > ** ** > > There was some interest in the WG in investigating the possible use of > ForCES to achieve what OpenFlow sets out to do. There were a couple of > different approaches proposed:**** > > 1. Replace OF with ForCES**** > > 2. Build a parallel mechanism/architecture**** > > 3. Model OF with ForCES**** > > ** ** > > I don't want to rule any of these in or out except to note that the IETF > cannot dictate or control what the ONF does with OF, and we shouldn't try > to. Thus, item 1 is only likely to happen through the development of item 2 > and the result of market decisions, or through a specific choice by the ONF. > **** > > ** ** > > At this stage, it seem that any work in the "SDN" sphere may be a bit > premature for standardisation. Thus, when discussing this with Jamal, we > agreed that the WG should be open to the discussion of such topics, but > should not (at this stage) be committing to or taking on milestones or > working group drafts on the subject. Hence, the draft charter text says... > **** > > ** ** > > > In addition to the specific work items described below, it is understood > that**** > > > there are a number of external activities which may have interactions > with the**** > > > ForCES work. Discussions of how to use ForCES to model topics of > interest to**** > > > Network Function Virtualization, I2RS, or OpenFlow may be discussed and* > *** > > > reviewed, although primary responsibility for such documents is likely > to live**** > > > in other working groups, individual contributions, or other standards > bodies.**** > > ** ** > > So my advice to people interested in using ForCES for Foo is to write > drafts and discuss the topic. Also to write prototype code and demonstrate > its utility.**** > > ** > Makes sense to me. --dmm > ** > > Cheers,**** > > Adrian**** > > ** ** > > ** ** > > ** ** > > *From:* forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] *On > Behalf Of *David Meyer > *Sent:* 02 April 2013 15:09 > *To:* ran@bgu.ac.il > *Cc:* forces@ietf.org > *Subject:* Re: [forces] Your recharter proposal**** > > ** ** > > On Tue, Apr 2, 2013 at 6:36 AM, Ran Giladi wrote:**** > > Hi ForCES, > > Several years ago, I communicated with some of you, proposing to use ForCES > for SDN (not by this name, it was at the beginning of OpenFlow), claiming > that in order to stay relevant ForCES should target "SDN". > > I'd like to use the opportunity and re-propose ForCES-based SDN, as > described in a paper I published in PRESTO'09, one of SIGCOM's workshops: > http://dl.acm.org/citation.cfm?id=1592637**** > > ** ** > > For those who don't have ACM credentials, try > http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p19.pdf > **** > > **** > > The main idea, in short, is to dictate (prescribe, force) a set of LFBs and > their interconnections (described in XML) on a generic data-plane platform, > using ForCES (we added OpenFlow later) LFBs and protocol, thus enabling the > generic platform to function as desired. > Applications can include OAM functionality, auto-learning, DPI, stateful > operations, and more, all (or most) at the data plane. It is a sort of a > superset of OpenFlow capabilities, based on ForCES. > > I was able even to generate a Service Oriented Networking - using various > service indicators (in incoming frames) to initiate service functions, most > of them were executed at the data-plane. The first system was tested at > British Telecom Labs (at Ipswich), running an experimental scalable > Ethernet, using Network Processors (EZchip's). Recently my students were > able to port the code to plain Linux system. > > If this is of interest, I can provide more info, including the Linux code. > **** > > ** ** > > I have been arguing that if OpenFlow evolves past 1.0 (basically L2 only) > and 1.1+ (multi-table 1.0 with additional protocol features and which > basically unimplementable on ASIC h/w), then it will wind up looking very > similar to ForCES. In fact if you look at the proposal that Google made for > what they were calling OF 2.0 at the time, it has quite a bit in common > with ForCES (at the very least architecturally). I'm not sure if that > proposal is publically available anywhere but will check. **** > > ** ** > > I have been spending some time examining the architectural implications of > the OF mode (salient features are separation of control and data planes, > open interface to the forwarding/data plane (OF), and centralized control). > Some of my (controversial) thoughts are on > http://www.1-4-5.net/~dmm/talks/upperside_sdn_summit_paris_2013.pdf (this > is necessarily abbreviated; see something like > http://www.1-4-5.net/~dmm/talks/ncrg86.pdf for the longer form...)**** > > ** ** > > ** ** > > --dmm**** > > ** ** > > > Ran > > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf > Of > Adrian Farrel > Sent: Tuesday, April 02, 2013 12:27 AM > To: forces@ietf.org > Subject: [forces] Your recharter proposal > > Hi ForCES, > > I have entered your proposed charter text at > https://datatracker.ietf.org/doc/charter-ietf-forces/ > > Since the meeting in Orlando I haven't heard a word of disquiet from you > about the charter so I am going to assume that you are all happy with what > is in/out within the bounds of understanding when you are in the rough. > Therefore, please shout loud and clear if that is not the case. > > I am now going to set about some wordsmithing because the current proposal > is about 25 pages too long :-) > > Cheers, > Adrian > > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces**** > > ** ** > --047d7b3a7f10968fae04d961a73f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 2, 2013 at 7:30 AM, Adrian Farrel <= ;adrian@olddog.co.= uk> wrote:

Thanks for th= e secondary pointer, Dave.

=A0<= /p>

There was some interes= t in the WG in investigating the possible use of ForCES to achieve what Ope= nFlow sets out to do. There were a couple of different approaches proposed:=

1. Replace OF with ForCES=

= 2. Build a parallel mechanism/architecture

3. Model OF with ForCES

=A0

I don't want to rule = any of these in or out except to note that the IETF cannot dictate or contr= ol what the ONF does with OF, and we shouldn't try to. Thus, item 1 is = only likely to happen through the development of item 2 and the result of m= arket decisions, or through a specific choice by the ONF.

=A0<= /p>

At this stage, it seem= that any work in the "SDN" sphere may be a bit premature for sta= ndardisation. Thus, when discussing this with Jamal, we agreed that the WG = should be open to the discussion of such topics, but should not (at this st= age) be committing to or taking on milestones or working group drafts on th= e subject. Hence, the draft charter text says...

=A0<= /p>

> In addition to th= e specific work items described below, it is understood that<= /span>

> there are a number o= f external activities which may have interactions with the

> ForCES work.= =A0 Discussions of how to use ForCES to model topics of interest to<= u>

> Network Function Vir= tualization, I2RS, or OpenFlow may be discussed and

> reviewed, although p= rimary responsibility for such documents is likely to live

> in other working gro= ups, individual contributions, or other standards bodies.

=A0<= /p>

So my advice to people= interested in using ForCES for Foo is to write drafts and discuss the topi= c. Also to write prototype code and demonstrate its utility.<= /span>

=A0


Makes sense to me. --dmm
=A0

Cheers,

Adrian

=A0<= /p>

=A0

=A0<= /p>

From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of David Meyer
Sent: 02 April 2013 15:09
To: ran@bgu.ac.il
Cc: forces@ietf.org
Subject: Re:= [forces] Your recharter proposal

=A0

On Tue, Apr 2, 2013 at 6:36 AM, Ran Giladi <ran@bgu.ac.il> wrote:=

Hi ForCES,

Several years ago, I communicated = with some of you, proposing to use ForCES
for SDN (not by this name, it = was at the beginning of OpenFlow), claiming
that in order to stay releva= nt ForCES should target "SDN".

I'd like to use the opportunity and re-propose ForCES-based SDN, as=
described in a paper I published in PRESTO'09, one of SIGCOM's = workshops:
http://dl.acm.org/citation.cfm?id=3D1592637<= /p>

=A0

=A0

=

The main idea, in short, is to dictate (prescribe, force) a set of LFBs and=
their interconnections (described in XML) on a generic data-plane platf= orm,
using ForCES (we added OpenFlow later) LFBs and protocol, thus enab= ling the
generic platform to function as desired.
Applications can include OAM fu= nctionality, auto-learning, DPI, stateful
operations, and more, all (or = most) at the data plane. It is a sort of a
superset of OpenFlow capabili= ties, based on ForCES.

I was able even to generate a Service Oriented Networking - using vario= us
service indicators (in incoming frames) to initiate service functions= , most
of them were executed at the data-plane. The first system was tes= ted at
British Telecom Labs (at Ipswich), running an experimental scalable
Ethe= rnet, using Network Processors (EZchip's). Recently my students wereable to port the code to plain Linux system.

If this is of interest= , I can provide more info, including the Linux code.

=A0

I have been arguing that if OpenFlow evolves past 1.0 = (basically L2 only) and 1.1+ (multi-table 1.0 with additional protocol feat= ures and which basically unimplementable on ASIC h/w), then it will wind up= looking very similar to ForCES. In fact if you look at the proposal that G= oogle made for what they were calling OF 2.0 at the time, it has quite a bi= t in common with ForCES (at the very least architecturally). I'm not su= re if that proposal is publically available anywhere but will check.=A0<= /u>

=A0

I have been spending some time examining the architectural i= mplications of the OF mode (salient features are separation of control and = data planes, open interface to the forwarding/data plane (OF), and centrali= zed control). Some of my (controversial) thoughts are on=A0http://www.1-4-5.net/~dmm/talks/upperside_sdn_summit_paris_2013.pdf<= /a> (this is necessarily=A0abbreviated; see something like=A0http://www.1-4-5= .net/~dmm/talks/ncrg86.pdf for the longer form...)

=A0

=A0

--dmm=

=A0


Ran

-----Original Message-----
From: <= a href=3D"mailto:forces-bounces@ietf.org" target=3D"_blank">forces-bounces@= ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of
Adrian Farrel
Sent: Tuesday, April 02, 2013 12:27 AM
To: forces@ietf.org
Subject: [f= orces] Your recharter proposal

Hi ForCES,

I have entered your= proposed charter text at
https://datatracker.ietf.org/doc/charter-ietf-forces/

S= ince the meeting in Orlando I haven't heard a word of disquiet from you=
about the charter so I am going to assume that you are all happy with what<= br>is in/out within the bounds of understanding when you are in the rough.<= br>Therefore, please shout loud and clear if that is not the case.

I am now going to set about some wordsmithing because the current proposal<= br>is about 25 pages too long :-)

Cheers,
Adrian



_= ______________________________________________
forces mailing list
forces@ietf.orghttps://www.ietf.org/mailman/listinfo/forces

__________________= _____________________________
forces mailing list
forces@ietf.org
https://www.ietf.org/mailman/listinfo/forces=

=A0

=

--047d7b3a7f10968fae04d961a73f-- From jmh@joelhalpern.com Tue Apr 2 07:44:34 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1735A21F8B25 for ; Tue, 2 Apr 2013 07:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Np5wf3YSdX7t for ; Tue, 2 Apr 2013 07:44:33 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 84ED621F8B13 for ; Tue, 2 Apr 2013 07:44:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 746501BCCCE2; Tue, 2 Apr 2013 07:44:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-50.clppva.east.verizon.net [70.106.135.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id DEE821BD47C6; Tue, 2 Apr 2013 07:44:31 -0700 (PDT) Message-ID: <515AEEBD.8060808@joelhalpern.com> Date: Tue, 02 Apr 2013 10:44:13 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <03a001ce2faf$5235e890$f6a1b9b0$@olddog.co.uk> In-Reply-To: <03a001ce2faf$5235e890$f6a1b9b0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] AD's review of charter text X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:44:34 -0000 If you think the IESG and readers can do without the extra background, then I am happy to see it removed. The rest of it look fine to me (the diff link doesn't work). Thank you Adrian, Joel On 4/2/2013 10:35 AM, Adrian Farrel wrote: > Hi, > > I did a review of the text. > > My edits are: > > - Cut out most of the preamble > - Move the "other business" paragraph to the end > - Tweak words > - Adjust layout > - Split milestones into separate items > > I posted a new revision at https://datatracker.ietf.org/doc/charter-ietf-forces/ > > You can see the differences at > https://www.ietf.org/rfcdiff?url1=http%3A%2F%2Fwww.ietf.org%2Fcharter%2Fcharter- > ietf-forces-03-02.txt&difftype=--html&submit=Go%21&url2=http%3A%2F%2Fwww.ietf.or > g%2Fcharter%2Fcharter-ietf-forces-03-04.txt > > I'd like to carry this forward with a little momentum, so would welcome comments > of approval or otherwise. > > Thanks, > Adrian > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Tue Apr 2 08:00:21 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84A221F86B7 for ; Tue, 2 Apr 2013 08:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIPZlGD7FRYx for ; Tue, 2 Apr 2013 08:00:21 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1929F21F8B61 for ; Tue, 2 Apr 2013 08:00:21 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id gd11so519094vcb.18 for ; Tue, 02 Apr 2013 08:00:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=bHOPJkSbTAMJXKQ1jqe5m95Vf2NJgxuCrSGEmwujUJ8=; b=Pq3ycMIbUbyy4Zt3BRLZzbBajWfS0JPXJlfiJaQBHWeeTt71xfAXjSoY48fYxGPhEH 5jdhHruKaXXWJnyS/9Tko4yunl0VmlFjJvruygJXyNHNHh8G/Oo+dZFbAiZ14L0T1Q8P 1a0V6Gn93twkWH42c0P9p6+QV/ohGVL82w7B1a1zFY1yts+j68C0TTTagt+s/oY/9j2j QSSv5piveXVyyNXSoeVArJO8h3j2w1HY38QLNtXXbC5UBQ5jgH7rR3DhUvMD3+YyhX5E 5vipTcASzmo6jt+1GY7aK/h8xZrK2eZY7heu6ZKePsJ2IuFFQM4FCM6Uh/PcE9eAPmLH /WiQ== X-Received: by 10.58.164.1 with SMTP id ym1mr12885089veb.43.1364914819976; Tue, 02 Apr 2013 08:00:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.253.194 with HTTP; Tue, 2 Apr 2013 07:59:59 -0700 (PDT) In-Reply-To: <03a001ce2faf$5235e890$f6a1b9b0$@olddog.co.uk> References: <03a001ce2faf$5235e890$f6a1b9b0$@olddog.co.uk> From: Jamal Hadi Salim Date: Tue, 2 Apr 2013 10:59:59 -0400 Message-ID: To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlzjCcC5qPsGcuoI8czcwqWQ7EDSWnOiAZAKuhZsEHgletI2Pa+8kFlFphv004JZILwtZJy Cc: forces@ietf.org Subject: Re: [forces] AD's review of charter text X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:00:21 -0000 Looks improved to me. To Joel's comment: Does the current charter have a possible (back) link to the older one so interested people can take a peek at the history? cheers, jamal On Tue, Apr 2, 2013 at 10:35 AM, Adrian Farrel wrote: > Hi, > > I did a review of the text. > > My edits are: > > - Cut out most of the preamble > - Move the "other business" paragraph to the end > - Tweak words > - Adjust layout > - Split milestones into separate items > > I posted a new revision at https://datatracker.ietf.org/doc/charter-ietf-forces/ > > You can see the differences at > https://www.ietf.org/rfcdiff?url1=http%3A%2F%2Fwww.ietf.org%2Fcharter%2Fcharter- > ietf-forces-03-02.txt&difftype=--html&submit=Go%21&url2=http%3A%2F%2Fwww.ietf.or > g%2Fcharter%2Fcharter-ietf-forces-03-04.txt > > I'd like to carry this forward with a little momentum, so would welcome comments > of approval or otherwise. > > Thanks, > Adrian > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From sm@resistor.net Tue Apr 2 05:54:47 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6D221F8C71 for ; Tue, 2 Apr 2013 05:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmVYAB-TWRB1 for ; Tue, 2 Apr 2013 05:54:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE6D21F8707 for ; Tue, 2 Apr 2013 05:54:41 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r32CsWUw028018; Tue, 2 Apr 2013 05:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364907280; bh=cU7eM1xmHJD1gk8G0nNdYq74OZgEBs1lmvuwS/XaTKY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XJNMDOupIpkodMYOYtUm9KTJS0LiyFdT0DET+Ld+rED1k592jqBK1cbqwICNsCOJ5 HCtnOB1nkvLxfaDGskFn9xu1pMIWzHf1DCQC5EE7G0o4x19rssXs0wYe/2Nj/tSO35 bBxhJ8jD4/kS96yBBX8LbFGTzqLGFWyi9mXqCEXs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364907280; i=@resistor.net; bh=cU7eM1xmHJD1gk8G0nNdYq74OZgEBs1lmvuwS/XaTKY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mdV8lurMOBiwTBGsCOTuQm0Pn6QpKOm6LGigAstinknuqLRJQ+REQMAZqnHmdzYAw a2dqgPvAICtIBCBXPn7jOd7aXE7tP/y/3kq/BPccdsrUd4w3SXt+nwLiLfUqyn19zX hz8vpJyovWESfHURvhGO10o2xLTlqRqQTewIz/ks= Message-Id: <6.2.5.6.2.20130402054504.0c041e10@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 Apr 2013 05:54:26 -0700 To: forces@ietf.org, forces-chairs@tools.ietf.org From: SM In-Reply-To: <20130401171928.14187.61003.idtracker@ietfa.amsl.com> References: <20130401171928.14187.61003.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 02 Apr 2013 08:02:01 -0700 Cc: RFC Editor Subject: Re: [forces] Protocol Action: 'ForCES Logical Function Block (LFB) Library' to Proposed Standard (draft-ietf-forces-lfb-lib-12.txt) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 12:54:47 -0000 At 10:19 01-04-2013, The IESG wrote: >The IESG has approved the following document: >- 'ForCES Logical Function Block (LFB) Library' > (draft-ietf-forces-lfb-lib-12.txt) as Proposed Standard draft-ietf-forces-lfb-lib-12 is intended to be published as a Proposed Standard. The RFC 2119 reference in the draft is informative. Regards, -sm From hadi@mojatatu.com Tue Apr 2 08:26:09 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395AB21F8AC2 for ; Tue, 2 Apr 2013 08:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zsL9BIPtRyX for ; Tue, 2 Apr 2013 08:26:08 -0700 (PDT) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9F921F8ACD for ; Tue, 2 Apr 2013 08:26:08 -0700 (PDT) Received: by mail-bk0-f42.google.com with SMTP id jc3so279792bkc.29 for ; Tue, 02 Apr 2013 08:26:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to:cc :content-type:x-gm-message-state; bh=iWK44MoUkm2DY7HrzSVDlZFPv7klWEKEiDtoP9q2Vr8=; b=dFtwImFMhkHtapTAhvGDoyPz0CaW51fjt95UE2WUk5ZCJohsiYsNj1c5MXCiIlIjw2 6MuoM/eyxpWKVsz0NHtqxnaReR7pPgnh2S4gHq/hVF4YfS3Hf/7mMLLkJdXzCdsjy5d5 vPGHeI03WP59JtXN4ecwtg6+sKeO1n0zUpCi1+/iKOzDHG3KCvn1/VEpteBU5aZkJ1L1 nqLHgn0bz4fjvwHFEGd/7Qe+B9DnJ+Fh4jg/jH/7VTWhin/zqXrpxhMRzZUxiR2/O5zw mc1az0qPFhqFKhq6znSrxlAPcVRjzArbttopRzot109m2drTkggYhwzGDsTIzfIXAmYo Ue2w== X-Received: by 10.205.116.131 with SMTP id fi3mr6979059bkc.58.1364916367159; Tue, 02 Apr 2013 08:26:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.156.210 with HTTP; Tue, 2 Apr 2013 08:25:47 -0700 (PDT) From: Jamal Hadi Salim Date: Tue, 2 Apr 2013 11:25:47 -0400 Message-ID: To: David Meyer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnox/m+1RxT4BIcgEtA+/lovD80p+s8Qi63e9HJC2MaYWZayc3Rey3G0agev9Iut3WEVozO Cc: forces@ietf.org Subject: [forces] Macro Trends, Complexity, and Sofware Defined Networking WAS(Re: Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:26:09 -0000 I would like to point out to folks interested in network programmability to take a closer look at Dave's presentation (the longer version at http://www.1-4-5.net/~dmm/talks/ncrg86.pd); I enjoyed it! In regards to OF vs ForCES - OF will eventually _have to_ look like ForCES. And I know this is hard to talk about in a public forum: As someone (technical) who is involved with ForCES and network programmability for years now, i find it frustrating that we cant have the ONF pay attention to ForCES (when you read some of the blogs we dont even exist). We have tried to extend an olive branch in the past and i think it will benefit both communities if we worked together. It doesnt seem the challenge is technical at all. One of the messages Ive gotten back is the ONF feels like they have to create things so the "IPR" is owned there. Given there are no know IPR issues known with ForCES, i didnt see what the issue is. Maybe i am not getting it since I dont attend ONF meetings. cheers, jamal On Tue, Apr 2, 2013 at 10:09 AM, David Meyer wrote: > For those who don't have ACM credentials, try > http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p19.pdf > > I have been arguing that if OpenFlow evolves past 1.0 (basically L2 only) > and 1.1+ (multi-table 1.0 with additional protocol features and which > basically unimplementable on ASIC h/w), then it will wind up looking very > similar to ForCES. In fact if you look at the proposal that Google made for > what they were calling OF 2.0 at the time, it has quite a bit in common with > ForCES (at the very least architecturally). I'm not sure if that proposal is > publically available anywhere but will check. > > I have been spending some time examining the architectural implications of > the OF mode (salient features are separation of control and data planes, > open interface to the forwarding/data plane (OF), and centralized control). > Some of my (controversial) thoughts are on > http://www.1-4-5.net/~dmm/talks/upperside_sdn_summit_paris_2013.pdf (this is > necessarily abbreviated; see something like > http://www.1-4-5.net/~dmm/talks/ncrg86.pdf for the longer form...) > From ran@bgu.ac.il Tue Apr 2 09:16:02 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3113621F8CA3 for ; Tue, 2 Apr 2013 09:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgtLrqM19SuQ for ; Tue, 2 Apr 2013 09:16:01 -0700 (PDT) Received: from smtp1.bgu.ac.il (smtp1.bgu.ac.il [132.72.126.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1851321F8700 for ; Tue, 2 Apr 2013 09:16:00 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by IMSVA80 (Postfix) with SMTP id 2BD131D0BD0; Tue, 2 Apr 2013 19:15:58 +0300 (IDT) Received: from [132.73.205.164] (unknown [132.73.205.164]) by smtp1.bgu.ac.il (Postfix) with ESMTP id 1DE161D0684; Tue, 2 Apr 2013 19:15:57 +0300 (IDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (10B329) From: Ran Giladi Date: Tue, 2 Apr 2013 19:15:55 +0300 To: Jamal Hadi Salim X-TM-AS-Product-Ver: IMSVA-8.0.0.1450-7.0.0.1014-19764.000 X-TMASE-MatchedRID: 5oZFrl7+et6PvrMjLFD6eDKH3QldZqKh04ZrfKkQEmCCsBeCv8CM/QxH Z3EylqR4nmgKAPFUekbbxr7tz8rCpFHZxHZPJAqei/vfAS7Q3HujiNbvNIOD2RL6MU7t349bxsr 6m7RljBHUWpBkBmhkavrQpUDuy6rk9y1Zvz+RbugmtTGirqG/DwvxMaV6x4s8IbxYwbCxGTT3Pc T9695w+YnEicCAF6YeWITTvlnwiI6OGtq4RwLbmfVFR4sC8dPykWjb8uGF1QUQ2rdtYjGRR4EMk ds8hccpYXX+4eEYPQTJ/lm8xN1Ib2SBCik5/ZoSbMGKOuLn5FX9yD4hAF+YInjeic/sH9oIae9S g3YKVhWpB8l8zTGMcnWi8CJ2ELfuE2ZRbV2rc3HHQ8MHM33wroLsLasl5ROhYIPlIzxi9UVHWoS +IifZqC7+9zLjqTj5DLvyKzG1xC2eHTkwQi/s1wjyj6hG1N2TlfGwpNSPVn7UHQeTVDUrIhir9A k4ADTttwKUvHHyXGXdB/CxWTRRuyUIayx+Skid X-TM-AS-Result: No--30.734-9.0-31-10 X-imss-scan-details: No--30.734-9.0-31-10 X-TM-AS-User-Approved-Sender: No Cc: "forces@ietf.org" Subject: Re: [forces] Macro Trends, Complexity, and Sofware Defined Networking WAS(Re: Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 16:16:02 -0000 You are absolutely right. When I tried to approach OF guys back then, with t= he notion of generalization using ForCES, as I did, and even demonstrated it= to them, I received very cold shoulder. However, it is a fact that they are= establishing the industry's standard, and even my company, EZchip (I'm on t= heir board) works with them. Later on I'll place info+code on my University server (some procedures requi= red...) Best, ran Sent from my iPhone On 2 =D7=91=D7=90=D7=A4=D7=A8 2013, at 18:25, Jamal Hadi Salim wrote: > I would like to point out to folks interested in network > programmability to take a > closer look at Dave's presentation (the longer version at > http://www.1-4-5.net/~dmm/talks/ncrg86.pd); > I enjoyed it! >=20 > In regards to OF vs ForCES - OF will eventually _have to_ look like ForCES= . > And I know this is hard to talk about in a public forum: > As someone (technical) who is involved with ForCES and > network programmability for years now, i find it frustrating that we cant > have the ONF pay attention to ForCES (when you read some of the blogs > we dont even exist). We have tried to extend an olive branch in the past > and i think it will benefit both communities if we worked together. > It doesnt seem the challenge is technical at all. One of the messages > Ive gotten back is the ONF feels like they have to create things so the > "IPR" is owned there. Given there are no know IPR issues known with > ForCES, i didnt see what the issue is. Maybe i am not getting it since > I dont attend ONF meetings. >=20 > cheers, > jamal >=20 > On Tue, Apr 2, 2013 at 10:09 AM, David Meyer wrote: >=20 >> For those who don't have ACM credentials, try >> http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p19.p= df >=20 >> I have been arguing that if OpenFlow evolves past 1.0 (basically L2 only)= >> and 1.1+ (multi-table 1.0 with additional protocol features and which >> basically unimplementable on ASIC h/w), then it will wind up looking very= >> similar to ForCES. In fact if you look at the proposal that Google made f= or >> what they were calling OF 2.0 at the time, it has quite a bit in common w= ith >> ForCES (at the very least architecturally). I'm not sure if that proposal= is >> publically available anywhere but will check. >>=20 >> I have been spending some time examining the architectural implications o= f >> the OF mode (salient features are separation of control and data planes, >> open interface to the forwarding/data plane (OF), and centralized control= ). >> Some of my (controversial) thoughts are on >> http://www.1-4-5.net/~dmm/talks/upperside_sdn_summit_paris_2013.pdf (this= is >> necessarily abbreviated; see something like >> http://www.1-4-5.net/~dmm/talks/ncrg86.pdf for the longer form...) >>=20 From damascene.joachimpillai@verizon.com Tue Apr 2 10:41:37 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC6221F8BA1 for ; Tue, 2 Apr 2013 10:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHtSgh9dW9n6 for ; Tue, 2 Apr 2013 10:41:36 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9D56521F8B9C for ; Tue, 2 Apr 2013 10:41:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe03.verizon.com with ESMTP; 02 Apr 2013 17:41:36 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.87,394,1363132800"; d="scan'208";a="452760248" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 02 Apr 2013 17:41:24 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Tue, 2 Apr 2013 13:41:33 -0400 To: Ran Giladi , Jamal Hadi Salim Date: Tue, 2 Apr 2013 13:41:22 -0400 Thread-Topic: [forces] Macro Trends, Complexity, and Sofware Defined Networking WAS(Re: Your recharter proposal Thread-Index: Ac4vvWynkHS1cGBYR2qbh++I2YW7SwAC6YvQ Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0119F66344@FHDP1LUMXC7V31.us.one.verizon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "forces@ietf.org" Subject: Re: [forces] Macro Trends, Complexity, and Sofware Defined Networking WAS(Re: Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 17:41:37 -0000 SmFtYWwvUmFuLA0KDQpJIHN0cm9uZ2x5IHN1cHBvcnQgdGhpcyB2aWV3LiBUaGlzIHdhcyB0aGUg cmVhc29uIHdoeSBJIHBpY2tlZCB1cCB0aGUgSW50ZXJGRSBMRkIgdG8gYmUgcGFydCBvZiB0aGUg c3RhbmRhcmRzLiANCg0KUmVnYXJkcywNCkRKDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBmb3JjZXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmZvcmNlcy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUmFuIEdpbGFkaQ0KU2VudDogVHVlc2RheSwgQXByaWwgMDIs IDIwMTMgMTI6MTYgUE0NClRvOiBKYW1hbCBIYWRpIFNhbGltDQpDYzogZm9yY2VzQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW2ZvcmNlc10gTWFjcm8gVHJlbmRzLCBDb21wbGV4aXR5LCBhbmQgU29m d2FyZSBEZWZpbmVkIE5ldHdvcmtpbmcgV0FTKFJlOiBZb3VyIHJlY2hhcnRlciBwcm9wb3NhbA0K DQpZb3UgYXJlIGFic29sdXRlbHkgcmlnaHQuIFdoZW4gSSB0cmllZCB0byBhcHByb2FjaCBPRiBn dXlzIGJhY2sgdGhlbiwgd2l0aCB0aGUgbm90aW9uIG9mIGdlbmVyYWxpemF0aW9uIHVzaW5nIEZv ckNFUywgYXMgSSBkaWQsIGFuZCBldmVuIGRlbW9uc3RyYXRlZCBpdCB0byB0aGVtLCBJIHJlY2Vp dmVkIHZlcnkgY29sZCBzaG91bGRlci4gSG93ZXZlciwgaXQgaXMgYSBmYWN0IHRoYXQgdGhleSBh cmUgZXN0YWJsaXNoaW5nIHRoZSBpbmR1c3RyeSdzIHN0YW5kYXJkLCBhbmQgZXZlbiBteSBjb21w YW55LCBFWmNoaXAgKEknbSBvbiB0aGVpciBib2FyZCkgd29ya3Mgd2l0aCB0aGVtLg0KDQpMYXRl ciBvbiBJJ2xsIHBsYWNlIGluZm8rY29kZSBvbiBteSBVbml2ZXJzaXR5IHNlcnZlciAoc29tZSBw cm9jZWR1cmVzIHJlcXVpcmVkLi4uKQ0KDQpCZXN0LCByYW4NCg0KU2VudCBmcm9tIG15IGlQaG9u ZQ0KDQpPbiAyINeR15DXpNeoIDIwMTMsIGF0IDE4OjI1LCBKYW1hbCBIYWRpIFNhbGltIDxoYWRp QG1vamF0YXR1LmNvbT4gd3JvdGU6DQoNCj4gSSB3b3VsZCBsaWtlIHRvIHBvaW50IG91dCB0byBm b2xrcyBpbnRlcmVzdGVkIGluIG5ldHdvcmsgDQo+IHByb2dyYW1tYWJpbGl0eSB0byB0YWtlIGEg Y2xvc2VyIGxvb2sgYXQgRGF2ZSdzIHByZXNlbnRhdGlvbiAodGhlIA0KPiBsb25nZXIgdmVyc2lv biBhdCBodHRwOi8vd3d3LjEtNC01Lm5ldC9+ZG1tL3RhbGtzL25jcmc4Ni5wZCk7DQo+IEkgZW5q b3llZCBpdCENCj4gDQo+IEluIHJlZ2FyZHMgdG8gT0YgdnMgRm9yQ0VTIC0gT0Ygd2lsbCBldmVu dHVhbGx5IF9oYXZlIHRvXyBsb29rIGxpa2UgRm9yQ0VTLg0KPiBBbmQgSSBrbm93IHRoaXMgaXMg aGFyZCB0byB0YWxrIGFib3V0IGluIGEgcHVibGljIGZvcnVtOg0KPiBBcyBzb21lb25lICh0ZWNo bmljYWwpIHdobyBpcyBpbnZvbHZlZCB3aXRoIEZvckNFUyBhbmQgbmV0d29yayANCj4gcHJvZ3Jh bW1hYmlsaXR5IGZvciB5ZWFycyBub3csIGkgZmluZCBpdCBmcnVzdHJhdGluZyB0aGF0IHdlIGNh bnQgaGF2ZSANCj4gdGhlIE9ORiBwYXkgYXR0ZW50aW9uIHRvIEZvckNFUyAod2hlbiB5b3UgcmVh ZCBzb21lIG9mIHRoZSBibG9ncyB3ZSANCj4gZG9udCBldmVuIGV4aXN0KS4gV2UgaGF2ZSB0cmll ZCB0byBleHRlbmQgYW4gb2xpdmUgYnJhbmNoIGluIHRoZSBwYXN0IA0KPiBhbmQgaSB0aGluayBp dCB3aWxsIGJlbmVmaXQgYm90aCBjb21tdW5pdGllcyBpZiB3ZSB3b3JrZWQgdG9nZXRoZXIuDQo+ IEl0IGRvZXNudCBzZWVtIHRoZSBjaGFsbGVuZ2UgaXMgdGVjaG5pY2FsIGF0IGFsbC4gT25lIG9m IHRoZSBtZXNzYWdlcyANCj4gSXZlIGdvdHRlbiBiYWNrIGlzIHRoZSBPTkYgZmVlbHMgbGlrZSB0 aGV5IGhhdmUgdG8gY3JlYXRlIHRoaW5ncyBzbyANCj4gdGhlICJJUFIiIGlzIG93bmVkIHRoZXJl LiBHaXZlbiB0aGVyZSBhcmUgbm8ga25vdyBJUFIgaXNzdWVzIGtub3duIA0KPiB3aXRoIEZvckNF UywgaSBkaWRudCBzZWUgd2hhdCB0aGUgaXNzdWUgaXMuIE1heWJlIGkgYW0gbm90IGdldHRpbmcg aXQgDQo+IHNpbmNlIEkgZG9udCBhdHRlbmQgT05GIG1lZXRpbmdzLg0KPiANCj4gY2hlZXJzLA0K PiBqYW1hbA0KPiANCj4gT24gVHVlLCBBcHIgMiwgMjAxMyBhdCAxMDowOSBBTSwgRGF2aWQgTWV5 ZXIgPGRtbUAxLTQtNS5uZXQ+IHdyb3RlOg0KPiANCj4+IEZvciB0aG9zZSB3aG8gZG9uJ3QgaGF2 ZSBBQ00gY3JlZGVudGlhbHMsIHRyeSANCj4+IGh0dHA6Ly9jb25mZXJlbmNlcy5zaWdjb21tLm9y Zy9zaWdjb21tLzIwMDkvd29ya3Nob3BzL3ByZXN0by9wYXBlcnMvcA0KPj4gMTkucGRmDQo+IA0K Pj4gSSBoYXZlIGJlZW4gYXJndWluZyB0aGF0IGlmIE9wZW5GbG93IGV2b2x2ZXMgcGFzdCAxLjAg KGJhc2ljYWxseSBMMiANCj4+IG9ubHkpIGFuZCAxLjErIChtdWx0aS10YWJsZSAxLjAgd2l0aCBh ZGRpdGlvbmFsIHByb3RvY29sIGZlYXR1cmVzIGFuZCANCj4+IHdoaWNoIGJhc2ljYWxseSB1bmlt cGxlbWVudGFibGUgb24gQVNJQyBoL3cpLCB0aGVuIGl0IHdpbGwgd2luZCB1cCANCj4+IGxvb2tp bmcgdmVyeSBzaW1pbGFyIHRvIEZvckNFUy4gSW4gZmFjdCBpZiB5b3UgbG9vayBhdCB0aGUgcHJv cG9zYWwgDQo+PiB0aGF0IEdvb2dsZSBtYWRlIGZvciB3aGF0IHRoZXkgd2VyZSBjYWxsaW5nIE9G IDIuMCBhdCB0aGUgdGltZSwgaXQgDQo+PiBoYXMgcXVpdGUgYSBiaXQgaW4gY29tbW9uIHdpdGgg Rm9yQ0VTIChhdCB0aGUgdmVyeSBsZWFzdCANCj4+IGFyY2hpdGVjdHVyYWxseSkuIEknbSBub3Qg c3VyZSBpZiB0aGF0IHByb3Bvc2FsIGlzIHB1YmxpY2FsbHkgYXZhaWxhYmxlIGFueXdoZXJlIGJ1 dCB3aWxsIGNoZWNrLg0KPj4gDQo+PiBJIGhhdmUgYmVlbiBzcGVuZGluZyBzb21lIHRpbWUgZXhh bWluaW5nIHRoZSBhcmNoaXRlY3R1cmFsIA0KPj4gaW1wbGljYXRpb25zIG9mIHRoZSBPRiBtb2Rl IChzYWxpZW50IGZlYXR1cmVzIGFyZSBzZXBhcmF0aW9uIG9mIA0KPj4gY29udHJvbCBhbmQgZGF0 YSBwbGFuZXMsIG9wZW4gaW50ZXJmYWNlIHRvIHRoZSBmb3J3YXJkaW5nL2RhdGEgcGxhbmUgKE9G KSwgYW5kIGNlbnRyYWxpemVkIGNvbnRyb2wpLg0KPj4gU29tZSBvZiBteSAoY29udHJvdmVyc2lh bCkgdGhvdWdodHMgYXJlIG9uIA0KPj4gaHR0cDovL3d3dy4xLTQtNS5uZXQvfmRtbS90YWxrcy91 cHBlcnNpZGVfc2RuX3N1bW1pdF9wYXJpc18yMDEzLnBkZiANCj4+ICh0aGlzIGlzIG5lY2Vzc2Fy aWx5IGFiYnJldmlhdGVkOyBzZWUgc29tZXRoaW5nIGxpa2UgDQo+PiBodHRwOi8vd3d3LjEtNC01 Lm5ldC9+ZG1tL3RhbGtzL25jcmc4Ni5wZGYgZm9yIHRoZSBsb25nZXIgZm9ybS4uLikNCj4+IA0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmZvcmNlcyBt YWlsaW5nIGxpc3QNCmZvcmNlc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9mb3JjZXMNCg== From ehalep@gmail.com Tue Apr 2 11:32:03 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D9421F8CE8 for ; Tue, 2 Apr 2013 11:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOhNoKgUa252 for ; Tue, 2 Apr 2013 11:32:02 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4307121F8C26 for ; Tue, 2 Apr 2013 11:31:59 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id q14so360950eaj.22 for ; Tue, 02 Apr 2013 11:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=UDu54r37m5THiNN2ZpNvkB7dUryyIh7Svwixg/RsJPE=; b=EnPrYLiMvJuMLc4jK1/n7I0iPFcvu49xOP5i92KFFXjJh+g+CV0PpuIOW4oFu3ACs0 H2bGjmjsF+g4vO9yG1/eJ6CV/dMcmV9Uk2Id6BBJlooVRMW3h9tmXSRNQFMaAs7K93g2 B694Dkyzd52eOeTdODeh5ltvNeSOjtQLNcccWUYYaQ+rxsCn7kmx6Jf221rW/Md/nx9/ z89POc79GfhuU0uLk5sN26IWepWLgza6bjHAFz8fjCbNy6dMxeyRcm3ZCcjuS1mIGPkB NGb13Ore21dReuGIgScjaq652DIst0bgK1JziPCMRkZY/Ze6vM5FUFZTYTRk6BYKPw1y GQyg== X-Received: by 10.14.4.69 with SMTP id 45mr52187651eei.0.1364927518449; Tue, 02 Apr 2013 11:31:58 -0700 (PDT) Received: from EhalepXPS (ppp079167082032.access.hol.gr. [79.167.82.32]) by mx.google.com with ESMTPS id f47sm4272111eep.13.2013.04.02.11.31.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 02 Apr 2013 11:31:57 -0700 (PDT) From: "Haleplidis Evangelos" To: References: <03a001ce2faf$5235e890$f6a1b9b0$@olddog.co.uk> In-Reply-To: Date: Tue, 2 Apr 2013 21:31:50 +0300 Message-ID: <011501ce2fd0$59a87b80$0cf97280$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4vstccH3Bh9/ckQFaaFsw3h6RPvAAEU1pQ Content-Language: el Subject: Re: [forces] AD's review of charter text X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:32:03 -0000 Greetings to the list, I think there is an errata in the Subsidiary Management section in the first . Change "Forwarding Element Model (FEM)" to "Forwarding Element Manager (FEM)" Did I capture the intent correctly? Also can I suggest a minor rewording for readability? From: In addition to the specific work items listed above, the working group will allow discussions of how to use ForCES to model topics of interest to Network Function Virtualization, I2RS, or OpenFlow may be discussed and reviewed. To: In addition to the specific work items listed above, the working group will allow discussions and review work of how to use ForCES to model topics of interest to Network Function Virtualization, I2RS, or OpenFlow. Other than these two I think the recharter text looks fine. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > Behalf Of Jamal Hadi Salim > Sent: Tuesday, April 02, 2013 6:00 PM > To: adrian@olddog.co.uk > Cc: forces@ietf.org > Subject: Re: [forces] AD's review of charter text > > Looks improved to me. > > To Joel's comment: > Does the current charter have a possible (back) link to the older one > so interested people can take a peek at the history? > > cheers, > jamal > > On Tue, Apr 2, 2013 at 10:35 AM, Adrian Farrel > wrote: > > Hi, > > > > I did a review of the text. > > > > My edits are: > > > > - Cut out most of the preamble > > - Move the "other business" paragraph to the end > > - Tweak words > > - Adjust layout > > - Split milestones into separate items > > > > I posted a new revision at > > https://datatracker.ietf.org/doc/charter-ietf-forces/ > > > > You can see the differences at > > > https://www.ietf.org/rfcdiff?url1=http%3A%2F%2Fwww.ietf.org%2Fcharter% > > 2Fcharter- > > ietf-forces-03-02.txt&difftype=-- > html&submit=Go%21&url2=http%3A%2F%2Fw > > ww.ietf.or g%2Fcharter%2Fcharter-ietf-forces-03-04.txt > > > > I'd like to carry this forward with a little momentum, so would > > welcome comments of approval or otherwise. > > > > Thanks, > > Adrian > > > > _______________________________________________ > > forces mailing list > > forces@ietf.org > > https://www.ietf.org/mailman/listinfo/forces > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From adrian@olddog.co.uk Tue Apr 2 14:13:20 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7FC21F8634 for ; Tue, 2 Apr 2013 14:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ma0NPCB5ZcOz for ; Tue, 2 Apr 2013 14:13:19 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 8280021F8632 for ; Tue, 2 Apr 2013 14:13:19 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32LDHeb005636; Tue, 2 Apr 2013 22:13:17 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32LDGls005627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Apr 2013 22:13:16 +0100 From: "Adrian Farrel" To: "'Haleplidis Evangelos'" , References: <03a001ce2faf$5235e890$f6a1b9b0$@olddog.co.uk> <011501ce2fd0$59a87b80$0cf97280$@com> In-Reply-To: <011501ce2fd0$59a87b80$0cf97280$@com> Date: Tue, 2 Apr 2013 22:13:17 +0100 Message-ID: <04c801ce2fe6$e5adcfc0$b1096f40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIxsNMYqI5MPfY/w3VWrEIzRuRpkgHIBBhLAlL18NiX25LHkA== Content-Language: en-gb Subject: Re: [forces] AD's review of charter text X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:13:20 -0000 Hi Haleplidis, > Change "Forwarding Element Model (FEM)" to "Forwarding Element Manager > (FEM)" > Did I capture the intent correctly? I need the WG to tell me the answer to that. The original text had "FEM" in the context of... Deployment experience has demonstrated usefulness of expressing the FEM with the same semantics as any other LFB and thus be controlled by the CE. I don't think you can express a manager with semantics (although I have had several managers that I would have liked to express :-) I checked in RFC 5810 and find you are right. But RFC 3654 talks about the "FE Model" and it seemed to me that a model is more easily expressed than a manager. > Also can I suggest a minor rewording for readability? > > From: > In addition to the specific work items listed above, the working group will > allow discussions of how to use ForCES to model topics of interest to > Network Function Virtualization, I2RS, or OpenFlow may be discussed and > reviewed. > > To: > In addition to the specific work items listed above, the working group will > allow discussions and review work of how to use ForCES to model topics of > interest to > Network Function Virtualization, I2RS, or OpenFlow. Good catch. Thanks. Adrian From joel@stevecrocker.com Tue Apr 2 14:26:07 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63CC21F8DAC for ; Tue, 2 Apr 2013 14:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNOkpYyE5qyl for ; Tue, 2 Apr 2013 14:26:07 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 41E9421F8D86 for ; Tue, 2 Apr 2013 14:26:07 -0700 (PDT) Received: from dummy.name; Tue, 02 Apr 2013 21:26:06 +0000 Message-ID: <515B4CDC.1060009@stevecrocker.com> Date: Tue, 02 Apr 2013 17:25:48 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <03a001ce2faf$5235e890$f6a1b9b0$@olddog.co.uk> <011501ce2fd0$59a87b80$0cf97280$@com> <04c801ce2fe6$e5adcfc0$b1096f40$@olddog.co.uk> In-Reply-To: <04c801ce2fe6$e5adcfc0$b1096f40$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] AD's review of charter text X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:26:08 -0000 The presentations to the working group have been about using ForCES to control the FE Manager, by creating an LFB to represent it's functions. It comes up in virtualization case, where you use normal mechanisms to establish communication with the device master, and then you instantiate FEMs to manage virtual FEs. Yours, Joel On 4/2/2013 5:13 PM, Adrian Farrel wrote: > Hi Haleplidis, > >> Change "Forwarding Element Model (FEM)" to "Forwarding Element Manager >> (FEM)" >> Did I capture the intent correctly? > > I need the WG to tell me the answer to that. > The original text had "FEM" in the context of... > > Deployment experience has demonstrated usefulness of expressing the FEM > with the same semantics as any other LFB and thus be controlled by the CE. > > I don't think you can express a manager with semantics (although I have had > several managers that I would have liked to express :-) > > I checked in RFC 5810 and find you are right. But RFC 3654 talks about the "FE > Model" and it seemed to me that a model is more easily expressed than a manager. > >> Also can I suggest a minor rewording for readability? >> >> From: >> In addition to the specific work items listed above, the working group will >> allow discussions of how to use ForCES to model topics of interest to >> Network Function Virtualization, I2RS, or OpenFlow may be discussed and >> reviewed. >> >> To: >> In addition to the specific work items listed above, the working group will >> allow discussions and review work of how to use ForCES to model topics of >> interest to >> Network Function Virtualization, I2RS, or OpenFlow. > > Good catch. Thanks. > > Adrian > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From joel@stevecrocker.com Tue Apr 2 14:40:29 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C092E21F8A4E for ; Tue, 2 Apr 2013 14:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31j4O4j59H0x for ; Tue, 2 Apr 2013 14:40:29 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2CF21F8A38 for ; Tue, 2 Apr 2013 14:40:29 -0700 (PDT) Received: from dummy.name; Tue, 02 Apr 2013 21:40:28 +0000 Message-ID: <515B503A.2080209@stevecrocker.com> Date: Tue, 02 Apr 2013 17:40:10 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: afarrel@juniper.net References: <03a001ce2faf$5235e890$f6a1b9b0$@olddog.co.uk> <011501ce2fd0$59a87b80$0cf97280$@com> <04c801ce2fe6$e5adcfc0$b1096f40$@olddog.co.uk> <515B4CDC.1060009@stevecrocker.com> <04ca01ce2fe9$70971cc0$51c55640$@juniper.net> In-Reply-To: <04ca01ce2fe9$70971cc0$51c55640$@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] AD's review of charter text X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:40:29 -0000 With two minor modifications, it works for me. 1) s/LFD/LFB/ 2) change "same semantics as for any other LFB" to "appropriate semantics, as is required for every LFB definition" The reason for point 2 is that the semantics of an LFB definition are its definition. They are not the same for all LFB definitions. Yours, Joel On 4/2/2013 5:31 PM, Adrian Farrel wrote: > Gotcha. Thanks! > > How about... > > OLD > Deployment experience has demonstrated usefulness of expressing the > Forwarding Element Model (FEM) using the same semantics as for any other LFB. > NEW > Deployment experience has demonstrated the value of using ForCES to control > the Forwarding Element Manager (FEM) by creating an LFD to represent its > function using the same semantics as for any other LFB. > END > > Adrian > >> -----Original Message----- >> From: Joel [mailto:joel@stevecrocker.com] >> Sent: 02 April 2013 22:26 >> To: adrian@olddog.co.uk >> Cc: 'Haleplidis Evangelos'; forces@ietf.org >> Subject: Re: [forces] AD's review of charter text >> >> The presentations to the working group have been about using ForCES to >> control the FE Manager, by creating an LFB to represent it's functions. >> It comes up in virtualization case, where you use normal mechanisms >> to establish communication with the device master, and then you >> instantiate FEMs to manage virtual FEs. >> >> Yours, >> Joel >> >> >> On 4/2/2013 5:13 PM, Adrian Farrel wrote: >>> Hi Haleplidis, >>> >>>> Change "Forwarding Element Model (FEM)" to "Forwarding Element Manager >>>> (FEM)" >>>> Did I capture the intent correctly? >>> >>> I need the WG to tell me the answer to that. >>> The original text had "FEM" in the context of... >>> >>> Deployment experience has demonstrated usefulness of expressing the FEM >>> with the same semantics as any other LFB and thus be controlled by the > CE. >>> >>> I don't think you can express a manager with semantics (although I have had >>> several managers that I would have liked to express :-) >>> >>> I checked in RFC 5810 and find you are right. But RFC 3654 talks about the > "FE >>> Model" and it seemed to me that a model is more easily expressed than a >> manager. >>> >>>> Also can I suggest a minor rewording for readability? >>>> >>>> From: >>>> In addition to the specific work items listed above, the working group will >>>> allow discussions of how to use ForCES to model topics of interest to >>>> Network Function Virtualization, I2RS, or OpenFlow may be discussed and >>>> reviewed. >>>> >>>> To: >>>> In addition to the specific work items listed above, the working group will >>>> allow discussions and review work of how to use ForCES to model topics of >>>> interest to >>>> Network Function Virtualization, I2RS, or OpenFlow. >>> >>> Good catch. Thanks. >>> >>> Adrian >>> >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces >>> > From afarrel@juniper.net Tue Apr 2 14:31:32 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245BE21F85CE for ; Tue, 2 Apr 2013 14:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6ncNt11rCm2 for ; Tue, 2 Apr 2013 14:31:31 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5F24A21F85CB for ; Tue, 2 Apr 2013 14:31:31 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32LVTX5010434; Tue, 2 Apr 2013 22:31:29 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r32LVSNA010428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Apr 2013 22:31:28 +0100 From: "Adrian Farrel" To: "'Joel'" , References: <03a001ce2faf$5235e890$f6a1b9b0$@olddog.co.uk> <011501ce2fd0$59a87b80$0cf97280$@com> <04c801ce2fe6$e5adcfc0$b1096f40$@olddog.co.uk> <515B4CDC.1060009@stevecrocker.com> In-Reply-To: <515B4CDC.1060009@stevecrocker.com> Date: Tue, 2 Apr 2013 22:31:29 +0100 Message-ID: <04ca01ce2fe9$70971cc0$51c55640$@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIxsNMYqI5MPfY/w3VWrEIzRuRpkgHIBBhLAlL18NgCCG2KmwKMzquXl7bukCA= Content-Language: en-gb X-Mailman-Approved-At: Tue, 02 Apr 2013 14:53:52 -0700 Cc: forces@ietf.org Subject: Re: [forces] AD's review of charter text X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: afarrel@juniper.net List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:31:32 -0000 Gotcha. Thanks! How about... OLD Deployment experience has demonstrated usefulness of expressing the Forwarding Element Model (FEM) using the same semantics as for any other LFB. NEW Deployment experience has demonstrated the value of using ForCES to control the Forwarding Element Manager (FEM) by creating an LFD to represent its function using the same semantics as for any other LFB. END Adrian > -----Original Message----- > From: Joel [mailto:joel@stevecrocker.com] > Sent: 02 April 2013 22:26 > To: adrian@olddog.co.uk > Cc: 'Haleplidis Evangelos'; forces@ietf.org > Subject: Re: [forces] AD's review of charter text > > The presentations to the working group have been about using ForCES to > control the FE Manager, by creating an LFB to represent it's functions. > It comes up in virtualization case, where you use normal mechanisms > to establish communication with the device master, and then you > instantiate FEMs to manage virtual FEs. > > Yours, > Joel > > > On 4/2/2013 5:13 PM, Adrian Farrel wrote: > > Hi Haleplidis, > > > >> Change "Forwarding Element Model (FEM)" to "Forwarding Element Manager > >> (FEM)" > >> Did I capture the intent correctly? > > > > I need the WG to tell me the answer to that. > > The original text had "FEM" in the context of... > > > > Deployment experience has demonstrated usefulness of expressing the FEM > > with the same semantics as any other LFB and thus be controlled by the CE. > > > > I don't think you can express a manager with semantics (although I have had > > several managers that I would have liked to express :-) > > > > I checked in RFC 5810 and find you are right. But RFC 3654 talks about the "FE > > Model" and it seemed to me that a model is more easily expressed than a > manager. > > > >> Also can I suggest a minor rewording for readability? > >> > >> From: > >> In addition to the specific work items listed above, the working group will > >> allow discussions of how to use ForCES to model topics of interest to > >> Network Function Virtualization, I2RS, or OpenFlow may be discussed and > >> reviewed. > >> > >> To: > >> In addition to the specific work items listed above, the working group will > >> allow discussions and review work of how to use ForCES to model topics of > >> interest to > >> Network Function Virtualization, I2RS, or OpenFlow. > > > > Good catch. Thanks. > > > > Adrian > > > > _______________________________________________ > > forces mailing list > > forces@ietf.org > > https://www.ietf.org/mailman/listinfo/forces > > From hadi@mojatatu.com Wed Apr 3 04:57:02 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E4E21F8B0C for ; Wed, 3 Apr 2013 04:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qdb--771Hvk9 for ; Wed, 3 Apr 2013 04:57:01 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 12B8221F8A8A for ; Wed, 3 Apr 2013 04:57:00 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id hx10so1398492vcb.33 for ; Wed, 03 Apr 2013 04:57:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=KQ92vVCi+mRXmd6HVkXCedxAW7uZXzhMUvqW32veVa0=; b=HAQjLD+1Fk5KAEWoUb3OEHfo8Ioba1wrPNaT/hXZGB+LlzJokMFBmBrKydoqzmYDxd CTykNE8UOzqCTLRQQ6ulyohfExqi1WfoLe+n2Quzxx3qKLNB9j8jRGChfy8dt9krqi8l Q4Ag6xdOE0/g90C838MGDk5WufWRqekExuwfu0Wac3jBbc4/fb+9skCOC9G6/fDh6cs8 ORbSLC1J48fLoIgLmmwi/RuGDCcCE830Nvcdw9Dussg85lKF9cOAZ/bRW5gMHer4NSIe WLL1IT6yg2aV7QqpY/5ya32nhk6JPqQQoZmdGMsQKqPadoAR7QqX950z6YsKSHLEXVuA Kkcg== X-Received: by 10.220.223.80 with SMTP id ij16mr933848vcb.28.1364990220362; Wed, 03 Apr 2013 04:57:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.59.106 with HTTP; Wed, 3 Apr 2013 04:56:40 -0700 (PDT) In-Reply-To: <20130403115550.28503.87661.idtracker@ietfa.amsl.com> References: <20130403115550.28503.87661.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Wed, 3 Apr 2013 07:56:40 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkXYgW8nLyU467IYSteEhMdqbAcVC97y/aNmJotBsDr+dU+zPnWReQDkIf8ihkwmmH+eHR5 Subject: [forces] Fwd: New Version Notification for draft-jhs-forces-protoextenstion-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 11:57:02 -0000 initial protocol update submission ---------- Forwarded message ---------- From: Date: Wed, Apr 3, 2013 at 7:55 AM Subject: New Version Notification for draft-jhs-forces-protoextenstion-00.txt To: hadi@mojatatu.com A new version of I-D, draft-jhs-forces-protoextenstion-00.txt has been successfully submitted by Jamal Hadi Salim and posted to the IETF repository. Filename: draft-jhs-forces-protoextenstion Revision: 00 Title: ForCES Protocol Extensions Creation date: 2013-04-03 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-jhs-forces-protoextenstion-00.txt Status: http://datatracker.ietf.org/doc/draft-jhs-forces-protoextenstion Htmlized: http://tools.ietf.org/html/draft-jhs-forces-protoextenstion-00 Abstract: Experience in implementing and deploying ForCES architecture has demonstrated need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. This document describes a few extensions to the ForCES Protocol Specification [RFC5810] semantics to achieve that end goal. The IETF Secretariat From adrian@olddog.co.uk Wed Apr 3 05:16:41 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180BD21F8BC5 for ; Wed, 3 Apr 2013 05:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqDIUbrnstbl for ; Wed, 3 Apr 2013 05:16:40 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4081521F8C0C for ; Wed, 3 Apr 2013 05:16:40 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r33CGc3x003350; Wed, 3 Apr 2013 13:16:38 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r33CGbFG003329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Apr 2013 13:16:37 +0100 From: "Adrian Farrel" To: "'Joel'" References: <03a001ce2faf$5235e890$f6a1b9b0$@olddog.co.uk> <011501ce2fd0$59a87b80$0cf97280$@com> <04c801ce2fe6$e5adcfc0$b1096f40$@olddog.co.uk> <515B4CDC.1060009@stevecrocker.com> <04ca01ce2fe9$70971cc0$51c55640$@juniper.net> <515B503A.2080209@stevecrocker.com> In-Reply-To: <515B503A.2080209@stevecrocker.com> Date: Wed, 3 Apr 2013 13:16:37 +0100 Message-ID: <058c01ce3065$179e8d20$46dba760$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIxsNMYqI5MPfY/w3VWrEIzRuRpkgHIBBhLAlL18NgCCG2KmwKMzquXAd6sKiYCWN9tS5eWKiBA Content-Language: en-gb Cc: forces@ietf.org Subject: Re: [forces] AD's review of charter text X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 12:16:41 -0000 Typos abound. Very good catch on "semantics". I think the intent of the original was "syntax". I.e., that it should be an LFB using the same encoding rules as in other LFBs. A > -----Original Message----- > From: Joel [mailto:joel@stevecrocker.com] > Sent: 02 April 2013 22:40 > To: afarrel@juniper.net > Cc: adrian@olddog.co.uk; 'Haleplidis Evangelos'; forces@ietf.org > Subject: Re: [forces] AD's review of charter text > > With two minor modifications, it works for me. > 1) s/LFD/LFB/ > 2) change "same semantics as for any other LFB" to "appropriate > semantics, as is required for every LFB definition" > > The reason for point 2 is that the semantics of an LFB definition are > its definition. They are not the same for all LFB definitions. > > Yours, > Joel > > On 4/2/2013 5:31 PM, Adrian Farrel wrote: > > Gotcha. Thanks! > > > > How about... > > > > OLD > > Deployment experience has demonstrated usefulness of expressing the > > Forwarding Element Model (FEM) using the same semantics as for any other > LFB. > > NEW > > Deployment experience has demonstrated the value of using ForCES to > control > > the Forwarding Element Manager (FEM) by creating an LFD to represent its > > function using the same semantics as for any other LFB. > > END > > > > Adrian > > > >> -----Original Message----- > >> From: Joel [mailto:joel@stevecrocker.com] > >> Sent: 02 April 2013 22:26 > >> To: adrian@olddog.co.uk > >> Cc: 'Haleplidis Evangelos'; forces@ietf.org > >> Subject: Re: [forces] AD's review of charter text > >> > >> The presentations to the working group have been about using ForCES to > >> control the FE Manager, by creating an LFB to represent it's functions. > >> It comes up in virtualization case, where you use normal mechanisms > >> to establish communication with the device master, and then you > >> instantiate FEMs to manage virtual FEs. > >> > >> Yours, > >> Joel > >> > >> > >> On 4/2/2013 5:13 PM, Adrian Farrel wrote: > >>> Hi Haleplidis, > >>> > >>>> Change "Forwarding Element Model (FEM)" to "Forwarding Element > Manager > >>>> (FEM)" > >>>> Did I capture the intent correctly? > >>> > >>> I need the WG to tell me the answer to that. > >>> The original text had "FEM" in the context of... > >>> > >>> Deployment experience has demonstrated usefulness of expressing the > FEM > >>> with the same semantics as any other LFB and thus be controlled by the > > CE. > >>> > >>> I don't think you can express a manager with semantics (although I have had > >>> several managers that I would have liked to express :-) > >>> > >>> I checked in RFC 5810 and find you are right. But RFC 3654 talks about the > > "FE > >>> Model" and it seemed to me that a model is more easily expressed than a > >> manager. > >>> > >>>> Also can I suggest a minor rewording for readability? > >>>> > >>>> From: > >>>> In addition to the specific work items listed above, the working group will > >>>> allow discussions of how to use ForCES to model topics of interest to > >>>> Network Function Virtualization, I2RS, or OpenFlow may be discussed and > >>>> reviewed. > >>>> > >>>> To: > >>>> In addition to the specific work items listed above, the working group will > >>>> allow discussions and review work of how to use ForCES to model topics of > >>>> interest to > >>>> Network Function Virtualization, I2RS, or OpenFlow. > >>> > >>> Good catch. Thanks. > >>> > >>> Adrian > >>> > >>> _______________________________________________ > >>> forces mailing list > >>> forces@ietf.org > >>> https://www.ietf.org/mailman/listinfo/forces > >>> > > From joel@stevecrocker.com Wed Apr 3 06:50:37 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC4921F8DC9 for ; Wed, 3 Apr 2013 06:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR6CF6H-SE3R for ; Wed, 3 Apr 2013 06:50:37 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id E0BBF21F8A91 for ; Wed, 3 Apr 2013 06:50:36 -0700 (PDT) Received: from dummy.name; Wed, 03 Apr 2013 13:50:36 +0000 Message-ID: <515C3398.7070604@stevecrocker.com> Date: Wed, 03 Apr 2013 09:50:16 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <03a001ce2faf$5235e890$f6a1b9b0$@olddog.co.uk> <011501ce2fd0$59a87b80$0cf97280$@com> <04c801ce2fe6$e5adcfc0$b1096f40$@olddog.co.uk> <515B4CDC.1060009@stevecrocker.com> <04ca01ce2fe9$70971cc0$51c55640$@juniper.net> <515B503A.2080209@stevecrocker.com> <058c01ce3065$179e8d20$46dba760$@olddog.co.uk> In-Reply-To: <058c01ce3065$179e8d20$46dba760$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] AD's review of charter text X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 13:50:37 -0000 "same syntax" would be fine. "same structure" would also be okay. Yours, Joel On 4/3/2013 8:16 AM, Adrian Farrel wrote: > Typos abound. > > Very good catch on "semantics". > I think the intent of the original was "syntax". I.e., that it should be an LFB > using the same encoding rules as in other LFBs. > > A > >> -----Original Message----- >> From: Joel [mailto:joel@stevecrocker.com] >> Sent: 02 April 2013 22:40 >> To: afarrel@juniper.net >> Cc: adrian@olddog.co.uk; 'Haleplidis Evangelos'; forces@ietf.org >> Subject: Re: [forces] AD's review of charter text >> >> With two minor modifications, it works for me. >> 1) s/LFD/LFB/ >> 2) change "same semantics as for any other LFB" to "appropriate >> semantics, as is required for every LFB definition" >> >> The reason for point 2 is that the semantics of an LFB definition are >> its definition. They are not the same for all LFB definitions. >> >> Yours, >> Joel >> >> On 4/2/2013 5:31 PM, Adrian Farrel wrote: >>> Gotcha. Thanks! >>> >>> How about... >>> >>> OLD >>> Deployment experience has demonstrated usefulness of expressing the >>> Forwarding Element Model (FEM) using the same semantics as for any other >> LFB. >>> NEW >>> Deployment experience has demonstrated the value of using ForCES to >> control >>> the Forwarding Element Manager (FEM) by creating an LFD to represent its >>> function using the same semantics as for any other LFB. >>> END >>> >>> Adrian >>> >>>> -----Original Message----- >>>> From: Joel [mailto:joel@stevecrocker.com] >>>> Sent: 02 April 2013 22:26 >>>> To: adrian@olddog.co.uk >>>> Cc: 'Haleplidis Evangelos'; forces@ietf.org >>>> Subject: Re: [forces] AD's review of charter text >>>> >>>> The presentations to the working group have been about using ForCES to >>>> control the FE Manager, by creating an LFB to represent it's functions. >>>> It comes up in virtualization case, where you use normal mechanisms >>>> to establish communication with the device master, and then you >>>> instantiate FEMs to manage virtual FEs. >>>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 4/2/2013 5:13 PM, Adrian Farrel wrote: >>>>> Hi Haleplidis, >>>>> >>>>>> Change "Forwarding Element Model (FEM)" to "Forwarding Element >> Manager >>>>>> (FEM)" >>>>>> Did I capture the intent correctly? >>>>> >>>>> I need the WG to tell me the answer to that. >>>>> The original text had "FEM" in the context of... >>>>> >>>>> Deployment experience has demonstrated usefulness of expressing the >> FEM >>>>> with the same semantics as any other LFB and thus be controlled by the >>> CE. >>>>> >>>>> I don't think you can express a manager with semantics (although I have > had >>>>> several managers that I would have liked to express :-) >>>>> >>>>> I checked in RFC 5810 and find you are right. But RFC 3654 talks about the >>> "FE >>>>> Model" and it seemed to me that a model is more easily expressed than a >>>> manager. >>>>> >>>>>> Also can I suggest a minor rewording for readability? >>>>>> >>>>>> From: >>>>>> In addition to the specific work items listed above, the working group > will >>>>>> allow discussions of how to use ForCES to model topics of interest to >>>>>> Network Function Virtualization, I2RS, or OpenFlow may be discussed and >>>>>> reviewed. >>>>>> >>>>>> To: >>>>>> In addition to the specific work items listed above, the working group > will >>>>>> allow discussions and review work of how to use ForCES to model topics of >>>>>> interest to >>>>>> Network Function Virtualization, I2RS, or OpenFlow. >>>>> >>>>> Good catch. Thanks. >>>>> >>>>> Adrian >>>>> >>>>> _______________________________________________ >>>>> forces mailing list >>>>> forces@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/forces >>>>> >>> > From adrian@olddog.co.uk Wed Apr 3 07:58:06 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8AE21F8EB5 for ; Wed, 3 Apr 2013 07:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFutLoQ4-nZo for ; Wed, 3 Apr 2013 07:58:05 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF9F21F8E71 for ; Wed, 3 Apr 2013 07:58:05 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r33EvuSs001707 for ; Wed, 3 Apr 2013 15:57:56 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r33EvtvL001681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 3 Apr 2013 15:57:56 +0100 From: "Adrian Farrel" To: Date: Wed, 3 Apr 2013 15:57:56 +0100 Message-ID: <05e801ce307b$a06f4340$e14dc9c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4we55vgtsveJ+rSoeKC+d8vof2qg== Content-Language: en-gb Subject: [forces] Charter text updates X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 14:58:06 -0000 Hi, Current update is at https://datatracker.ietf.org/doc/charter-ietf-forces/ I am still looking for comments of support, disagreement, or ridicule. Adrian From hadi@mojatatu.com Thu Apr 4 03:55:21 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB1121F9656 for ; Thu, 4 Apr 2013 03:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.678 X-Spam-Level: X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_62=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWrOht2il8d3 for ; Thu, 4 Apr 2013 03:55:20 -0700 (PDT) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB7E21F9651 for ; Thu, 4 Apr 2013 03:55:20 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id p13so1156646vbe.7 for ; Thu, 04 Apr 2013 03:55:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding:x-gm-message-state; bh=YN561b5IJxYOL39S8U6+m1NUoV9NqBFzRBwwjtxooZ8=; b=LAYUg1kwrPImykvoSM/p1vql7wg5dY2DBOL9BwYHLqZ+7TIzGt6Xw1krlcnSf0HMB2 EQjGMGWVRTw4FDZEy/eP1GB2eAYV3U5mNxtlJR4rkJ0uBLSXNuLqyy/vLm9DRR+LUMO/ YEwFAZTwqBD9Qq3q3xqHZjt7L9Jt02R6ui+vB8cCH5Nuc8gIxD5aW7kswPrnv11yIzU+ RnAjz3tWaRcAH75BBnxZ5aJT1lDsormMLPgqVA6guz5JK0dnwtC1r3k7vxyhizzwd9Er N86A0M7G356f9hqJ4zd6pDpXm9MU/Ar5cYJdha7gp8jz/o8WWR92njWIzgooTCI/k02+ 7OYQ== X-Received: by 10.52.162.71 with SMTP id xy7mr3644365vdb.11.1365072919828; Thu, 04 Apr 2013 03:55:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.59.106 with HTTP; Thu, 4 Apr 2013 03:54:59 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 4 Apr 2013 06:54:59 -0400 Message-ID: To: i2rs@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmpdWcqNngafutRWI+F1KdHWqzE7C7/gSFMWmbHViFy+NCCRGMkDsFFIcE5f7ifkYL5gfTo Cc: forces@ietf.org Subject: [forces] Proposing ForCES model for I2RS X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 10:55:21 -0000 Hi, Ive been meaning to put out a draft, but since i havent gathered the energy to do so, I figured at minimal i should post my notes. I'd like to have the ForCES data model be put to consideration for I2RS and I hope to make some basic case for its validity with this post. Really, I was hoping there would be requirements put out first (but). There is no publicly available tutorial of ForCES(we are working on it); closest I can point you to at the moment is: https://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-2.pdf A few of the slides in that presentation talk about the model. But to get a detailed grasp of the model, please read RFC 5812. Highlights of the ForCES data model ------------------------------------------------------ -Hierarchical control/config/state data models -reusable atomic types, complex/compound types, grouping of compound types in the form of indexed/keyed tables and Logical Functional Blocks(LFB) -informational-modeled metadata and expectations -Built in capability definition/advertisement -publish/subscribe event model with expressive trigger and report definitio= ns -data model flexibility/extensibility through augmentations, inheritance -backward and forward compatibility -formal constraints for validation of defined components -data model modularity through LFB modules -versioning rules -produced by _the smart people_ of the IETF (Paraphrasing J=FCrgen ;->) On meeting the needs for I2RS -------------------------------------------- If one was to start with the floated Yang models (I think there was route, IP address and port models), then we can express any of those using ForCES language. I believe it would be useful for I2RS WG to come up with some simple information model that can be then used to do some gap analysis of the different contending data models. Yes, Ive seen the debate on the list but it is getting silly when we have engineering solutions being pushed forward to ignore this fact. And since I couldnt find "requirements" for a data model anywhere, as a starting point, I am going to use Alia's excellent summary post at: https://www.ietf.org/mail-archive/web/i2rs/current/msg00580.html and try to address only the issues I think relate to the model. If i missed something let me know. I think the relevant points on the model expressed in Alia's post are: 1) client ownership. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ForCES has rudimentary ACLs (read/write permissions) which are defined as properties of a controlled/configured component. In my opinion, client ownership of a specific runtime state could be: a) made as an additional ForCES component property. A 32 bit id identifying some owner client would suffice. One could go further and make this look like unix permissions with the read/write ACL having world/group/owner ids as properties This will require an additional extension to add a new ForCES property but has the nice feature of being exposable as a unix filesystem and therefore re-use all the good (and bad) attributes of filesystems. b) Make it part of the model definition. In classical route entries, the client that inserted a route is typically specified and stored at the FIB (in my experience for debug purposes). If you take this approach you dont need to make any ForCES extensions. In both #a and #b, inheritted ACL/ownership will work because of the hierarchical nature of ForCES data model. I am also ignoring the credential vetting which i believe belongs in an orthogonal interface. 2) Notifications when written state changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Trivial to achieve in ForCES. Part of the data model definition of whatever is decided as the data model. 3) Filtered threshold notifications. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Supported by ForCES. Refer to: https://tools.ietf.org/html/rfc5812#section-4.8.5 Event filtering supported by ForCES includes: a) hysteresis - used to suppress generation of notifications for oscillations around a condition value. example: generate an event if the link laser goes below 10 or goes above 15. b) count - used to suppress event generation around occurence count. Example, report the event to the client only after 5 consecutive occurances= . c) time interval - used to suppress event generation around a time limit Example: Generate an event if some table row hasnt been used in the last 10 minutes. There could be multiple filters defined per event and any one triggers then a subscribed to event is generated. Example of compound filtering: Generate an event when the count reaches 5 or every 10 minutes when there is at least one event. 4) Different Operational models =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D a) Persistence. In ForCES this is part of what we call the Protocol Object LFB; a config LFB which states the graceful properties of state. I would envision something equivalent would be needed for I2RS. b) Start-time modes. I was a little confused by this. Shouldnt such state be installed by some client when ready to be used (i.e use some external approach such as crontab) c) state expiration. One could use the ForCES event mechanism to express different views of this= . Example, you could age state based on timer filtering or expire state based on complex filter which includes a timer and table hits Ok, what else did i miss? cheers, jamal From adrian@olddog.co.uk Sun Apr 7 05:23:34 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9196821F8EE1 for ; Sun, 7 Apr 2013 05:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80qSTYE16gII for ; Sun, 7 Apr 2013 05:23:34 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id A9AD821F8ED8 for ; Sun, 7 Apr 2013 05:23:33 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r37CNVZ1012756 for ; Sun, 7 Apr 2013 13:23:32 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r37CNVH9012748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 7 Apr 2013 13:23:31 +0100 From: "Adrian Farrel" To: Date: Sun, 7 Apr 2013 13:23:30 +0100 Message-ID: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4zirLyAvyPuQDFTjCUCK10z3PG0Q== Content-Language: en-gb Subject: [forces] Voices of support needed! [Was: Charter text updates] X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 12:23:34 -0000 Hi ForCES, I am not going to go to the rest of the IESG and say "Two people said OK, and no-one else actually objected." If I do that, they will (rightly) object to re-chartering the WG. This is your make or break! If you can't enthusiastically commit to this proposed re-charter then it is pretty obvious where we stand. I know that a number of you say you want to work on this stuff, so stand up and wave your hat in the air! Thanks, Adrian > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: 03 April 2013 15:58 > To: forces@ietf.org > Subject: [forces] Charter text updates > > Hi, > > Current update is at https://datatracker.ietf.org/doc/charter-ietf-forces/ > > I am still looking for comments of support, disagreement, or ridicule. > > Adrian > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Sun Apr 7 06:23:10 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824E921F8618 for ; Sun, 7 Apr 2013 06:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.934 X-Spam-Level: X-Spam-Status: No, score=-102.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+0Z4YhTHe2u for ; Sun, 7 Apr 2013 06:23:09 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id BA3CB21F8617 for ; Sun, 7 Apr 2013 06:23:09 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id cy12so4665345veb.4 for ; Sun, 07 Apr 2013 06:23:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=f5Md3+8DKJtlBs5O6fm/XuYY7BKCjMRE46HAPnwS/JQ=; b=Gblmit6mJ4KBwwePTDxLwmeEUfI58q2S6EsWUtOFaFLTQhPvVyfOiWme337jSmqo/4 2h37XeaXrVpXPHhGmrtQThfXK9yiCTH3pv5tfPgSjLJiRXzJMShY+44MHFYcO5qNm0Vg 6xWFsXQg39YowIUCdv1slvKcEGo5aZ3qY9lr1G/IXLF5bXrFGjeVerrjE7Ob95jJ72FD Nu/uD5+mNuT6lAmwaSlfjRZqHyWeVMRwjoPcWki844VyWMVNdnaJmRwDmbMvbapibzZq ZX29BTMe6kj6nYQHAGkO2+++g7e9NfUXHxXuhIN3+XNTgmn350fCWO1u+wCY3MXW2PXC u/iA== X-Received: by 10.220.77.138 with SMTP id g10mr7729925vck.69.1365340982858; Sun, 07 Apr 2013 06:23:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.237.229 with HTTP; Sun, 7 Apr 2013 06:22:42 -0700 (PDT) In-Reply-To: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> References: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> From: Jamal Hadi Salim Date: Sun, 7 Apr 2013 09:22:42 -0400 Message-ID: To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk9o1Ew8YO0Cf2g9Av/PlU58AV4NZwaNOVgljQLNTPcPFQhMwdhVyjlDUFt2KAP/BhtLS/r Cc: forces@ietf.org Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 13:23:10 -0000 Hi Adrian, I noticed Joel was the only person to respond on the last update you made. Please accept my ACK. The "problem" is there is nothing controversial about the posted charter. I did take a glance (it looked good). So silence on my part means ACK as i am sure it does for most people committed to doing the work. Could people reading this message please give an ACK or a comment to Adrian? cheers, jamal On Sun, Apr 7, 2013 at 8:23 AM, Adrian Farrel wrote: > Hi ForCES, > > I am not going to go to the rest of the IESG and say "Two people said OK, and > no-one else actually objected." If I do that, they will (rightly) object to > re-chartering the WG. > > This is your make or break! If you can't enthusiastically commit to this > proposed re-charter then it is pretty obvious where we stand. I know that a > number of you say you want to work on this stuff, so stand up and wave your hat > in the air! > > Thanks, > Adrian > >> -----Original Message----- >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of >> Adrian Farrel >> Sent: 03 April 2013 15:58 >> To: forces@ietf.org >> Subject: [forces] Charter text updates >> >> Hi, >> >> Current update is at https://datatracker.ietf.org/doc/charter-ietf-forces/ >> >> I am still looking for comments of support, disagreement, or ridicule. >> >> Adrian >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From vumip1@gmail.com Sun Apr 7 06:50:32 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B452821F8E63 for ; Sun, 7 Apr 2013 06:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaQlFmUR3lgf for ; Sun, 7 Apr 2013 06:50:31 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2BE21F8585 for ; Sun, 7 Apr 2013 06:50:31 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b12so5129163wgh.30 for ; Sun, 07 Apr 2013 06:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2RPu63+9ZwpEGTZHzyRLAwQwW21YzWDwmhpIvojgLoc=; b=J6ezjLwYKCqszOP3fRzlbmYyVGAbccpGonHRvmrH9eEXRfh2zTZRnAG4i156j5n+Q0 orKgQ1K/DzZW/kD4cx2TuCCGMAJ3dFH6hNv8mUROeHr4VOCU44YHQ63KWG0SaDgmic+o wscVwreyZS4BUp5uOM1KpKovms+EpPP3DrqUCZvee5pA5c4lOPluZLZgs0rhiWtrncpb AKuaudZ7OP+9K5hO+PT3jnS/HSS/p+Z1Zv8goZmKOIxW6dxsLxzluY2aHvhl80kMhOpU CbZ2Cp811wwxGRERj1aWXsdXB5ACDqqFWXTDEzMJEcXKXdZDzpZ8IDU5/SN+Dn+gl+Sj w4mg== MIME-Version: 1.0 X-Received: by 10.194.173.228 with SMTP id bn4mr26440164wjc.20.1365342630390; Sun, 07 Apr 2013 06:50:30 -0700 (PDT) Received: by 10.216.124.5 with HTTP; Sun, 7 Apr 2013 06:50:30 -0700 (PDT) In-Reply-To: <01ca01ce2f1f$aa478ab0$fed6a010$@olddog.co.uk> References: <01ca01ce2f1f$aa478ab0$fed6a010$@olddog.co.uk> Date: Sun, 7 Apr 2013 09:50:30 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: adrian@olddog.co.uk, Jamal Hadi Salim Content-Type: multipart/alternative; boundary=089e0122e8dc7b30a304d9c59adf Cc: forces@ietf.org Subject: Re: [forces] Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 13:50:32 -0000 --089e0122e8dc7b30a304d9c59adf Content-Type: text/plain; charset=ISO-8859-1 Adrian, Jamal, Thanks. The updated charter looks fine. We are interested to work on and contribute to virtualization of FE and CE. In addition, we look forward to work with others on database sharding ( http://en.wikipedia.org/wiki/Shard_(database_architecture) ) for inter-LFB and other relevant features/services. Thanks again. Best. Bhumip On Mon, Apr 1, 2013 at 5:27 PM, Adrian Farrel wrote: > Hi ForCES, > > I have entered your proposed charter text at > https://datatracker.ietf.org/doc/charter-ietf-forces/ > > Since the meeting in Orlando I haven't heard a word of disquiet from you > about > the charter so I am going to assume that you are all happy with what is > in/out > within the bounds of understanding when you are in the rough. Therefore, > please > shout loud and clear if that is not the case. > > I am now going to set about some wordsmithing because the current proposal > is > about 25 pages too long :-) > > Cheers, > Adrian > > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > --089e0122e8dc7b30a304d9c59adf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adrian, Jamal,
=A0
Thanks. The updated charter loo= ks fine. We are interested to
work on and contribute to virtuali= zation of FE and CE.
=A0
In addition, we look forward t= o work with others on database
for inter-LFB and other relevant features/services.
=A0
Thanks again.
=A0
Best.
=A0
Bhumip
=A0

On Mon, Apr 1, 2013 at 5:27 PM, Adrian Far= rel <adrian@olddog.co.uk> wrote:
Hi ForCES,

I have entered your proposed charter tex= t at
https://datatracker.ietf.org/doc/charter-ietf-forces/

Since the meeting in Orlando I haven't heard a word of disquiet fro= m you about
the charter so I am going to assume that you are all happy w= ith what is in/out
within the bounds of understanding when you are in th= e rough. Therefore, please
shout loud and clear if that is not the case.

I am now going to set = about some wordsmithing because the current proposal is
about 25 pages t= oo long :-)

Cheers,
Adrian



_______________________= ________________________
forces mailing list
forces@ietf.org
https://www.ietf.org/mailman/listinfo/forces



=A0 --089e0122e8dc7b30a304d9c59adf-- From ehalep@gmail.com Sun Apr 7 07:14:24 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AEC21F8617 for ; Sun, 7 Apr 2013 07:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=1.345, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ureELZvRTBRK for ; Sun, 7 Apr 2013 07:14:23 -0700 (PDT) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id BECC021F8606 for ; Sun, 7 Apr 2013 07:14:22 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id e53so1982117eek.23 for ; Sun, 07 Apr 2013 07:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=V+hVBdLCHrji2+bDWJKp5UFnZvbG3LfvBApObfCMRkc=; b=h5Hw63Wr2opiHmqzWKVx8OUPMnUsIDLXbp6+7m5gG++RNDuBYukKHF2pDkoUboRzwr Mq1W1SBWC0e4ZjvLtErKTKRg6XOzfZ5FOqorZULfpvxouNcyRltkj8UjkAzJxyJn9a4i hopEF+a+t07D530XrvhA5s5no8KGrJ1+UZjnM9nPRfWm8fsL5KphB6hcBOYOv/M1XkRV 7NBLJzt2FMzeQewNTOaUuWaeLy5cn1GmYWAA7x6MuN4V4fdqEEHIHf0v4LiyJxXeZphO 4Dr6Gdx5vWD3wX6cjf6/QV5vX5+9HPClNhWiQZp82+KwO3Mn+2PD0Eb3g0GzEf4rjOyl TYbA== X-Received: by 10.15.34.199 with SMTP id e47mr29220232eev.35.1365344060113; Sun, 07 Apr 2013 07:14:20 -0700 (PDT) Received: from EhalepXPS (ppp141237226221.access.hol.gr. [141.237.226.221]) by mx.google.com with ESMTPS id n2sm26497282eeo.10.2013.04.07.07.14.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 07 Apr 2013 07:14:19 -0700 (PDT) From: "Haleplidis Evangelos" To: , , "'Jamal Hadi Salim'" , "'B.Khasnabish@ieee.org'" References: <01ca01ce2f1f$aa478ab0$fed6a010$@olddog.co.uk> In-Reply-To: Date: Sun, 7 Apr 2013 17:14:16 +0300 Message-ID: <005d01ce339a$31affb80$950ff280$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01CE33B3.56FD3380" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4zl3lkk2/K/fqUQ7eQaU7N0RY8+gAAIL3Q Content-Language: el Subject: Re: [forces] Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 14:14:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005E_01CE33B3.56FD3380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings to the list, Although I think I have already mentioned that the charter looks good, let me be explicit and also acknowledge that the updated charter looks fine as well. Regards, Evangelos Haleplidis. From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of B.Khasnabish@ieee.org Sent: Sunday, April 07, 2013 4:51 PM To: adrian@olddog.co.uk; Jamal Hadi Salim Cc: forces@ietf.org Subject: Re: [forces] Your recharter proposal Adrian, Jamal, Thanks. The updated charter looks fine. We are interested to work on and contribute to virtualization of FE and CE. In addition, we look forward to work with others on database sharding ( http://en.wikipedia.org/wiki/Shard_(database_architecture) ) for inter-LFB and other relevant features/services. Thanks again. Best. Bhumip On Mon, Apr 1, 2013 at 5:27 PM, Adrian Farrel wrote: Hi ForCES, I have entered your proposed charter text at https://datatracker.ietf.org/doc/charter-ietf-forces/ Since the meeting in Orlando I haven't heard a word of disquiet from you about the charter so I am going to assume that you are all happy with what is in/out within the bounds of understanding when you are in the rough. Therefore, please shout loud and clear if that is not the case. I am now going to set about some wordsmithing because the current proposal is about 25 pages too long :-) Cheers, Adrian _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces ------=_NextPart_000_005E_01CE33B3.56FD3380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings to the list,

 

Although I think I have already mentioned that the charter looks = good, let me be explicit and also acknowledge that the updated charter = looks fine as well.

 

Regards,

Evangelos Haleplidis.

 

From:= = forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of = B.Khasnabish@ieee.org
Sent: Sunday, April 07, 2013 4:51 = PM
To: adrian@olddog.co.uk; Jamal Hadi Salim
Cc: = forces@ietf.org
Subject: Re: [forces] Your recharter = proposal

 

Adrian, = Jamal,

 

Thanks. The updated charter looks fine. We are = interested to

work on and = contribute to virtualization of FE and CE.

 

In addition, we look forward to work with others on = database

for inter-LFB and other = relevant features/services.

 

Thanks again.

 

Best.

 

Bhumip

 

 




  =

------=_NextPart_000_005E_01CE33B3.56FD3380-- From vumip1@gmail.com Sun Apr 7 07:49:55 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19F021F8DBF for ; Sun, 7 Apr 2013 07:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+xjaIMNdN1h for ; Sun, 7 Apr 2013 07:49:54 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0DB21F8DE4 for ; Sun, 7 Apr 2013 07:49:54 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id a12so4977467wgh.33 for ; Sun, 07 Apr 2013 07:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zzIwSEvXgqC9s2L/9PsOPg0svw6PgOfp8A4NPHIytlg=; b=DfAIIel2meL1yZJnBfD/Pfk4a91oSZCNmBebm9Nln7Dan+WLubh8287DLHes9WIJJe jPeb+D6kfC+rQYAHMvvn73dB4RbuGYYIBQ3EM3CzrIs/4Xt29Gafuo2zkPxEYQsSj6uE 9GTcIoG5wlf6JWCeWgukvaogdoKnQACmd7Ub9Q8NBjmTG02vFYgMVajyxuVQr04CkkQI cS3ZOGiUml48UyK9EogUD7z55/E4/sR+yl5yDBrCePVIiAcyl+lTIiD5T6cCy4QF1sBb FVXeyjAeK/f5GPH1I8H5cLx24A5j2XcJRX4tHloVRbVLYw7YvM6HjbeFzrCBt1o3s4YL e9Xw== MIME-Version: 1.0 X-Received: by 10.180.182.36 with SMTP id eb4mr8194342wic.8.1365346193514; Sun, 07 Apr 2013 07:49:53 -0700 (PDT) Received: by 10.216.124.5 with HTTP; Sun, 7 Apr 2013 07:49:53 -0700 (PDT) In-Reply-To: References: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> Date: Sun, 7 Apr 2013 10:49:53 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=047d7b622926dc25d304d9c66ee4 Cc: "forces@ietf.org" Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 14:49:55 -0000 --047d7b622926dc25d304d9c66ee4 Content-Type: text/plain; charset=ISO-8859-1 Adrian, Jamal, Thanks. The updated charter looks fine. We are interested to work on and contribute to virtualization of FE and CE. In addition, we look forward to work with others on database sharding ( http://en.wikipedia.org/wiki/Shard_(database_architecture) ) for inter-LFB and other relevant features/services. Thanks again. Best. Bhumip On Sun, Apr 7, 2013 at 9:22 AM, Jamal Hadi Salim wrote: > Hi Adrian, > > I noticed Joel was the only person to respond on the last update you made. > Please accept my ACK. > The "problem" is there is nothing controversial about the posted charter. > I did take a glance (it looked good). So silence on my part means ACK > as i am sure it does for most people committed to doing the work. > > Could people reading this message please give an ACK or a comment to > Adrian? > > cheers, > jamal > > On Sun, Apr 7, 2013 at 8:23 AM, Adrian Farrel wrote: > > Hi ForCES, > > > > I am not going to go to the rest of the IESG and say "Two people said > OK, and > > no-one else actually objected." If I do that, they will (rightly) object > to > > re-chartering the WG. > > > > This is your make or break! If you can't enthusiastically commit to this > > proposed re-charter then it is pretty obvious where we stand. I know > that a > > number of you say you want to work on this stuff, so stand up and wave > your hat > > in the air! > > > > Thanks, > > Adrian > > > >> -----Original Message----- > >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > Behalf Of > >> Adrian Farrel > >> Sent: 03 April 2013 15:58 > >> To: forces@ietf.org > >> Subject: [forces] Charter text updates > >> > >> Hi, > >> > >> Current update is at > https://datatracker.ietf.org/doc/charter-ietf-forces/ > >> > >> I am still looking for comments of support, disagreement, or ridicule. > >> > >> Adrian > >> > >> _______________________________________________ > >> forces mailing list > >> forces@ietf.org > >> https://www.ietf.org/mailman/listinfo/forces > > > > _______________________________________________ > > forces mailing list > > forces@ietf.org > > https://www.ietf.org/mailman/listinfo/forces > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > --047d7b622926dc25d304d9c66ee4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adrian, Jamal,
Thanks. The upda= ted charter looks fine. We are interested to
work on and contrib= ute to virtualization of FE and CE.
In addition, we l= ook forward to work with others on database
for inter-LFB and other relevant features/services.
<= div>Thanks again.
Bhumip<= /div>


On Sun, = Apr 7, 2013 at 9:22 AM, Jamal Hadi Salim <hadi@mojatatu.com>= wrote:
Hi Adrian,

I noticed Joel was the only person to respond on the last update you made.<= br> Please accept my ACK.
The "problem" is there is nothing controversial about the posted = charter.
I did take a glance (it looked good). So silence on my part means ACK
as i am sure it does for most people committed to doing the work.

Could people reading this message please give an ACK or a comment to Adrian= ?

cheers,
jamal

On Sun, Apr 7, 2013 at 8:23 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> Hi ForCES,
>
> I am not going to go to the rest of the IESG and say "Two people = said OK, and
> no-one else actually objected." If I do that, they will (rightly)= object to
> re-chartering the WG.
>
> This is your make or break! If you can't enthusiastically commit t= o this
> proposed re-charter then it is pretty obvious where we stand. I know t= hat a
> number of you say you want to work on this stuff, so stand up and wave= your hat
> in the air!
>
> Thanks,
> Adrian
>
>> -----Original Message-----
>> From: forces-bounces@ie= tf.org [mailto:forces-bounce= s@ietf.org] On Behalf Of
>> Adrian Farrel
>> Sent: 03 April 2013 15:58
>> To: forces@ietf.org
>> Subject: [forces] Charter text updates
>>
>> Hi,
>>
>> Current update is at https://datatracker.ietf.org/doc/cha= rter-ietf-forces/
>>
>> I am still looking for comments of support, disagreement, or ridic= ule.
>>
>> Adrian
>>
>> _______________________________________________
>> forces mailing list
>> forces@ietf.org
>> https://www.ietf.org/mailman/listinfo/forces
>
> _______________________________________________
> forces mailing list
> forces@ietf.org
> https://www.ietf.org/mailman/listinfo/forces
_______________________________________________
forces mailing list
forces@ietf.org
= https://www.ietf.org/mailman/listinfo/forces



=A0
--047d7b622926dc25d304d9c66ee4-- From joel@stevecrocker.com Sun Apr 7 09:32:24 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2BD21F86C1 for ; Sun, 7 Apr 2013 09:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26tUPdQJAZZ0 for ; Sun, 7 Apr 2013 09:32:23 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 79B6121F86BA for ; Sun, 7 Apr 2013 09:32:23 -0700 (PDT) Received: from dummy.name; Sun, 07 Apr 2013 16:32:22 +0000 Message-ID: <51619F83.9010908@stevecrocker.com> Date: Sun, 07 Apr 2013 12:32:03 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> In-Reply-To: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 16:32:24 -0000 Suggestion folks. Even if you think Adrian has heard from you, speak again. In case it is unclear, I strongly support this charter. yours, Joel On 4/7/2013 8:23 AM, Adrian Farrel wrote: > Hi ForCES, > > I am not going to go to the rest of the IESG and say "Two people said OK, and > no-one else actually objected." If I do that, they will (rightly) object to > re-chartering the WG. > > This is your make or break! If you can't enthusiastically commit to this > proposed re-charter then it is pretty obvious where we stand. I know that a > number of you say you want to work on this stuff, so stand up and wave your hat > in the air! > > Thanks, > Adrian > >> -----Original Message----- >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of >> Adrian Farrel >> Sent: 03 April 2013 15:58 >> To: forces@ietf.org >> Subject: [forces] Charter text updates >> >> Hi, >> >> Current update is at https://datatracker.ietf.org/doc/charter-ietf-forces/ >> >> I am still looking for comments of support, disagreement, or ridicule. >> >> Adrian >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From omar.cherkaoui@gmail.com Sun Apr 7 18:31:12 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1907D21F9020 for ; Sun, 7 Apr 2013 18:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cvp5ynqz3ZmH for ; Sun, 7 Apr 2013 18:31:11 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD7921F9015 for ; Sun, 7 Apr 2013 18:31:10 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id x13so3363599vbb.20 for ; Sun, 07 Apr 2013 18:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GKNGSSPycyFQdJJJkik2OVhhbJVf4wqN26mwAHiFVSA=; b=me3JSzDpGQfIQzmo17wn4xFpB93yU781J6mYYiV23e69lIMs0Sae/romBWQOiClRQm TbG0GJXRDPjB+hh885AE8MW/HtgFjaIozEkPZ2/vwomadjJF7RzAcZYcJ70TtnBLvAlg C5WzlUd1HA8WgRZBMmLKEY4uuVJEOaeUeu2Qsrf5dNG/MRTTxlrYATSPv7GKRsfnHfPt 85QC9nPTzI5USKFg1gY6BbavyeRT542ybPYStCWk413NJ6kG6z/6oAbUhFtF4C34Q8qu 96jOIiXKa6pmW3+wSwZgCWtY170O7OF0danqA2qlm8BgECPgKjVEfwGo9ty8xLjAcUhx lo0g== MIME-Version: 1.0 X-Received: by 10.52.96.138 with SMTP id ds10mr790398vdb.3.1365384670359; Sun, 07 Apr 2013 18:31:10 -0700 (PDT) Sender: omar.cherkaoui@gmail.com Received: by 10.58.198.100 with HTTP; Sun, 7 Apr 2013 18:31:10 -0700 (PDT) In-Reply-To: References: <01ca01ce2f1f$aa478ab0$fed6a010$@olddog.co.uk> Date: Sun, 7 Apr 2013 21:31:10 -0400 X-Google-Sender-Auth: KOwAG1xaxcSTASEp_vkSJSI1ZYs Message-ID: From: omar cherkaoui To: forces@ietf.org Content-Type: multipart/alternative; boundary=20cf307f3a36426c6e04d9cf64a2 Subject: Re: [forces] Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 01:31:12 -0000 --20cf307f3a36426c6e04d9cf64a2 Content-Type: text/plain; charset=ISO-8859-1 Hi We are highly interested to work on and contribute to virtualization of FE and CE. Regards Omar On Sun, Apr 7, 2013 at 9:50 AM, B.Khasnabish@ieee.org wrote: > Adrian, Jamal, > > Thanks. The updated charter looks fine. We are interested to > work on and contribute to virtualization of FE and CE. > > In addition, we look forward to work with others on database > sharding ( http://en.wikipedia.org/wiki/Shard_(database_architecture) ) > for inter-LFB and other relevant features/services. > > Thanks again. > > Best. > > Bhumip > > > On Mon, Apr 1, 2013 at 5:27 PM, Adrian Farrel wrote: > >> Hi ForCES, >> >> I have entered your proposed charter text at >> https://datatracker.ietf.org/doc/charter-ietf-forces/ >> >> Since the meeting in Orlando I haven't heard a word of disquiet from you >> about >> the charter so I am going to assume that you are all happy with what is >> in/out >> within the bounds of understanding when you are in the rough. Therefore, >> please >> shout loud and clear if that is not the case. >> >> I am now going to set about some wordsmithing because the current >> proposal is >> about 25 pages too long :-) >> >> Cheers, >> Adrian >> >> >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > > > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > > -- Omar Cherkaoui UQAM --20cf307f3a36426c6e04d9cf64a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi
We are highly interested to work on and contribute= to virtualization of FE and CE.
= =A0
=A0
Regards
Omar=A0
=A0



On Sun, Apr 7, 2013 at 9:50 AM, B.Khasnabish@ieee.org <vumip1@gmail.com> wrote:=
Adrian, Jamal,
=A0
= Thanks. The updated charter looks fine. We are interested to
wor= k on and contribute to virtualization of FE and CE.
=A0
In addition, we look forward to work with others on data= base
for inter-LFB and other relevant features/serv= ices.
=A0
Thanks again.
=A0
Best.
=A0
Bhumip
=A0

On Mon, Apr 1, 2013 at 5:27 PM, Adrian Far= rel <adrian@olddog.co.uk> wrote:
Hi ForCES,

I have entered your proposed charter tex= t at
https://datatracker.ietf.org/doc/charter-ietf-forces/

Since the meeting in Orlando I haven't heard a word of disquiet fro= m you about
the charter so I am going to assume that you are all happy w= ith what is in/out
within the bounds of understanding when you are in th= e rough. Therefore, please
shout loud and clear if that is not the case.

I am now going to set = about some wordsmithing because the current proposal is
about 25 pages t= oo long :-)

Cheers,
Adrian



_______________________= ________________________
forces mailing list
forces@ietf.org
https://www.ietf.org/mailman/listinfo/forces



=A0
_______________________________________________
forces mailing list
forces@ietf.org
= https://www.ietf.org/mailman/listinfo/forces




--
Omar Che= rkaoui
UQAM
--20cf307f3a36426c6e04d9cf64a2-- From wmwang2001@hotmail.com Sun Apr 7 19:00:49 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C83121F900D for ; Sun, 7 Apr 2013 19:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ2LzU+Eqm34 for ; Sun, 7 Apr 2013 19:00:49 -0700 (PDT) Received: from blu0-omc4-s34.blu0.hotmail.com (blu0-omc4-s34.blu0.hotmail.com [65.55.111.173]) by ietfa.amsl.com (Postfix) with ESMTP id E25A321F8C04 for ; Sun, 7 Apr 2013 19:00:48 -0700 (PDT) Received: from BLU0-SMTP182 ([65.55.111.137]) by blu0-omc4-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 7 Apr 2013 19:00:48 -0700 X-EIP: [7zjACyaDa9EYlAkknMOR5HmvOqklH+kB] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([125.120.81.133]) by BLU0-SMTP182.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 7 Apr 2013 19:00:47 -0700 From: "Wang,Weiming" To: , References: <05e801ce307b$a06f4340$e14dc9c0$@olddog.co.uk> Date: Mon, 8 Apr 2013 10:00:28 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 08 Apr 2013 02:00:47.0712 (UTC) FILETIME=[E336D600:01CE33FC] Subject: Re: [forces] Charter text updates X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 02:00:49 -0000 SGkgQWRyaWFuLA0KDQpJIHN0cm9uZ2x5IHN1Z2dlc3Qgd2UgYWRkIGFuIGl0ZW0gdG8gbWlsZXN0 b25lcyBvbiBhbiBpbmZvcm1hdGlvbmFsIGRvY3VlbWVudCBvbiBOZXR3b3JrIEZ1bmN0aW9uIFZp cnR1YWxpemF0aW9uIGZvciBwdWJsaWNhdGlvbiBiZWZvcmUgTWFyY2ggMjAxNC4gSSBqdXN0IGJl bGlldmUgaXQgaXMgdmVyeSB2YWx1YWJsZSB0byBkbyB0aGlzIGJlZm9yZSBlbmRpbmcgdGhlIEZv ckNFUyBXRy4gVGhlIGRvY3VtZW50IG1heSBiZSB0aXRsZWQgbGlrZSAiQ29uc2lkZXJhdGlvbnMg b24gbmV0d29yayBmdW5jdGlvbiB2aXJ0dWFsaXphdGlvbiB3aXRoIEZvckNFUyIuDQoNCk9uIEV4 dGVuc2lvbnMgdG8gTW9kZWwgYW5kIFByb3RvY29sLCB0aGUgd29yayBpdGVtcyBhcmUgY2xlYXJs eSBsaXN0ZWQuIEkgc3VnZ2VzdCB3ZSBhbHNvIHN0YXRlIHRvIGFsbG93IGFueSBvdGhlciBpdGVt cyB0aGFuIGxpc3RlZCB3aGljaCBhcmUgaW4gdGhlIHByb2Nlc3MgZm91bmQgdXNlZnVsIGFuZCBu ZWNlc3NhcnkuIA0KDQpBZ2Fpbiwgd2UgYXJlIGludGVyZXN0ZWQgaW4gdGhlIG1vZGVsIGFuZCBw cm90b2NvbCBleHRlbnRpb24gd29yayBhbmQgdGhlIHZpcnR1YWxpemF0aW9uIHdvcmssIGFuZCB0 aGUgcGFyYWxlbGxpemF0aW9uIHdvcmsgaWYgbmVlZGVkLiANCg0KdGhhbmtzIGEgbG90Lg0KV2Vp bWluZw0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQWRyaWFuIEZh cnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+DQoNCj4gSGksDQo+IA0KPiBDdXJyZW50IHVwZGF0 ZSBpcyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtZm9y Y2VzLw0KPiANCj4gSSBhbSBzdGlsbCBsb29raW5nIGZvciBjb21tZW50cyBvZiBzdXBwb3J0LCBk aXNhZ3JlZW1lbnQsIG9yIHJpZGljdWxlLg0KPiANCj4gQWRyaWFuDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmb3JjZXMgbWFpbGluZyBs aXN0DQo+IGZvcmNlc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ZvcmNlcw0KPg== From sdena@upatras.gr Sun Apr 7 23:04:21 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF6221F91A5 for ; Sun, 7 Apr 2013 23:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5cCeSQbYZxu for ; Sun, 7 Apr 2013 23:04:20 -0700 (PDT) Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by ietfa.amsl.com (Postfix) with ESMTP id 072F721F91BC for ; Sun, 7 Apr 2013 23:04:19 -0700 (PDT) Received: from localhost (nic.upatras.gr [127.0.0.1]) by nic.upatras.gr (Postfix) with ESMTP id A58CF27596E for ; Mon, 8 Apr 2013 09:04:17 +0300 (EEST) X-Virus-Scanned: amavisd-new at upatras.gr Received: from nic.upatras.gr ([127.0.0.1]) by localhost (nic.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbpiKH9b6g81 for ; Mon, 8 Apr 2013 09:04:17 +0300 (EEST) Received: from mail.upatras.gr (patreas.upatras.gr [150.140.129.29]) by nic.upatras.gr (Postfix) with ESMTP for ; Mon, 8 Apr 2013 09:04:17 +0300 (EEST) Received: from [150.140.187.134] (GLAFKOS.wcl.ee.upatras.gr [150.140.187.134]) by mail.upatras.gr (Postfix) with ESMTPSA id 105C7593DC1; Mon, 8 Apr 2013 09:04:16 +0300 (EEST) Message-ID: <51625DE1.3060301@upatras.gr> Date: Mon, 08 Apr 2013 09:04:17 +0300 From: Spyros Denazis Organization: University of Patras User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: forces@ietf.org References: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> In-Reply-To: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 06:04:21 -0000 Hi All, As already stated by others, we also support the re-chartering and we do not object. Best regards Spyros Denazis University of Patras On 7/4/2013 3:23 μμ, Adrian Farrel wrote: > Hi ForCES, > > I am not going to go to the rest of the IESG and say "Two people said OK, and > no-one else actually objected." If I do that, they will (rightly) object to > re-chartering the WG. > > This is your make or break! If you can't enthusiastically commit to this > proposed re-charter then it is pretty obvious where we stand. I know that a > number of you say you want to work on this stuff, so stand up and wave your hat > in the air! > > Thanks, > Adrian > >> -----Original Message----- >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of >> Adrian Farrel >> Sent: 03 April 2013 15:58 >> To: forces@ietf.org >> Subject: [forces] Charter text updates >> >> Hi, >> >> Current update is at https://datatracker.ietf.org/doc/charter-ietf-forces/ >> >> I am still looking for comments of support, disagreement, or ridicule. >> >> Adrian >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From a.galis@ee.ucl.ac.uk Mon Apr 8 00:10:42 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEC521F859D for ; Mon, 8 Apr 2013 00:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv5y9ND3M34e for ; Mon, 8 Apr 2013 00:10:41 -0700 (PDT) Received: from kryten.ee.ucl.ac.uk (mail2.ee.ucl.ac.uk [128.40.38.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9D19821F8EC3 for ; Mon, 8 Apr 2013 00:10:41 -0700 (PDT) Received: from unknown-02:0f:b5:d5:b0:47.home (host31-53-187-65.range31-53.btcentralplus.com [31.53.187.65]) (authenticated bits=0) by kryten.ee.ucl.ac.uk (8.14.5/8.14.3) with ESMTP id r387AFBv007196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Apr 2013 08:10:16 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2CD12652-0601-4AF3-9E57-47336E7EE1C8" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Alex Galis In-Reply-To: <51625DE1.3060301@upatras.gr> Date: Mon, 8 Apr 2013 08:10:10 +0100 Message-Id: <4D8EE8E7-8B8F-494C-8898-E15CC6AB96ED@ee.ucl.ac.uk> References: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> <51625DE1.3060301@upatras.gr> To: forces@ietf.org X-Mailer: Apple Mail (2.1503) X-UCL-EE-MailScanner-Information: Please contact the ISP for more information X-UCL-EE-MailScanner-ID: r387AFBv007196 X-UCL-EE-MailScanner: Found to be clean X-UCL-EE-MailScanner-From: a.galis@ee.ucl.ac.uk Cc: Alex Galis Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 07:10:43 -0000 --Apple-Mail=_2CD12652-0601-4AF3-9E57-47336E7EE1C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, We also support the re-chartering. The proposed work plan is both timely and essential as far as = developments of key and high SDN impact issues are concerned. Best Regards Alex Galis University College London On 8 Apr 2013, at 07:04, Spyros Denazis wrote: > Hi All, >=20 > As already stated by others, we also support the re-chartering and we = do not object. >=20 > Best regards >=20 > Spyros Denazis > University of Patras >=20 > On 7/4/2013 3:23 =CE=BC=CE=BC, Adrian Farrel wrote: >> Hi ForCES, >>=20 >> I am not going to go to the rest of the IESG and say "Two people said = OK, and >> no-one else actually objected." If I do that, they will (rightly) = object to >> re-chartering the WG. >>=20 >> This is your make or break! If you can't enthusiastically commit to = this >> proposed re-charter then it is pretty obvious where we stand. I know = that a >> number of you say you want to work on this stuff, so stand up and = wave your hat >> in the air! >>=20 >> Thanks, >> Adrian >>=20 >>> -----Original Message----- >>> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On = Behalf Of >>> Adrian Farrel >>> Sent: 03 April 2013 15:58 >>> To: forces@ietf.org >>> Subject: [forces] Charter text updates >>>=20 >>> Hi, >>>=20 >>> Current update is at = https://datatracker.ietf.org/doc/charter-ietf-forces/ >>>=20 >>> I am still looking for comments of support, disagreement, or = ridicule. >>>=20 >>> Adrian >>>=20 >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >>=20 >=20 > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces --Apple-Mail=_2CD12652-0601-4AF3-9E57-47336E7EE1C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi All,

We also support the = re-chartering.

The proposed work plan is both timely and = essential as far as developments of key and high SDN impact issues = are concerned.

Best Regards

Alex Galis
University = College London


On 8 Apr = 2013, at 07:04, Spyros Denazis <sdena@upatras.gr> = wrote:

Hi All,

As already stated by others, = we also support the re-chartering and we do not object.

Best = regards

Spyros Denazis
University of Patras

On 7/4/2013 = 3:23 =CE=BC=CE=BC, Adrian Farrel wrote:
Hi ForCES,

I am = not going to go to the rest of the IESG and say "Two people said OK, = and
no-one else actually objected." If I do that, they will (rightly) = object to
re-chartering the WG.

This is your make or break! If = you can't enthusiastically commit to this
proposed re-charter then it = is pretty obvious where we stand. I know that a
number of you say you = want to work on this stuff, so stand up and wave your hat
in the = air!

Thanks,
Adrian

-----Original = Message-----
From: forces-bounces@ietf.org = [mailto:forces-bounces@ietf.org] = On Behalf Of
Adrian Farrel
Sent: 03 April 2013 15:58
To: forces@ietf.org
Subject: [forces] = Charter text updates

Hi,

Current update is at https://dat= atracker.ietf.org/doc/charter-ietf-forces/

I am still looking = for comments of support, disagreement, or = ridicule.

Adrian

___________________________________________= ____
forces mailing list
forces@ietf.org
https://www.ietf.or= g/mailman/listinfo/forces
_______________________________________________
forces = mailing list
forces@ietf.org
https://www.ietf.or= g/mailman/listinfo/forces


_______________________________________________
forces = mailing list
forces@ietf.org
https://www.ietf.or= g/mailman/listinfo/forces

= --Apple-Mail=_2CD12652-0601-4AF3-9E57-47336E7EE1C8-- From damascene.joachimpillai@verizon.com Mon Apr 8 06:08:22 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FAD21F93A9 for ; Mon, 8 Apr 2013 06:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFqb4dwfhtMR for ; Mon, 8 Apr 2013 06:08:21 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id CD49021F9397 for ; Mon, 8 Apr 2013 06:08:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 08 Apr 2013 13:08:17 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="4.87,431,1363132800"; d="scan'208,217";a="450475189" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 08 Apr 2013 13:08:17 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Mon, 8 Apr 2013 09:08:15 -0400 To: Alex Galis , "forces@ietf.org" Date: Mon, 8 Apr 2013 09:08:15 -0400 Thread-Topic: [forces] Voices of support needed! [Was: Charter text updates] Thread-Index: Ac40KDLN2sypLk9URDm9ADt9r/IzwgAMd9Lg Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB011A077A1B@FHDP1LUMXC7V31.us.one.verizon.com> References: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> <51625DE1.3060301@upatras.gr> <4D8EE8E7-8B8F-494C-8898-E15CC6AB96ED@ee.ucl.ac.uk> In-Reply-To: <4D8EE8E7-8B8F-494C-8898-E15CC6AB96ED@ee.ucl.ac.uk> 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_689CE984BDBA8B4CAF3EA6E2CDC5CACB011A077A1BFHDP1LUMXC7V3_" MIME-Version: 1.0 Cc: Alex Galis Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 13:08:22 -0000 --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB011A077A1BFHDP1LUMXC7V3_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpXZSBzdXBwb3J0IHRoZSByZS1jaGFydGVyLg0KDQpSZWdhcmRzLA0KREoNCg0K RnJvbTogZm9yY2VzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpmb3JjZXMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEFsZXggR2FsaXMNClNlbnQ6IE1vbmRheSwgQXByaWwgMDgsIDIw MTMgMzoxMCBBTQ0KVG86IGZvcmNlc0BpZXRmLm9yZw0KQ2M6IEFsZXggR2FsaXMNClN1YmplY3Q6 IFJlOiBbZm9yY2VzXSBWb2ljZXMgb2Ygc3VwcG9ydCBuZWVkZWQhIFtXYXM6IENoYXJ0ZXIgdGV4 dCB1cGRhdGVzXQ0KDQpIaSBBbGwsDQoNCldlIGFsc28gc3VwcG9ydCB0aGUgcmUtY2hhcnRlcmlu Zy4NCg0KVGhlIHByb3Bvc2VkIHdvcmsgcGxhbiBpcyBib3RoIHRpbWVseSBhbmQgZXNzZW50aWFs IGFzIGZhciBhcyBkZXZlbG9wbWVudHMgb2Yga2V5IGFuZCBoaWdoIFNETiBpbXBhY3QgaXNzdWVz IGFyZSBjb25jZXJuZWQuDQoNCkJlc3QgUmVnYXJkcw0KDQpBbGV4IEdhbGlzDQpVbml2ZXJzaXR5 IENvbGxlZ2UgTG9uZG9uDQoNCg0KT24gOCBBcHIgMjAxMywgYXQgMDc6MDQsIFNweXJvcyBEZW5h emlzIDxzZGVuYUB1cGF0cmFzLmdyPG1haWx0bzpzZGVuYUB1cGF0cmFzLmdyPj4gd3JvdGU6DQoN Cg0KSGkgQWxsLA0KDQpBcyBhbHJlYWR5IHN0YXRlZCBieSBvdGhlcnMsIHdlIGFsc28gc3VwcG9y dCB0aGUgcmUtY2hhcnRlcmluZyBhbmQgd2UgZG8gbm90IG9iamVjdC4NCg0KQmVzdCByZWdhcmRz DQoNClNweXJvcyBEZW5hemlzDQpVbml2ZXJzaXR5IG9mIFBhdHJhcw0KDQpPbiA3LzQvMjAxMyAz OjIzIM68zrwsIEFkcmlhbiBGYXJyZWwgd3JvdGU6DQoNCkhpIEZvckNFUywNCg0KSSBhbSBub3Qg Z29pbmcgdG8gZ28gdG8gdGhlIHJlc3Qgb2YgdGhlIElFU0cgYW5kIHNheSAiVHdvIHBlb3BsZSBz YWlkIE9LLCBhbmQNCm5vLW9uZSBlbHNlIGFjdHVhbGx5IG9iamVjdGVkLiIgSWYgSSBkbyB0aGF0 LCB0aGV5IHdpbGwgKHJpZ2h0bHkpIG9iamVjdCB0bw0KcmUtY2hhcnRlcmluZyB0aGUgV0cuDQoN ClRoaXMgaXMgeW91ciBtYWtlIG9yIGJyZWFrISBJZiB5b3UgY2FuJ3QgZW50aHVzaWFzdGljYWxs eSBjb21taXQgdG8gdGhpcw0KcHJvcG9zZWQgcmUtY2hhcnRlciB0aGVuIGl0IGlzIHByZXR0eSBv YnZpb3VzIHdoZXJlIHdlIHN0YW5kLiBJIGtub3cgdGhhdCBhDQpudW1iZXIgb2YgeW91IHNheSB5 b3Ugd2FudCB0byB3b3JrIG9uIHRoaXMgc3R1ZmYsIHNvIHN0YW5kIHVwIGFuZCB3YXZlIHlvdXIg aGF0DQppbiB0aGUgYWlyIQ0KDQpUaGFua3MsDQpBZHJpYW4NCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogZm9yY2VzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmZvcmNlcy1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmZvcmNlcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpi b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mDQpBZHJpYW4gRmFycmVsDQpTZW50OiAwMyBB cHJpbCAyMDEzIDE1OjU4DQpUbzogZm9yY2VzQGlldGYub3JnPG1haWx0bzpmb3JjZXNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBbZm9yY2VzXSBDaGFydGVyIHRleHQgdXBkYXRlcw0KDQpIaSwNCg0KQ3Vy cmVudCB1cGRhdGUgaXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRl ci1pZXRmLWZvcmNlcy8NCg0KSSBhbSBzdGlsbCBsb29raW5nIGZvciBjb21tZW50cyBvZiBzdXBw b3J0LCBkaXNhZ3JlZW1lbnQsIG9yIHJpZGljdWxlLg0KDQpBZHJpYW4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmZvcmNlcyBtYWlsaW5nIGxpc3QN CmZvcmNlc0BpZXRmLm9yZzxtYWlsdG86Zm9yY2VzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpmb3JjZXMgbWFpbGluZyBsaXN0DQpmb3JjZXNAaWV0Zi5v cmc8bWFpbHRvOmZvcmNlc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZm9yY2VzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpmb3JjZXMgbWFpbGluZyBsaXN0DQpmb3JjZXNAaWV0Zi5vcmc8bWFpbHRvOmZv cmNlc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9y Y2VzDQoNCg== --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB011A077A1BFHDP1LUMXC7V3_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVy cGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPkhpIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldlIHN1cHBvcnQgdGhlIHJl LWNoYXJ0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5ESjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAg Y2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IGZvcmNl cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Zm9yY2VzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9u IEJlaGFsZiBPZiA8L2I+QWxleCBHYWxpczxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAw OCwgMjAxMyAzOjEwIEFNPGJyPjxiPlRvOjwvYj4gZm9yY2VzQGlldGYub3JnPGJyPjxiPkNjOjwv Yj4gQWxleCBHYWxpczxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtmb3JjZXNdIFZvaWNlcyBvZiBz dXBwb3J0IG5lZWRlZCEgW1dhczogQ2hhcnRlciB0ZXh0IHVwZGF0ZXNdPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdCc+SGkgQWxs LDxicj48YnI+V2UgYWxzbyBzdXBwb3J0IHRoZSByZS1jaGFydGVyaW5nLjxicj48YnI+VGhlIHBy b3Bvc2VkIHdvcmsgcGxhbiBpcyBib3RoIHRpbWVseSBhbmQgZXNzZW50aWFsJm5ic3A7YXMgZmFy IGFzIGRldmVsb3BtZW50cyBvZiBrZXkgYW5kIGhpZ2ggU0ROIGltcGFjdCBpc3N1ZXMgYXJlIGNv bmNlcm5lZC48YnI+PGJyPkJlc3QgUmVnYXJkczxicj48YnI+QWxleCBHYWxpczxicj5Vbml2ZXJz aXR5IENvbGxlZ2UgTG9uZG9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo5LjBwdCc+T24gOCBBcHIgMjAxMywgYXQgMDc6MDQsIFNweXJvcyBEZW5hemlz ICZsdDs8YSBocmVmPSJtYWlsdG86c2RlbmFAdXBhdHJhcy5nciI+c2RlbmFAdXBhdHJhcy5ncjwv YT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdCc+PGJyPjxicj48L3NwYW4+PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQnPkhp IEFsbCw8YnI+PGJyPkFzIGFscmVhZHkgc3RhdGVkIGJ5IG90aGVycywgd2UgYWxzbyBzdXBwb3J0 IHRoZSByZS1jaGFydGVyaW5nIGFuZCB3ZSBkbyBub3Qgb2JqZWN0Ljxicj48YnI+QmVzdCByZWdh cmRzPGJyPjxicj5TcHlyb3MgRGVuYXppczxicj5Vbml2ZXJzaXR5IG9mIFBhdHJhczxicj48YnI+ T24gNy80LzIwMTMgMzoyMyDOvM68LCBBZHJpYW4gRmFycmVsIHdyb3RlOjxicj48YnI+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjkuMHB0Jz5IaSBGb3JDRVMsPGJyPjxicj5JIGFtIG5vdCBnb2luZyB0byBnbyB0byB0aGUgcmVz dCBvZiB0aGUgSUVTRyBhbmQgc2F5ICZxdW90O1R3byBwZW9wbGUgc2FpZCBPSywgYW5kPGJyPm5v LW9uZSBlbHNlIGFjdHVhbGx5IG9iamVjdGVkLiZxdW90OyBJZiBJIGRvIHRoYXQsIHRoZXkgd2ls bCAocmlnaHRseSkgb2JqZWN0IHRvPGJyPnJlLWNoYXJ0ZXJpbmcgdGhlIFdHLjxicj48YnI+VGhp cyBpcyB5b3VyIG1ha2Ugb3IgYnJlYWshIElmIHlvdSBjYW4ndCBlbnRodXNpYXN0aWNhbGx5IGNv bW1pdCB0byB0aGlzPGJyPnByb3Bvc2VkIHJlLWNoYXJ0ZXIgdGhlbiBpdCBpcyBwcmV0dHkgb2J2 aW91cyB3aGVyZSB3ZSBzdGFuZC4gSSBrbm93IHRoYXQgYTxicj5udW1iZXIgb2YgeW91IHNheSB5 b3Ugd2FudCB0byB3b3JrIG9uIHRoaXMgc3R1ZmYsIHNvIHN0YW5kIHVwIGFuZCB3YXZlIHlvdXIg aGF0PGJyPmluIHRoZSBhaXIhPGJyPjxicj5UaGFua3MsPGJyPkFkcmlhbjxicj48YnI+PGJyPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo5LjBwdCc+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+RnJvbTogPGEgaHJlZj0i bWFpbHRvOmZvcmNlcy1ib3VuY2VzQGlldGYub3JnIj5mb3JjZXMtYm91bmNlc0BpZXRmLm9yZzwv YT4gW21haWx0bzpmb3JjZXMtPGEgaHJlZj0ibWFpbHRvOmJvdW5jZXNAaWV0Zi5vcmciPmJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Y8YnI+QWRyaWFuIEZhcnJlbDxicj5TZW50OiAw MyBBcHJpbCAyMDEzIDE1OjU4PGJyPlRvOiA8YSBocmVmPSJtYWlsdG86Zm9yY2VzQGlldGYub3Jn Ij5mb3JjZXNAaWV0Zi5vcmc8L2E+PGJyPlN1YmplY3Q6IFtmb3JjZXNdIENoYXJ0ZXIgdGV4dCB1 cGRhdGVzPGJyPjxicj5IaSw8YnI+PGJyPkN1cnJlbnQgdXBkYXRlIGlzIGF0IDxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1mb3JjZXMvIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtZm9yY2VzLzwvYT48YnI+ PGJyPkkgYW0gc3RpbGwgbG9va2luZyBmb3IgY29tbWVudHMgb2Ygc3VwcG9ydCwgZGlzYWdyZWVt ZW50LCBvciByaWRpY3VsZS48YnI+PGJyPkFkcmlhbjxicj48YnI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Zm9yY2VzIG1haWxpbmcgbGlzdDxicj48 YSBocmVmPSJtYWlsdG86Zm9yY2VzQGlldGYub3JnIj5mb3JjZXNAaWV0Zi5vcmc8L2E+PGJyPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlczwvYT48L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdCc+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+Zm9yY2VzIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJt YWlsdG86Zm9yY2VzQGlldGYub3JnIj5mb3JjZXNAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlczwvYT48L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQnPjxicj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5mb3JjZXMgbWFp bGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpmb3JjZXNAaWV0Zi5vcmciPmZvcmNlc0BpZXRm Lm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9mb3JjZXMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzPC9h Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB011A077A1BFHDP1LUMXC7V3_-- From dmm@1-4-5.net Mon Apr 8 07:27:40 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C6F21F979A for ; Mon, 8 Apr 2013 07:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHFyljaYMk1R for ; Mon, 8 Apr 2013 07:27:39 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6930B21F9797 for ; Mon, 8 Apr 2013 07:27:38 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id y8so5799330lbh.35 for ; Mon, 08 Apr 2013 07:27:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=daYjsY4+qYGmwbloMqQwD4V1OJpXEiaLttkfBO4kV4E=; b=HVl/lsHbgMaV2kejy1rOA3eAFfsThUUAxPZLun2MEothamJ/hx6aKPy0LNfuUyJeyN nRsCF6H4q1pF6JDmobQbWD94il0YcfWVFHZ2y6poJJGNSvBt74tj8PgN12CIpR92uM5A mR1FUcX+ZJCHm4JbzlbD4KxIkKDpeAGyaKacR5WFsjsNGYSmyh2p2n0Ex0WQON3G72TV hJUzS4/OH3QHlKOrx/b8HxEv7i6eX87xywr/YOLxR4TtUMlxfL+J1TX88EEZ4MCWOzyr lRR5e+JG25X3/RefB+hl4Srk+w1CIwH+ACdA+NoEJgXncRKEj7Bwwcl0Cd1TKhLJKdwI wHBA== MIME-Version: 1.0 X-Received: by 10.112.76.39 with SMTP id h7mr10293923lbw.118.1365431257266; Mon, 08 Apr 2013 07:27:37 -0700 (PDT) Received: by 10.112.180.38 with HTTP; Mon, 8 Apr 2013 07:27:37 -0700 (PDT) X-Originating-IP: [2001:468:d01:9c::80df:9cfd] In-Reply-To: <51625DE1.3060301@upatras.gr> References: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> <51625DE1.3060301@upatras.gr> Date: Mon, 8 Apr 2013 07:27:37 -0700 Message-ID: From: David Meyer To: forces@ietf.org Content-Type: multipart/alternative; boundary=14dae9cfc7100e06d004d9da3dd9 X-Gm-Message-State: ALoCoQkV9YCuPcTm9PeN5S+3vJkvIAY7OFeZRwAmwZgUeGuD0w/90Te9LroiGU48koGY2b2j7tZx Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 14:27:40 -0000 --14dae9cfc7100e06d004d9da3dd9 Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Support rechartering... --dmm On Sun, Apr 7, 2013 at 11:04 PM, Spyros Denazis wrote: > Hi All, > > As already stated by others, we also support the re-chartering and we do > not object. > > Best regards > > Spyros Denazis > University of Patras > > On 7/4/2013 3:23 =EC=EC, Adrian Farrel wrote: > >> Hi ForCES, >> >> I am not going to go to the rest of the IESG and say "Two people said OK= , >> and >> no-one else actually objected." If I do that, they will (rightly) object >> to >> re-chartering the WG. >> >> This is your make or break! If you can't enthusiastically commit to this >> proposed re-charter then it is pretty obvious where we stand. I know tha= t >> a >> number of you say you want to work on this stuff, so stand up and wave >> your hat >> in the air! >> >> Thanks, >> Adrian >> >> -----Original Message----- >>> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.**org] >>> On Behalf Of >>> Adrian Farrel >>> Sent: 03 April 2013 15:58 >>> To: forces@ietf.org >>> Subject: [forces] Charter text updates >>> >>> Hi, >>> >>> Current update is at https://datatracker.ietf.org/** >>> doc/charter-ietf-forces/ >>> >>> I am still looking for comments of support, disagreement, or ridicule. >>> >>> Adrian >>> >>> ______________________________**_________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/**listinfo/forces >>> >> ______________________________**_________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/**listinfo/forces >> >> > ______________________________**_________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/**listinfo/forces > --14dae9cfc7100e06d004d9da3dd9 Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Support rechartering... --dmm

On Sun, Apr= 7, 2013 at 11:04 PM, Spyros Denazis <sdena@upatras.gr> wrote= :
Hi All,

As already stated by others, we also support the re-chartering and we do no= t object.

Best regards

Spyros Denazis
University of Patras

On 7/4/2013 3:23 =EC=EC, Adrian Farrel wrote:
Hi ForCES,

I am not going to go to the rest of the IESG and say "Two people said = OK, and
no-one else actually objected." If I do that, they will (rightly) obje= ct to
re-chartering the WG.

This is your make or break! If you can't enthusiastically commit to thi= s
proposed re-charter then it is pretty obvious where we stand. I know that a=
number of you say you want to work on this stuff, so stand up and wave your= hat
in the air!

Thanks,
Adrian

-----Original Message-----
From: forces-b= ounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of
Adrian Farrel
Sent: 03 April 2013 15:58
To: forces@ietf.org
Subject: [forces] Charter text updates

Hi,

Current update is at https://datatracker.ietf.org/doc/chart= er-ietf-forces/

I am still looking for comments of support, disagreement, or ridicule.

Adrian

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


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

--14dae9cfc7100e06d004d9da3dd9-- From hadi@mojatatu.com Mon Apr 8 09:28:04 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3B621F949A for ; Mon, 8 Apr 2013 09:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.64 X-Spam-Level: X-Spam-Status: No, score=-102.64 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk8aDQFJefwX for ; Mon, 8 Apr 2013 09:28:03 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id D5C3C21F9410 for ; Mon, 8 Apr 2013 09:27:57 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ht11so5059086vcb.41 for ; Mon, 08 Apr 2013 09:27:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=/g86vNzB0GeoH+53DKjRh91Zbe0HIcij1czs1vJ35GE=; b=SGvICZfCb3PXtAyJqnXbjCHqjIJoHkIM/A6GWdpqS0pnrL63LTErLIvs1Zukv48bKt RZeH40hnNCxTUAWn6GIf5yIq/Tbw3RzaynqVhSlzxBDZ4V9OhtjEiAyAiRUU7Tk3YllH US7tbyRLp0dGpG6Xq0UBciwq7S8pZ4u7T89gqepps08TyUqGgqhM1SQguwR7wOggR2Yb m+r+ISSg3YsbuksIEfn7SUMYV020sNKgsubMDWWTMOL748/z01m9kevmj1jZUU4iR1uU cJcAs1KaapSWkotr28rwqYSxq/Kbuy0Rngw+wxK4sZgsoqTalRpbrZEYlLbvDNMMQ3El 6moQ== X-Received: by 10.58.80.4 with SMTP id n4mr16186086vex.5.1365438477033; Mon, 08 Apr 2013 09:27:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.237.229 with HTTP; Mon, 8 Apr 2013 09:27:36 -0700 (PDT) In-Reply-To: References: <05e801ce307b$a06f4340$e14dc9c0$@olddog.co.uk> From: Jamal Hadi Salim Date: Mon, 8 Apr 2013 12:27:36 -0400 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkUrUjDEqmEOOw6RnYJxrsyFefi+5shtzZCOpKMcHqbFSWgcsmv2aIOmi3xU46kWaQvF39b Cc: forces@ietf.org Subject: Re: [forces] Charter text updates X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 16:28:05 -0000 Hi Weiming, On Sun, Apr 7, 2013 at 10:00 PM, Wang,Weiming wrote: > Hi Adrian, > > I strongly suggest we add an item to milestones on an informational docuement on Network > Function Virtualization for publication before March 2014. I just believe it is very valuable to do this >before ending the ForCES WG. The document may be titled like "Considerations on network function >virtualization with ForCES". NFV is mentioned as an example in the charter. The current text also says informational documents are more than welcome. If there is something ForCES is missing that is needed for NFV (I cant think of one), then by all means put out a draft as well and we may add it on the next re-charter. > On Extensions to Model and Protocol, the work items are clearly listed. I suggest > we also state to allow any other items than listed which are in the process found useful and necessary. > Adrian may not be too happy if we added more things along the way. However, given we have 1 year to complete the current listed task - and we deliver on the current tasks, we should be able to get more rope. > Again, we are interested in the model and protocol extention work and the virtualization work, > and the paralellization work if needed. > Please let the party begin. cheers, jamal From adrian@olddog.co.uk Mon Apr 8 10:09:15 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C64C21F8A84 for ; Mon, 8 Apr 2013 10:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+TLg5C9jJ5K for ; Mon, 8 Apr 2013 10:09:15 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id C98D321F8A4E for ; Mon, 8 Apr 2013 10:09:14 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r38H9Cqs013482; Mon, 8 Apr 2013 18:09:13 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r38H9BwG013461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Apr 2013 18:09:12 +0100 From: "Adrian Farrel" To: "'Jamal Hadi Salim'" , "'Wang,Weiming'" References: <05e801ce307b$a06f4340$e14dc9c0$@olddog.co.uk> In-Reply-To: Date: Mon, 8 Apr 2013 18:09:11 +0100 Message-ID: <06bb01ce347b$cab42b30$601c8190$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG/9L7rOQEH9JykTXY/Y9nwFLejSAHHgyE5AW/aLUaYz1IFEA== Content-Language: en-gb Cc: forces@ietf.org Subject: Re: [forces] Charter text updates X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 17:09:15 -0000 Hi, > > On Extensions to Model and Protocol, the work items are clearly > > listed. I suggest we also state to allow any other items than listed > > which are in the process found useful and necessary. > > Adrian may not be too happy if we added more things along the > way. However, given we have 1 year to complete the current > listed task - and we deliver on the current tasks, we should be > able to get more rope. Yes, Jamal is right. And is just not I who would be unhappy. We will not get an open-ended charter past the IESG. You have to know what it is you plan to work on. If you know now, then speak up. Otherwise, let's wait for new ideas to be floated and crystalize. Charters can be updated at any time. Adrian From dro@zurich.ibm.com Tue Apr 9 02:24:51 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7B221F8F1E for ; Tue, 9 Apr 2013 02:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8unFdXTP3wS for ; Tue, 9 Apr 2013 02:24:50 -0700 (PDT) Received: from e06smtp17.uk.ibm.com (e06smtp17.uk.ibm.com [195.75.94.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7C92121F8E7C for ; Tue, 9 Apr 2013 02:24:48 -0700 (PDT) Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 9 Apr 2013 10:22:18 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp17.uk.ibm.com (192.168.101.147) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 9 Apr 2013 10:22:00 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 749BF1B0805D for ; Tue, 9 Apr 2013 10:24:27 +0100 (BST) Received: from d06av05.portsmouth.uk.ibm.com (d06av05.portsmouth.uk.ibm.com [9.149.37.229]) by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r399OHoT53084280 for ; Tue, 9 Apr 2013 09:24:17 GMT Received: from d06av05.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r399ORLl022343 for ; Tue, 9 Apr 2013 03:24:27 -0600 Received: from aare.zurich.ibm.com (aare.zurich.ibm.com [9.4.2.232]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r399ORjY022322; Tue, 9 Apr 2013 03:24:27 -0600 Received: from [127.0.0.1] (sig-9-145-136-86.de.ibm.com [9.145.136.86]) by aare.zurich.ibm.com (AIX6.1/8.14.4/8.13.4) with ESMTP id r399OEeJ7274784; Tue, 9 Apr 2013 11:24:23 +0200 Message-ID: <5163DE3E.5080601@zurich.ibm.com> Date: Tue, 09 Apr 2013 11:24:14 +0200 From: Patrick Droz Organization: IBM Research Division User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Joel , forces@ietf.org, "adrian@olddog.co.uk >> Adrian Farrel" References: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> <51619F83.9010908@stevecrocker.com> In-Reply-To: <51619F83.9010908@stevecrocker.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080908040906060200090701" X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13040909-0542-0000-0000-000004E00219 Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 09:24:51 -0000 This is a cryptographically signed message in MIME format. --------------ms080908040906060200090701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I can only second the opinion form Jamal and Joel, I think no=20 oppositions means that there is common agreement. Regards, Patrick On 07.04.2013 18:32, Joel wrote: > Suggestion folks. Even if you think Adrian has heard from you, speak > again. > > In case it is unclear, I strongly support this charter. > > yours, > Joel > > On 4/7/2013 8:23 AM, Adrian Farrel wrote: >> Hi ForCES, >> >> I am not going to go to the rest of the IESG and say "Two people said >> OK, and >> no-one else actually objected." If I do that, they will (rightly) >> object to >> re-chartering the WG. >> >> This is your make or break! If you can't enthusiastically commit to th= is >> proposed re-charter then it is pretty obvious where we stand. I know >> that a >> number of you say you want to work on this stuff, so stand up and wave= >> your hat >> in the air! >> >> Thanks, >> Adrian >> >>> -----Original Message----- >>> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On >>> Behalf Of >>> Adrian Farrel >>> Sent: 03 April 2013 15:58 >>> To: forces@ietf.org >>> Subject: [forces] Charter text updates >>> >>> Hi, >>> >>> Current update is at >>> https://datatracker.ietf.org/doc/charter-ietf-forces/ >>> >>> I am still looking for comments of support, disagreement, or ridicule= =2E >>> >>> Adrian >>> >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > > > > --=20 Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-44-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-44-724-85-78 --------------ms080908040906060200090701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXjCC BeowggTSoAMCAQICEAcs9nuoW8TkdkQtCCxafi0wDQYJKoZIhvcNAQEFBQAwggEBMQswCQYD VQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jw b3JhdGlvbjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxNTAzBgNV BAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMScwJQYD VQQDEx5JQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwNzExMDAwMDAwWhcN MTMwNzExMjM1OTU5WjCBhTEuMCwGA1UEChQlSW50ZXJuYXRpb25hbCBCdXNpbmVzcyBNYWNo aW5lcyBDb3JwLjEVMBMGA1UEAwwMUGF0cmljayBEcm96MRkwFwYKCZImiZPyLGQBARQJMzMx OTAzODQ4MSEwHwYJKoZIhvcNAQkBFhJkcm9AenVyaWNoLmlibS5jb20wgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBALDklA9/GOds99t6tvx/Lz5A2orK9oIxaiIPwB0wRzLsEeL9Rf03 /EAokFI8N9NwW0NzbARwixDKeCle3GFdIJ/zEabI94JblBLT6O/mFoLzuJyldsDW1AyDLTSn i2/zuHrKkcbB3wvWviQLh2g3RWv75HvlC6q7KdUFucc6g6Q1AgMBAAGjggJZMIICVTAJBgNV HRMEAjAAMAsGA1UdDwQEAwIFoDBtBgNVHR8EZjBkMGKgYKBehlxodHRwOi8vb25zaXRlY3Js LnZlcmlzaWduLmNvbS9JbnRlcm5hdGlvbmFsQnVzaW5lc3NNYWNoaW5lc0NvcnBDb3Jwb3Jh dGVDSU8vTGF0ZXN0Q1JMLUcyLmNybDCCASkGA1UdIASCASAwggEcMIIBGAYLYIZIAYb4RQEH FwIwggEHMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMIHX BggrBgEFBQcCAjCByhqBx05vdGljZSBUZXh0PU5PVElDRTogUHJpdmF0ZSBrZXkgbWF5IGJl IHJlY292ZXJlZCBieSBWZXJpU2lnbidzIGN1c3RvbWVyIHdobyBtYXkgYmUgYWJsZSB0byBk ZWNyeXB0IG1lc3NhZ2VzIHlvdSBzZW5kIHRvIGNlcnRpZmljYXRlIGhvbGRlci4gIFVzZSBp cyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3Iw HwYDVR0jBBgwFoAUErYk3v17uPCRV4ht2Y3ymDoCW+QwHQYDVR0OBBYEFNqbpQquvQQ9GmR0 wW0bY1nVJDh1MC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQCA6AUDBJkcm9AenVyaWNoLmlibS5j b20wHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGCWCGSAGG+EIBAQQEAwIFoDAN BgkqhkiG9w0BAQUFAAOCAQEAbq/oTapGWYNeueEavlQENzBn2YxuKDJkcsFUdzotIN+17Jua 58FYPsV3VpfPnCPbj6KAeUBK1Wa/tVPobqbR7TEqbUj4kS9JyC+nPRufCoOlcWvGw2Wnnaee LQQPNCtZNzBuA8qAlsiKwDGgY3pvcItBglAExUmR5IoOjfSW34NKxZ2Y7Acf7cZYY3tepovQ G0JCWNwxtLqD3kfk1yiGRDmGIXFihfTqe7kbSi0+9+oaEytjZRNK8LSr5FW3WrpzsUkk+ra+ AsiD7gF9g2R2pwKOK6EqYLDEMl/8/z/xMz04ClmhOI/AaCa3Al8vF5jdMtbpjXjdchDU9bjn 3nKQ1zCCBmwwggVUoAMCAQICECpwlV5qit9BM9aVZKKwry8wDQYJKoZIhvcNAQEFBQAwgcox CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDcwNzAwMDAw MFoXDTE0MDcwNjIzNTk1OVowggEBMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRp b25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBMScwJQYDVQQDEx5JQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7BYDLJYFcruxsH9wx M2NZB534dcay/fsbPCEH94xKEg06AWloXwkq/Go75ocPRnN/QnSweSTdl/2WpmMIcsNjflEu ZnFpAkOQ9ZhLcICKM2d1oXaJuUPDUbIL/0KlB0rTYQnYaJOC0A36El+tcJTbv4HjM2fsVOBP VQ9kN/1EaHmy2Rb+mRhGrYDdYC7Hv9/9kL+RfWEjMtbQic4KrrRUu08E+vHjzXShPeKgq5B+ ZR9k5jQb1UJ/uh7oDh8kuY4gEk8vOGXu877KufRegrF9UwZww9aCXHm1caFZSQU9NuTkmKVB mQsPbXfpoz9bRO6Cyac9c1gnk2PWuALNZMZLAgMBAAGjggISMIICDjASBgNVHRMBAf8ECDAG AQH/AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwIwVjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cudmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjAuBgNVHREEJzAlpCMwITEfMB0GA1UEAxMW UHJpdmF0ZUxhYmVsNC0yMDQ4LTEzMDAdBgNVHQ4EFgQUErYk3v17uPCRV4ht2Y3ymDoCW+Qw gfAGA1UdIwSB6DCB5aGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykg MTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQD EzxWZXJpU2lnbiBDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzOCEGFwy0mMX5hFKeewptlQW3owDQYJKoZIhvcNAQEFBQADggEBADYlbxAYtL6+ V1OwhRyIzvXaaCDY1GOltZid8oS3pne3z41VY6QCgOlmBlFfBqikHtAH1inOO+dh4FAalR+f xhA14slfIZDWO7I4exjtFMLm5eavHUF13AaDKMzmqIOPWU3ddB8Y/wLMSF1PFIjL92GblkXN 6Z3sYSmc5B4OfDpIHh4qgz0ljNQa2yPz4Z2ZXrU9XpF8z094MEF8AgAGaKBi7Q9l61Ecl/6n n5jGsnyqTa12UubnWb6KPqIMWx1e9eWNGeVT865X8a8ajnXiWsy7rnu/fAk2bKPHCD5oRrWf 9ZL8mnsEsBrl+smRGPh9Wsk/OKRgY/ZnaHLe0yf1v9cxggTsMIIE6AIBATCCARcwggEBMQsw CQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxNTAz BgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMScw JQYDVQQDEx5JQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEAcs9nuoW8TkdkQtCCxa fi0wCQYFKw4DAhoFAKCCAykwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTMwNDA5MDkyNDE0WjAjBgkqhkiG9w0BCQQxFgQUmKUR04r26FuxK8Cu/OELal90 O1owbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCCASoGCSsGAQQBgjcQBDGCARswggEXMIIBATELMAkGA1UEBhMCVVMxNDAyBgNVBAoT K0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFn ZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEnMCUGA1UEAxMeSUJNIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IEcyAhAHLPZ7qFvE5HZELQgsWn4tMIIBLAYLKoZIhvcNAQkQAgsx ggEboIIBFzCCAQExCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExJzAlBgNVBAMTHklCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMgIQ Byz2e6hbxOR2RC0ILFp+LTANBgkqhkiG9w0BAQEFAASBgGsGKeqbJSV3DkKxb9rmfXxU2yCy TyfwEz7PKQm4l54UFew6JiQ+V6JA2vPPmaDnbxE8SjOq/ujJtGHUDiQJ18b+u3bFp+7+g/bX Bq3kavbM5B15rZbte9crJmZdNlsJQVhF7/jj4S9Qd6+GQnr1tDqrRtl178kVs+odeuHZ2yxy AAAAAAAA --------------ms080908040906060200090701-- From alan.crouch@intel.com Tue Apr 9 05:02:06 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F7C21F9132 for ; Tue, 9 Apr 2013 05:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDkDAQNsvc4c for ; Tue, 9 Apr 2013 05:02:06 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC6A21F9029 for ; Tue, 9 Apr 2013 05:02:06 -0700 (PDT) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 09 Apr 2013 05:02:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,438,1363158000"; d="scan'208";a="225005352" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by AZSMGA002.ch.intel.com with ESMTP; 09 Apr 2013 05:02:03 -0700 Received: from orsmsx102.amr.corp.intel.com ([169.254.1.197]) by ORSMSX105.amr.corp.intel.com ([169.254.4.39]) with mapi id 14.01.0355.002; Tue, 9 Apr 2013 05:02:03 -0700 From: "Crouch, Alan" To: Patrick Droz , Joel , "forces@ietf.org" , "adrian@olddog.co.uk >> Adrian Farrel" Thread-Topic: [forces] Voices of support needed! [Was: Charter text updates] Thread-Index: AQHONQQAA6KjUk0/B0WWbyi1BCtoC5jNx5jg Date: Tue, 9 Apr 2013 12:02:02 +0000 Message-ID: References: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> <51619F83.9010908@stevecrocker.com> <5163DE3E.5080601@zurich.ibm.com> In-Reply-To: <5163DE3E.5080601@zurich.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 12:02:06 -0000 Agree as well - good work to be done here to continue explicit control/forw= arding plane separation to foster rapid innovation in internet infrastructu= re.=20 The updated charter with 5 model extensions and 4 protocol extensions is we= ll in line with the original vision for ForCES. The working group have exp= erts who are signed up to do the work: Inter-FE Connectivity, Paralleliza= tion, and Subsidiary Management.=20 I join Jamal, Joel, Weiming, Patrick, and others who have spoken in strong = support.=20 Alan=20 -----Original Message----- From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of= Patrick Droz Sent: Tuesday, April 9, 2013 2:24 AM To: Joel; forces@ietf.org; adrian@olddog.co.uk >> Adrian Farrel Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] I can only second the opinion form Jamal and Joel, I think no oppositions m= eans that there is common agreement. Regards, Patrick On 07.04.2013 18:32, Joel wrote: > Suggestion folks. Even if you think Adrian has heard from you, speak=20 > again. > > In case it is unclear, I strongly support this charter. > > yours, > Joel > > On 4/7/2013 8:23 AM, Adrian Farrel wrote: >> Hi ForCES, >> >> I am not going to go to the rest of the IESG and say "Two people said=20 >> OK, and no-one else actually objected." If I do that, they will=20 >> (rightly) object to re-chartering the WG. >> >> This is your make or break! If you can't enthusiastically commit to=20 >> this proposed re-charter then it is pretty obvious where we stand. I=20 >> know that a number of you say you want to work on this stuff, so=20 >> stand up and wave your hat in the air! >> >> Thanks, >> Adrian >> >>> -----Original Message----- >>> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On=20 >>> Behalf Of Adrian Farrel >>> Sent: 03 April 2013 15:58 >>> To: forces@ietf.org >>> Subject: [forces] Charter text updates >>> >>> Hi, >>> >>> Current update is at >>> https://datatracker.ietf.org/doc/charter-ietf-forces/ >>> >>> I am still looking for comments of support, disagreement, or ridicule. >>> >>> Adrian >>> >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > > > > --=20 Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-44-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-44-724-85-78 From hormuzd.m.khosravi@intel.com Tue Apr 9 08:26:11 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F70121F973D for ; Tue, 9 Apr 2013 08:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g541oghka8fN for ; Tue, 9 Apr 2013 08:26:10 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id D46A721F9497 for ; Tue, 9 Apr 2013 08:26:09 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 09 Apr 2013 08:26:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,439,1363158000"; d="scan'208";a="315400311" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by orsmga002.jf.intel.com with ESMTP; 09 Apr 2013 08:26:04 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.213]) by ORSMSX105.amr.corp.intel.com ([169.254.4.39]) with mapi id 14.01.0355.002; Tue, 9 Apr 2013 08:26:04 -0700 From: "Khosravi, Hormuzd M" To: "Crouch, Alan" , Patrick Droz , Joel , "forces@ietf.org" , "adrian@olddog.co.uk >> Adrian Farrel" Thread-Topic: [forces] Voices of support needed! [Was: Charter text updates] Thread-Index: AQHONQQ3GOhxLs6/2EO8v3NUQTOz7pjOP2cA///DiHA= Date: Tue, 9 Apr 2013 15:26:03 +0000 Message-ID: <9E72AD5A3CD2A243B37C858637FD2A5B71337A38@ORSMSX101.amr.corp.intel.com> References: <04c801ce338a$b73f3780$25bda680$@olddog.co.uk> <51619F83.9010908@stevecrocker.com> <5163DE3E.5080601@zurich.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:26:11 -0000 I second Alan and team on this, Regards Hormuzd -----Original Message----- From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of= Crouch, Alan Sent: Tuesday, April 09, 2013 5:02 AM To: Patrick Droz; Joel; forces@ietf.org; adrian@olddog.co.uk >> Adrian Farr= el Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] Agree as well - good work to be done here to continue explicit control/forw= arding plane separation to foster rapid innovation in internet infrastructu= re.=20 The updated charter with 5 model extensions and 4 protocol extensions is we= ll in line with the original vision for ForCES. The working group have exp= erts who are signed up to do the work: Inter-FE Connectivity, Paralleliza= tion, and Subsidiary Management.=20 I join Jamal, Joel, Weiming, Patrick, and others who have spoken in strong = support.=20 Alan=20 -----Original Message----- From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of= Patrick Droz Sent: Tuesday, April 9, 2013 2:24 AM To: Joel; forces@ietf.org; adrian@olddog.co.uk >> Adrian Farrel Subject: Re: [forces] Voices of support needed! [Was: Charter text updates] I can only second the opinion form Jamal and Joel, I think no oppositions m= eans that there is common agreement. Regards, Patrick On 07.04.2013 18:32, Joel wrote: > Suggestion folks. Even if you think Adrian has heard from you, speak=20 > again. > > In case it is unclear, I strongly support this charter. > > yours, > Joel > > On 4/7/2013 8:23 AM, Adrian Farrel wrote: >> Hi ForCES, >> >> I am not going to go to the rest of the IESG and say "Two people said=20 >> OK, and no-one else actually objected." If I do that, they will >> (rightly) object to re-chartering the WG. >> >> This is your make or break! If you can't enthusiastically commit to=20 >> this proposed re-charter then it is pretty obvious where we stand. I=20 >> know that a number of you say you want to work on this stuff, so=20 >> stand up and wave your hat in the air! >> >> Thanks, >> Adrian >> >>> -----Original Message----- >>> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On=20 >>> Behalf Of Adrian Farrel >>> Sent: 03 April 2013 15:58 >>> To: forces@ietf.org >>> Subject: [forces] Charter text updates >>> >>> Hi, >>> >>> Current update is at >>> https://datatracker.ietf.org/doc/charter-ietf-forces/ >>> >>> I am still looking for comments of support, disagreement, or ridicule. >>> >>> Adrian >>> >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > > > > --=20 Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-44-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-44-724-85-78 _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Wed Apr 10 04:42:22 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271CF21F9423 for ; Wed, 10 Apr 2013 04:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOZM+B14t6mI for ; Wed, 10 Apr 2013 04:42:21 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0C321F92EC for ; Wed, 10 Apr 2013 04:42:21 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id b10so292562vea.16 for ; Wed, 10 Apr 2013 04:42:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=pQjaPwOTgHUf7WPxLk7AseyicKcnTNorSPKuYYIneE0=; b=ktcXsquKMWl+zuQ4dGE7rZ1Wqog96IR0yv7ylZpz99TJ3vCCxyRLA4xLbHGPrRRwTP kn0bRVkLNezWnuDheLxFSWrfGHKZGt6eRGZeo4NNs6qp0dSxGtrlIlxLimOzWOrwlNPY nL9fUYvgp3StmAhPSz9EYuOoIyeV83B16TT1mGZVFR4ijarC4kS+HtvX3M2vu6/mXVUc fWR8Q9UVnzfltiQ8bafdUdGvD7C7dz95aPInoxwIwYuFF154sbH+uiiJufkAzAd5mpQf 6tA8IP9viwc9h3mKltuTyNLZSpnr7PddS7oOgF9yW+3B17+1dqgsUjqinoPHwtV68pRn Oeyw== X-Received: by 10.220.222.8 with SMTP id ie8mr1164427vcb.27.1365594140489; Wed, 10 Apr 2013 04:42:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.24.137 with HTTP; Wed, 10 Apr 2013 04:41:59 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB9CFC424@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB9CFC424@PUEXCB1B.nanterre.francetelecom.fr> From: Jamal Hadi Salim Date: Wed, 10 Apr 2013 07:41:59 -0400 Message-ID: To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmD4zfYe7LRyZj68weoORa/67Vx8OtcfHxcLllNHL3eUvx05kx3OZrk5kqCYPGDNKpnFF03 Cc: forces@ietf.org, "sdn@irtf.org" , JACQUENET Christian OLNC/OLN Subject: Re: [forces] [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 11:42:22 -0000 Hi Med, I am finally going to answer the original email you posted instead of talking about IETF liasons ;-> Since i am consuming excellent brew of coffee, I will try to tone it down ;-> On Wed, Mar 20, 2013 at 11:40 AM, wrote: > Dear all, > > We submitted this new I-D. > > Comments and inputs are welcome. while the title is very specific/descriptive, it was a little hard to extract the central message upfront. If i was to sum up your message: This document provides an _operator perspective_ on what SDN needs are; and also serves to offer advice to network operators? The document injects a dose of pragmatism about inter-working with existing infrastructre. It took me a re-read to understand your draft is pushing an SDN theme of automation as the desired end goal. Did i get this right? Maybe your doc needs to break down what programmability aspect is needed from an operator perspective (CLI aka netconf, Policy management, service management, control-datapath separation etc). And, sorry, who is deploying COPS out there? Or perhaps your text on COPS was intended to emphasizw the point that nothing is new here? why not mention SS7 then (which is still in deployment)? Overall, I think theres a lot of words of wisdom as well as a good measure of cynicism against some of the over-marketing of SDN(which i empathize with). Thanks for pointing out that OF is not the end-all-be-all and that Control-datapath separation is merely infrastructure requirement in the larger picture (and, yes ForCES falls under the same umbrella). I have to say i was a little disappointed on the number of bytes you allocated to ForCES on this document. Mentioning ForCES in the same breath as RFC 1383 is rather harsh! from your sections 1 and 2 (it was hard to extract this): The (operator) "network is getting more complex"; ATAWAD is making it worse then you talk about desire from operator perspective is to create and deliver services despite the presence of such complexities in a manner which "evolves easily, remains scalable, robust and available (even in presence of DOS attacks)" But also you ask for "cost effectiveness". 1) On the issue of complexity, an interesting sample was illustrated by slide 6 from D. Meyer here: http://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-0.pdf 2) And if i was to correlate Dave's slide to some food analogy: Equipment vendors are in the business of selling cookies (chocolate-chip, vanilla, ginger, etc of different sizes and shapes, etc) created via some well understood "factory" assembly line. Look at all those cookies in the slide. I am reading your view to be: the existing cookie-cut approach is _ok_ as long as the vendors provide you ways to automate and hide that complexity. But if that is the case, isnt it contradictory to also ask for (what i am assuming to be capital) cost effectiveness? more cookies will cost more, no? And more smart people figuring ways to give you atkins diet using cookies is also gonna cost you more. My view of the power of SDN is ability to be able to inject new Network Functions and be able to elongate life times of existing equipment (and all network functions become programmable). i.e in the ideal scenario I should be able to inject a new network function in an existing box without playing acrobatics with how to hack some tables in a distributed system. Whats your view of NFV? One thing you left out as an operator desire is "vendor lock-in". Is this not an important detail to you or it is taboo to talk about? On some of the expressed cynicsm in the document that i disagree with: I think you are under-valuing the control-data separation standardization such as the one pushed forward by ForCES in section 3.1. "tautology" by stating that vendors have been doing for years software based control etc. The SDN emphasis is: a) the control-data path separation is proprietary in those boxes b) tends to run on these tiny cpus (to which you are locked until you buy the next GodBox). My coffee-defined-energy is still high and I could say more - but i think i threw in a lot of text there... cheers, jamal From hadi@mojatatu.com Wed Apr 10 05:06:31 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644AE21F92E8 for ; Wed, 10 Apr 2013 05:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew3BKcDTTi5j for ; Wed, 10 Apr 2013 05:06:30 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF9721F92B7 for ; Wed, 10 Apr 2013 05:06:30 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id gd11so290732vcb.31 for ; Wed, 10 Apr 2013 05:06:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=fxL/hqWwQWoN/R0iWO2vbuK1rZ2DM5i7z4hCVucYSwQ=; b=F0nQ9V4Hp8riDUqlZOWvfCvBJPMj+Zqo0/AoaMcJgqb0oTw13BlW+ODZsRT/1LDItU dx2IW91qWe0oZ0GZHHj0z+tJdpWq8M9RI+Y26cjMoICmjF6WCkCJmb+SFTzTcN3Gv7TL YYZTphu9i/e7Bc8RxjKaW6ndzAcjDXXRCGn3K4FHKQLBYaOfH3zvDv/YOrFK7SjRhqyK Z0kxunMXjaE70Wz9md5AkUILk8L58NYATjEhlpFZc1oRg8b5xJuH76ggIyhoWAH3xnxL BTeGHw/icQcOyT7HgUOf2RWqO3KLomGy07y8BkemZBHl1c02pHbYkhNPw3l+Prl1iuOt VFEw== X-Received: by 10.220.82.3 with SMTP id z3mr1241806vck.18.1365595589969; Wed, 10 Apr 2013 05:06:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.24.137 with HTTP; Wed, 10 Apr 2013 05:06:09 -0700 (PDT) From: Jamal Hadi Salim Date: Wed, 10 Apr 2013 08:06:09 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn+hnSytcr5MFbE0plzlcF91ZzDlzJea58zUjsNY6naDPLR+iviPx6xNXEhdNqhU1HlJelA Subject: [forces] wikipedia X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 12:06:31 -0000 Apparently https://en.wikipedia.org/wiki/Software-defined_networking does not mention ForCES. We need to fix this. Can we have some volunteers to edit and add appropriate references? cheers, jamal From christian.jacquenet@orange.com Wed Apr 10 05:23:57 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8FD21F9409 for ; Wed, 10 Apr 2013 05:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux5sn9U2cGnv for ; Wed, 10 Apr 2013 05:23:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1D74621F8FE8 for ; Wed, 10 Apr 2013 05:23:55 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0687522CA54; Wed, 10 Apr 2013 14:23:55 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D8E3727C069; Wed, 10 Apr 2013 14:23:54 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 10 Apr 2013 14:23:51 +0200 From: To: Jamal Hadi Salim , BOUCADAIR Mohamed OLNC/OLN Date: Wed, 10 Apr 2013 14:23:49 +0200 Thread-Topic: [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt Thread-Index: Ac414HhOYIB3rPg0Tvek/PLjKWCecQAAuPrw Message-ID: <14742_1365596634_516559DA_14742_324_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A7C596F2B@PUEXCB1C.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB9CFC424@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 X-Mailman-Approved-At: Wed, 10 Apr 2013 05:31:52 -0700 Cc: "forces@ietf.org" , "sdn@irtf.org" Subject: Re: [forces] [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 12:23:57 -0000 Hello Jamal, Many thanks for your detailed feedback. I'll let my fellow colleague furthe= r comment, but here's a first shot of responses from my side - inline.=20 [snip] while the title is very specific/descriptive, it was a little hard to extra= ct the central message upfront. If i was to sum up your message: This document provides an _operator perspective_ on what SDN needs are; and= also serves to offer advice to network operators? CJ: it's mostly a provider's perspective on current SDN hype (and beyond). = I think the "advice" wording is a bit strong - the draft is rather meant to= list a few things one should not forget when considering the use of SDN te= chniques to improve network service delivery procedures. The document injects a dose of pragmatism about inter-working with existing= infrastructre. It took me a re-read to understand your draft is pushing an SDN theme of au= tomation as the desired end goal. Did i get this right? CJ: automation is a means, not a goal per se. We believe automation is a ke= y benefit that can be brought by the activation of SDN techniques. The auto= mation of complex service delivery is clearly an attractive feature, for th= e sake of cost reduction. Maybe your doc needs to break down what programmability aspect is needed fr= om an operator perspective (CLI aka netconf, Policy management, service man= agement, control-datapath separation etc). And, sorry, who is deploying CO= PS out there? CJ: you'd be surprised by the number of networks that use COPS-PR implement= ations for the sake of bandwidth management in the access...This is a proto= col (along with the related SPPI-formatted information) that is supported b= y at least a couple of vendors and which is deployed in the operational fie= ld (at least a couple of networks operated by some of Orange's affiliates).= As for your suggestion, I'm not sure what you mean as we see programmabili= ty as a feature. Or perhaps your text on COPS was intended to emphasizw the point that nothi= ng is new here? why not mention SS7 then (which is still in deployment)? CJ: I certainly recognize there are plenty of functional components that ha= ve been specified and standardized (for some of them) for quite some time. = And I also recognize we may have not listed your favorite tool :-)=20 Overall, I think theres a lot of words of wisdom as well as a good measure = of cynicism against some of the over-marketing of SDN(which i empathize wit= h). CJ: thank you! That said, the point of the draft is certainly not to adopt = a cynical position towards SDN techniques - beyond the SDN wording, we are = true "SDN believers", provided we keep in mind a few things like this is no= t a one-size-fits-all solution, performance and scalability must be taken i= nto account as a function of the number and the nature of services to be de= livered and that the major technical challenges reside in the ability to co= mbine the 4 meta-functional blocks that we briefly introduce in the documen= t. That is, for example, take the results of a (CCP-based) negotiation of s= ervice parameters between the customer and the service provider as an input= that could gracefully feed a path computation module. Thanks for pointing out that OF is not the end-all-be-all and that Control-= datapath separation is merely infrastructure requirement in the larger pict= ure (and, yes ForCES falls under the same umbrella). I have to say i was a little disappointed on the number of bytes you alloca= ted to ForCES on this document. Mentioning ForCES in the same breath as RFC= 1383 is rather harsh! CJ: ha, ha! Well again, we don't mean to be rude or cynical - there are int= eresting approaches aout there that are probably part of the global SDN lan= dscape. It's up to us to pick the technology that suits best. from your sections 1 and 2 (it was hard to extract this): The (operator) "network is getting more complex"; ATAWAD is making it worse= then you talk about desire from operator perspective is to create and deli= ver services despite the presence of such complexities in a manner which "e= volves easily, remains scalable, robust and available (even in presence of = DOS attacks)" But also you ask for "cost effectiveness". CJ: right. 1) On the issue of complexity, an interesting sample was illustrated by sli= de 6 from D. Meyer here: http://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-0.pdf CJ: indeed. 2) And if i was to correlate Dave's slide to some food analogy: Equipment vendors are in the business of selling cookies (chocolate-chip, v= anilla, ginger, etc of different sizes and shapes, etc) created via some we= ll understood "factory" assembly line. Look at all those cookies in the sli= de. CJ: and the factory assembly is precisely where it gets really tricky. I am reading your view to be: the existing cookie-cut approach is _ok_ as l= ong as the vendors provide you ways to automate and hide that complexity. CJ: not exactly. We do not deny complexity, as long as it is hidden to our = *customers*. But if that is the case, isnt it contradictory to also ask for (what i am a= ssuming to be capital) cost effectiveness? more cookies will cost more, no?= And more smart people figuring ways to give you atkins diet using cookies= is also gonna cost you more. CJ: I don't think there is a single answer to your comment. Let me give you= an example: within the context of our current inter-domain VPN service off= ering, we need to request PE resources with peering partners, in a bilatera= l fashion. The corresponding negotiation remains paper- and fax- (yes fax)b= ased, and I can tell you it takes quite some time the get the proprer resou= rces right, let alone the CE-PE connection (especially in a dual homign con= text, depending on the location of the PE routers and the customer premises= ). Based upon an apporpriately-formatted CPP template, we believe that the = inherent complexity should be adequately balanced by a dramatic improvement= of the time-to-deliver the service, from several weeks to a few days, if n= ot hours. This will have a dramatic impact on the overall cost. My view of the power of SDN is ability to be able to inject new Network Fun= ctions and be able to elongate life times of existing equipment (and all ne= twork functions become programmable). i.e in the ideal scenario I should be= able to inject a new network function in an existing box without playing a= crobatics with how to hack some tables in a distributed system. Whats your = view of NFV? CJ: NFV is part of the global SDN landscape from my perspective. This is wh= y we see information models and data (including policy provisioning informa= tion) as a key component of what you call NFV. That said, I'm not convinced= NFV can be applied to each and every network capability you could think of= , depending on the nature of the service and the impact on the amount of (c= onfiguration information) traffic that needs to be exchanged between the co= ntrol and the data planes, for example. One thing you left out as an operator desire is "vendor lock-in". Is this n= ot an important detail to you or it is taboo to talk about? CJ: that's certainly important, this is clearly not a taboo, but this is al= so something tht is not SDN-specific (at least as far asFT Orange is concer= ned). On some of the expressed cynicsm in the document that i disagree with: I think you are under-valuing the control-data separation standardization s= uch as the one pushed forward by ForCES in section 3.1. "tautology" by stating that vendors have been doing for years software based control et= c. The SDN emphasis is: a) the control-data path separation is proprietary in those boxes CJ: correct. b) tends to run on these tiny cpus (to which you are locked until you buy t= he next GodBox). CJ; right, but we were actually discussing the fuzz around separated contro= l and forwarding planes. We understand the SDN approach, but we'd appreciat= e a more specific/accurate wording for the sake of undertsnadability. My coffee-defined-energy is still high and I could say more - but i think i= threw in a lot of text there... CJ: thanks again for this interesting discussion. We're looking forward to = hearing from you all! Cheers, Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From christian.jacquenet@orange.com Wed Apr 10 05:26:38 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B926321F95EC for ; Wed, 10 Apr 2013 05:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJfUgCgga8vu for ; Wed, 10 Apr 2013 05:26:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 60F5921F94CC for ; Wed, 10 Apr 2013 05:26:37 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id A2FBC22CB37; Wed, 10 Apr 2013 14:26:36 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8266427C058; Wed, 10 Apr 2013 14:26:36 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 10 Apr 2013 14:26:31 +0200 From: To: Jamal Hadi Salim , BOUCADAIR Mohamed OLNC/OLN Date: Wed, 10 Apr 2013 14:26:29 +0200 Thread-Topic: [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt Thread-Index: Ac414HhOYIB3rPg0Tvek/PLjKWCecQAAuPrwAADN9fA= Message-ID: <15335_1365596796_51655A7C_15335_156_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A7C596F2F@PUEXCB1C.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB9CFC424@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 X-Mailman-Approved-At: Wed, 10 Apr 2013 05:31:52 -0700 Cc: "forces@ietf.org" , "sdn@irtf.org" Subject: Re: [forces] [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 12:26:38 -0000 Re-sending, first mail was bounced. -----Message d'origine----- De : JACQUENET Christian OLNC/OLN=20 Envoy=E9 : mercredi 10 avril 2013 14:24 =C0 : 'Jamal Hadi Salim'; BOUCADAIR Mohamed OLNC/OLN Cc : sdn@irtf.org; forces@ietf.org Objet : RE: [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt Hello Jamal, Many thanks for your detailed feedback. I'll let my fellow colleague furthe= r comment, but here's a first shot of responses from my side - inline.=20 [snip] while the title is very specific/descriptive, it was a little hard to extra= ct the central message upfront. If i was to sum up your message: This document provides an _operator perspective_ on what SDN needs are; and= also serves to offer advice to network operators? CJ: it's mostly a provider's perspective on current SDN hype (and beyond). = I think the "advice" wording is a bit strong - the draft is rather meant to= list a few things one should not forget when considering the use of SDN te= chniques to improve network service delivery procedures. The document injects a dose of pragmatism about inter-working with existing= infrastructre. It took me a re-read to understand your draft is pushing an SDN theme of au= tomation as the desired end goal. Did i get this right? CJ: automation is a means, not a goal per se. We believe automation is a ke= y benefit that can be brought by the activation of SDN techniques. The auto= mation of complex service delivery is clearly an attractive feature, for th= e sake of cost reduction. Maybe your doc needs to break down what programmability aspect is needed fr= om an operator perspective (CLI aka netconf, Policy management, service man= agement, control-datapath separation etc). And, sorry, who is deploying CO= PS out there? CJ: you'd be surprised by the number of networks that use COPS-PR implement= ations for the sake of bandwidth management in the access...This is a proto= col (along with the related SPPI-formatted information) that is supported b= y at least a couple of vendors and which is deployed in the operational fie= ld (at least a couple of networks operated by some of Orange's affiliates).= As for your suggestion, I'm not sure what you mean as we see programmabili= ty as a feature. Or perhaps your text on COPS was intended to emphasizw the point that nothi= ng is new here? why not mention SS7 then (which is still in deployment)? CJ: I certainly recognize there are plenty of functional components that ha= ve been specified and standardized (for some of them) for quite some time. = And I also recognize we may have not listed your favorite tool :-)=20 Overall, I think theres a lot of words of wisdom as well as a good measure = of cynicism against some of the over-marketing of SDN(which i empathize wit= h). CJ: thank you! That said, the point of the draft is certainly not to adopt = a cynical position towards SDN techniques - beyond the SDN wording, we are = true "SDN believers", provided we keep in mind a few things like this is no= t a one-size-fits-all solution, performance and scalability must be taken i= nto account as a function of the number and the nature of services to be de= livered and that the major technical challenges reside in the ability to co= mbine the 4 meta-functional blocks that we briefly introduce in the documen= t. That is, for example, take the results of a (CCP-based) negotiation of s= ervice parameters between the customer and the service provider as an input= that could gracefully feed a path computation module. Thanks for pointing out that OF is not the end-all-be-all and that Control-= datapath separation is merely infrastructure requirement in the larger pict= ure (and, yes ForCES falls under the same umbrella). I have to say i was a little disappointed on the number of bytes you alloca= ted to ForCES on this document. Mentioning ForCES in the same breath as RFC= 1383 is rather harsh! CJ: ha, ha! Well again, we don't mean to be rude or cynical - there are int= eresting approaches aout there that are probably part of the global SDN lan= dscape. It's up to us to pick the technology that suits best. from your sections 1 and 2 (it was hard to extract this): The (operator) "network is getting more complex"; ATAWAD is making it worse= then you talk about desire from operator perspective is to create and deli= ver services despite the presence of such complexities in a manner which "e= volves easily, remains scalable, robust and available (even in presence of = DOS attacks)" But also you ask for "cost effectiveness". CJ: right. 1) On the issue of complexity, an interesting sample was illustrated by sli= de 6 from D. Meyer here: http://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-0.pdf CJ: indeed. 2) And if i was to correlate Dave's slide to some food analogy: Equipment vendors are in the business of selling cookies (chocolate-chip, v= anilla, ginger, etc of different sizes and shapes, etc) created via some we= ll understood "factory" assembly line. Look at all those cookies in the sli= de. CJ: and the factory assembly is precisely where it gets really tricky. I am reading your view to be: the existing cookie-cut approach is _ok_ as l= ong as the vendors provide you ways to automate and hide that complexity. CJ: not exactly. We do not deny complexity, as long as it is hidden to our = *customers*. But if that is the case, isnt it contradictory to also ask for (what i am a= ssuming to be capital) cost effectiveness? more cookies will cost more, no?= And more smart people figuring ways to give you atkins diet using cookies= is also gonna cost you more. CJ: I don't think there is a single answer to your comment. Let me give you= an example: within the context of our current inter-domain VPN service off= ering, we need to request PE resources with peering partners, in a bilatera= l fashion. The corresponding negotiation remains paper- and fax- (yes fax)b= ased, and I can tell you it takes quite some time the get the proprer resou= rces right, let alone the CE-PE connection (especially in a dual homign con= text, depending on the location of the PE routers and the customer premises= ). Based upon an apporpriately-formatted CPP template, we believe that the = inherent complexity should be adequately balanced by a dramatic improvement= of the time-to-deliver the service, from several weeks to a few days, if n= ot hours. This will have a dramatic impact on the overall cost. My view of the power of SDN is ability to be able to inject new Network Fun= ctions and be able to elongate life times of existing equipment (and all ne= twork functions become programmable). i.e in the ideal scenario I should be= able to inject a new network function in an existing box without playing a= crobatics with how to hack some tables in a distributed system. Whats your = view of NFV? CJ: NFV is part of the global SDN landscape from my perspective. This is wh= y we see information models and data (including policy provisioning informa= tion) as a key component of what you call NFV. That said, I'm not convinced= NFV can be applied to each and every network capability you could think of= , depending on the nature of the service and the impact on the amount of (c= onfiguration information) traffic that needs to be exchanged between the co= ntrol and the data planes, for example. One thing you left out as an operator desire is "vendor lock-in". Is this n= ot an important detail to you or it is taboo to talk about? CJ: that's certainly important, this is clearly not a taboo, but this is al= so something tht is not SDN-specific (at least as far asFT Orange is concer= ned). On some of the expressed cynicsm in the document that i disagree with: I think you are under-valuing the control-data separation standardization s= uch as the one pushed forward by ForCES in section 3.1. "tautology" by stating that vendors have been doing for years software based control et= c. The SDN emphasis is: a) the control-data path separation is proprietary in those boxes CJ: correct. b) tends to run on these tiny cpus (to which you are locked until you buy t= he next GodBox). CJ; right, but we were actually discussing the fuzz around separated contro= l and forwarding planes. We understand the SDN approach, but we'd appreciat= e a more specific/accurate wording for the sake of undertsnadability. My coffee-defined-energy is still high and I could say more - but i think i= threw in a lot of text there... CJ: thanks again for this interesting discussion. We're looking forward to = hearing from you all! Cheers, Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From hadi@mojatatu.com Wed Apr 10 07:15:05 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8ED21F9806 for ; Wed, 10 Apr 2013 07:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.378 X-Spam-Level: X-Spam-Status: No, score=-101.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OmSklKfOLlZ for ; Wed, 10 Apr 2013 07:15:04 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6C25B21F97FC for ; Wed, 10 Apr 2013 07:15:04 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w15so390355vbb.37 for ; Wed, 10 Apr 2013 07:15:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=XQlXgPAwW+j0ebJyCkExdBkUYBScs+KveWRqC0J4I1g=; b=Y82eMawiMgYPYpHZdsg3PMw1C8N3/Q61gT+QlmQ6DlDV94NuOiCTR0qTHXYkbgBnbC RDGg6goXCn4YeWVqppmMflvNP0+IL19S9KUGjlOIv967qUOcNwFH899bEIQM0nzAKhoE dQI9u175YQy3szPqqH0XwBe9ac1sL4Ue98xBCbRWXXLrqzKUvvyFzbv6h50tcIe7aorL eL2A9nNZkJyuhljdf2KhELbTQXKYndR5H8Awc4+B7K4eZd32mEExNAPxjspfo6GZhxVc M/KzlAedOztEKOE1aKuLeFJRHxT6sx7TCWZ47ElzT6JYc8CxHuU+rsqvSAUNcF96JbbH z/kQ== X-Received: by 10.58.155.133 with SMTP id vw5mr1598257veb.43.1365603303732; Wed, 10 Apr 2013 07:15:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.24.137 with HTTP; Wed, 10 Apr 2013 07:14:43 -0700 (PDT) In-Reply-To: <14742_1365596634_516559DA_14742_324_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A7C596F2B@PUEXCB1C.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB9CFC424@PUEXCB1B.nanterre.francetelecom.fr> <14742_1365596634_516559DA_14742_324_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A7C596F2B@PUEXCB1C.nanterre.francetelecom.fr> From: Jamal Hadi Salim Date: Wed, 10 Apr 2013 10:14:43 -0400 Message-ID: To: christian.jacquenet@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlk+1oBNA8FHF+y7iNxYh+Sp3m3aPi1zXdwzXOhcy00wVbiS7CbOTZnEO7vaUk3UfXRB6K9 Cc: "sdn@irtf.org" , "forces@ietf.org" , BOUCADAIR Mohamed OLNC/OLN Subject: Re: [forces] [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 14:15:05 -0000 Hi Christian, On Wed, Apr 10, 2013 at 8:23 AM, wrote: > CJ: it's mostly a provider's perspective on current SDN hype (and beyond)= . I think the >"advice" wording is a bit strong - the draft is rather meant to list a few= things one should >not forget when considering the use of SDN techniques to improve network s= ervice >delivery procedures. > ;-> So it is advice. I think it will make the draft stronger if you invite other providers to co-author. My view of what a provider needs is shaped by some presentation i saw a while back - the emphasis there was on the theme that "each network is different, and SDN allows us to build our network the way we want it without worrying about the boxes". > CJ: automation is a means, not a goal per se. We believe automation is a = key benefit that can be brought by the activation of SDN > techniques. The automation of complex service delivery is clearly an attr= active feature, for the sake of cost reduction. It may help to describe how such cost effectiveness is achieved. I am assuming getting rid of the genius who knows the network is one effective cost-saving. Is fostering competition among vendors another? > CJ: you'd be surprised by the number of networks that use COPS-PR impleme= ntations for the sake of bandwidth management in >the access...This is a protocol (along with the related SPPI-formatted inf= ormation) that is supported by at least a couple of vendors >and which is deployed in the operational field (at least a couple of netwo= rks operated by some of Orange's affiliates). As for your >suggestion, I'm not sure what you mean as we see programmability as a feat= ure. > ok, i take that back. I know COPS went through a lot of battles at IETF and seemed defeated. > CJ: I certainly recognize there are plenty of functional components that = have been specified and standardized (for some of them) >for quite some time. And I also recognize we may have not listed your favo= rite tool :-) > Agreed. My intention was to point out relevance. From a historical perspect= ive SS7 was doing data/control separation before half the IETF population was born ;-> Whereas i had no clue COPS was being used. > CJ: thank you! That said, the point of the draft is certainly not to adop= t a cynical position towards SDN techniques - beyond the > SDN wording, we are true "SDN believers", provided we keep in mind a few = things like this is not a one-size-fits-all solution, I dont think there will ever be a one size fits all. >performance and scalability must be taken into account as a function of th= e number and the nature of services to be delivered and >that the major technical challenges reside in the ability to combine the 4= meta-functional blocks that we briefly introduce in the >document. That is, for example, take the results of a (CCP-based) negotiat= ion of service parameters between the customer and the >service provider as an input that could gracefully feed a path computation= module. > Indeed interesting idea. > I have to say i was a little disappointed on the number of bytes you allo= cated to ForCES on this document. Mentioning ForCES in the same breath as R= FC 1383 is rather harsh! > > CJ: ha, ha! Well again, we don't mean to be rude or cynical - there are i= nteresting approaches aout there that are probably part of the global SDN l= andscape. It's up to us to pick the technology that suits best. > True - but you are writing a generic draft, so I just wanted you to be fair= ;-> We have enough of the big gorilla marketing machine like ONF that is ignoring the facts. It is not even an orange apple comparison to put ForCES and RFC 1383 in the same basket. ForCES is a generic datapath/control separation _architecture_ unlike the basic RFC 1383 specific feature; or OF with a specific datapath or COPS with a specific bandwidth enforcement domain perspective etc. > CJ: not exactly. We do not deny complexity, as long as it is hidden to ou= r *customers*. > That is very interesting perspective. > CJ: I don't think there is a single answer to your comment. Let me give y= ou an example: within the context of our current inter- >domain VPN service offering, we need to request PE resources with peering = partners, in a bilateral fashion. The corresponding >negotiation remains paper- and fax- (yes fax)based, and I can tell you it = takes quite some time the get the proprer resources right, >let alone the CE-PE connection (especially in a dual homign context, depen= ding on the location of the PE routers and the customer >premises). Based upon an apporpriately-formatted CPP template, we believe = that the inherent complexity should be adequately >balanced by a dramatic improvement of the time-to-deliver the service, fro= m several weeks to a few days, if not hours. This will >have a dramatic impact on the overall cost. > Agreed above example as a clear use case with an obvious win. It was eye-opening for me to read. > CJ: NFV is part of the global SDN landscape from my perspective. This is = why we see information models and data (including >policy provisioning info= rmation) as a key component of what you call NFV. That said, I'm not convin= ced NFV can be applied to >each and every network capability you could thin= k of, depending on the nature of the service and the impact on the amount o= f >(configuration information) traffic that needs to be exchanged between the= control and the data planes, for example. I doubt it can be applied to every network capability, but: One thing i didnt comment on earlier was the 5 year "centralized control" plan ;-> I saw somewhere that in data centres it is 1-2 year before hardware is replaced. I would suspect this would affect your approach to "cost customization" would be very different compared to data centres. Wouldnt it then be logical you want your boxes from vendors to allow you to inject more network functions over their lifetime? This is what NFV is suggesting. > CJ: that's certainly important, this is clearly not a taboo, but this is = also something tht is not SDN-specific (at least as far asFT >Orange is con= cerned). > So you dont mind being locked-in as long as the vendor meets those requirements you specify? Vendor lock-in has been considered an SDN motivation from a sales perspecti= ve. The arguement goes something like this (at least for ForCES): allow an architecture that is _standard_ to evolve. It means you can buy different part from different competing vendors (instead of a mainframe from IBM you = buy a PC chasis from Vendor X, VGA card from Y, OS from Z, etc); the consumer being you benefits from cost reduction and no specific lock in (not entirely 100% given some OS vendors could still lock you in). > b) tends to run on these tiny cpus (to which you are locked until you buy= the next GodBox). > CJ; right, but we were actually discussing the fuzz around separated cont= rol and forwarding planes. We understand the SDN approach, but we'd appreci= ate a more specific/accurate wording for the sake of undertsnadability. > I think the way you expressed then sounded like you were dismissing the value of standardizing that part. cheers, jamal From hadi@mojatatu.com Wed Apr 10 13:39:06 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8676421F9359 for ; Wed, 10 Apr 2013 13:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.678 X-Spam-Level: X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIetLjV9bLhL for ; Wed, 10 Apr 2013 13:39:06 -0700 (PDT) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B342021F9356 for ; Wed, 10 Apr 2013 13:39:05 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id je9so459506bkc.5 for ; Wed, 10 Apr 2013 13:39:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to:cc :content-type:x-gm-message-state; bh=fArmTAf5fwSG+8noMWgzSWilFi8beshBIU7q6wbebEc=; b=oyVpfkoKb8peHS0izUCRkob0BCPOJmpnVzEE8eX6HVS70Q/w7pWxNF+8DCM+pVW9+N KacndYPbMlvRBzptpADr8Mo3koMhwW10vV07TkSDaAUwhYi1/mbk/fomvpxqRMAZxjsM vd3+G8AcvUbui0O4oAVmb7FH7naTQEv1xEtVoffuj75ypHLGFWPyMIW0+kHYxmkgazOI ajEc0PCYPIehjYjsc6qjfu1kk9ji9LMf+TdMgYvSieyPQ5FcxOmkCypXCD6+Jp8rol/Q fjA5zLN5iOKdWyT2dNgE0zQWohGGy6hV7YjvsBr6eLcE6FxCdYn/wmpmIgoIpQP3keIG 8Thw== X-Received: by 10.205.100.198 with SMTP id cx6mr1438656bkc.106.1365626344619; Wed, 10 Apr 2013 13:39:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.15.136 with HTTP; Wed, 10 Apr 2013 13:38:43 -0700 (PDT) From: Jamal Hadi Salim Date: Wed, 10 Apr 2013 16:38:43 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlK0mjNE3gVMWnW3n3C5UgYWsWMzA1PUzw19ylHxPCzoYQe1JhlLFHwgTM80FAVS7kzie+y Subject: [forces] Fwd: Re: Your recharter proposal X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 20:39:06 -0000 message was caught in the ether ---------- Forwarded message ---------- From: shares@ndzh.com To: "Haleplidis Evangelos" , forces-bounces@ietf.org, forces@ietf.org, "Adrian Farrel" , "'Jamal Hadi Salim'" , "'B.Khasnabish@ieee.org'" Cc: Date: Wed, 10 Apr 2013 18:58:13 +0000 Subject: Re: [forces] Your recharter proposal Halepdlidis and Adrian: +1. I fully support the charter revision. Hats odd to all who worked on it. Sue Hares Sent via BlackBerry by AT&T -----Original Message----- From: "Haleplidis Evangelos" Sender: forces-bounces@ietf.org Date: Sun, 7 Apr 2013 17:14:16 To: ; ; 'Jamal Hadi Salim'; 'B.Khasnabish@ieee.org' Subject: Re: [forces] Your recharter proposal _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces From adrian@olddog.co.uk Thu Apr 11 12:39:35 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE37E21F8BE4 for ; Thu, 11 Apr 2013 12:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4pYaRvc8Uam for ; Thu, 11 Apr 2013 12:39:35 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8C621F8A38 for ; Thu, 11 Apr 2013 12:39:34 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3BJdX7b012340 for ; Thu, 11 Apr 2013 20:39:34 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3BJdV75012322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 11 Apr 2013 20:39:33 +0100 From: "Adrian Farrel" To: Date: Thu, 11 Apr 2013 20:39:30 +0100 Message-ID: <03f501ce36ec$4a3852b0$dea8f810$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: Ac426+c6ypuzZRDJT+CXGyQK61uZcw== Subject: [forces] Next steps with ForCES charter X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 19:39:35 -0000 Hi, Thanks for the voices of support. I have put the charter in front of the IESG for review and they will comment on or before April 25th. Watch out for any mails on the topic and join in the discussions. Adrian From adrian@olddog.co.uk Thu Apr 11 14:26:52 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A622021F907E for ; Thu, 11 Apr 2013 14:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vvx5ppNcnCxp for ; Thu, 11 Apr 2013 14:26:52 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id BC97821F8A0B for ; Thu, 11 Apr 2013 14:26:51 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3BLQoY4017027; Thu, 11 Apr 2013 22:26:50 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3BLQnxF017005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Apr 2013 22:26:49 +0100 From: "Adrian Farrel" To: Date: Thu, 11 Apr 2013 22:26:48 +0100 Message-ID: <048e01ce36fb$46d1d150$d47573f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: Ac42+x5wLxpL/Mi4TIqpPBt+iiI+Yw== Cc: forces@ietf.org Subject: [forces] AD review of draft-ietf-forces-interop X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 21:26:52 -0000 Hi authors of draft-ietf-forces-interop, I have done my usual AD review of your document as part of processing the publication request. The intention of the review is to catch issues that might show up in IETF last call or IESG review and thereby improve the efficiency of those review stages. There are a few small issues that I would like you to address with a new revision. As always, my comments are open for discussion and disagreement. I have placed the document into "Revised I-D Needed" state in the datatracker until we resolve these small points. Thanks for the work, Adrian --- I believe the intention of this work is to provide supplementary information on top of that already contained in RFC 6053. In view of that, you are correct to state that this document updates RFC 6053. To achieve that smoothly you need to: - Add a piece of metadata to the top of the file to read: Updates: 6053 (if approved) (see http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ for an example) - Explain the update in the Abstract. I'd suggest... RFC 6053 reported the results of the first ForCES interoperability test, and this document updates RFC 6053 by providing further interoperability results. The additional context to the update that you give in the Introduction is perfect. --- I am worried by the references to two I-Ds. [I-D.ietf-forces-lfb-lib] and [I-D.ietf-forces-ceha] were I-Ds at the time of testing. There is no law against this, but it gives us a problem: The versions tested need to be pinned in time. For example, draft-ietf-forces-lfb-lib will probably be published as an RFC before your document becomes an RFC, but it would not be correct to say that you tested that RFC. So, I think you need some text talking about the draft versions tested and giving specific name to the drafts rather than just pointing at the citation. I can probably help you draft some text here, but I think that it would be quickest for you to try to write down what you tested, and then I can polish it. --- The references are all to pot! idnits shows this up clearly and you need to fix this before the draft can go forward. (The uses of IP addresses flagged by idnits are OK and do not need to be changed.) --- The use of RFC 2119 language is a problem and needs to be fixed. You are not defining protocol behavior in this document and do not need section 2.1 at all. Then you need to go through the document and clean up the upper case. If you are making a direct quote from another RFC, then please make it much clearer using indentation, quote marks, and by saying "As stated in [RFC1234]:" If you are not quoting, then you really can use lower case. But please be careful even then. What would it mean to say "An implementation must do this"? Would it really be the case that you mean: "We tested to see whether an implementation does this as required in section 1.2 or [RFC1234]"? --- I have a personal dislike of repeated definitions copied from other documents. They can cause all sorts of fun if you make a mistake when you copy the text! So I would prefer section 2.2. simply to point at the definitions from other RFCs. However, I think this is a matter of style, and I do not insist that you make this change. --- Section 3.1 says: Some errata related to ForCES document were found by the interoperability test. The errata has been reported to related IETF RFCs. This is great. IMHO it is a more valuable outcome than the rest of the work :-) If you can find a way to briefly list these or provide pointers to the errata reports, I think this would be really nice and would help validate all your hard work. From wmwang2001@hotmail.com Thu Apr 11 18:57:41 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E817621F861A for ; Thu, 11 Apr 2013 18:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DM0b-0dtd7ZB for ; Thu, 11 Apr 2013 18:57:41 -0700 (PDT) Received: from blu0-omc4-s24.blu0.hotmail.com (blu0-omc4-s24.blu0.hotmail.com [65.55.111.163]) by ietfa.amsl.com (Postfix) with ESMTP id EB7AC21F8615 for ; Thu, 11 Apr 2013 18:57:40 -0700 (PDT) Received: from BLU0-SMTP407 ([65.55.111.136]) by blu0-omc4-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Apr 2013 18:57:40 -0700 X-EIP: [7zBD3nHZ11r0W+ipsNnKz3vTkiVGWsoj] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([60.177.109.28]) by BLU0-SMTP407.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Apr 2013 18:57:38 -0700 From: "Wang,Weiming" To: , References: <048e01ce36fb$46d1d150$d47573f0$@olddog.co.uk> Date: Fri, 12 Apr 2013 09:57:42 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 12 Apr 2013 01:57:38.0697 (UTC) FILETIME=[1C346F90:01CE3721] Cc: forces@ietf.org Subject: Re: [forces] AD review of draft-ietf-forces-interop X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 01:57:42 -0000 SGkgQUQsIFNoZXBoZXJkLCBhdXRob2VycywgYW5kIGFsbCwNCg0KUGxlYXNlIGFsbG93IG1lIHRv IHJlcHJlc2VudCBhbGwgYXV0aG9ycyB0byB0aGFuayBBRCB2ZXJ5IG11Y2ggZm9yIHRoZSB2YWx1 YWJsZSByZXZpZXcuIEJlZm9yZSB3ZSBhY3R1YWxseSBiZWdpbiB0aGUgcmV2aXNpb24sIEknZCBs aWtlIHRvIGdpdmUgYSBxdWljayByZXNwb25zZSB0byBzb21lIGNvbW1lbnRzIGZpcnN0bHkuIA0K DQp0aGFua3MsDQpXZWltaW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9t OiAiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+DQoNCj4gSGkgYXV0aG9ycyBv ZiBkcmFmdC1pZXRmLWZvcmNlcy1pbnRlcm9wLA0KPiANCj4gSSBoYXZlIGRvbmUgbXkgdXN1YWwg QUQgcmV2aWV3IG9mIHlvdXIgZG9jdW1lbnQgYXMgcGFydCBvZiBwcm9jZXNzaW5nDQo+IHRoZSBw dWJsaWNhdGlvbiByZXF1ZXN0LiBUaGUgaW50ZW50aW9uIG9mIHRoZSByZXZpZXcgaXMgdG8gY2F0 Y2ggaXNzdWVzDQo+IHRoYXQgbWlnaHQgc2hvdyB1cCBpbiBJRVRGIGxhc3QgY2FsbCBvciBJRVNH IHJldmlldyBhbmQgdGhlcmVieQ0KPiBpbXByb3ZlIHRoZSBlZmZpY2llbmN5IG9mIHRob3NlIHJl dmlldyBzdGFnZXMuDQo+IA0KPiBUaGVyZSBhcmUgYSBmZXcgc21hbGwgaXNzdWVzIHRoYXQgSSB3 b3VsZCBsaWtlIHlvdSB0byBhZGRyZXNzIHdpdGggYQ0KPiBuZXcgcmV2aXNpb24uIEFzIGFsd2F5 cywgbXkgY29tbWVudHMgYXJlIG9wZW4gZm9yIGRpc2N1c3Npb24gYW5kDQo+IGRpc2FncmVlbWVu dC4NCj4gDQo+IEkgaGF2ZSBwbGFjZWQgdGhlIGRvY3VtZW50IGludG8gIlJldmlzZWQgSS1EIE5l ZWRlZCIgc3RhdGUgaW4gdGhlDQo+IGRhdGF0cmFja2VyIHVudGlsIHdlIHJlc29sdmUgdGhlc2Ug c21hbGwgcG9pbnRzLg0KPiANCj4gVGhhbmtzIGZvciB0aGUgd29yaywNCj4gQWRyaWFuDQo+IA0K PiAtLS0NCj4gDQo+IEkgYmVsaWV2ZSB0aGUgaW50ZW50aW9uIG9mIHRoaXMgd29yayBpcyB0byBw cm92aWRlIHN1cHBsZW1lbnRhcnkNCj4gaW5mb3JtYXRpb24gb24gdG9wIG9mIHRoYXQgYWxyZWFk eSBjb250YWluZWQgaW4gUkZDIDYwNTMuIEluIHZpZXcgb2YNCj4gdGhhdCwgeW91IGFyZSBjb3Jy ZWN0IHRvIHN0YXRlIHRoYXQgdGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQyA2MDUzLiBUbw0KPiBh Y2hpZXZlIHRoYXQgc21vb3RobHkgeW91IG5lZWQgdG86DQo+IA0KPiAtIEFkZCBhIHBpZWNlIG9m IG1ldGFkYXRhIHRvIHRoZSB0b3Agb2YgdGhlIGZpbGUgdG8gcmVhZDoNCj4gDQo+IFVwZGF0ZXM6 IDYwNTMgKGlmIGFwcHJvdmVkKQ0KPiANCj4gIChzZWUgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYvIGZvciBhbg0KPiAgIGV4YW1wbGUpDQo+ IA0KPiAtIEV4cGxhaW4gdGhlIHVwZGF0ZSBpbiB0aGUgQWJzdHJhY3QuIEknZCBzdWdnZXN0Li4u DQo+IA0KPiAgIFJGQyA2MDUzIHJlcG9ydGVkIHRoZSByZXN1bHRzIG9mIHRoZSBmaXJzdCBGb3JD RVMgaW50ZXJvcGVyYWJpbGl0eQ0KPiAgIHRlc3QsIGFuZCB0aGlzIGRvY3VtZW50IHVwZGF0ZXMg UkZDIDYwNTMgYnkgcHJvdmlkaW5nIGZ1cnRoZXINCj4gICBpbnRlcm9wZXJhYmlsaXR5IHJlc3Vs dHMuDQo+IA0KPiBUaGUgYWRkaXRpb25hbCBjb250ZXh0IHRvIHRoZSB1cGRhdGUgdGhhdCB5b3Ug Z2l2ZSBpbiB0aGUgSW50cm9kdWN0aW9uDQo+IGlzIHBlcmZlY3QuDQo+IA0KWWVzLCAgY2xlYXIg ZW5vdWdoIHRvIGRvLg0KPiAtLS0NCj4gDQo+IEkgYW0gd29ycmllZCBieSB0aGUgcmVmZXJlbmNl cyB0byB0d28gSS1Ecy4gW0ktRC5pZXRmLWZvcmNlcy1sZmItbGliXQ0KPiBhbmQgW0ktRC5pZXRm LWZvcmNlcy1jZWhhXSB3ZXJlIEktRHMgYXQgdGhlIHRpbWUgb2YgdGVzdGluZy4gIFRoZXJlIGlz DQo+IG5vIGxhdyBhZ2FpbnN0IHRoaXMsIGJ1dCBpdCBnaXZlcyB1cyBhIHByb2JsZW06DQo+IA0K PiBUaGUgdmVyc2lvbnMgdGVzdGVkIG5lZWQgdG8gYmUgcGlubmVkIGluIHRpbWUuIEZvciBleGFt cGxlLCANCj4gZHJhZnQtaWV0Zi1mb3JjZXMtbGZiLWxpYiB3aWxsIHByb2JhYmx5IGJlIHB1Ymxp c2hlZCBhcyBhbiBSRkMgYmVmb3JlDQo+IHlvdXIgZG9jdW1lbnQgYmVjb21lcyBhbiBSRkMsIGJ1 dCBpdCB3b3VsZCBub3QgYmUgY29ycmVjdCB0byBzYXkgdGhhdA0KPiB5b3UgdGVzdGVkIHRoYXQg UkZDLiBTbywgSSB0aGluayB5b3UgbmVlZCBzb21lIHRleHQgdGFsa2luZyBhYm91dCB0aGUNCj4g ZHJhZnQgdmVyc2lvbnMgdGVzdGVkIGFuZCBnaXZpbmcgc3BlY2lmaWMgbmFtZSB0byB0aGUgZHJh ZnRzIHJhdGhlciB0aGFuDQo+IGp1c3QgcG9pbnRpbmcgYXQgdGhlIGNpdGF0aW9uLg0KPiANCj4g SSBjYW4gcHJvYmFibHkgaGVscCB5b3UgZHJhZnQgc29tZSB0ZXh0IGhlcmUsIGJ1dCBJIHRoaW5r IHRoYXQgaXQgd291bGQgDQo+IGJlIHF1aWNrZXN0IGZvciB5b3UgdG8gdHJ5IHRvIHdyaXRlIGRv d24gd2hhdCB5b3UgdGVzdGVkLCBhbmQgdGhlbiBJIGNhbg0KPiBwb2xpc2ggaXQuDQo+IA0KSSB0 aGluayB0aGlzIGlzIHRoZSBrZXkgaXNzdWUgcmFpc2VkLiBJIGFncmVlIHdlbGwgd2hhdCBBRCBz dWdnZXN0LCBpLmUuLCB0byBhZGQgYSB0ZXh0IHRvIG1lbnRpb24gdGhlIGlzc3VlLCB3aGljaCBt YXkgbG9vayBsaWtlOiAgDQoNCiAgICAuLi4uLi4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC4uLi4gICAgIFRoZSB0ZXN0IGludm9sdmVkIHNldmVy YWwNCiAgIGRvY3VtZW50cyBuYW1lbHk6IEZvckNFUyBwcm90b2NvbCBbUkZDNTgxMF0gLCBGb3JD RVMgRkUgbW9kZWwNCiAgIFtSRkM1ODEyXSAsIEZvckNFUyBUTUwgW1JGQzU4MTFdICwgRm9yQ0VT IExGQiBMaWJyYXJ5DQogICBbUkZDID8/Pz9dIGFuZCBGb3JDRVMgQ0UgSEEgc3BlY2lmaWNhdGlv bg0KICAgW0ktRC5pZXRmLWZvcmNlcy1jZWhhXS4gIFRocmVlIGluZGVwZW5kZW50IEZvckNFUyBp bXBsZW1lbnRhdGlvbnMNCiAgIHBhcnRpY2lwYXRlZCBpbiB0aGUgdGVzdC4NCg0KICAgTm90ZSB0 aGF0LCB3aGVuIHRoZSBpbnRlcm9wZXJhYmlsaXR5IHRleHQgaGFwcGVuZWQsIHRoZSBGb3JDRVMg TEZCIExpYnJhcnkgZG9jdW1lbnQgW1JGQyA/Pz8/XSB3YXMgc3RpbGwgaW4gcHJvZ3Jlc3Mgb2Yg aXRzIGludGVybmV0LWRyYWZ0IHVwZGF0ZXMsIGFuZCB0aGlzIHRlc3QgdGFyZ2V0cyBhdCB2MDMg dXBkYXRlIG9mIHRoZSBkb2N1bWVudCwgd2hpY2ggY2FuIGJlIGFjY2Vzc2VkIGF0IFsuLi4uLl0u IFRoZSB0ZXN0IHRvIEZvckNFUyBDRSBIQSBkb2N1bWVudCB0YXJnZXRzIGF0IHRoZSBpbnRlcm5l dC1kcmFmdCB2MDAgWy4uLi4uXS4gDQoNCi0tLS0tLS0tLS0tLS0tDQpJIG5vdyBoYXZlIG1vcmUg cXVlc3Rpb24gdGhhdCwgaWYgd2Ugc2hvdWxkIHBvaW50IG91dCB0aGUgZGVmZXJlbmNlIGJldHdl ZW4gdGhlIHRlc3RlZCB2ZXJzaW9uIGFuZCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkb2N1 bWVudD8gT3IsIHNoYWxsIHdlIGFsc28gbWVudGlvbiB3aGF0IHRlc3RlZCBpcyBzdGlsbCBvciBu b3QgaW4gZXhpc3RlbnNlIGluIGN1cnJlbnQgdmVyc2lvbiwgb3Igd2hhdCBjaGFuZ2UgaGFzIGhh cHBlbmVkPyANCg0KSSBkbyBob3BlIGF1dGhvcnMgY2FuIHNob3cgeW91ciBzdWdnZXN0aW9ucyB0 byBzb2x2ZSB0aGUgaXNzdWUuDQoNCj4gLS0tDQo+IA0KPiBUaGUgcmVmZXJlbmNlcyBhcmUgYWxs IHRvIHBvdCEgaWRuaXRzIHNob3dzIHRoaXMgdXAgY2xlYXJseSBhbmQgeW91IG5lZWQNCj4gdG8g Zml4IHRoaXMgYmVmb3JlIHRoZSBkcmFmdCBjYW4gZ28gZm9yd2FyZC4NCj4gDQo+IChUaGUgdXNl cyBvZiBJUCBhZGRyZXNzZXMgZmxhZ2dlZCBieSBpZG5pdHMgYXJlIE9LIGFuZCBkbyBub3QgbmVl ZCB0byBiZQ0KPiBjaGFuZ2VkLikNCj4gDQpTdXJlLCB0aGFua3MuDQo+IC0tLQ0KPiANCj4gVGhl IHVzZSBvZiBSRkMgMjExOSBsYW5ndWFnZSBpcyBhIHByb2JsZW0gYW5kIG5lZWRzIHRvIGJlIGZp eGVkLiANCj4gDQo+IFlvdSBhcmUgbm90IGRlZmluaW5nIHByb3RvY29sIGJlaGF2aW9yIGluIHRo aXMgZG9jdW1lbnQgYW5kIGRvIG5vdCBuZWVkDQo+IHNlY3Rpb24gMi4xIGF0IGFsbC4gDQo+IA0K PiBUaGVuIHlvdSBuZWVkIHRvIGdvIHRocm91Z2ggdGhlIGRvY3VtZW50IGFuZCBjbGVhbiB1cCB0 aGUgdXBwZXIgY2FzZS4gSWYNCj4geW91IGFyZSBtYWtpbmcgYSBkaXJlY3QgcXVvdGUgZnJvbSBh bm90aGVyIFJGQywgdGhlbiBwbGVhc2UgbWFrZSBpdCBtdWNoDQo+IGNsZWFyZXIgdXNpbmcgaW5k ZW50YXRpb24sIHF1b3RlIG1hcmtzLCBhbmQgYnkgc2F5aW5nDQo+ICAgIkFzIHN0YXRlZCBpbiBb UkZDMTIzNF06Ig0KPiANCj4gSWYgeW91IGFyZSBub3QgcXVvdGluZywgdGhlbiB5b3UgcmVhbGx5 IGNhbiB1c2UgbG93ZXIgY2FzZS4gQnV0IHBsZWFzZSANCj4gYmUgY2FyZWZ1bCBldmVuIHRoZW4u IFdoYXQgd291bGQgaXQgbWVhbiB0byBzYXkgIkFuIGltcGxlbWVudGF0aW9uIG11c3QNCj4gZG8g dGhpcyI/IFdvdWxkIGl0IHJlYWxseSBiZSB0aGUgY2FzZSB0aGF0IHlvdSBtZWFuOiAiV2UgdGVz dGVkIHRvIHNlZQ0KPiB3aGV0aGVyIGFuIGltcGxlbWVudGF0aW9uIGRvZXMgdGhpcyBhcyByZXF1 aXJlZCBpbiBzZWN0aW9uIDEuMiBvciANCj4gW1JGQzEyMzRdIj8NCj4gDQo+IC0tLQ0KPiANCj4g SSBoYXZlIGEgcGVyc29uYWwgZGlzbGlrZSBvZiByZXBlYXRlZCBkZWZpbml0aW9ucyBjb3BpZWQg ZnJvbSBvdGhlciANCj4gZG9jdW1lbnRzLiBUaGV5IGNhbiBjYXVzZSBhbGwgc29ydHMgb2YgZnVu IGlmIHlvdSBtYWtlIGEgbWlzdGFrZSB3aGVuDQo+IHlvdSBjb3B5IHRoZSB0ZXh0ISAgU28gSSB3 b3VsZCBwcmVmZXIgc2VjdGlvbiAyLjIuIHNpbXBseSB0byBwb2ludCBhdCANCj4gdGhlIGRlZmlu aXRpb25zIGZyb20gb3RoZXIgUkZDcy4NCj4gDQo+IEhvd2V2ZXIsIEkgdGhpbmsgdGhpcyBpcyBh IG1hdHRlciBvZiBzdHlsZSwgYW5kIEkgZG8gbm90IGluc2lzdCB0aGF0DQo+IHlvdSBtYWtlIHRo aXMgY2hhbmdlLg0KWWVzLCBJIGFncmVlLiAgSWhlIGR1cGxpY2F0aW9uIG9mIGRlZmluaXRpb25z IGlzIG5vdCBhbHdheXMgbmVjZXNzYXJ5IGVzcGVjaWFsbHkgZm9yIGFuIGluZm9ybWF0aW9uYWwg UkZDIGRvY3VtZW50LiANCg0KPiANCj4gLS0tDQo+IA0KPiBTZWN0aW9uIDMuMSBzYXlzOg0KPiAN Cj4gICBTb21lIGVycmF0YSByZWxhdGVkIHRvIEZvckNFUyBkb2N1bWVudCB3ZXJlIGZvdW5kIGJ5 IHRoZQ0KPiAgIGludGVyb3BlcmFiaWxpdHkgdGVzdC4gIFRoZSBlcnJhdGEgaGFzIGJlZW4gcmVw b3J0ZWQgdG8gcmVsYXRlZCBJRVRGDQo+ICAgUkZDcy4NCj4gDQo+IFRoaXMgaXMgZ3JlYXQuIElN SE8gaXQgaXMgYSBtb3JlIHZhbHVhYmxlIG91dGNvbWUgdGhhbiB0aGUgcmVzdCBvZiB0aGUNCj4g d29yayA6LSkgSWYgeW91IGNhbiBmaW5kIGEgd2F5IHRvIGJyaWVmbHkgbGlzdCB0aGVzZSBvciBw cm92aWRlIHBvaW50ZXJzDQo+IHRvIHRoZSBlcnJhdGEgcmVwb3J0cywgSSB0aGluayB0aGlzIHdv dWxkIGJlIHJlYWxseSBuaWNlIGFuZCB3b3VsZCBoZWxwDQo+IHZhbGlkYXRlIGFsbCB5b3VyIGhh cmQgd29yay4NClN1cmUsIHdlIGF1dGhvcnMgd2lsbCByZWNhbGwgYW5kIGNoZWNrIGJhY2sgdGhl IGxpc3QgYW5kIGFkZCB0ZXh0IGluIHRoZSBkcmFmdC4NCg0KdGhhbmtzIGFnYWluLg0KV2VpbWlu Zw0KDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBmb3JjZXMgbWFpbGluZyBsaXN0DQo+IGZvcmNlc0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcw== From hadi@mojatatu.com Fri Apr 12 05:53:44 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A3021F8533 for ; Fri, 12 Apr 2013 05:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZZ7qVsGcQeL for ; Fri, 12 Apr 2013 05:53:44 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD5621F8528 for ; Fri, 12 Apr 2013 05:53:43 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id pb11so2340045veb.6 for ; Fri, 12 Apr 2013 05:53:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=bz4oJRt1AAfAVfw17kLsoOu+4eJ91Z3OIbj+ULHEiR4=; b=OQ9293WJpOK2purBbU6xLRhxqlBLaZjPMNqIQlGodUmMveL8Pftm6XhXrKKd5g0LlB 88l4Oa3WsuZzoWxN5yIrANFYnCr6bQNAtP+LRni0ws40xJkjuT0vOoXbPDK6zebZgWza NeiQO2jm3KciRbZHiHMILmKrBIe6RYA3U7XUksBKzllmBJMNAtqOqGnxOaoCy8Igws+i oTsZqjQ8YGVcxe81ramACx46qw2Rlwr4HXlYUKvg7/Afm8n+EiuX//Ky7ROaDR9uU8Rj 8HVNeK4EVWBmWiPs3NPMs8BpKgsShI+zpE2ii83m2TW4G1enPe2V+eEM7T15B8hdav/A w9Ew== X-Received: by 10.52.119.175 with SMTP id kv15mr7004965vdb.23.1365771223502; Fri, 12 Apr 2013 05:53:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.24.137 with HTTP; Fri, 12 Apr 2013 05:53:23 -0700 (PDT) In-Reply-To: References: <048e01ce36fb$46d1d150$d47573f0$@olddog.co.uk> From: Jamal Hadi Salim Date: Fri, 12 Apr 2013 08:53:23 -0400 Message-ID: To: "Wang,Weiming" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlCrCT084mUGR77Pl/Q56tISmGyK798cllKEHjn3ERBVcHno/ZSNh853ZyU/tlOe6nL7sI5 Cc: forces@ietf.org, draft-ietf-forces-interop@tools.ietf.org Subject: Re: [forces] AD review of draft-ietf-forces-interop X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 12:53:44 -0000 On Thu, Apr 11, 2013 at 9:57 PM, Wang,Weiming wrote: > -------------- > I now have more question that, if we should point out the deference between the tested version and the current version of the document? Or, shall we also mention what tested is still or not in existense in current version, or what change has happened? > > I do hope authors can show your suggestions to solve the issue. > I think we point to the RFCs, if they exist and mention specific versions of the drafts pre-RFC. I am not sure if the xml will allow you to use obsoleted documents as references; and if you reference them - whether they are guaranteed to be accessible when someone needs to reference them. Example, in 2 years from now, will someone be able to access ceha draft version 3 on the ietf web site? Since the AD has graciously offered to come up with some language, why dont we let him do that for us? >> I have a personal dislike of repeated definitions copied from other >> documents. They can cause all sorts of fun if you make a mistake when >> you copy the text! So I would prefer section 2.2. simply to point at >> the definitions from other RFCs. >> Agreed in this case. In general I have the opposite taste ;-> I would rather have the context in place so i can correlate instead of going and reading some other doc elsewhere. [Yes, one could make a mistake in copying. But also one could fix previously erronous and provide more extended information such as the CEHA document does when it provides context for HA derived from RFC 5810.] cheers, jamal From joel@stevecrocker.com Fri Apr 12 05:56:34 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0775421F891D for ; Fri, 12 Apr 2013 05:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, J_CHICKENPOX_47=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBX39I3ZG5dY for ; Fri, 12 Apr 2013 05:56:33 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7A63421F890D for ; Fri, 12 Apr 2013 05:56:33 -0700 (PDT) Received: from dummy.name; Fri, 12 Apr 2013 12:56:32 +0000 Message-ID: <5168047E.3060200@stevecrocker.com> Date: Fri, 12 Apr 2013 08:56:30 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jamal Hadi Salim References: <048e01ce36fb$46d1d150$d47573f0$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org, draft-ietf-forces-interop@tools.ietf.org Subject: Re: [forces] AD review of draft-ietf-forces-interop X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 12:56:34 -0000 Yes, we consider old versions of I-D's to be referencable for this sort of document. They are sufficiently stable. (Nothing is forever, but the current IETF operating policy is that all old versins remain accessible.) Yours, Joel On 4/12/2013 8:53 AM, Jamal Hadi Salim wrote: > On Thu, Apr 11, 2013 at 9:57 PM, Wang,Weiming wrote: > > >> -------------- >> I now have more question that, if we should point out the deference between the tested version and the current version of the document? Or, shall we also mention what tested is still or not in existense in current version, or what change has happened? >> >> I do hope authors can show your suggestions to solve the issue. >> > > I think we point to the RFCs, if they exist and mention specific versions > of the drafts pre-RFC. I am not sure if the xml will allow you to use obsoleted > documents as references; and if you reference them - whether they are > guaranteed > to be accessible when someone needs to reference them. Example, in 2 years > from now, will someone be able to access ceha draft version 3 on the ietf > web site? > > Since the AD has graciously offered to come up with some language, why > dont we let him do that for us? > > >>> I have a personal dislike of repeated definitions copied from other >>> documents. They can cause all sorts of fun if you make a mistake when >>> you copy the text! So I would prefer section 2.2. simply to point at >>> the definitions from other RFCs. >>> > > Agreed in this case. > In general I have the opposite taste ;-> I would rather have the > context in place > so i can correlate instead of going and reading some other doc elsewhere. > [Yes, one could make a mistake in copying. But also one could fix previously > erronous and provide more extended information such as the CEHA document > does when it provides context for HA derived from RFC 5810.] > > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From adrian@olddog.co.uk Sun Apr 14 05:52:21 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD67921F90A1 for ; Sun, 14 Apr 2013 05:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzh3bDuFIaoJ for ; Sun, 14 Apr 2013 05:52:21 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id AE06921F909A for ; Sun, 14 Apr 2013 05:52:20 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3ECqI2p022018; Sun, 14 Apr 2013 13:52:19 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3ECqH4T022012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 14 Apr 2013 13:52:18 +0100 From: "Adrian Farrel" To: "'Jamal Hadi Salim'" , "'Wang,Weiming'" References: <048e01ce36fb$46d1d150$d47573f0$@olddog.co.uk> In-Reply-To: Date: Sun, 14 Apr 2013 13:52:15 +0100 Message-ID: <082101ce390e$e42be390$ac83aab0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQEkncNfNjZrxNnHTyVnOTiJbUQJFgHbzG0AAoXRV+SaA3FKgA== Cc: forces@ietf.org, draft-ietf-forces-interop@tools.ietf.org Subject: Re: [forces] AD review of draft-ietf-forces-interop X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 12:52:22 -0000 Hi all, > > I now have more question that, if we should point out the deference > > between the tested version and the current version of the document? > > Or, shall we also mention what tested is still or not in existense in > > current version, or what change has happened? > > > > I do hope authors can show your suggestions to solve the issue. > > I think we point to the RFCs, if they exist and mention specific versions > of the drafts pre-RFC. I am not sure if the xml will allow you to use obsoleted > documents as references; and if you reference them - whether they are > guaranteed to be accessible when someone needs to reference them. > Example, in 2 years from now, will someone be able to access ceha draft > version 3 on the ietf web site? I think it is really important to reference them. Like Joel says (and unlike what the boilerplate says;-) I-ds seem to persist on the interweb for ever. You shouldn't put them in as normative references, but you should put them in as specific numbered and dated version. I would also recommend adding an RFC editor note for each one as follows: OLD [I-D.ietf-forces-ceha] Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES Intra-NE High Availability", draft-ietf-forces-ceha-05 (work in progress), January 2013. [I-D.ietf-forces-lfb-lib] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. Halpern, "ForCES Logical Function Block (LFB) Library", draft-ietf-forces-lfb-lib-10 (work in progress), January 2013. NEW [I-D.ietf-forces-ceha-00] Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES Intra-NE High Availability", draft-ietf-forces-ceha-00, October 2010, work in progress. [RFC Editor Note. This reference is intended to indicate a specific version of an Internet-Draft that was used during interop testing. Please Do NOT update this reference to a more recent version of the draft or to an RFC. Please remove this note before publication.] [I-D.ietf-forces-lfb-lib-03] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. Halpern, "ForCES Logical Function Block (LFB) Library", draft-ietf-forces-lfb-lib-03, December 2010, work in progress. [RFC Editor Note. This reference is intended to indicate a specific version of an Internet-Draft that was used during interop testing. Please Do NOT update this reference to a more recent version of the draft or to an RFC. Please remove this note before publication.] END > Since the AD has graciously offered to come up with some language, why > dont we let him do that for us? OK, here we go... OLD This document captures results of the second interoperability test of the Forwarding and Control Element Separation (ForCES) which took place February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. The test involved several documents namely: ForCES protocol [RFC5810] , ForCES FE model [RFC5812] , ForCES TML [RFC5811] , ForCES LFB Library [I-D.ietf-forces-lfb-lib] and ForCES CE HA specification [I-D.ietf-forces-ceha]. Three independent ForCES implementations participated in the test. NEW This document captures results of the second interoperability test of the Forwarding and Control Element Separation (ForCES) which took place February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. The test involved protocol elements described in several documents namely: - The ForCES protocol [RFC5810] - The ForCES Forwarding Element model [RFC5812] - The ForCES Transport Mapping Layer [RFC5811]. The test also involved protocol elements described in the then- current versions of two Internet-Drafts. Although these documents have subsequently been revised and advanced, it is important to understand which versions of the work were used during this test. - ForCES Logical Function Block Library [I-D.ietf-forces-lfb-lib-03] - ForCES Intra-Network Element High Availability specification [I-D.ietf-forces-ceha-00]. Three independent ForCES implementations participated in the test. END > >> I have a personal dislike of repeated definitions copied from other > >> documents. They can cause all sorts of fun if you make a mistake when > >> you copy the text! So I would prefer section 2.2. simply to point at > >> the definitions from other RFCs. > > > > Agreed in this case. > > In general I have the opposite taste ;-> I would rather have the > context in place so i can correlate instead of going and reading > some other doc elsewhere. > [Yes, one could make a mistake in copying. But also one could fix previously > erronous and provide more extended information such as the CEHA document > does when it provides context for HA derived from RFC 5810.] Like I said, I'll let y'all decide what to do here since I don't feel strongly enough. Can I just note, however, that if you are "fixing" a definition that is already in a published RFC, you are creating a nice little mess unless you also fix the definition in the RFC. That fix could be through an Errata Report for a typographical error, or by updating the published RFC. But simply publishing a new RFC with a different definition is not a good idea. And one other thing: Weiming's initial response didn't include any response to my issues with RFC 2119 language. Once again, thanks for all the work. Cheers, Adrian From wmwang2001@hotmail.com Mon Apr 15 05:17:28 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670A021F9393 for ; Mon, 15 Apr 2013 05:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSBeK5MVX9Q1 for ; Mon, 15 Apr 2013 05:17:27 -0700 (PDT) Received: from blu0-omc4-s27.blu0.hotmail.com (blu0-omc4-s27.blu0.hotmail.com [65.55.111.166]) by ietfa.amsl.com (Postfix) with ESMTP id 4749321F9380 for ; Mon, 15 Apr 2013 05:17:26 -0700 (PDT) Received: from BLU0-SMTP234 ([65.55.111.135]) by blu0-omc4-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Apr 2013 05:17:25 -0700 X-EIP: [3t30gtUmJY65DxdEwh4IobzuH5chVmu5] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([183.156.119.53]) by BLU0-SMTP234.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Apr 2013 05:17:06 -0700 From: "Wang,Weiming" To: , "'Jamal Hadi Salim'" References: <048e01ce36fb$46d1d150$d47573f0$@olddog.co.uk> <082101ce390e$e42be390$ac83aab0$@olddog.co.uk> Date: Mon, 15 Apr 2013 20:16:59 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02BE_01CE3A16.2F59D130" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 15 Apr 2013 12:17:07.0207 (UTC) FILETIME=[259A3970:01CE39D3] Cc: forces@ietf.org, draft-ietf-forces-interop@tools.ietf.org Subject: Re: [forces] AD review of draft-ietf-forces-interop X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 12:17:28 -0000 ------=_NextPart_000_02BE_01CE3A16.2F59D130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgQWRyaWFuIGFuZCBhbGwsDQoNCkkgdGhpbmsgbW9zdCBvZiB0aGUgaXNzdWVzIHJhaXNlZCBi eSBBRCBhcmUgYmVlbiBhZGRyZXNzZWQgYW5kIHdlIGFyZSBnb2luZyB0byBmb3JtIGEgbmV3IDA3 IHZlcnNpb24gdmVyeSBzb29uLiBUaGUgMDcgYmV0YSB2ZXJzaW9uIGFuZCBhIGRpZmYgZmlsZSB0 byB2MDYgaW4gdGhlIGF0dGFjaG1lbnQgYXJlIGZvciB5b3VyIHJldmlldyBhZ2Fpbi4NCg0KdGhh bmtzIHZlcnkgbXVjaC4NCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAN CkZyb206ICJBZHJpYW4gRmFycmVsIiA8YWRyaWFuQG9sZGRvZy5jby51az4NCg0KPiBIaSBhbGws DQo+IA0KPj4gPiBJIG5vdyBoYXZlIG1vcmUgcXVlc3Rpb24gdGhhdCwgaWYgd2Ugc2hvdWxkIHBv aW50IG91dCB0aGUgZGVmZXJlbmNlDQo+PiA+IGJldHdlZW4gdGhlIHRlc3RlZCB2ZXJzaW9uIGFu ZCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudD8NCj4+ID4gT3IsIHNoYWxsIHdl IGFsc28gbWVudGlvbiB3aGF0IHRlc3RlZCBpcyBzdGlsbCBvciBub3QgaW4gZXhpc3RlbnNlIGlu DQo+PiA+IGN1cnJlbnQgdmVyc2lvbiwgb3Igd2hhdCBjaGFuZ2UgaGFzIGhhcHBlbmVkPw0KPj4g Pg0KPj4gPiBJIGRvIGhvcGUgYXV0aG9ycyBjYW4gc2hvdyB5b3VyIHN1Z2dlc3Rpb25zIHRvIHNv bHZlIHRoZSBpc3N1ZS4NCj4+IA0KPj4gSSB0aGluayB3ZSBwb2ludCB0byB0aGUgUkZDcywgaWYg dGhleSBleGlzdCBhbmQgbWVudGlvbiBzcGVjaWZpYyB2ZXJzaW9ucw0KPj4gb2YgdGhlIGRyYWZ0 cyBwcmUtUkZDLiBJIGFtIG5vdCBzdXJlIGlmIHRoZSB4bWwgd2lsbCBhbGxvdyB5b3UgdG8gdXNl DQo+IG9ic29sZXRlZA0KPj4gZG9jdW1lbnRzIGFzIHJlZmVyZW5jZXM7IGFuZCBpZiB5b3UgcmVm ZXJlbmNlIHRoZW0gLSB3aGV0aGVyIHRoZXkgYXJlDQo+PiBndWFyYW50ZWVkIHRvIGJlIGFjY2Vz c2libGUgd2hlbiBzb21lb25lIG5lZWRzIHRvIHJlZmVyZW5jZSB0aGVtLiANCj4+IEV4YW1wbGUs IGluIDIgeWVhcnMgZnJvbSBub3csIHdpbGwgc29tZW9uZSBiZSBhYmxlIHRvIGFjY2VzcyBjZWhh IGRyYWZ0DQo+PiB2ZXJzaW9uIDMgb24gdGhlIGlldGYgd2ViIHNpdGU/DQo+IA0KPiBJIHRoaW5r IGl0IGlzIHJlYWxseSBpbXBvcnRhbnQgdG8gcmVmZXJlbmNlIHRoZW0uIExpa2UgSm9lbCBzYXlz IChhbmQgdW5saWtlDQo+IHdoYXQgdGhlIGJvaWxlcnBsYXRlIHNheXM7LSkgSS1kcyBzZWVtIHRv IHBlcnNpc3Qgb24gdGhlIGludGVyd2ViIGZvciBldmVyLiBZb3UNCj4gc2hvdWxkbid0IHB1dCB0 aGVtIGluIGFzIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCBidXQgeW91IHNob3VsZCBwdXQgdGhlbSBp biBhcw0KPiBzcGVjaWZpYyBudW1iZXJlZCBhbmQgZGF0ZWQgdmVyc2lvbi4gSSB3b3VsZCBhbHNv IHJlY29tbWVuZCBhZGRpbmcgYW4gUkZDIGVkaXRvcg0KPiBub3RlIGZvciBlYWNoIG9uZSBhcyBm b2xsb3dzOg0KPiANCj4gT0xEDQo+ICAgW0ktRC5pZXRmLWZvcmNlcy1jZWhhXQ0KPiAgICAgICAg ICAgICAgT2dhd2EsIEsuLCBXYW5nLCBXLiwgSGFsZXBsaWRpcywgRS4sIGFuZCBKLiBTYWxpbSwg IkZvckNFUw0KPiAgICAgICAgICAgICAgSW50cmEtTkUgSGlnaCBBdmFpbGFiaWxpdHkiLCBkcmFm dC1pZXRmLWZvcmNlcy1jZWhhLTA1DQo+ICAgICAgICAgICAgICAod29yayBpbiBwcm9ncmVzcyks IEphbnVhcnkgMjAxMy4NCj4gDQo+ICAgW0ktRC5pZXRmLWZvcmNlcy1sZmItbGliXQ0KPiAgICAg ICAgICAgICAgV2FuZywgVy4sIEhhbGVwbGlkaXMsIEUuLCBPZ2F3YSwgSy4sIExpLCBDLiwgYW5k IEouDQo+ICAgICAgICAgICAgICBIYWxwZXJuLCAiRm9yQ0VTIExvZ2ljYWwgRnVuY3Rpb24gQmxv Y2sgKExGQikgTGlicmFyeSIsDQo+ICAgICAgICAgICAgICBkcmFmdC1pZXRmLWZvcmNlcy1sZmIt bGliLTEwICh3b3JrIGluIHByb2dyZXNzKSwNCj4gICAgICAgICAgICAgIEphbnVhcnkgMjAxMy4N Cj4gTkVXDQo+ICAgW0ktRC5pZXRmLWZvcmNlcy1jZWhhLTAwXQ0KPiAgICAgICAgICAgICAgT2dh d2EsIEsuLCBXYW5nLCBXLiwgSGFsZXBsaWRpcywgRS4sIGFuZCBKLiBTYWxpbSwgIkZvckNFUw0K PiAgICAgICAgICAgICAgSW50cmEtTkUgSGlnaCBBdmFpbGFiaWxpdHkiLCBkcmFmdC1pZXRmLWZv cmNlcy1jZWhhLTAwLA0KPiAgICAgICAgICAgICAgT2N0b2JlciAyMDEwLCB3b3JrIGluIHByb2dy ZXNzLg0KPiAgICAgICAgICAgICAgW1JGQyBFZGl0b3IgTm90ZS4gVGhpcyByZWZlcmVuY2UgaXMg aW50ZW5kZWQgdG8gaW5kaWNhdGUgYQ0KPiAgICAgICAgICAgICAgc3BlY2lmaWMgdmVyc2lvbiBv ZiBhbiBJbnRlcm5ldC1EcmFmdCB0aGF0IHdhcyB1c2VkIGR1cmluZw0KPiAgICAgICAgICAgICAg aW50ZXJvcCB0ZXN0aW5nLiBQbGVhc2UgRG8gTk9UIHVwZGF0ZSB0aGlzIHJlZmVyZW5jZSB0byBh IA0KPiAgICAgICAgICAgICAgbW9yZSByZWNlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgb3IgdG8g YW4gUkZDLiBQbGVhc2UNCj4gICAgICAgICAgICAgIHJlbW92ZSB0aGlzIG5vdGUgYmVmb3JlIHB1 YmxpY2F0aW9uLl0NCj4gDQo+ICAgW0ktRC5pZXRmLWZvcmNlcy1sZmItbGliLTAzXQ0KPiAgICAg ICAgICAgICAgV2FuZywgVy4sIEhhbGVwbGlkaXMsIEUuLCBPZ2F3YSwgSy4sIExpLCBDLiwgYW5k IEouDQo+ICAgICAgICAgICAgICBIYWxwZXJuLCAiRm9yQ0VTIExvZ2ljYWwgRnVuY3Rpb24gQmxv Y2sgKExGQikgTGlicmFyeSIsDQo+ICAgICAgICAgICAgICBkcmFmdC1pZXRmLWZvcmNlcy1sZmIt bGliLTAzLCBEZWNlbWJlciAyMDEwLCB3b3JrIGluIA0KPiAgICAgICAgICAgICAgcHJvZ3Jlc3Mu DQo+ICAgICAgICAgICAgICANCj4gICAgICAgICAgICAgIFtSRkMgRWRpdG9yIE5vdGUuIFRoaXMg cmVmZXJlbmNlIGlzIGludGVuZGVkIHRvIGluZGljYXRlIGENCj4gICAgICAgICAgICAgIHNwZWNp ZmljIHZlcnNpb24gb2YgYW4gSW50ZXJuZXQtRHJhZnQgdGhhdCB3YXMgdXNlZCBkdXJpbmcNCj4g ICAgICAgICAgICAgIGludGVyb3AgdGVzdGluZy4gUGxlYXNlIERvIE5PVCB1cGRhdGUgdGhpcyBy ZWZlcmVuY2UgdG8gYSANCj4gICAgICAgICAgICAgIG1vcmUgcmVjZW50IHZlcnNpb24gb2YgdGhl IGRyYWZ0IG9yIHRvIGFuIFJGQy4gUGxlYXNlDQo+ICAgICAgICAgICAgICByZW1vdmUgdGhpcyBu b3RlIGJlZm9yZSBwdWJsaWNhdGlvbi5dDQo+IEVORA0KPiANCj4+IFNpbmNlIHRoZSBBRCBoYXMg Z3JhY2lvdXNseSBvZmZlcmVkIHRvIGNvbWUgdXAgd2l0aCBzb21lIGxhbmd1YWdlLCB3aHkNCj4+ IGRvbnQgd2UgbGV0IGhpbSBkbyB0aGF0IGZvciB1cz8NCj4gDQo+IE9LLCBoZXJlIHdlIGdvLi4u DQo+IA0KPiBPTEQgICANCj4gICBUaGlzIGRvY3VtZW50IGNhcHR1cmVzIHJlc3VsdHMgb2YgdGhl IHNlY29uZCBpbnRlcm9wZXJhYmlsaXR5IHRlc3Qgb2YNCj4gICB0aGUgRm9yd2FyZGluZyBhbmQg Q29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gKEZvckNFUykgd2hpY2ggdG9vaw0KPiAgIHBsYWNl IEZlYnJ1YXJ5IDI0LTI1LCAyMDExIGluIHRoZSBJbnRlcm5ldCBUZWNobm9sb2d5IExhYiAoSVRM KSBvZg0KPiAgIFpoZWppYW5nIEdvbmdzaGFuZyBVbml2ZXJzaXR5LCBDaGluYS4gIFRoZSB0ZXN0 IGludm9sdmVkIHNldmVyYWwNCj4gICBkb2N1bWVudHMgbmFtZWx5OiBGb3JDRVMgcHJvdG9jb2wg W1JGQzU4MTBdICwgRm9yQ0VTIEZFIG1vZGVsDQo+ICAgW1JGQzU4MTJdICwgRm9yQ0VTIFRNTCBb UkZDNTgxMV0gLCBGb3JDRVMgTEZCIExpYnJhcnkNCj4gICBbSS1ELmlldGYtZm9yY2VzLWxmYi1s aWJdIGFuZCBGb3JDRVMgQ0UgSEEgc3BlY2lmaWNhdGlvbg0KPiAgIFtJLUQuaWV0Zi1mb3JjZXMt Y2VoYV0uICBUaHJlZSBpbmRlcGVuZGVudCBGb3JDRVMgaW1wbGVtZW50YXRpb25zDQo+ICAgcGFy dGljaXBhdGVkIGluIHRoZSB0ZXN0Lg0KPiBORVcNCj4gICBUaGlzIGRvY3VtZW50IGNhcHR1cmVz IHJlc3VsdHMgb2YgdGhlIHNlY29uZCBpbnRlcm9wZXJhYmlsaXR5IHRlc3Qgb2YNCj4gICB0aGUg Rm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gKEZvckNFUykgd2hpY2gg dG9vaw0KPiAgIHBsYWNlIEZlYnJ1YXJ5IDI0LTI1LCAyMDExIGluIHRoZSBJbnRlcm5ldCBUZWNo bm9sb2d5IExhYiAoSVRMKSBvZg0KPiAgIFpoZWppYW5nIEdvbmdzaGFuZyBVbml2ZXJzaXR5LCBD aGluYS4gIFRoZSB0ZXN0IGludm9sdmVkIHByb3RvY29sDQo+ICAgZWxlbWVudHMgZGVzY3JpYmVk IGluIHNldmVyYWwgZG9jdW1lbnRzIG5hbWVseTogDQo+IA0KPiAgIC0gVGhlIEZvckNFUyBwcm90 b2NvbCBbUkZDNTgxMF0NCj4gICAtIFRoZSBGb3JDRVMgRm9yd2FyZGluZyBFbGVtZW50IG1vZGVs IFtSRkM1ODEyXQ0KPiAgIC0gVGhlIEZvckNFUyBUcmFuc3BvcnQgTWFwcGluZyBMYXllciBbUkZD NTgxMV0uDQo+ICAgDQo+ICAgVGhlIHRlc3QgYWxzbyBpbnZvbHZlZCBwcm90b2NvbCBlbGVtZW50 cyBkZXNjcmliZWQgaW4gdGhlIHRoZW4tDQo+ICAgY3VycmVudCB2ZXJzaW9ucyBvZiB0d28gSW50 ZXJuZXQtRHJhZnRzLiAgQWx0aG91Z2ggdGhlc2UgZG9jdW1lbnRzDQo+ICAgaGF2ZSBzdWJzZXF1 ZW50bHkgYmVlbiByZXZpc2VkIGFuZCBhZHZhbmNlZCwgaXQgaXMgaW1wb3J0YW50IHRvIA0KPiAg IHVuZGVyc3RhbmQgd2hpY2ggdmVyc2lvbnMgb2YgdGhlIHdvcmsgd2VyZSB1c2VkIGR1cmluZyB0 aGlzIHRlc3QuDQo+IA0KPiAgIC0gRm9yQ0VTIExvZ2ljYWwgRnVuY3Rpb24gQmxvY2sgTGlicmFy eSBbSS1ELmlldGYtZm9yY2VzLWxmYi1saWItMDNdDQo+ICAgLSBGb3JDRVMgSW50cmEtTmV0d29y ayBFbGVtZW50IEhpZ2ggQXZhaWxhYmlsaXR5IHNwZWNpZmljYXRpb24NCj4gICAgIFtJLUQuaWV0 Zi1mb3JjZXMtY2VoYS0wMF0uDQo+ICAgDQo+ICAgVGhyZWUgaW5kZXBlbmRlbnQgRm9yQ0VTIGlt cGxlbWVudGF0aW9ucyBwYXJ0aWNpcGF0ZWQgaW4gdGhlIHRlc3QuDQo+IEVORA0KPiANCj4+ID4+ IEkgaGF2ZSBhIHBlcnNvbmFsIGRpc2xpa2Ugb2YgcmVwZWF0ZWQgZGVmaW5pdGlvbnMgY29waWVk IGZyb20gb3RoZXINCj4+ID4+IGRvY3VtZW50cy4gVGhleSBjYW4gY2F1c2UgYWxsIHNvcnRzIG9m IGZ1biBpZiB5b3UgbWFrZSBhIG1pc3Rha2Ugd2hlbg0KPj4gPj4geW91IGNvcHkgdGhlIHRleHQh ICBTbyBJIHdvdWxkIHByZWZlciBzZWN0aW9uIDIuMi4gc2ltcGx5IHRvIHBvaW50IGF0DQo+PiA+ PiB0aGUgZGVmaW5pdGlvbnMgZnJvbSBvdGhlciBSRkNzLg0KPj4gPiANCj4+ID4gQWdyZWVkIGlu IHRoaXMgY2FzZS4NCj4+DQo+PiBJbiBnZW5lcmFsIEkgaGF2ZSB0aGUgb3Bwb3NpdGUgdGFzdGUg Oy0+IEkgd291bGQgcmF0aGVyIGhhdmUgdGhlDQo+PiBjb250ZXh0IGluIHBsYWNlIHNvIGkgY2Fu IGNvcnJlbGF0ZSBpbnN0ZWFkIG9mIGdvaW5nIGFuZCByZWFkaW5nIA0KPj4gc29tZSBvdGhlciBk b2MgZWxzZXdoZXJlLg0KPj4gW1llcywgb25lIGNvdWxkIG1ha2UgYSBtaXN0YWtlIGluIGNvcHlp bmcuIEJ1dCBhbHNvIG9uZSBjb3VsZCBmaXggcHJldmlvdXNseQ0KPj4gZXJyb25vdXMgYW5kIHBy b3ZpZGUgbW9yZSBleHRlbmRlZCBpbmZvcm1hdGlvbiBzdWNoIGFzIHRoZSBDRUhBIGRvY3VtZW50 DQo+PiBkb2VzIHdoZW4gaXQgcHJvdmlkZXMgY29udGV4dCBmb3IgSEEgZGVyaXZlZCBmcm9tIFJG QyA1ODEwLl0NCj4gDQo+IExpa2UgSSBzYWlkLCBJJ2xsIGxldCB5J2FsbCBkZWNpZGUgd2hhdCB0 byBkbyBoZXJlIHNpbmNlIEkgZG9uJ3QgZmVlbCBzdHJvbmdseQ0KPiBlbm91Z2guDQo+IA0KPiBD YW4gSSBqdXN0IG5vdGUsIGhvd2V2ZXIsIHRoYXQgaWYgeW91IGFyZSAiZml4aW5nIiBhIGRlZmlu aXRpb24gdGhhdCBpcyBhbHJlYWR5DQo+IGluIGEgcHVibGlzaGVkIFJGQywgeW91IGFyZSBjcmVh dGluZyBhIG5pY2UgbGl0dGxlIG1lc3MgdW5sZXNzIHlvdSBhbHNvIGZpeCB0aGUNCj4gZGVmaW5p dGlvbiBpbiB0aGUgUkZDLiBUaGF0IGZpeCBjb3VsZCBiZSB0aHJvdWdoIGFuIEVycmF0YSBSZXBv cnQgZm9yIGENCj4gdHlwb2dyYXBoaWNhbCBlcnJvciwgb3IgYnkgdXBkYXRpbmcgdGhlIHB1Ymxp c2hlZCBSRkMuIEJ1dCBzaW1wbHkgcHVibGlzaGluZyBhDQo+IG5ldyBSRkMgd2l0aCBhIGRpZmZl cmVudCBkZWZpbml0aW9uIGlzIG5vdCBhIGdvb2QgaWRlYS4NCj4gDQo+IEFuZCBvbmUgb3RoZXIg dGhpbmc6IFdlaW1pbmcncyBpbml0aWFsIHJlc3BvbnNlIGRpZG4ndCBpbmNsdWRlIGFueSByZXNw b25zZSB0bw0KPiBteSBpc3N1ZXMgd2l0aCBSRkMgMjExOSBsYW5ndWFnZS4NCj4gDQo+IE9uY2Ug YWdhaW4sIHRoYW5rcyBmb3IgYWxsIHRoZSB3b3JrLg0KPiANCj4gQ2hlZXJzLA0KPiBBZHJpYW4N Cj4gDQo+ ------=_NextPart_000_02BE_01CE3A16.2F59D130 Content-Type: text/plain; name="draft-ietf-forces-interop-07beta.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-forces-interop-07beta.txt" =0A= =0A= =0A= =0A= Internet Engineering Task Force W. Wang=0A= Internet-Draft Zhejiang Gongshang University=0A= Updates: 6053 (if approved) K. Ogawa=0A= Intended status: Informational NTT Corporation=0A= Expires: October 17, 2013 E. Haleplidis=0A= University of Patras=0A= M. Gao=0A= Hangzhou BAUD Networks=0A= J. Hadi Salim=0A= Mojatatu Networks=0A= April 15, 2013=0A= =0A= =0A= Interoperability Report for Forwarding and Control Element Separation=0A= (ForCES)=0A= draft-ietf-forces-interop-07=0A= =0A= Abstract=0A= =0A= This document captures results of the second Forwarding and Control=0A= Element Separation (ForCES) interoperability test which took place on=0A= February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang=0A= Gongshang University, China. RFC 6053 reported the results of the=0A= first ForCES interoperability test, and this document updates RFC=0A= 6053 by providing further interoperability results.=0A= =0A= Status of This Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at http://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on October 17, 2013.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 1]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2013 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.2. ForCES FE Model . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 4=0A= 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 2.1. Date, Location, and Participants . . . . . . . . . . . . 4=0A= 2.2. Testbed Configuration . . . . . . . . . . . . . . . . . . 5=0A= 2.2.1. Participants Access . . . . . . . . . . . . . . . . . 5=0A= 2.2.2. Testbed Configuration . . . . . . . . . . . . . . . . 6=0A= 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 3.1. Scenario 1 - LFB Operation . . . . . . . . . . . . . . . 7=0A= 3.2. Scenario 2 - TML with IPSec . . . . . . . . . . . . . . . 8=0A= 3.3. Scenario 3 - CE High Availability . . . . . . . . . . . . 9=0A= 3.4. Scenario 4 - Packet forwarding . . . . . . . . . . . . . 10=0A= 4. Test Results . . . . . . . . . . . . . . . . . . . . . . . . 12=0A= 4.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . 12=0A= 4.2. TML with IPSec Test . . . . . . . . . . . . . . . . . . . 18=0A= 4.3. CE High Availability Test . . . . . . . . . . . . . . . . 19=0A= 4.4. Packet Forwarding Test . . . . . . . . . . . . . . . . . 19=0A= 5. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 22=0A= 5.1. On Data Encapsulation Format . . . . . . . . . . . . . . 22=0A= 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24=0A= 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25=0A= 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25=0A= 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25=0A= 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25=0A= 10.1. Normative References . . . . . . . . . . . . . . . . . . 26=0A= 10.2. Informative References . . . . . . . . . . . . . . . . . 26=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27=0A= =0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 2]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= 1. Introduction=0A= =0A= This document captures results of the second interoperability test of=0A= the Forwarding and Control Element Separation (ForCES) which took=0A= place February 24-25, 2011 in the Internet Technology Lab (ITL) of=0A= Zhejiang Gongshang University, China. The test involved protocol=0A= elements described in several documents namely:=0A= =0A= - ForCES Protocol [RFC5810]=0A= - ForCES Forwarding Element Model [RFC5812]=0A= - ForCES Transport Mapping Layer [RFC5811]=0A= =0A= The test also involved protocol elements described in the then-=0A= current versions of two Internet-Drafts. Although these documents=0A= have subsequently been revised and advanced, it is important to=0A= understand which versions of the work were used during this test.=0A= The then-current Internet-Drafts are:=0A= =0A= - ForCES Logical Function Block (LFB) Library=0A= [I-D.ietf-forces-lfb-lib-03].=0A= - ForCES Intra-NE High Availability [I-D.ietf-forces-ceha-00].=0A= =0A= Three independent ForCES implementations participated in the test.=0A= =0A= Scenarios of ForCES LFB Operation, TML with IPSec, CE High=0A= Availability, and Packet Forwarding are constructed. Series of=0A= testing items for every scenario are carried out and interoperability=0A= results are achieved. Popular packet analyzers Ethereal/=0A= Wireshark[Ethereal] and Tcpdump[Tcpdump] are used to verify the wire=0A= results.=0A= =0A= This document is an update to RFC 6053, which captured the results of=0A= the first ForCES interoperability test. The first test on ForCES was=0A= held in July 2008 at the University of Patras, Greece. That test=0A= focused on validating the basic semantics of the ForCES protocol and=0A= ForCES FE model.=0A= =0A= 1.1. ForCES Protocol=0A= =0A= The ForCES protocol works in a master-slave mode in which FEs are=0A= slaves and CEs are masters. The protocol includes commands for=0A= transport of Logical Function Block (LFB) configuration information,=0A= association setup, status, and event notifications, etc. The reader=0A= is encouraged to read the ForCES protocol specification [RFC5810] for=0A= further information.=0A= =0A= 1.2. ForCES FE Model=0A= =0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 3]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= The ForCES FE model [RFC5812] presents a formal way to define FE=0A= Logical Function Blocks (LFBs) using XML. LFB configuration=0A= components, capabilities, and associated events are defined when the=0A= LFB is formally created. The LFBs within the FE are accordingly=0A= controlled in a standardized way by the ForCES protocol.=0A= =0A= 1.3. Transport Mapping Layer=0A= =0A= The ForCES Transport Mapping Layer (TML) transports the ForCES=0A= Protocol Layer (PL) messages. The TML is where the issues of how to=0A= achieve transport level reliability, congestion control, multicast,=0A= ordering, etc are handled. It is expected that more than one TML=0A= will be standardized. RFC 5811 specifies an SCTP-Based Transport=0A= Mapping Layer (TML) for ForCES protocol, which is a mandated TML for=0A= ForCES. See RFC 5811 for more details.=0A= =0A= 1.4. Definitions=0A= =0A= This document follows the terminology defined by ForCES related=0A= documents, including RFC3654, RFC3746, RFC5810, RFC5811, RFC5812,=0A= RFC5813, etc.=0A= =0A= 2. Overview=0A= =0A= 2.1. Date, Location, and Participants=0A= =0A= The second ForCES interoperability test meeting was held by IETF=0A= ForCES Working Group on February 24-25, 2011, and was chaired by=0A= Jamal Hadi Salim. Three independent ForCES implementations=0A= participated in the test:=0A= =0A= o Zhejiang Gongshang University/Hangzhou BAUD Corporation of=0A= Information and Networks Technology (Hangzhou BAUD Networks),=0A= China. This implementation is referred to as "China" or in some=0A= cases "C" in the document for the sake of brevity.=0A= =0A= o NTT Corporation, Japan. This implementation is referred to as=0A= "Japan" or in some cases "J" in the document for the sake of=0A= brevity.=0A= =0A= o The University of Patras, Greece. This implementation is referred=0A= to as "Greece" or in some cases "G" in the document for the sake=0A= of brevity.=0A= =0A= Two other organizations, Mojatatu Networks and Hangzhou BAUD Networks=0A= Corporation, which independently extended two different well known=0A= public domain protocol analyzers, Ethereal/Wireshark [Ethereal] and=0A= Tcpdump [Tcpdump], also participated in the interop test. During the=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 4]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= interoperability test, the two protocol analyzers were used to verify=0A= the validity of ForCES protocol messages and in some cases semantics.=0A= =0A= Some issues related to interoperability among implementations were=0A= discovered. Most of the issues were solved on site during the test.=0A= The most contentious issue found was on the format of encapsulation=0A= for protocol TLV (Refer to Section 5.1 ).=0A= =0A= Some errata related to ForCES document were found by the=0A= interoperability test. The errata has been reported to related IETF=0A= RFCs.=0A= =0A= At times, interoperability testing was exercised between two instead=0A= of all three representative implementations due to a third one=0A= lacking a specific feature; however, in ensuing discussions, all=0A= implementers mentioned they will be implementing any missing features=0A= in the future.=0A= =0A= 2.2. Testbed Configuration=0A= =0A= 2.2.1. Participants Access=0A= =0A= Japan and China physically attended on site at the Internet=0A= Technology Lab (ITL) of Zhejiang Gongshang University in China. The=0A= University of Patras implementation joined remotely from Greece. The=0A= chair, Jamal Hadi Salim, joined remotely from Canada by using the=0A= Teamviewer as the monitoring tool[Teamviewer]. The approach is as=0A= shown in Figure 1. In the figure, FE/CE refers to FE or CE that the=0A= implementer may act alternatively.=0A= =0A= =0A= +---------+ +----+ +----------+=0A= | FE/CE | | | +---|Monitoring|=0A= | China |-----| | /\/\/\/\/\ | |(TeamViewer)=0A= +---------+ | | \Internet/ | | Canada |=0A= |LAN |----/ \--| +----------+=0A= +---------+ | | \/\/\/\/\/ | +----------+=0A= | FE/CE |-----| | | | FE/CE |=0A= | Japan | | | +---| Greece |=0A= +---------+ +----+ +----------+=0A= =0A= Figure 1: Access for Participants=0A= =0A= As specified in RFC 5811, all CEs and FEs shall implement IPSec=0A= security in the TML.=0A= =0A= On the internet boundary, gateways used must allow for IPSec, SCTP=0A= protocol and SCTP ports as defined in the ForCES SCTP-TML [RFC5811] .=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 5]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= 2.2.2. Testbed Configuration=0A= =0A= CEs and FEs from China and Japan implementations were physically=0A= located within the ITL Lab of Zhejiang Gongshang University and=0A= connected together using Ethernet switches. The configuration can be=0A= seen in Figure 2. In the figure, the SmartBits is a third-party=0A= supplied routing protocol testing machine, which acts as a router=0A= running OSPF and RIP and exchanges routing protocol messages with=0A= ForCES routers in the network. The Internet is connected via an ADSL=0A= channel.=0A= =0A= /\/\/\/\/\=0A= \Internet/=0A= / \=0A= \/\/\/\/\/=0A= |=0A= |124.90.146.218 (ADSL)=0A= |=0A= +------------------------------------------------------------------+=0A= | LAN (10.20.0.0/24) |=0A= +------------------------------------------------------------------+=0A= | | | | | |=0A= | | | | | |=0A= |.222 |.230 |.221 |.179 |.231 |.220=0A= +-----+ +-----+ +-----+ +-----+ +-----+ +---------+=0A= | CE | | CE | | | | | | | | Protocol|=0A= |China| |Japan| | FE1 |.1 .2| FE |.1 .2| FE2 | | Analyzer|=0A= +-----+ +-----+ |China|---------|Japan|---------|China| +---------+=0A= +---------| |192.169. | | 192.168.| |------+=0A= | .2 +-----+ 20.0.24 +-----+ 30.0/24+-----+ .2 |=0A= | .12| |.12 |=0A= | | | |=0A= 192.168.50.0/24 | |192.168.60.0/24=0A= | 192.168.10.0/24 192.168.40.0/24 |=0A= .1 | |.11 |.11 |.1=0A= +--------+ +--------------------------------------+ +--------+=0A= |Terminal| | Smartbits | |Terminal|=0A= +--------+ +--------------------------------------+ +--------+=0A= =0A= Figure 2: Testbed Configuration Located in ITL Lab,China=0A= =0A= Hardware and Software (CE and FE) of Greece those were located within=0A= the University of Patras, Greece, were connected together using LAN=0A= as shown in Figure 3. The Internet is connected via a VPN channel.=0A= =0A= =0A= /\/\/\/\/\=0A= \Internet/=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 6]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= / \=0A= \/\/\/\/\/=0A= |=0A= |150.140.254.110(VPN)=0A= |=0A= +------------------------------------+=0A= | LAN |=0A= +------------------------------------+=0A= | | |=0A= | | |=0A= +------+ +--------+ +------+=0A= | FE | |Protocol| | CE |=0A= |Greece| |Analyzer| |Greece|=0A= +------+ +--------+ +------+=0A= =0A= Figure 3: Testbed Configuration Located in the University of=0A= Patras,Greece=0A= =0A= All above testbed configurations can then satisfy requirements of all=0A= the interoperability test scenarios that are mentioned in this=0A= document.=0A= =0A= 3. Scenarios=0A= =0A= 3.1. Scenario 1 - LFB Operation=0A= =0A= This scenario is to test the interoperability on LFB operations among=0A= the participants. The connection diagram for the participants is as=0A= shown in Figure 4.=0A= =0A= +------+ +------+ +------+ +------+ +------+ +------+=0A= | CE | | CE | | CE | | CE | | CE | | CE |=0A= | China| | Japan| | China| |Greece| | Japan| |Greece|=0A= +------+ +------+ +------+ +------+ +------+ +------+=0A= | | | | | |=0A= | | | | | |=0A= +------+ +------+ +------+ +------+ +------+ +------+=0A= | FE | | FE | | FE | | FE | | FE | | FE |=0A= |Japan | |China | |Greece| |China | |Greece| |Japan |=0A= +------+ +------+ +------+ +------+ +------+ +------+=0A= =0A= Figure 4: Scenario for LFB Operation=0A= =0A= In order to make interoperability more credible, the three=0A= implementers are required to carry out the test in a way acting as CE=0A= or FE alternatively. As a result, every LFB operation is combined=0A= with 6 scenarios, as shown by Figure 4.=0A= =0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 7]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= The test scenario is designed with the following purposes:=0A= =0A= Firstly, the scenario is designed to verify all kinds of protocol=0A= messages with their complex data formats, which are defined in RFC=0A= 5810. Specially, we try to verify the data format of a PATH-DATA=0A= with nested PATH-DATAs, and the operation(SET, GET, DEL) of an array=0A= or an array with a nested array.=0A= =0A= Secondly, the scenario is designed to verify the definition of ForCES=0A= LFB Library [I-D.ietf-forces-lfb-lib-03], which defines a base set of=0A= ForCES LFB classes for typical router functions. Successful test=0A= under this scenario also means the validity of the LFB definitions.=0A= =0A= 3.2. Scenario 2 - TML with IPSec=0A= =0A= This scenario is designed to implement a TML with IPSec, which is the=0A= requirement by RFC 5811. TML with IPSec was not implemented in the=0A= first ForCES interoperability test as reported by RFC 6053. For this=0A= reason, in the second interoperability test, we specifically designed=0A= the test scenario to verify the TML over IPSec channel.=0A= =0A= In this scenario, tests on LFB operations for Scenario 1 were=0A= repeated with the difference that TML was secured via IPSec. This=0A= setup scenario allows us to verify whether all interactions between=0A= CE and FE can be made correctly under an IPSec TML environment.=0A= =0A= The connection diagram for this scenario is shown as Figure 5.=0A= Because of system deficiency to deploy IPSec over TML in Greece, the=0A= text only took place between China and Japan.=0A= =0A= +------+ +------+=0A= | CE | | CE |=0A= | China| | Japan|=0A= +------+ +------+=0A= | |=0A= |TML over IPSec |TML over IPSec=0A= +------+ +------+=0A= | FE | | FE |=0A= |Japan | |China |=0A= +------+ +------+=0A= =0A= Figure 5: Scenario for LFB Operation with TML over IPSec=0A= =0A= In this scenario, ForCES TML was run over IPSec channel.=0A= Implementers joined in this interoperability have used the same=0A= third-party software 'racoon' to have established the IPSec channel.=0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 8]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= China and Japan have made a successful test with the scenario, and=0A= the following items have been realized:=0A= =0A= o Internet Key Exchange (IKE) with certificates for endpoint=0A= authentication.=0A= =0A= o Transport Mode Encapsulating Security Payload (ESP). HMAC-SHA1-96=0A= for message integrity protection.=0A= =0A= 3.3. Scenario 3 - CE High Availability=0A= =0A= CE High Availability (CEHA) was tested based on the ForCES CEHA=0A= document [I-D.ietf-forces-ceha-00]=0A= =0A= The design of the setup and the scenario for the CEHA were simplified=0A= so as to focus mostly on the mechanics of the CEHA, which are:=0A= =0A= o Associating with more than one CE.=0A= =0A= o Switching to backup CE on master CE failure.=0A= =0A= The connection diagram for the scenario is as shown in Figure 6.=0A= =0A= master standby master standby=0A= +------+ +------+ +------+ +------+=0A= | CE | | CE | | CE | | CE |=0A= | China| |Greece| |Japan | |Greece|=0A= +------+ +------+ +------+ +------+=0A= | | | |=0A= +----------+ +-----------+=0A= | |=0A= +------+ +------+=0A= | FE | | FE |=0A= |Greece| |Greece|=0A= +------+ +------+=0A= (a) (b)=0A= =0A= Figure 6: Scenario for CE High Availability=0A= =0A= In this scenario one FE is connected and associated to a master CE=0A= and a backup CE. In the pre-association phase, the FE would be=0A= configured to have China's or Japan's CE as master CE and Greece's CE=0A= as standby CE. The CEFailoverPolicy component of the FE Protocol=0A= Object LFB that specifies whether the FE is in High Availability mode=0A= (value 2 or 3) would either be set in the pre-association phase by=0A= the FEM interface or in post-association phase by the master CE.=0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 9]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= If the CEFailoverPolicy value is set to 2 or 3, the FE (in the post-=0A= association phase) will attempt to connect and associate with the=0A= standby CE.=0A= =0A= When the master CE is deemed disconnected, either by a TearDown, Loss=0A= of Heartbeats or physically disconnected, the FE would assume that=0A= the standby CE is now the master CE. The FE will then send an Event=0A= Notification, Primary CE Down,to all associated CEs, only the standby=0A= CE in this case, with the value of the new master CEID. The standby=0A= CE will then respond by sending a configuration message to the CEID=0A= component of the FE Protocol Object with its own ID to confirm that=0A= the CE considers itself as the master as well.=0A= =0A= The steps of the CEHA test scenario are as follows:=0A= =0A= 1. In the pre-association phase, setup of FE with master CE and=0A= backup CE=0A= =0A= 2. FE connecting and associating with master CE.=0A= =0A= 3. When CEFailoverPolicy is set to 2 or 3, the FE will connect and=0A= associate with backup CE.=0A= =0A= 4. Once the master CE is considered disconnected then the FE chooses=0A= the first Associated backup CE.=0A= =0A= 5. It sends an Event Notification specifying that the master CE is=0A= down and who is now the master CE.=0A= =0A= 6. The new master CE sends a SET Configuration message to the FE=0A= setting the CEID value to who is now the new master CE completing=0A= the switch.=0A= =0A= 3.4. Scenario 4 - Packet forwarding=0A= =0A= This test scenario is to verify LFBs like RedirectIn, RedirectOut,=0A= IPv4NextHop, IPv4UcastLPM defined by the ForCES LFB library document=0A= [I-D.ietf-forces-lfb-lib-03], and more importantly, to verify the=0A= combination of the LFBs to implement IP packet forwarding.=0A= =0A= The connection diagram for this scenario is as Figure 7.=0A= =0A= +------+=0A= | CE |=0A= | Japan|=0A= +------+=0A= | ^=0A= | | OSPF=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 10]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= | +------->=0A= +------+ +------+=0A= +--------+ | FE | | OSPF | +--------+=0A= |Terminal|------|China |-------|Router|------|Terminal|=0A= +--------+ +------+ +------+ +--------+=0A= =0A= <-------------------------------------------->=0A= Packet Forwarding=0A= =0A= (a)=0A= =0A= =0A= +------+=0A= | CE |=0A= | China|=0A= +------+=0A= ^ | ^=0A= OSPF | | | OSPF=0A= <-----+ | +----->=0A= +-------+ +------+ +------+=0A= +--------+ | OSPF | | FE | | OSPF | +--------+=0A= |Terminal|----|Router |----|Japan |-----|Router|--|Terminal|=0A= +--------+ +-------+ +------+ +------+ +--------+=0A= =0A= <-------------------------------------------->=0A= Packet Forwarding=0A= =0A= (b)=0A= =0A= =0A= +------+ +------+=0A= | CE | | CE |=0A= | Japan| | China|=0A= +------+ +------+=0A= | ^ ^ |=0A= | | OSPF | |=0A= | +----------+ |=0A= +------+ +------+=0A= +--------+ | FE | | FE | +--------+=0A= |Terminal|------|China |-------|Japan |------|Terminal|=0A= +--------+ +------+ +------+ +--------+=0A= =0A= <-------------------------------------------->=0A= Packet Forwarding=0A= =0A= (c)=0A= =0A= Figure 7: Scenario for IP Packet forwarding=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 11]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= In case (a), a CE by Japan is connected to an FE by China to form a=0A= ForCES router. A Smartbits test machine with its routing protocol=0A= software are used to simulate an OSPF router and are connected with=0A= the ForCES router to try to exchange OSPF hello packets and LSA=0A= packets among them. Terminals are simulated by Smartbits to send and=0A= receive packets. As a result, the CE in the ForCES router need to be=0A= configured to run and support OSPF routing protocol.=0A= =0A= In case (b), a CE by China is connected to an FE by Japan to form a=0A= ForCES router. Two routers running OSPF are simulated and connected=0A= to the ForCES router to test if the ForCES router can support OSPF=0A= protocol and support packet forwarding.=0A= =0A= In case (c), two ForCES routers are constructed. One is with CE by=0A= Japan and FE by China and the other is opposite. OSPF and packet=0A= forwarding are tested in the environment.=0A= =0A= Testing process for this scenario is as below:=0A= =0A= 1. Boot terminals and routers, and set IP addresses of their=0A= interfaces.=0A= =0A= 2. Boot CE and FE.=0A= =0A= 3. Establish association between CE and FE, and set IP addresses of=0A= FEs interfaces.=0A= =0A= 4. Start OSPF among CE and routers, and set FIB on FE.=0A= =0A= 5. Send packets between terminals.=0A= =0A= 4. Test Results=0A= =0A= 4.1. LFB Operation Test=0A= =0A= The test result is as reported by Figure 8. For the convenience=0A= sake, as mentioned earlier, abbreviations of 'C' in the table means=0A= implementation from China,'J'Japan implementation, and 'G' Greece=0A= implementation.=0A= =0A= +-----+----+-----+-----+--------------+-------------------+---------+=0A= |Test#| CE |FE(s)|Oper | LFB | Component | Result |=0A= | | | | | | /Capability | |=0A= +-----+----+-----+-----+--------------+-------------------+---------+=0A= | 1 | C | J | GET | FEObject | LFBTopology | Success |=0A= | | J | C | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 12]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 2 | C | J | GET | FEObject | LFBSelector | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 3 | C | J | GET | EtherPHYCop | PHYPortID | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 4 | C | J | GET | EtherPHYCop | AdminStatus | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 5 | C | J | GET | EtherPHYCop | OperStatus | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 6 | C | J | GET | EtherPHYCop | AdminLinkSpeed | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 7 | C | J | GET | EtherPHYCop | OperLinkSpeed | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 8 | C | J | GET | EtherPHYCop | AdminDuplexSpeed | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 13]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 9 | C | J | GET | EtherPHYCop | OperDuplexSpeed | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 10 | C | J | GET | EtherPHYCop | CarrierStatus | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 11 | C | J | GET | EtherMACIn | AdminStatus | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 12 | C | J | GET | EtherMACIn | LocalMacAddresses | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 13 | C | J | GET | EtherMACIn | L2Bridging | Success |=0A= | | J | C | | | PathEnable | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 14 | C | J | GET | EtherMACIn | PromiscuousMode | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 15 | C | J | GET | EtherMACIn | TxFlowControl | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 14]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 16 | C | J | GET | EtherMACIn | RxFlowControl | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 17 | C | J | GET | EtherMACIn | MACInStats | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 18 | C | J | GET | EtherMACOut | AdminStatus | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 19 | C | J | GET | EtherMACOut | MTU | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 20 | C | J | GET | EtherMACOut | TxFlowControl | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 21 | C | J | GET | EtherMACOut | TxFlowControl | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 22 | C | J | GET | EtherMACOut | MACOutStats | Success |=0A= | | J | C | | | | Success |=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 15]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 23 | C | J | GET | ARP |PortV4AddrInfoTable| Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 24 | C | J | SET | ARP |PortV4AddrInfoTable| Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 25 | C | J | DEL | ARP |PortV4AddrInfoTable| Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 26 | C | J | SET | EtherMACIn | LocalMACAddresses | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 27 | C | J | SET | EtherMACIn | MTU | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 28 | C | J | SET | IPv4NextHop | IPv4NextHopTable | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 29 | C | J | SET | IPv4UcastLPM | IPv4PrefixTable | Success |=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 16]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 30 | C | J | DEL | IPv4NextHop | IPv4NextHopTable | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 31 | C | J | DEL | IPv4UcastLPM | IPv4PrefixTable | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 32 | C | J | SET | EtherPHYCop | AdminStatus | Success |=0A= | | J | C | | | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 33 | C | J | SET | Ether | VlanInputTable | Success |=0A= | | J | C | | Classifier | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 34 | C | J | DEL | Ether | VlanInputTable | Success |=0A= | | J | C | | Classifier | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= | 35 | C | J | SET | Ether | VlanOutputTable | Success |=0A= | | J | C | | Encapsulator | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= | | | | | | | |=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 17]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= | 36 | C | J | DEL | Ether | VlanOutputTable | Success |=0A= | | J | C | | Encapsulator | | Success |=0A= | | C | G | | | | Success |=0A= | | G | C | | | | Success |=0A= | | J | G | | | | Success |=0A= | | G | J | | | | Success |=0A= +-----+----+-----+-----+--------------+-------------------+---------+=0A= =0A= Figure 8: LFB Operation Test Results=0A= =0A= Note on test 1#:=0A= =0A= On the wire format of encapsulation on array, only the case of=0A= FULLDATA-in-FULLDATA was tested.=0A= =0A= In China's implementation, after test 2# CE have to get all LFBs'=0A= instance data actively according to the queried component of=0A= LFBSelectors.=0A= =0A= Note on test 28# and 29#:=0A= =0A= Only had new reachable network destination been set, can route entry=0A= be added into system.=0A= =0A= Note on test 30# and 31#:=0A= =0A= Corresponding nexthop entry must be deleted before prefix entry which=0A= is decided by FE's routing management.=0A= =0A= 4.2. TML with IPSec Test=0A= =0A= In this scenario, the ForCES TML is run over IPSec. Implementers=0A= joined this interoperability test use the same third-party tool=0A= software 'racoon' to establish IPSec channel. Some typical LFB=0A= operation tests as in Scenario 1 are repeated with the IPSec enabled=0A= TML.=0A= =0A= A note on this test is, because of the system difficulty to implement=0A= IPSec over TML, Greece did not join in the test. Therefore, this=0A= scenario only took place between C and J.=0A= =0A= The TML with IPSec test results are reported by Figure 9.=0A= =0A= +-----+----+-----+-----+--------------+-------------------+---------+=0A= |Test#| CE |FE(s)|Oper | LFB | Component/ | Result |=0A= | | | | | | Capability | |=0A= +-----+----+-----+-----+--------------+-------------------+---------+=0A= | 1 | C | J | GET | FEObject | LFBTopology | Success |=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 18]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= | | J | C | | | | Success |=0A= | | | | | | | |=0A= | 2 | C | J | GET | FEObject | LFBSelectors | Success |=0A= | | J | C | | | | Success |=0A= | | | | | | | |=0A= | 3 | C | J | SET | Ether | VlanInputTable | Success |=0A= | | J | C | | Classifier | | Success |=0A= | | | | | | | |=0A= | 4 | C | J | DEL | Ether | VlanInputTable | Success |=0A= | | J | C | | Classifier | | Success |=0A= +-----+----+-----+-----+--------------+-------------------+---------+=0A= =0A= Figure 9: TML with IPSec Test Results=0A= =0A= 4.3. CE High Availability Test=0A= =0A= In this scenario one FE connects and associates with a master CE and=0A= a backup CE. When the master CE is deemed disconnected the FE would=0A= attempt to find another associated CE to become the master CE.=0A= =0A= The CEHA scenario as is described in Scenario 3 was completed=0A= successfully for both setups.=0A= =0A= Due to a bug in one of the FEs, a interesting issue was caught: it=0A= was observed that the buggy FE took up to a second to failover. It=0A= was eventually found that the issue was due to the FE's=0A= prioritization of the different CEs. All messages from the backup CE=0A= were being ignored unless the master CE is disconnected.=0A= =0A= While the bug was fixed and the CEHA scenario was completed=0A= successfully, the authors feel it was important to capture the=0A= implementation issue in this document. The recommended approach is=0A= the following:=0A= =0A= o The FE should receive and handle messages first from the master CE=0A= on all priority channels to maintain proper functionality and then=0A= receive and handle messages from the backup CEs.=0A= =0A= o Only when the FE is attempting to associate with the backup CEs,=0A= then the FE should receive and handle messages per priority=0A= channel from all CEs. When all backup CEs are associated with or=0A= deemed unreachable, then the FE should return to receiving and=0A= handling messages first from the master CE.=0A= =0A= 4.4. Packet Forwarding Test=0A= =0A= As described in the ForCES LFB library [I-D.ietf-forces-lfb-lib-03],=0A= packet forwarding is implemented by a set of LFB classes that compose=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 19]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= a processing path for packets. In this test scenario, as shown in=0A= Figure 7, a ForCES router running OSPF protocol was constructed. In=0A= addition, a set of LFBs including RedirectIn, RedirectOut,=0A= IPv4UcastLPM, and IPv4NextHop LFBs are used. RedirectIn and=0A= RedirectOut LFBs redirect OSPF hello and LSA packets from and to CE.=0A= A Smartbits test machine is used to simulate an OSPF router and=0A= exchange the OSPF hello and LSA packets with CE in ForCES router.=0A= =0A= Cases (a) and (b) in Figure 7 both need a RedirectIn LFB to send OSPF=0A= packets generated by CE to FE by use of ForCES packet redirect=0A= messages. The OSPF packets are further sent to an outside OSPF=0A= Router by the FE via forwarding LFBs including IPv4NextHop and=0A= IPv4UcastLPM LFBs. A RedirectOut LFB in the FE is used to send OSPF=0A= packets received from outside OSPF Router to CE by ForCES packet=0A= redirect messages.=0A= =0A= By running OSPF, the CE in the ForCES router can generate new routes=0A= and load them to routing table in FE. The FE is then able to forward=0A= packets according to the routing table.=0A= =0A= The test is reported with the results in Figure 10=0A= =0A= +-----+----+-----+-------------------------+--------------+---------+=0A= |Test#| CE |FE(s)| Item | LFBs Related | Result |=0A= +-----+----+-----+-------------------------+--------------+---------+=0A= | 1 | J | C | IPv4NextHopTable SET | IPv4NextHop | Success |=0A= | | | | | | |=0A= | 2 | J | C | IPv4PrefixTable SET | IPv4UcastLPM | Success |=0A= | | | | | | |=0A= | 3 | J | C |Redirect OSPF packet from| RedirectIn | Success |=0A= | | | | CE to SmartBits | | |=0A= | | | | | | |=0A= | 4 | J | C |Redirect OSPF packet from| RedirectOut | Success |=0A= | | | | SmartBits to CE | | |=0A= | | | | | | |=0A= | 5 | J | C | Metadata in | RedirectOut | Success |=0A= | | | | redirect message | RedirectIn | |=0A= | | | | | | |=0A= | 6 | J | C | OSPF neighbor discovery | RedirectOut | Success |=0A= | | | | | RedirectIn | |=0A= | | | | | | |=0A= | 7 | J | C | OSPF DD exchange | RedirectOut | Success |=0A= | | | | | RedirectIn | |=0A= | | | | | IPv4NextHop | |=0A= | | | | | | |=0A= | 8 | J | C | OSPF LSA exchange | RedirectOut | Success |=0A= | | | | | RedirectIn | |=0A= | | | | | IPv4NextHop | |=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 20]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= | | | | | IPv4UcastLPM| |=0A= | | | | | | |=0A= | 9 | J | C | Data Forwarding | RedirectOut | Success |=0A= | | | | | RedirectIn | |=0A= | | | | | IPv4NextHop | |=0A= | | | | | IPv4UcastLPM| |=0A= | | | | | | |=0A= | 10 | C | J | IPv4NextHopTable SET | IPv4NextHop | Success |=0A= | | | | | | |=0A= | 11 | C | J | IPv4PrefixTable SET | IPv4UcastLPM| Success |=0A= | | | | | | |=0A= | 12 | C | J |Redirect OSPF packet from| RedirectIn | Success |=0A= | | | | CE to other OSPF router | | |=0A= | | | | | | |=0A= | 13 | C | J |Redirect OSPF packet from| RedirectOut | Success |=0A= | | | |other OSPF router to CE | | |=0A= | | | | | | |=0A= | 14 | C | J | Metadata in | RedirectOut | Success |=0A= | | | | redirect message | RedirectIn | |=0A= | | | | | | |=0A= | 15 | C | J |OSPF neighbor discovery | RedirectOut | Success |=0A= | | | | | RedirectIn | |=0A= | | | | | | |=0A= | 16 | C | J | OSPF DD exchange | RedirectOut | Failure |=0A= | | | | | RedirectIn | |=0A= | | | | | IPv4NextHop | |=0A= | | | | | | |=0A= | 17 | C | J | OSPF LSA exchange | RedirectOut | Failure |=0A= | | | | | RedirectIn | |=0A= | | | | | IPv4NextHop | |=0A= | | | | | IPv4UcastLPM| |=0A= +-----+----+-----+-------------------------+--------------+---------+=0A= =0A= Figure 10: Packet Forwarding Test Results=0A= =0A= Note on test 1# and 2#:=0A= =0A= A multicast route pointed to localhost was manually set before=0A= redirect channel could work normally.=0A= =0A= Note on test 3# to 9#:=0A= =0A= During the tests, OSPF packets received from CE were found by=0A= Ethereal/Wireshark with checksum errors. China's FE corrected the=0A= checksum in FE so that the Smartbits would not drop the packets and=0A= the neighbor discovery can continue. Such correcting action does not=0A= affect the test scenarios and the results.=0A= =0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 21]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= Comment on Test #16 and #17:=0A= =0A= The two test items failed. Note that Test #7 and #8 are exactly the=0A= same as these tests, only with CE and FE implementers are exchanged,=0A= and Test #12 and #13 show the redirect channel works well. As a=0A= result, it can be inferred that the problem caused the test failure=0A= was almost certainly from the implementation of the related LFBs=0A= rather than from the ForCES protocol design problem, therefore the=0A= failure does not lead to the interoperability problem on ForCES.=0A= =0A= 5. Discussions=0A= =0A= 5.1. On Data Encapsulation Format=0A= =0A= In the first day of the test, it was found that the LFB inter-=0A= operations about tables all failed. The reason is found to be the=0A= different ForCES protocol data encapsulation method among different=0A= implementations. The encapsulation issues are detailed as below:=0A= =0A= Assuming that an LFB has two components, one is a struct with ID 1=0A= and the other an array with ID 2, further with two components of u32=0A= both inside, as below:=0A= =0A= struct1: type struct, ID=3D1=0A= components are:=0A= a, type u32, ID=3D1=0A= b, type u32, ID=3D2=0A= =0A= table1: type array, ID=3D2=0A= components for each row are (a struct of):=0A= x, type u32, ID=3D1=0A= y, type u32, ID=3D2=0A= =0A= =0A= 1. On response of PATH-DATA format=0A= =0A= When a CE sends a config/query ForCES protocol message to an FE from=0A= a different implementer, the CE probably receives response from the=0A= FE with different PATH-DATA encapsulation format. For example, if a=0A= CE sends a query message with a path of 1 to a third party FE to=0A= manipulate struct 1 as defined above, the FE is probable to generate=0A= response with two different PATH-DATA encapsulation format: one is=0A= the value with FULL/SPARSE-DATA and the other is the value with many=0A= parallel PATH-DATA TLV and nested PATH-DATA TLV, as below:=0A= =0A= format 1:=0A= OPER =3D GET-RESPONSE-TLV=0A= PATH-DATA-TLV:=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 22]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= IDs=3D1=0A= FULLDATA-TLV containing valueof(a),valueof(b)=0A= format 2:=0A= OPER =3D GET-RESPONSE-TLV=0A= PATH-DATA-TLV:=0A= IDs=3D1=0A= PATH-DATA-TLV:=0A= IDs=3D1=0A= FULLDATA-TLV containing valueof(a)=0A= PATH-DATA-TLV:=0A= IDs=3D2=0A= FULLDATA-TLV containing valueof(b)=0A= =0A= =0A= The interoperability test witnessed that a ForCES element (CE or FE)=0A= sender is free to choose whatever data structure that IETF ForCES=0A= documents define and best suits the element, while a ForCES element=0A= (CE or FE) should be able to accept and process information (requests=0A= and responses) that use any legitimate structure defined by IETF=0A= ForCES documents. While in the case a ForCES element is free to=0A= choose any legitimate data structure as a response, it is preferred=0A= the ForCES element responds in the same format that the request was=0A= made, as it is most probably the data structure is the request sender=0A= looks forward to receive.=0A= =0A= 2. On operation to array=0A= =0A= An array operation may also have several different data encapsulation=0A= formats. For instance, if a CE sends a config message to table 1=0A= with a path of (2.1), which refers to component with ID=3D2, which is=0A= an array, and the second ID is the row, so row 1, it may be=0A= encapsulated with three formats as below:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 23]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= format 1:=0A= OPER =3D SET-TLV=0A= PATH-DATA-TLV:=0A= IDs=3D2.1=0A= FULLDATA-TLV containing valueof(x),valueof(y)=0A= format 2:=0A= OPER =3D SET-TLV=0A= PATH-DATA-TLV:=0A= IDs=3D2.1=0A= PATH-DATA-TLV:=0A= IDs=3D1=0A= FULLDATA-TLV containing valueof(x)=0A= PATH-DATA-TLV=0A= IDs=3D2=0A= FULLDATA-TLV containing valueof(y)=0A= =0A= =0A= Moreover, if CE is targeting the whole array, for example if the=0A= array is empty and CE wants to add the first row to the table, it=0A= could also adopt another format:=0A= =0A= format 3:=0A= OPER =3D SET-TLV=0A= PATH-DATA-TLV:=0A= IDs=3D2=0A= FULLDATA-TLV containing rowindex=3D1,valueof(x),valueof(y)=0A= =0A= =0A= =0A= The interoperability test experience shows that format 1 and format=0A= 3, which take full advantage of multiple data elements description in=0A= one TLV of FULLDATA-TLV, get more efficiency, although format 2 can=0A= also get the same operating goal.=0A= =0A= 6. Contributors=0A= =0A= Contributors who have made major contributions to the=0A= interoperability test are as below:=0A= =0A= Hirofumi Yamazaki=0A= NTT Corporation=0A= Tokyo=0A= Japan=0A= Email: yamazaki.horofumi@lab.ntt.co.jp=0A= =0A= Rong Jin=0A= Zhejiang Gongshang University=0A= Hangzhou=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 24]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= P.R.China=0A= Email: jinrong@zjsu.edu.cn=0A= =0A= Yuta Watanabe=0A= NTT Corporation=0A= Tokyo=0A= Japan=0A= Email: yuta.watanabe@ntt-at.co.jp=0A= =0A= Xiaochun Wu=0A= Zhejiang Gongshang University=0A= Hangzhou=0A= P.R.China=0A= Email: spring-403@zjsu.edu.cn=0A= =0A= 7. Acknowledgements=0A= =0A= The authors thank the following test participants:=0A= =0A= Chuanhuang Li, Hangzhou BAUD Networks=0A= Ligang Dong, Zhejiang Gongshang University=0A= Bin Zhuge, Zhejiang Gongshang University=0A= Jingjing Zhou, Zhejiang Gongshang University=0A= Liaoyuan Ke, Hangzhou BAUD Networks=0A= Kelei Jin, Hangzhou BAUD Networks=0A= =0A= The authors also thank very much to Adrian Farrel and Joel Halpern=0A= for their important help in the document publication process.=0A= =0A= 8. IANA Considerations=0A= =0A= This memo includes no request to IANA.=0A= =0A= 9. Security Considerations=0A= =0A= Developers of ForCES FEs and CEs must take the security=0A= considerations of the ForCES Framework [RFC3746] and the ForCES=0A= Protocol [RFC5810] into account. Also, as specified in the security=0A= considerations section of the SCTP-Based TML for the ForCES Protocol=0A= [RFC5811], the transport-level security has to be ensured by IPsec.=0A= =0A= 10. References=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 25]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= 10.1. Normative References=0A= =0A= [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,=0A= W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and=0A= Control Element Separation (ForCES) Protocol=0A= Specification", RFC 5810, March 2010.=0A= =0A= [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping=0A= Layer (TML) for the Forwarding and Control Element=0A= Separation (ForCES) Protocol", RFC 5811, March 2010.=0A= =0A= [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control=0A= Element Separation (ForCES) Forwarding Element Model", RFC=0A= 5812, March 2010.=0A= =0A= [RFC5813] Haas, R., "Forwarding and Control Element Separation=0A= (ForCES) MIB", RFC 5813, March 2010.=0A= =0A= 10.2. Informative References=0A= =0A= [Ethereal]=0A= , "Ethereal, also named Wireshark, is a protocol analyzer.=0A= The specific Ethereal that was used is an updated=0A= Ethereal, by Fenggen Jia, that can analyze and decode the=0A= ForCES protocol messages", http://www.ietf.org/mail-=0A= archive/web/forces/current/msg03687.html , .=0A= =0A= [I-D.ietf-forces-ceha-00]=0A= Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES=0A= Intra-NE High Availability", draft-ietf-forces-ceha-00=0A= (work in progress) [RFC Editor Note: This reference is=0A= intended to indicate a specific version of an Internet-=0A= Draft that was used during interop testing. Please Do NOT=0A= update this reference to a more recent version of the=0A= draft or to an RFC. Please remove this note before=0A= publication] , October 2010.=0A= =0A= [I-D.ietf-forces-lfb-lib-03]=0A= Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.=0A= Halpern, "ForCES Logical Function Block (LFB) Library",=0A= draft-ietf-forces-lfb-lib-03 (work in progress) [RFC=0A= Editor Note: This reference is intended to indicate a=0A= specific version of an Internet-Draft that was used during=0A= interop testing. Please Do NOT update this reference to a=0A= more recent version of the draft or to an RFC. Please=0A= remove this note before publication] , December 2010.=0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 26]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation=0A= of IP Control and Forwarding", RFC 3654, November 2003.=0A= =0A= [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,=0A= "Forwarding and Control Element Separation (ForCES)=0A= Framework", RFC 3746, April 2004.=0A= =0A= [RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim,=0A= "Implementation Report for Forwarding and Control Element=0A= Separation (ForCES)", RFC 6053, November 2010.=0A= =0A= [Tcpdump] , "Tcpdump is a Linux protocol analyzer. The specific=0A= tcpdump that was used is a modified tcpdump, by Jamal Hadi=0A= Salim, that can analyze and decode the ForCES protocol=0A= messages", http://www.ietf.org/mail-archive/web/forces/=0A= current/msg03811.html , .=0A= =0A= [Teamviewer]=0A= , "TeamViewer connects to any PC or server around the=0A= world within a few seconds. ", http://www.teamviewer.com/=0A= , .=0A= =0A= Authors' Addresses=0A= =0A= Weiming Wang=0A= Zhejiang Gongshang University=0A= 18 Xuezheng Str., Xiasha University Town=0A= Hangzhou 310018=0A= P.R.China=0A= =0A= Phone: +86-571-28877721=0A= Email: wmwang@zjsu.edu.cn=0A= =0A= =0A= Kentaro Ogawa=0A= NTT Corporation=0A= Tokyo=0A= Japan=0A= =0A= Email: ogawa.kentaro@lab.ntt.co.jp=0A= =0A= =0A= Evangelos Haleplidis=0A= University of Patras=0A= Patras=0A= Greece=0A= =0A= Email: ehalep@ece.upatras.gr=0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 27]=0A= =0C=0A= Internet-Draft ForCES Interop Report April 2013=0A= =0A= =0A= Ming Gao=0A= Hangzhou BAUD Networks=0A= 408 Wen-San Road=0A= Hangzhou 310012=0A= P.R.China=0A= =0A= Email: gmyyqno1@zjsu.edu.cn=0A= =0A= =0A= Jamal Hadi Salim=0A= Mojatatu Networks=0A= Ottawa=0A= Canada=0A= =0A= Email: hadi@mojatatu.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires October 17, 2013 [Page 28]=0A= ------=_NextPart_000_02BE_01CE3A16.2F59D130 Content-Type: text/html; name="Diff draft-ietf-forces-interop-06_txt - draft-ietf-forces-interop-07_txt.htm" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Diff draft-ietf-forces-interop-06_txt - draft-ietf-forces-interop-07_txt.htm" =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Diff: draft-ietf-forces-interop-06.txt - = draft-ietf-forces-interop-07.txt =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= = =0A= =0A= = =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
< draft-ietf-forces-interop-06.txt  =  draft-ietf-forces-interop-07.txt >
Internet Engineering Task Force = W. Wang Internet Engineering = Task Force W. Wang
Internet-Draft Zhejiang = Gongshang University Internet-Draft = Zhejiang Gongshang University
Intended status: Informational = K. Ogawa Updates: 6053 (if approved) = K. Ogawa
Expires: August 10, 2013 = NTT Corporation Intended status: Informational = NTT Corporation
= E. = Haleplidis Expires: October 17, 2013 = E. Haleplidis
= University of = Patras = University of Patras
= M. = Gao = M. Gao
= Hangzhou BAUD = Networks = Hangzhou BAUD Networks
= J. Hadi = Salim = J. Hadi Salim
= Mojatatu = Networks = Mojatatu Networks
= February 6, 2013 = April 15, 2013
= Interoperability Report for Forwarding and Control Element = Separation Interoperability Report = for Forwarding and Control Element Separation
= (ForCES) = (ForCES)
= draft-ietf-forces-interop-06 = draft-ietf-forces-interop-07
Abstract Abstract
= This document captures results of the second Forwarding and = Control This document captures = results of the second Forwarding and Control
= Element Separation (ForCES) interoperability test which took place = on Element Separation (ForCES) = interoperability test which took place on
= February 24-25, 2011 in the Internet Technology Lab (ITL) of = Zhejiang February 24-25, 2011 in = the Internet Technology Lab (ITL) of Zhejiang
= Gongshang University, China. The document is = an update to RFC 6053, = Gongshang University, China. RFC 6053 reported the results of the
which captured the = results of the first ForCES interoperability test. = first ForCES interoperability test, and this = document updates RFC
6053 by providing further interoperability = results.
Status of this = Memo Status of This Memo
= This Internet-Draft is submitted in full conformance with the = This Internet-Draft is submitted in full = conformance with the
= provisions of BCP 78 and BCP 79. = provisions of BCP 78 and BCP 79.
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
= Task Force (IETF). Note that other groups may also distribute = Task Force (IETF). Note that other groups = may also distribute
= working documents as Internet-Drafts. The list of current = Internet- working documents as = Internet-Drafts. The list of current Internet-
= Drafts is at http://datatracker.ietf.org/drafts/current/. = Drafts is at = http://datatracker.ietf.org/drafts/current/.
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
= and may be updated, replaced, or obsoleted by other documents at = any and may be updated, replaced, = or obsoleted by other documents at any
= time. It is inappropriate to use Internet-Drafts as reference = time. It is inappropriate to use = Internet-Drafts as reference
= material or to cite them other than as "work in progress." = material or to cite them other than as "work = in progress."
= This Internet-Draft will expire on August = 10, 2013. This = Internet-Draft will expire on October 17, = 2013.
Copyright Notice Copyright Notice
= Copyright (c) 2013 IETF Trust and the persons identified as the = Copyright (c) 2013 IETF Trust and the = persons identified as the
= document authors. All rights reserved. document authors. All rights reserved.
= This document is subject to BCP 78 and the IETF Trust's Legal = This document is subject to BCP 78 and the = IETF Trust's Legal
= Provisions Relating to IETF Documents = Provisions Relating to IETF Documents
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://trustee.ietf.org/license-info) in = effect on the date of
= publication of this document. Please review these documents = publication of this document. Please review = these documents
= carefully, as they describe your rights and restrictions with = respect carefully, as they describe = your rights and restrictions with respect
= to this document. Code Components extracted from this document = must to this document. Code = Components extracted from this document must
= include Simplified BSD License text as described in Section 4.e = of include Simplified BSD License = text as described in Section 4.e of
= the Trust Legal Provisions and are provided without warranty as = the Trust Legal Provisions and are provided = without warranty as
= described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table = of Contents
= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3
= 1.1. ForCES Protocol . . . . . . . . . . . . . . . . . . . . . = 3 1.1. ForCES Protocol . . . . = . . . . . . . . . . . . . . . . . 3
= 1.2. ForCES FE Model . . . . . . . . . . . . . . . . . . . . . = 3 1.2. ForCES FE Model . . . . = . . . . . . . . . . . . . . . . . 3
= 1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . = 3 = 1.3. Transport Mapping Layer . . . . . . . . . . . . . . . . . 4
2. Terminology and = Conventions . . . . . . . . . . . . . . . . . 5 = 1.4. = Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language = . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . = . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Definitions . = . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Date, Location, and Participants . . = . . . . . . . . . . 4
3. Overview . . . . . = . . . . . . . . . . . . . . . . . . . . . . = 7 = 2.2. Testbed Configuration . . . . . . . . . . . . . . . . . . = 5
3.1. Date, = Location, and Participants . . . . . . . . . . . . . 7 2.2.1. Participants Access . . . . . . . = . . . . . . . . . . 5
3.2. Testbed = Configuration . . . . . . . . . . . . . . . . . . 7 2.2.2. Testbed Configuration . . . . . . = . . . . . . . . . . 6
3.2.1. = Participants Access . . . . . . . . . . . . . . . . . 7 3. Scenarios . . . . . . . . . . . . . . . . = . . . . . . . . . . 7
3.2.2. Testbed = Configuration . . . . . . . . . . . . . . . . 8 3.1. Scenario 1 - LFB Operation . . . . . = . . . . . . . . . . 7
4. Scenarios . . . . = . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Scenario 2 - TML with IPSec . . . . . = . . . . . . . . . . 8
4.1. Scenario 1 - = LFB Operation . . . . . . . . . . . . . . . . = 11 = 3.3. Scenario 3 - CE High Availability . . . . . . . . . . . . = 9
4.2. Scenario 2 - = TML with IPSec . . . . . . . . . . . . . . . 11 3.4. Scenario 4 - Packet forwarding . . . = . . . . . . . . . . 10
4.3. Scenario 3 - = CE High Availability . . . . . . . . . . . . 12 4. Test Results . . . . . . . . . . . . . . = . . . . . . . . . . 12
4.4. Scenario 4 - = Packet forwarding . . . . . . . . . . . . . . = 14 = 4.1. LFB Operation Test . . . . . . . . . . . . . . . . . . . = 12
5. Test Results . . . = . . . . . . . . . . . . . . . . . . . . . . = 17 = 4.2. TML with IPSec Test . . . . . . . . . . . . . . . . . . . = 18
5.1. LFB Operation = Test . . . . . . . . . . . . . . . . . . . . = 17 = 4.3. CE High Availability Test . . . . . . . . . . . . . . . . = 19
5.2. TML with IPSec = Test . . . . . . . . . . . . . . . . . . . 23 4.4. Packet Forwarding Test . . . . . . . = . . . . . . . . . . 19
5.3. CE High = Availability Test . . . . . . . . . . . . . . . . 23 5. Discussions . . . . . . . . . . . . . . . = . . . . . . . . . . 22
5.4. Packet = Forwarding Test . . . . . . . . . . . . . . . . . . 24 5.1. On Data Encapsulation Format . . . . = . . . . . . . . . . 22
6. Discussions . . . = . . . . . . . . . . . . . . . . . . . . . . 27 6. Contributors . . . . . . . . . . . . . . = . . . . . . . . . . 24
6.1. On Data = Encapsulation Format . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . = . . . . . . . . . . 25
7. Contributors . . . = . . . . . . . . . . . . . . . . . . . . . . = 30 = 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 25
8. Acknowledgements . = . . . . . . . . . . . . . . . . . . . . . . = 31 = 9. Security Considerations . . . . . . . . . . . . . . . . . . . = 25
9. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . = . . . . . . . . . . 25
10. Security = Considerations . . . . . . . . . . . . . . . . . . . 33 10.1. Normative References . . . . . . . . = . . . . . . . . . . 26
11. References . . . . = . . . . . . . . . . . . . . . . . . . . . . = 34 = 10.2. Informative References . . . . . . . . . . . . . . . . . = 26
11.1. Normative = References . . . . . . . . . . . . . . . . . . . = 34 Authors' Addresses . . = . . . . . . . . . . . . . . . . . . . . . 27
11.2. Informative = References . . . . . . . . . . . . . . . . . . = 34
= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. = Introduction 1. Introduction
= This document captures results of the second interoperability test = of This document captures results = of the second interoperability test of
= the Forwarding and Control Element Separation (ForCES) which = took the Forwarding and Control = Element Separation (ForCES) which took
= place February 24-25, 2011 in the Internet Technology Lab (ITL) = of place February 24-25, 2011 in = the Internet Technology Lab (ITL) of
= Zhejiang Gongshang University, China. The test involved = several Zhejiang Gongshang = University, China. The test involved protocol
= documents namely: ForCES protocol = [RFC5810] , ForCES FE model elements described in = several documents namely:
= [RFC5812] , ForCES TML [RFC5811] , = ForCES LFB Library =
= [I-D.ietf-forces-lfb-lib] and ForCES = CE HA specification - ForCES Protocol [RFC5810]
= [I-D.ietf-forces-ceha]. Three independent ForCES = implementations - ForCES Forwarding = Element Model [RFC5812]
= participated in the test. = - ForCES Transport = Mapping Layer [RFC5811]
=
The test also involved protocol elements described in = the then-
current versions of two Internet-Drafts. Although = these documents
have subsequently been revised and advanced, it is = important to
understand which versions of the work were used = during this test.
The then-current Internet-Drafts are:
- ForCES Logical = Function Block (LFB) Library
[I-D.ietf-forces-lfb-lib-03].
- ForCES Intra-NE = High Availability [I-D.ietf-forces-ceha-00].
=
Three = independent ForCES implementations participated in the test.
= Scenarios of ForCES LFB Operation, TML with IPSec, CE High = Scenarios of ForCES LFB Operation, TML with = IPSec, CE High
= Availability, and Packet Forwarding are constructed. Series of = Availability, and Packet Forwarding are = constructed. Series of
= testing items for every scenario are carried out and = interoperability testing items for = every scenario are carried out and interoperability
= results are achieved. Popular packet analyzers Ethereal/ = results are achieved. Popular packet = analyzers Ethereal/
= Wireshark[Ethereal] and Tcpdump[Tcpdump] are used to verify the = wire Wireshark[Ethereal] and = Tcpdump[Tcpdump] are used to verify the wire
= results. results.
= This document is an update to [RFC6053], = which captured the results This = document is an update to RFC 6053, which = captured the results of
= of the first ForCES interoperability test. The first test on = ForCES the first ForCES = interoperability test. The first test on ForCES was
= was held in July 2008 at the University of Patras, Greece. The test = held in July 2008 at the University of Patras, Greece. That test
= focused on validating the basic semantics of the ForCES protocol = and focused on validating the basic = semantics of the ForCES protocol and
= ForCES FE model. The test results were = captured by [RFC6053] . = ForCES FE model.
1.1. ForCES Protocol 1.1. ForCES Protocol
= The ForCES protocol works in a master-slave mode in which FEs = are The ForCES protocol works in a = master-slave mode in which FEs are
= slaves and CEs are masters. The protocol includes commands for = slaves and CEs are masters. The protocol = includes commands for
= transport of Logical Function Block (LFB) configuration = information, transport of Logical = Function Block (LFB) configuration information,
= association setup, status, and event notifications, etc. The = reader association setup, status, = and event notifications, etc. The reader
= is encouraged to read the ForCES protocol specification [RFC5810] = for is encouraged to read the = ForCES protocol specification [RFC5810] for
= further information. further = information.
1.2. ForCES FE Model 1.2. ForCES FE Model
= = The ForCES FE model [RFC5812] = presents a formal way to define FE
= The ForCES FE model [RFC5812] presents a formal way to define = FE
= Logical Function Blocks (LFBs) using XML. LFB configuration = Logical Function Blocks (LFBs) using XML. = LFB configuration
= components, capabilities, and associated events are defined when = the components, capabilities, and = associated events are defined when the
= LFB is formally created. The LFBs within the FE are = accordingly LFB is formally = created. The LFBs within the FE are accordingly
= controlled in a standardized way by the ForCES protocol. = controlled in a standardized way by the = ForCES protocol.
1.3. Transport Mapping Layer 1.3. Transport Mapping Layer
= The ForCES Transport Mapping Layer (TML) transports the ForCES = The ForCES Transport Mapping Layer (TML) = transports the ForCES
= Protocol Layer (PL) messages. The TML is where the issues of how = to Protocol Layer (PL) messages. = The TML is where the issues of how to
= achieve transport level reliability, congestion control, = multicast, achieve transport level = reliability, congestion control, multicast,
= ordering, etc are handled. It is expected that more than one = TML ordering, etc are handled. It = is expected that more than one TML
= will be standardized. The various possible = TMLs could vary their will = be standardized. RFC 5811 specifies an = SCTP-Based Transport
implementations based on the = capabilities of underlying media and Mapping Layer (TML) for ForCES protocol, which is a mandated TML for
transport. However, since = each TML is standardized, interoperability ForCES. See RFC 5811 for = more details.
is guaranteed as long as both = endpoints support the same TML. All
ForCES Protocol Layer = implementations MUST be portable across = all
TMLs. Although more than one = TML may be standardized for the = ForCES
= Protocol, for the purposes of the = interoperability test, the mandated
= MUST IMPLEMENT SCTP TML [RFC5811] was be used.
2. Terminology and = Conventions
2.1. Requirements = Language
The key words "MUST", "MUST = NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", = "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be = interpreted as described in [RFC2119].
2.2. = Definitions 1.4. Definitions
= This document follows the terminology defined by ForCES related = This document follows the terminology = defined by ForCES related
= documents, including RFC3654, RFC3746, RFC5810, RFC5811, = RFC5812, documents, including = RFC3654, RFC3746, RFC5810, RFC5811, RFC5812,
= RFC5813, etc. Some definitions are repeated = below for clarity. RFC5813, = etc.
Control Element (CE) - A = logical entity that implements the ForCES
protocol and uses it to = instruct one or more FEs on how to process
packets. CEs handle = functionality such as the execution of
control and signaling = protocols.
Forwarding Element (FE) - = A logical entity that implements the
ForCES protocol. FEs use = the underlying hardware to provide per-
packet processing and = handling as directed/controlled by one or
more CEs via the ForCES = protocol.
LFB (Logical Functional = Block) - The basic building block that is
operated on by the ForCES = protocol. The LFB is a well defined,
logically separable = functional block that resides in an FE and is
controlled by the CE via = the ForCES protocol. The LFB may reside
at the FE's datapath and = process packets or may be purely an FE
control or configuration = entity that is operated on by the CE.
Note that the LFB is a = functionally accurate abstraction of the
FE's processing = capabilities, but not a hardware-accurate
representation of the FE = implementation.
LFB Class and LFB Instance = - LFBs are categorized by LFB Classes.
An LFB Instance represents = an LFB Class (or Type) existence.
There may be multiple = instances of the same LFB Class (or Type) in
an FE. An LFB Class is = represented by an LFB Class ID, and an LFB
Instance is represented by = an LFB Instance ID. As a result, an
LFB Class ID associated = with an LFB Instance ID uniquely specifies
an LFB = existence.
LFB Metadata - Metadata is = used to communicate per-packet state
from one LFB to another, = but is not sent across the network. The
FE model defines how such = metadata is identified, produced, and
consumed by the LFBs. It = defines the functionality but not how
metadata is encoded within = an implementation.
LFB Components - = Operational parameters of the LFBs that must be
visible to the CEs are = conceptualized in the FE model as the LFB
components. The LFB = components include, for example, flags,
single-parameter = arguments, complex arguments, and tables that the =
CE can read and/or write = via the ForCES protocol.
ForCES Protocol - While = there may be multiple protocols used
within the overall ForCES = architecture, the term "ForCES protocol"
and "protocol" refer to = the "Fp" reference points in the ForCES
framework in [RFC3746] . = This protocol does not apply to CE-to-CE
communication, FE-to-FE = communication, or to communication between
FE and CE managers. = Basically, the ForCES protocol works in a
master-slave mode in which = FEs are slaves and CEs are masters.
ForCES Protocol Transport = Mapping Layer (ForCES TML) - A layer in
ForCES protocol = architecture that uses the capabilities of
existing transport = protocols to specifically address protocol
message transportation = issues, such as how the protocol messages
are mapped to different = transport media (like TCP, IP, ATM,
Ethernet, etc.), and how = to achieve and implement reliability,
multicast, ordering, etc. = The ForCES TML specifications are
detailed in separate = ForCES documents, one for each TML.
3. Overview = 2. = Overview
3.1. Date, Location, and = Participants 2.1. Date, Location, and Participants
= The second ForCES interoperability test meeting was held by = IETF The second ForCES = interoperability test meeting was held by IETF
= ForCES Working Group on February 24-25, 2011, and was chaired = by ForCES Working Group on February = 24-25, 2011, and was chaired by
= Jamal Hadi Salim. Three independent ForCES implementations = Jamal Hadi Salim. Three independent ForCES = implementations
= participated in the test: = participated in the test:
= * Zhejiang Gongshang University/Hangzhou = BAUD Corporation of o Zhejiang Gongshang University/Hangzhou BAUD = Corporation of
= Information and Networks Technology (Hangzhou BAUD Networks), = China. Information and Networks = Technology (Hangzhou BAUD Networks),
= This implementation is referred to as "China" or in some cases "C" = in China. This implementation = is referred to as "China" or in some
= the document for the sake of brevity. cases "C" in the document for the sake of = brevity.
= * NTT Corporation, Japan. This = implementation is referred to as = =
= "Japan" or in some cases "J" in the document for the sake of = brevity. o NTT Corporation, Japan. This implementation = is referred to as
= * The University of Patras, Greece. = This implementation is referred = "Japan" or in some cases "J" in the document for the sake of
= to as "Greece" or in some cases "G" in the document for the sake = of brevity.
= brevity. =
o The University of Patras, Greece. This = implementation is referred
to as = "Greece" or in some cases "G" in the document for the sake
of = brevity.
= Two other organizations, Mojatatu Networks and Hangzhou BAUD = Networks Two other organizations, = Mojatatu Networks and Hangzhou BAUD Networks
= Corporation, which independently extended two different well = known Corporation, which = independently extended two different well known
= public domain protocol analyzers, Ethereal/Wireshark [Ethereal] = and public domain protocol = analyzers, Ethereal/Wireshark [Ethereal] and
= Tcpdump [Tcpdump], also participated in the interop test. During = the Tcpdump [Tcpdump], also = participated in the interop test. During the
= interoperability test, the two protocol analyzers were used to = verify interoperability test, the = two protocol analyzers were used to verify
= the validity of ForCES protocol messages and in some cases = semantics. the validity of ForCES = protocol messages and in some cases semantics.
= Some issues related to interoperability among implementations = were Some issues related to = interoperability among implementations were
= discovered. Most of the issues were solved on site during the = test. discovered. Most of the = issues were solved on site during the test.
= The most contentious issue found was on the format of = encapsulation The most contentious = issue found was on the format of encapsulation
= for protocol TLV (Refer to Section 6.1 = ). for protocol TLV (Refer to = Section 5.1 ).
= Some errata related to ForCES document were found by the = Some errata related to ForCES document were = found by the
= interoperability test. The errata has been reported to related = IETF interoperability test. The = errata has been reported to related IETF
= RFCs. RFCs.
= At times, interoperability testing was exercised between two = instead At times, interoperability = testing was exercised between two instead
= of all three representative implementations due to a third one = of all three representative implementations = due to a third one
= lacking a specific feature; however, in ensuing discussions, = all lacking a specific feature; = however, in ensuing discussions, all
= implementers mentioned they will be implementing any missing = features implementers mentioned = they will be implementing any missing features
= in the future. in the = future.
3.2. Testbed = Configuration 2.2. Testbed Configuration
3.2.1. Participants = Access 2.2.1. Participants Access
= Japan and China physically attended on site at the Internet = Japan and China physically attended on site = at the Internet
= Technology Lab (ITL) of Zhejiang Gongshang University in China. = The Technology Lab (ITL) of = Zhejiang Gongshang University in China. The
= University of Patras implementation joined remotely from Greece. = The University of Patras = implementation joined remotely from Greece. The
= chair, Jamal Hadi Salim, joined remotely from Canada by using = the chair, Jamal Hadi Salim, joined = remotely from Canada by using the
= Teamviewer as the monitoring tool[Teamviewer]. The approach is = as Teamviewer as the monitoring = tool[Teamviewer]. The approach is as
= shown in Figure 1. In the figure, FE/CE refers to FE or CE that = the shown in Figure 1. In the = figure, FE/CE refers to FE or CE that the
= implementer may act alternatively. = implementer may act alternatively.
= +---------+ +----+ +----------+ = +---------+ +----+ = +----------+
=
skipping to change at page 8, line 21 = skipping to change at = page 5, line 46
= | China |-----| | /\/\/\/\/\ | |(TeamViewer) = | China |-----| | /\/\/\/\/\ | = |(TeamViewer)
= +---------+ | | \Internet/ | | Canada | = +---------+ | | \Internet/ | = | Canada |
= |LAN |----/ \--| +----------+ = |LAN |----/ \--| = +----------+
= +---------+ | | \/\/\/\/\/ | +----------+ = +---------+ | | \/\/\/\/\/ | = +----------+
= | FE/CE |-----| | | | FE/CE | = | FE/CE |-----| | | = | FE/CE |
= | Japan | | | +---| Greece | = | Japan | | | = +---| Greece |
= +---------+ +----+ +----------+ = +---------+ +----+ = +----------+
= Figure 1: Access for Participants Figure 1: Access for = Participants
= As specified in RFC 5811, all CEs and FEs SHALL implement IPSec As specified in RFC 5811, all CEs and FEs shall implement IPSec
= security in the TML. security in = the TML.
= On the internet boundary, gateways used MUST allow for IPSec, SCTP On the internet boundary, gateways used must allow for IPSec, SCTP
= protocol and SCTP ports as defined in the ForCES SCTP-TML [RFC5811] = . protocol and SCTP ports as = defined in the ForCES SCTP-TML [RFC5811] .
3.2.2. Testbed = Configuration 2.2.2. Testbed Configuration
= CEs and FEs from China and Japan implementations were = physically CEs and FEs from China = and Japan implementations were physically
= located within the ITL Lab of Zhejiang Gongshang University and = located within the ITL Lab of Zhejiang = Gongshang University and
= connected together using Ethernet switches. The configuration can = be connected together using = Ethernet switches. The configuration can be
= seen in Figure 2. In the figure, the SmartBits is a = third-party seen in Figure 2. In = the figure, the SmartBits is a third-party
= supplied routing protocol testing machine, which acts as a = router supplied routing protocol = testing machine, which acts as a router
= running OSPF and RIP and exchanges routing protocol messages = with running OSPF and RIP and = exchanges routing protocol messages with
= ForCES routers in the network. The Internet is connected via an = ADSL ForCES routers in the network. = The Internet is connected via an ADSL
= channel. channel.
= /\/\/\/\/\ = /\/\/\/\/\
= \Internet/ = \Internet/
= / \ = / \
= \/\/\/\/\/ = \/\/\/\/\/
= | = |
= |124.90.146.218 (ADSL) |124.90.146.218 = (ADSL)
= | = |
+-------------------------------------------------------= -----------+ = +------------------------------------------------------------------+
| LAN (10.20.0.0/24) = | | = LAN (10.20.0.0/24) |
+-------------------------------------------------------= -----------+ = +------------------------------------------------------------------+
= | | | | | = | | | | = | | |
= | | | | | = | | | | = | | |
= |.222 |.230 |.221 |.179 |.231 = |.220 |.222 |.230 |.221 = |.179 |.231 |.220
+-----+ +-----+ +-----+ +-----+ = +-----+ +---------+ +-----+ = +-----+ +-----+ +-----+ +-----+ +---------+
| CE | | CE | | | | | | = | | Protocol| | CE | | CE | = | | | | | | | Protocol|
|China| |Japan| | FE1 |.1 .2| FE |.1 .2| = FE2 | | Analyzer| |China| = |Japan| | FE1 |.1 .2| FE |.1 .2| FE2 | | Analyzer|
+-----+ +-----+ |China|---------|Japan|----------|China| = +---------+ +-----+ +-----+ = |China|---------|Japan|---------|China| = +---------+
= +---------| |192.169. | | 192.168. = | |-------+ = +---------| |192.169. | | 192.168.| = |------+
= | .2 +-----+ 20.0.24 +-----+ 30.0/24 = +-----+ .2 | | = .2 +-----+ 20.0.24 +-----+ 30.0/24+-----+ .2 |
= | .12| |.12 = | | .12| = |.12 |
= | | | = | | | = | |
= 192.168.50.0/24 | | 192.168.60.0/24 192.168.50.0/24 | = |192.168.60.0/24
= | 192.168.10.0/24 192.168.40.0/24 = | | 192.168.10.0/24 = 192.168.40.0/24 |
= .1 | |.11 |.11 = |.1 .1 | |.11 = |.11 |.1
= +--------+ +---------------------------------------+ = +--------+ +--------+ +--------------------------------------+ = +--------+
= |Terminal| | Smartbits | = |Terminal| |Terminal| | = Smartbits | |Terminal|
= +--------+ +---------------------------------------+ = +--------+ +--------+ +--------------------------------------+ = +--------+
= Figure 2: Testbed Configuration Located in ITL Lab,China = Figure 2: Testbed Configuration = Located in ITL Lab,China
= Hardware and Software (CE and FE) of Greece those were located = within Hardware and Software (CE = and FE) of Greece those were located within
= the University of Patras, Greece, were connected together using = LAN the University of Patras, = Greece, were connected together using LAN
= as shown in Figure 3. The Internet is connected via a VPN = channel. as shown in Figure 3. The = Internet is connected via a VPN channel.
= /\/\/\/\/\ /\/\/\/\/\
= \Internet/ \Internet/
= / \ / \
= \/\/\/\/\/ \/\/\/\/\/
= = | = |
= |150.140.254.110(VPN) = |150.140.254.110(VPN)
= | = |
= +------------------------------------+ = +------------------------------------+
= | LAN | | LAN = |
= +------------------------------------+ = +------------------------------------+
= | | | | | |
= | | | | | |
= +------+ +--------+ +------+ +------+ +--------+ = +------+
= | FE | |Protocol| | CE | | FE | |Protocol| | CE = |
= |Greece| |Analyzer| |Greece| |Greece| |Analyzer| = |Greece|
= +------+ +--------+ +------+ +------+ +--------+ = +------+
= Figure 3: Testbed Configuration Located in the University = of Figure 3: Testbed = Configuration Located in the University of
= Patras,Greece Patras,Greece
= All above testbed configurations can then satisfy requirements of = all All above testbed = configurations can then satisfy requirements of all
= the interoperability test scenarios that are mentioned in this = the interoperability test scenarios that are = mentioned in this
= document. document.
4. Scenarios = 3. = Scenarios
4.1. Scenario 1 - LFB = Operation 3.1. Scenario 1 - LFB Operation
= This scenario is to test the interoperability on LFB operations = among This scenario is to test the = interoperability on LFB operations among
= the participants. The connection diagram for the participants is = as the participants. The = connection diagram for the participants is as
= shown in Figure 4. shown in Figure = 4.
= +------+ +------+ +------+ +------+ +------+ = +------+ +------+ +------+ = +------+ +------+ +------+ +------+
= | CE | | CE | | CE | | CE | | CE | | CE = | | CE | | CE | | CE | = | CE | | CE | | CE |
= | China| | Japan| | China| |Greece| | Japan| = |Greece| | China| | Japan| | = China| |Greece| | Japan| |Greece|
= +------+ +------+ +------+ +------+ +------+ = +------+ +------+ +------+ = +------+ +------+ +------+ +------+
= | | | | | = | | | | = | | |
= | | | | | = | | | | = | | |
= +------+ +------+ +------+ +------+ +------+ = +------+ +------+ +------+ = +------+ +------+ +------+ +------+
= | FE | | FE | | FE | | FE | | FE | | FE = | | FE | | FE | | FE | = | FE | | FE | | FE |
= |Japan | |China | |Greece| |China | |Greece| |Japan = | |Japan | |China | |Greece| = |China | |Greece| |Japan |
= +------+ +------+ +------+ +------+ +------+ = +------+ +------+ +------+ = +------+ +------+ +------+ +------+
= Figure 4: Scenario for LFB Operation Figure 4: Scenario for LFB = Operation
= In order to make interoperability more credible, the three = In order to make interoperability more = credible, the three
= implementers are required to carry out the test in a way acting as = CE implementers are required to = carry out the test in a way acting as CE
= or FE alternatively. As a result, every LFB operation is = combined or FE alternatively. As a = result, every LFB operation is combined
= with 6 scenarios, as shown by Figure 4. with 6 scenarios, as shown by Figure 4.
= The test scenario is designed with the following purposes: = The test scenario is designed with the = following purposes:
= Firstly, the scenario is designed to verify all kinds of = protocol Firstly, the scenario is = designed to verify all kinds of protocol
= messages with their complex data formats, which are defined in = RFC messages with their complex = data formats, which are defined in RFC
= 5810. Specially, we try to verify the data format of a = PATH-DATA 5810. Specially, we try = to verify the data format of a PATH-DATA
= with nested PATH-DATAs, and the operation(SET, GET, DEL) of an = array with nested PATH-DATAs, and = the operation(SET, GET, DEL) of an array
= or an array with a nested array. or = an array with a nested array.
= Secondly, the scenario is designed to verify the definition of = ForCES Secondly, the scenario is = designed to verify the definition of ForCES
= LFB Library[FORCES-LFBLIB], which = defines a base set of ForCES LFB = LFB Library [I-D.ietf-forces-lfb-lib-03], = which defines a base set of
= classes for typical router functions. Successful test under = this ForCES LFB classes for = typical router functions. Successful test
= scenario also means the validity of the LFB definitions. = under this scenario also means the validity = of the LFB definitions.
4.2. Scenario 2 - TML = with IPSec 3.2. Scenario 2 - TML with IPSec
= This scenario is designed to implement a TML with IPSec, which is = the This scenario is designed to = implement a TML with IPSec, which is the
= requirement by RFC 5811. TML with IPSec was not implemented in = the requirement by RFC 5811. TML = with IPSec was not implemented in the
= first ForCES interoperability test as reported by RFC 6053. For = this first ForCES interoperability = test as reported by RFC 6053. For this
= reason, in the second interoperability test, we specifically = designed reason, in the second = interoperability test, we specifically designed
= the test scenario to verify the TML over IPSec channel. = the test scenario to verify the TML over = IPSec channel.
= In this scenario, tests on LFB operations for Scenario 1 were = In this scenario, tests on LFB operations = for Scenario 1 were
= repeated with the difference that TML was secured via IPSec. = This repeated with the difference = that TML was secured via IPSec. This
= setup scenario allows us to verify whether all interactions = between setup scenario allows us to = verify whether all interactions between
= CE and FE can be made correctly under an IPSec TML environment. = CE and FE can be made correctly under an = IPSec TML environment.
= The connection diagram for this scenario is shown as Figure 5. = The connection diagram for this scenario is = shown as Figure 5.
= Because of system deficiency to deploy IPSec over TML in Greece, = the Because of system deficiency to = deploy IPSec over TML in Greece, the
= text only took place between China and Japan. text only took place between China and Japan.
= +------+ +------+ +------+ +------+
= | CE | | CE | | CE | | CE |
= | China| | Japan| | China| | Japan|
= +------+ +------+ +------+ +------+
= | | | |
= |TML over IPSec |TML over IPSec = |TML over IPSec |TML = over IPSec
= +------+ +------+ +------+ +------+
= | FE | | FE | | FE | | FE |
= |Japan | |China | |Japan | |China |
= +------+ +------+ +------+ +------+
= Figure 5: Scenario for LFB Operation with TML over IPSec = Figure 5: Scenario for LFB Operation = with TML over IPSec
= In this scenario, ForCES TML was run over IPSec channel. = In this scenario, ForCES TML was run over = IPSec channel.
= Implementers joined in this interoperability have used the same = Implementers joined in this interoperability = have used the same
= third-party software 'racoon' to have established the IPSec = channel. third-party software = 'racoon' to have established the IPSec channel.
= China and Japan have made a successful test with the scenario, = and China and Japan have made a = successful test with the scenario, and
= the following items have been realized: the following items have been realized:
= o Internet Key Exchange (IKE) with certificates for endpoint = o Internet Key Exchange (IKE) with = certificates for endpoint
= authentication. = authentication.
= o Transport Mode Encapsulating Security Payload (ESP). = HMAC-SHA1-96 o Transport Mode = Encapsulating Security Payload (ESP). HMAC-SHA1-96
= [RFC2404] for message integrity = protection. for message = integrity protection.
4.3. Scenario 3 - CE = High Availability 3.3. Scenario 3 - CE High Availability
= CE High Availability (CEHA) was tested based on the ForCES CEHA = CE High Availability (CEHA) was tested based = on the ForCES CEHA
= document [ForCES-CEHA]. = document [I-D.ietf-forces-ceha-00]
= The design of the setup and the scenario for the CEHA were = simplified The design of the setup = and the scenario for the CEHA were simplified
= so as to focus mostly on the mechanics of the CEHA, which are: = so as to focus mostly on the mechanics of = the CEHA, which are:
= o Associating with more than one CE. = o Associating with more than one CE.
= o Switching to backup CE on master CE failure. o Switching to backup CE on master CE = failure.
= The connection diagram for the scenario is as shown in Figure = 6. The connection diagram for the = scenario is as shown in Figure 6.
= master standby master standby = master standby master = standby
= +------+ +------+ +------+ +------+ = +------+ +------+ = +------+ +------+
= | CE | | CE | | CE | | CE | = | CE | | CE | | CE = | | CE |
= | China| |Greece| |Japan | |Greece| = | China| |Greece| |Japan = | |Greece|
= +------+ +------+ +------+ +------+ = +------+ +------+ = +------+ +------+
= | | | | = | | | = |
= +----------+ +-----------+ = +----------+ = +-----------+
= | | | |
= +------+ +------+ +------+ +------+
= | FE | | FE | | FE | | FE |
= |Greece| |Greece| |Greece| |Greece|
= +------+ +------+ +------+ +------+
= (a) (b) (a) = (b)
= Figure 6: Scenario for CE High Availability = Figure 6: Scenario for CE High = Availability
= In this scenario one FE is connected and associated to a master = CE In this scenario one FE is = connected and associated to a master CE
= and a backup CE. In the pre-association phase, the FE would be = and a backup CE. In the pre-association = phase, the FE would be
= configured to have China's or Japan's CE as master CE and Greece's = CE configured to have China's or = Japan's CE as master CE and Greece's CE
= as standby CE. The CEFailoverPolicy component of the FE = Protocol as standby CE. The = CEFailoverPolicy component of the FE Protocol
= Object LFB that specifies whether the FE is in High Availability = mode Object LFB that specifies = whether the FE is in High Availability mode
= (value 2 or 3) would either be set in the pre-association phase = by (value 2 or 3) would either be = set in the pre-association phase by
= the FEM interface or in post-association phase by the master = CE. the FEM interface or in = post-association phase by the master CE.
=
skipping to change at page 14, line = 15 skipping to = change at page 10, line 38
= 4. Once the master CE is considered disconnected then the FE = chooses 4. Once the master CE is = considered disconnected then the FE chooses
= the first Associated backup CE. = the first Associated backup CE.
= 5. It sends an Event Notification specifying that the master CE = is 5. It sends an Event = Notification specifying that the master CE is
= down and who is now the master CE. down and who is now the master CE.
= 6. The new master CE sends a SET Configuration message to the = FE 6. The new master CE sends a = SET Configuration message to the FE
= setting the CEID value to who is now the new master CE = completing setting the CEID = value to who is now the new master CE completing
= the switch. the = switch.
4.4. Scenario 4 - Packet = forwarding 3.4. Scenario 4 - Packet forwarding
= This test scenario is to verify LFBs like RedirectIn, = RedirectOut, This test scenario is = to verify LFBs like RedirectIn, RedirectOut,
= IPv4NextHop, IPv4UcastLPM defined by the ForCES LFB library = IPv4NextHop, IPv4UcastLPM defined by the = ForCES LFB library document
= document[ForCES-LFBLIB], and more = importantly, to verify the [I-D.ietf-forces-lfb-lib-03], and more = importantly, to verify the
= combination of the LFBs to implement IP packet forwarding. = combination of the LFBs to implement IP = packet forwarding.
= The connection diagram for this scenario is as Figure 7. = The connection diagram for this scenario is = as Figure 7.
= +------+ +------+
= | CE | | CE |
= | Japan| | Japan|
= +------+ +------+
= | ^ = | ^
= | | OSPF | | OSPF
= | +-------> | = +------->
= +------+ +------+ +------+ = +------+
= +--------+ | FE | | OSPF | = +--------+ +--------+ = | FE | | OSPF | +--------+
= |Terminal|------|China = |-------|Router|------|Terminal| = |Terminal|------|China = |-------|Router|------|Terminal|
= +--------+ +------+ +------+ = +--------+ +--------+ = +------+ +------+ +--------+
= = <--------------------------------------------> = <-------------------------------------------->
= Packet Forwarding Packet Forwarding
= (a) (a)
= +------+ +------+
= | CE | | CE |
= | China| | China|
= +------+ +------+
= ^ | ^ ^ | ^
= OSPF | | | OSPF OSPF | | | = OSPF
= <-----+ | +-----> = <-----+ | = +----->
= +-------+ +------+ +------+ = +-------+ +------+ = +------+
= +--------+ | OSPF | | FE | | OSPF | = +--------+ +--------+ | = OSPF | | FE | | OSPF | +--------+
= |Terminal|----|Router |----|Japan |-----|Router|----|Terminal| |Terminal|----|Router |----|Japan |-----|Router|--|Terminal|
= +--------+ +-------+ +------+ +------+ = +--------+ +--------+ = +-------+ +------+ +------+ +--------+
= <-------------------------------------------->
= Packet Forwarding
= (b) = <-------------------------------------------->
Packet = Forwarding
= +------+ = +------+ = (b)
| = CE | | CE |
| = Japan| | China|
= +------+ +------+
= | ^ ^ |
= | | OSPF | |
= | +----------+ |
= +------+ +------+
+--------+ | = FE | | FE | +--------+
= |Terminal|------|China |-------|Japan |------|Terminal| =
+--------+ = +------+ +------+ +--------+
= <--------------------------------------------> = +------+ +------+
= Packet Forwarding | CE | | CE = |
| Japan| | = China|
+------+ = +------+
| ^ ^ = |
| | OSPF | = |
| +----------+ = |
+------+ = +------+
+--------+ | FE | | FE | = +--------+
|Terminal|------|China |-------|Japan = |------|Terminal|
+--------+ +------+ +------+ = +--------+
= (c) <-------------------------------------------->
Packet = Forwarding
=
= (c)
= Figure 7: Scenario for IP Packet forwarding = Figure 7: Scenario for IP = Packet forwarding
= In case (a), a CE by Japan is connected to an FE by China to form = a In case (a), a CE by Japan is = connected to an FE by China to form a
= ForCES router. A Smartbits test machine with its routing = protocol ForCES router. A = Smartbits test machine with its routing protocol
= software are used to simulate an OSPF router and are connected = with software are used to simulate = an OSPF router and are connected with
= the ForCES router to try to exchange OSPF hello packets and LSA = the ForCES router to try to exchange OSPF = hello packets and LSA
= packets among them. Terminals are simulated by Smartbits to send = and packets among them. Terminals = are simulated by Smartbits to send and
= receive packets. As a result, the CE in the ForCES router need to = be receive packets. As a result, = the CE in the ForCES router need to be
= configured to run and support OSPF routing protocol. configured to run and support OSPF routing = protocol.
=
skipping to change at page 17, line 5 = skipping to change at = page 12, line 36
= 2. Boot CE and FE. 2. Boot CE and = FE.
= 3. Establish association between CE and FE, and set IP addresses = of 3. Establish association = between CE and FE, and set IP addresses of
= FEs interfaces. FEs = interfaces.
= 4. Start OSPF among CE and routers, and set FIB on FE. = 4. Start OSPF among CE and routers, and set = FIB on FE.
= 5. Send packets between terminals. = 5. Send packets between terminals.
5. Test Results = 4. Test = Results
5.1. LFB Operation = Test 4.1. LFB Operation Test
= The test result is as reported by Figure 8. For the = convenience The test result is as = reported by Figure 8. For the convenience
= sake, as mentioned earlier, abbreviations of 'C' in the table = means sake, as mentioned earlier, = abbreviations of 'C' in the table means
= implementation from China,'J'Japan implementation, and 'G' = Greece implementation from = China,'J'Japan implementation, and 'G' Greece
= implementation. = implementation.
= +-----+----+-----+-----+--------------+-------------------+---------+ = +-----+----+-----+-----+--------------+-------------------+---------+
= |Test#| CE |FE(s)|Oper | LFB | Component | Result = | |Test#| CE |FE(s)|Oper | LFB = | Component | Result |
= | | | | | | /Capability | = | | | | | | = | /Capability | |
= +-----+----+-----+-----+--------------+-------------------+---------+ = +-----+----+-----+-----+--------------+-------------------+---------+
=
skipping to change at page 23, line 5 = skipping to change at = page 18, line 33
= Note on test 28# and 29#: Note on = test 28# and 29#:
= Only had new reachable network destination been set, can route = entry Only had new reachable = network destination been set, can route entry
= be added into system. be added into = system.
= Note on test 30# and 31#: Note on = test 30# and 31#:
= Corresponding nexthop entry must be deleted before prefix entry = which Corresponding nexthop entry = must be deleted before prefix entry which
= is decided by FE's routing management. is decided by FE's routing management.
5.2. TML with IPSec = Test 4.2. TML with IPSec Test
= In this scenario, the ForCES TML is run over IPSec. = Implementers In this scenario, the = ForCES TML is run over IPSec. Implementers
= joined this interoperability test use the same third-party tool = joined this interoperability test use the = same third-party tool
= software 'racoon' to establish IPSec channel. Some typical LFB = software 'racoon' to establish IPSec = channel. Some typical LFB
= operation tests as in Scenario 1 are repeated with the IPSec = enabled operation tests as in = Scenario 1 are repeated with the IPSec enabled
= TML. TML.
= A note on this test is, because of the system difficulty to = implement A note on this test is, = because of the system difficulty to implement
= IPSec over TML, Greece did not join in the test. Therefore, = this IPSec over TML, Greece did not = join in the test. Therefore, this
= scenario only took place between C and J. scenario only took place between C and J.
=
skipping to change at page 23, line = 38 skipping to = change at page 19, line 18
= | | | | | | | = | | | | | | = | | |
= | 3 | C | J | SET | Ether | VlanInputTable | Success = | | 3 | C | J | SET | Ether = | VlanInputTable | Success |
= | | J | C | | Classifier | | Success = | | | J | C | | = Classifier | | Success |
= | | | | | | | = | | | | | | = | | |
= | 4 | C | J | DEL | Ether | VlanInputTable | Success = | | 4 | C | J | DEL | Ether = | VlanInputTable | Success |
= | | J | C | | Classifier | | Success = | | | J | C | | = Classifier | | Success |
= +-----+----+-----+-----+--------------+-------------------+---------+ = +-----+----+-----+-----+--------------+-------------------+---------+
= Figure 9: TML with IPSec Test Results Figure 9: TML with IPSec Test = Results
5.3. CE High = Availability Test 4.3. CE High Availability Test
= In this scenario one FE connects and associates with a master CE = and In this scenario one FE = connects and associates with a master CE and
= a backup CE. When the master CE is deemed disconnected the FE = would a backup CE. When the master = CE is deemed disconnected the FE would
= attempt to find another associated CE to become the master CE. = attempt to find another associated CE to = become the master CE.
= The CEHA scenario as is described in Scenario 3 was completed = The CEHA scenario as is described in = Scenario 3 was completed
= successfully for both setups. = successfully for both setups.
= Due to a bug in one of the FEs, a interesting issue was caught: = it Due to a bug in one of the FEs, = a interesting issue was caught: it
= was observed that the buggy FE took up to a second to failover. = It was observed that the buggy FE = took up to a second to failover. It
= was eventually found that the issue was due to the FE's = was eventually found that the issue was due = to the FE's
= prioritization of the different CEs. All messages from the backup = CE prioritization of the different = CEs. All messages from the backup CE
= were being ignored unless the master CE is disconnected. = were being ignored unless the master CE is = disconnected.
= While the bug was fixed and the CEHA scenario was completed = While the bug was fixed and the CEHA = scenario was completed
= successfully, the authors feel it was important to capture the = successfully, the authors feel it was = important to capture the
= implementation issue in this document. The recommended approach = is implementation issue in this = document. The recommended approach is
= the following: the = following:
= o The FE SHOULD receive and handle = messages first from the master CE = o The FE should receive and handle = messages first from the master CE
= on all priority channels to maintain proper functionality and = then on all priority channels to = maintain proper functionality and then
= receive and handle messages from the backup CEs. receive and handle messages from the backup = CEs.
= o Only when the FE is attempting to associate with the backup = CEs, o Only when the FE is = attempting to associate with the backup CEs,
= then the FE SHOULD receive and handle = messages per priority then the = FE should receive and handle messages per = priority
= channel from all CEs. When all backup CEs are associated with = or channel from all CEs. When = all backup CEs are associated with or
= deemed unreachable, then the FE SHOULD return to receiving and deemed unreachable, then the FE should return to receiving and
= handling messages first from the master CE. handling messages first from the master = CE.
5.4. Packet Forwarding = Test 4.4. Packet Forwarding Test
= As described in the ForCES LFB library = [I-D.ietf-forces-lfb-lib], As = described in the ForCES LFB library [I-D.ietf-forces-lfb-lib-03],
= packet forwarding is implemented by a set of LFB classes that = compose packet forwarding is = implemented by a set of LFB classes that compose
= a processing path for packets. In this test scenario, as shown = in a processing path for packets. = In this test scenario, as shown in
= Figure 7, a ForCES router running OSPF protocol was constructed. = In Figure 7, a ForCES router = running OSPF protocol was constructed. In
= addition, a set of LFBs including RedirectIn, RedirectOut, = addition, a set of LFBs including = RedirectIn, RedirectOut,
= IPv4UcastLPM, and IPv4NextHop LFBs are used. RedirectIn and = IPv4UcastLPM, and IPv4NextHop LFBs are used. = RedirectIn and
= RedirectOut LFBs redirect OSPF hello and LSA packets from and to = CE. RedirectOut LFBs redirect OSPF = hello and LSA packets from and to CE.
= A Smartbits test machine is used to simulate an OSPF router and = A Smartbits test machine is used to simulate = an OSPF router and
= exchange the OSPF hello and LSA packets with CE in ForCES = router. exchange the OSPF hello and = LSA packets with CE in ForCES router.
= Cases (a) and (b) in Figure 7 both need a RedirectIn LFB to send = OSPF Cases (a) and (b) in Figure 7 = both need a RedirectIn LFB to send OSPF
=
skipping to change at page 27, line 5 = skipping to change at = page 22, line 15
= Comment on Test #16 and #17: = Comment on Test #16 and #17:
= The two test items failed. Note that Test #7 and #8 are exactly = the The two test items failed. = Note that Test #7 and #8 are exactly the
= same as these tests, only with CE and FE implementers are = exchanged, same as these tests, = only with CE and FE implementers are exchanged,
= and Test #12 and #13 show the redirect channel works well. As = a and Test #12 and #13 show the = redirect channel works well. As a
= result, it can be inferred that the problem caused the test = failure result, it can be inferred = that the problem caused the test failure
= was almost certainly from the implementation of the related = LFBs was almost certainly from the = implementation of the related LFBs
= rather than from the ForCES protocol design problem, therefore = the rather than from the ForCES = protocol design problem, therefore the
= failure does not lead to the interoperability problem on = ForCES. failure does not lead to = the interoperability problem on ForCES.
6. Discussions = 5. = Discussions
6.1. On Data = Encapsulation Format 5.1. On Data Encapsulation Format
= In the first day of the test, it was found that the LFB inter- = In the first day of the test, it was found = that the LFB inter-
= operations about tables all failed. The reason is found to be = the operations about tables all = failed. The reason is found to be the
= different ForCES protocol data encapsulation method among = different different ForCES protocol = data encapsulation method among different
= implementations. The encapsulation issues are detailed as = below: implementations. The = encapsulation issues are detailed as below:
= Assuming that an LFB has two components, one is a struct with ID = 1 Assuming that an LFB has two = components, one is a struct with ID 1
= and the other an array with ID 2, further with two components of = u32 and the other an array with ID = 2, further with two components of u32
= both inside, as below: both inside, = as below:
= struct1: type struct, ID=3D1 = struct1: type struct, ID=3D1
= components are: = components are:
= a, type u32, ID=3D1 = a, type u32, ID=3D1
= b, type u32, ID=3D2 = b, type u32, ID=3D2
= table1: type array, ID=3D2 table1: = type array, ID=3D2
= components for each row are (a struct of): components for each row are (a struct = of):
= x, type u32, ID=3D1 = x, type u32, ID=3D1
= y, type u32, ID=3D2 = y, type u32, ID=3D2
= 1. On response of PATH-DATA format = 1. On response of PATH-DATA format
= When a CE sends a config/query ForCES protocol message to an FE = from When a CE sends a config/query = ForCES protocol message to an FE from
= a different implementer, the CE probably receives response from = the a different implementer, the CE = probably receives response from the
= FE with different PATH-DATA encapsulation format. For example, if = a FE with different PATH-DATA = encapsulation format. For example, if a
= CE sends a query message with a path of 1 to a third party FE = to CE sends a query message with a = path of 1 to a third party FE to
= manipulate struct 1 as defined above, the FE is probable to = generate manipulate struct 1 as = defined above, the FE is probable to generate
= response with two different PATH-DATA encapsulation format: one = is response with two different = PATH-DATA encapsulation format: one is
= the value with FULL/SPARSE-DATA and the other is the value with = many the value with = FULL/SPARSE-DATA and the other is the value with many
=
skipping to change at page 28, line 9 = skipping to change at = page 23, line 21
= PATH-DATA-TLV: = PATH-DATA-TLV:
= IDs=3D1 = IDs=3D1
= FULLDATA-TLV containing valueof(a) FULLDATA-TLV containing = valueof(a)
= PATH-DATA-TLV: = PATH-DATA-TLV:
= IDs=3D2 = IDs=3D2
= FULLDATA-TLV containing valueof(b) FULLDATA-TLV containing = valueof(b)
= The interoperability test witnessed that a ForCES element (CE or = FE) The interoperability test = witnessed that a ForCES element (CE or FE)
= sender is free to choose whatever data structure that IETF = ForCES sender is free to choose = whatever data structure that IETF ForCES
= documents define and best suits the element, while a ForCES = element documents define and best = suits the element, while a ForCES element
= (CE or FE) MUST be able to accept and = process information (requests (CE = or FE) should be able to accept and = process information (requests
= and responses) that use any legitimate structure defined by = IETF and responses) that use any = legitimate structure defined by IETF
= ForCES documents. While in the case a ForCES element is free = to ForCES documents. While in the = case a ForCES element is free to
= choose any legitimate data structure as a response, it is = preferred choose any legitimate = data structure as a response, it is preferred
= the ForCES element responds in the same format that the request = was the ForCES element responds in = the same format that the request was
= made, as it is most probably the data structure is the request = sender made, as it is most probably = the data structure is the request sender
= looks forward to receive. looks = forward to receive.
= 2. On operation to array 2. On = operation to array
= An array operation may also have several different data = encapsulation An array operation = may also have several different data encapsulation
=
skipping to change at page 30, line 5 = skipping to change at = page 24, line 36
= OPER =3D SET-TLV OPER =3D = SET-TLV
= PATH-DATA-TLV: = PATH-DATA-TLV:
= IDs=3D2 = IDs=3D2
= FULLDATA-TLV containing = rowindex=3D1,valueof(x),valueof(y) = FULLDATA-TLV containing = rowindex=3D1,valueof(x),valueof(y)
= The interoperability test experience shows that format 1 and = format The interoperability test = experience shows that format 1 and format
= 3, which take full advantage of multiple data elements description = in 3, which take full advantage of = multiple data elements description in
= one TLV of FULLDATA-TLV, get more efficiency, although format 2 = can one TLV of FULLDATA-TLV, get = more efficiency, although format 2 can
= also get the same operating goal. = also get the same operating goal.
7. Contributors = 6. = Contributors
= Contributors who have made major contributions to the Contributors who have made major contributions to = the
= interoperability test are as below: = interoperability test are as below:
= Hirofumi Yamazaki Hirofumi = Yamazaki
= NTT Corporation NTT = Corporation
= Tokyo Tokyo
= Japan Japan
= Email: yamazaki.horofumi@lab.ntt.co.jp Email: yamazaki.horofumi@lab.ntt.co.jp
=
skipping to change at page 31, line 5 = skipping to change at = page 25, line 19
= Tokyo Tokyo
= Japan Japan
= Email: yuta.watanabe@ntt-at.co.jp = Email: yuta.watanabe@ntt-at.co.jp
= Xiaochun Wu Xiaochun = Wu
= Zhejiang Gongshang University = Zhejiang Gongshang University
= Hangzhou Hangzhou
= P.R.China P.R.China
= Email: spring-403@zjsu.edu.cn = Email: spring-403@zjsu.edu.cn
8. = Acknowledgements 7. Acknowledgements
= The authors would also like thank the = following test participants: The = authors thank the following test participants:
= Chuanhuang Li, Hangzhou BAUD Networks Chuanhuang Li, Hangzhou BAUD Networks
= Ligang Dong, Zhejiang Gongshang University Ligang Dong, Zhejiang Gongshang University
Bin Zhuge, Zhejiang Gongshang = University
= Jingjing Zhou, Zhejiang Gongshang University Jingjing Zhou, Zhejiang Gongshang = University
= Liaoyuan Ke, Hangzhou BAUD Networks Liaoyuan Ke, Hangzhou BAUD Networks
= Kelei Jin, Hangzhou BAUD Networks = Kelei Jin, Hangzhou BAUD Networks
9. IANA = Considerations The authors also thank very much to Adrian Farrel and = Joel Halpern
for their important help in the document publication = process.
8. IANA Considerations
= This memo includes no request to IANA. This memo includes no request to IANA.
10. Security = Considerations 9. Security Considerations
= Developers of ForCES FEs and CEs must take the security = Developers of ForCES FEs and CEs must take = the security
= considerations of the ForCES Framework [RFC3746] and the = ForCES considerations of the = ForCES Framework [RFC3746] and the ForCES
= Protocol [RFC5810] into account. Also, as specified in the = security Protocol [RFC5810] into = account. Also, as specified in the security
= considerations section of the SCTP-Based TML for the ForCES = Protocol considerations section of = the SCTP-Based TML for the ForCES Protocol
= [RFC5811] the transport-level security, has to be ensured by IPsec. = [RFC5811], = the transport-level security has to be = ensured by IPsec.
= =
11. References =
11.1. Normative = References 10. = References
10.1. Normative References
= [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., = Wang, [RFC5810] Doria, A., Hadi = Salim, J., Haas, R., Khosravi, H., Wang,
= W., Dong, L., Gopal, R., and J. Halpern, "Forwarding = and W., Dong, L., Gopal, = R., and J. Halpern, "Forwarding and
= Control Element Separation (ForCES) Protocol = Control Element Separation = (ForCES) Protocol
= Specification", RFC 5810, March 2010. Specification", RFC 5810, March = 2010.
= [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport = Mapping [RFC5811] Hadi Salim, J. = and K. Ogawa, "SCTP-Based Transport Mapping
= Layer (TML) for the Forwarding and Control Element = Layer (TML) for the Forwarding = and Control Element
= Separation (ForCES) Protocol", RFC 5811, March 2010. = Separation (ForCES) Protocol", = RFC 5811, March 2010.
= [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and = Control [RFC5812] Halpern, J. and = J. Hadi Salim, "Forwarding and Control
= Element Separation (ForCES) Forwarding Element = Model", Element = Separation (ForCES) Forwarding Element Model", RFC
= RFC 5812, March 2010. = 5812, March 2010.
= [RFC5813] Haas, R., "Forwarding and Control Element Separation = [RFC5813] Haas, R., "Forwarding and Control = Element Separation
= (ForCES) MIB", RFC 5813, March 2010. (ForCES) MIB", RFC 5813, March = 2010.
11.2. Informative = References 10.2. Informative References
= [Ethereal] [Ethereal]
= "Ethereal, also named Wireshark, is a protocol = analyzer. , "Ethereal, also named Wireshark, is a protocol = analyzer.
= The specific Ethereal that was used is an updated = The specific Ethereal that was = used is an updated
= Ethereal, by Fenggen Jia, that can analyze and decode = the Ethereal, by Fenggen = Jia, that can analyze and decode the
= ForCES protocol messages", http://www.ietf.org/ ForCES protocol messages", http://www.ietf.org/mail-
= mail-archive/web/forces/current/msg03687.html . = archive/web/forces/current/msg03687.html , .
= [I-D.ietf-forces-ceha] = [I-D.ietf-forces-ceha-00]
= Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, = "ForCES Ogawa, K., Wang, = W., Haleplidis, E., and J. Salim, "ForCES
= Intra-NE High Availability", draft-ietf-forces-ceha-05 Intra-NE High Availability", draft-ietf-forces-ceha-00
= (work in progress), January = 2013. (work in = progress) [RFC Editor Note: This reference = is
intended to indicate a specific version = of an Internet-
Draft that was used during interop = testing. Please Do NOT
update this reference to a more recent = version of the
draft or to an RFC. Please remove this = note before
publication] , October = 2010.
= [I-D.ietf-forces-lfb-lib] = [I-D.ietf-forces-lfb-lib-03]
= Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. = Wang, W., Haleplidis, E., Ogawa, = K., Li, C., and J.
= Halpern, "ForCES Logical Function Block (LFB) = Library", Halpern, = "ForCES Logical Function Block (LFB) Library",
= draft-ietf-forces-lfb-lib-10 = (work in progress), draft-ietf-forces-lfb-lib-03 (work in progress) [RFC
January = 2013. = Editor Note: This reference is intended to indicate = a
specific version = of an Internet-Draft that was used during
[RFC2629] Rose, M., "Writing = I-Ds and RFCs using XML", RFC 2629, interop testing. = Please Do NOT update this reference to a
June = 1999. = more recent version of the draft or to an RFC. = Please
remove this note before publication] , = December 2010.
= [RFC3654] Khosravi, H. and T. Anderson, "Requirements for = Separation [RFC3654] Khosravi, H. = and T. Anderson, "Requirements for Separation
= of IP Control and Forwarding", RFC 3654, November = 2003. of IP Control and = Forwarding", RFC 3654, November 2003.
= [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, = [RFC3746] Yang, L., Dantu, R., Anderson, = T., and R. Gopal,
= "Forwarding and Control Element Separation (ForCES) = "Forwarding and Control Element = Separation (ForCES)
= Framework", RFC 3746, April 2004. Framework", RFC 3746, April 2004.
= [RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi = Salim, [RFC6053] Haleplidis, E., = Ogawa, K., Wang, W., and J. Hadi Salim,
= "Implementation Report for Forwarding and Control = Element "Implementation = Report for Forwarding and Control Element
= Separation (ForCES)", RFC 6053, November 2010. = Separation (ForCES)", RFC 6053, = November 2010.
= [Tcpdump] "Tcpdump is a Linux protocol analyzer. The = specific [Tcpdump] , "Tcpdump is a Linux protocol analyzer. The = specific
= tcpdump that was used is a modified tcpdump, by Jamal = Hadi tcpdump that was = used is a modified tcpdump, by Jamal Hadi
= Salim, that can analyze and decode the ForCES = protocol Salim, that can = analyze and decode the ForCES protocol
= messages", = http://www.ietf.org/mail-archive/web/forces/ messages", = http://www.ietf.org/mail-archive/web/forces/
= current/msg03811.html . = current/msg03811.html , = .
= [Teamviewer] [Teamviewer]
= "TeamViewer connects to any PC or server around the = world , "TeamViewer connects to any PC or server = around the
= within a few seconds.", = http://www.teamviewer.com/ . = world within a few seconds. ", = http://www.teamviewer.com/
, .
Authors' Addresses Authors' Addresses
= Weiming Wang Weiming Wang
= Zhejiang Gongshang University = Zhejiang Gongshang University
= 18 Xuezheng Str., Xiasha University Town 18 Xuezheng Str., Xiasha University Town
= Hangzhou, 310018 Hangzhou 310018
= P.R.China P.R.China
= Phone: +86-571-28877721 Phone: = +86-571-28877721
= Email: wmwang@zjsu.edu.cn Email: = wmwang@zjsu.edu.cn
= Kentaro Ogawa Kentaro Ogawa
= NTT Corporation NTT = Corporation
= Tokyo, Tokyo
= Japan Japan
= Email: ogawa.kentaro@lab.ntt.co.jp = Email: ogawa.kentaro@lab.ntt.co.jp
= Evangelos Haleplidis Evangelos = Haleplidis
= University of Patras University of = Patras
= Patras, Patras
= Greece Greece
= Email: ehalep@ece.upatras.gr Email: = ehalep@ece.upatras.gr
=
= Ming Gao Ming Gao
= Hangzhou BAUD Networks Hangzhou = BAUD Networks
= 408 Wen-San Road 408 Wen-San = Road
= Hangzhou, 310012 Hangzhou 310012
= P.R.China P.R.China
= Phone: +86-571-28877751 = Email: gmyyqno1@zjsu.edu.cn
= Email: gmyyqno1@pop.zjgsu.edu.cn
= Jamal Hadi Salim Jamal Hadi = Salim
= Mojatatu Networks Mojatatu = Networks
= Ottawa Ottawa
= Canada Canada
= Email: hadi@mojatatu.com Email: = hadi@mojatatu.com
 End of changes. 85 change blocks. 
315 lines changed or = deleted 267 lines changed or = added

This = html diff was produced by rfcdiff 1.41. The latest version is available = from http://tools.ietf.org/tools/rfcdiff/
=0A= =0A= =0A= ------=_NextPart_000_02BE_01CE3A16.2F59D130-- From wmwang2001@hotmail.com Mon Apr 15 17:11:45 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603DB21F91B8 for ; Mon, 15 Apr 2013 17:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.651 X-Spam-Level: ** X-Spam-Status: No, score=2.651 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq-akBoKupnY for ; Mon, 15 Apr 2013 17:11:44 -0700 (PDT) Received: from blu0-omc4-s36.blu0.hotmail.com (blu0-omc4-s36.blu0.hotmail.com [65.55.111.175]) by ietfa.amsl.com (Postfix) with ESMTP id C04A521F9349 for ; Mon, 15 Apr 2013 17:11:43 -0700 (PDT) Received: from BLU0-SMTP278 ([65.55.111.137]) by blu0-omc4-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Apr 2013 17:11:42 -0700 X-EIP: [vecjgd0rsBIH1n96aU7wM1ezwMiJNU2/] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([183.156.119.53]) by BLU0-SMTP278.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Apr 2013 17:11:40 -0700 From: "Wang,Weiming" To: Date: Tue, 16 Apr 2013 08:11:42 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0538_01CE3A7A.072799E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 16 Apr 2013 00:11:40.0807 (UTC) FILETIME=[F8426970:01CE3A36] Cc: forces@ietf.org Subject: Re: [forces] AD review of draft-ietf-forces-interop X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 00:11:45 -0000 ------=_NextPart_000_0538_01CE3A7A.072799E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgQWRyaWFuIGFuZCBhbGwsDQoNCkkgd2VudCBiYWNrIGNoZWNrZWQgdGhlIHByb2Nlc3MsIGl0 IHNlZW1zIHdlIHJlcG9ydGVkIHNldmVyYWwgZXJyYXRhLCBidXQgbm90IGFjdHVhbGx5IGFjY2Vw dGVkLCB3aGljaCBpbmNsdWRlZDogDQoNCg0KMS4gU2VjdGlvbiA3LjEuMSAoUkZDIDU4MTApIHBh cnQgdGhhdCBzYXlzOg0KICAgICogIFdoZW4gYSB0YWJsZSBpcyByZWZlcnJlZCB0byBpbiB0aGUg UEFUSCAoSURzKSBvZiBhIFBBVEgtREFUQS0NCiAgICAgICAgIFRMViwgdGhlbiB0aGUgRlVMTERB VEEtVExWJ3MgIlYiIHdpbGwgY29udGFpbiB0aGF0IHRhYmxlJ3Mgcm93DQogICAgICAgICBjb250 ZW50IHByZWZpeGVkIGJ5IGl0cyAzMi1iaXQgaW5kZXgvc3Vic2NyaXB0LiAgT24gdGhlIG90aGVy DQogICAgICAgICBoYW5kLCB0aGUgUEFUSCBtYXkgY29udGFpbiBhbiBpbmRleCBwb2ludGluZyB0 byBhIHJvdyBpbiB0YWJsZTsNCiAgICAgICAgIGluIHN1Y2ggYSBjYXNlLCB0aGUgRlVMTERBVEEt VExWJ3MgIlYiIHdpbGwgb25seSBjb250YWluIHRoZQ0KICAgICAgICAgY29udGVudCB3aXRoIHRo ZSBpbmRleCBpbiBvcmRlciB0byBhdm9pZCBhbWJpZ3VpdHkuDQoNCkF0IHRoZSBlbmQgb2YgdGhl IHRleHQ6ICJ0aGUgRlVMTERBVEEtVExWJ3MgIlYiIHdpbGwgb25seSBjb250YWluIHRoZQ0KY29u dGVudCB3aXRoIHRoZSBpbmRleCAuIg0KSXQgc2hvdWxkIGJlICJ0aGUgRlVMTERBVEEtVExWJ3Mg IlYiIHdpbGwgb25seSBjb250YWluIHRoZSBjb250ZW50IHdpdGhvdXQNCnRoZSBpbmRleCAuIg0K DQoyLiBBbmQgYWxzbyBzb21ldGhpbmcgb2YgbGVzc2VyIGltcG9ydGFuY2UuIFBhZ2UgMTA5IChS RkMgNTgxMCkuIEZvciAjNS4NClNheXMgZm9yIFJlc3VsdDoNCk9QRVI9U0VULVRMVg0KU2hvdWxk IGhhdmUgYmVlbjoNCk9QRVI9U0VULVJFU1BPTlNFLVRMVg0KDQozLiAgVGhlcmUgYXJlIHNldmVy YWwgcGxhY2VzIGluIHRhYmxlIDMgb2YgcmZjNTgxMCB3aGVyZSB0aGUgdGV4dCBzYXlzICJhbiBj b21wb25lbnQiLiANCg0KQXMgYSByZXN1bHQsIHdlIGFyZSBub3QgZ29pbmcgdG8gYW5kIHRoZSBy ZXBvcnRzIGxpc3QgaW4gdGhlIGRvY3VtZW50LCByYXRoZXIsIGp1c3Qga2VlcCB0aGUgdGV4dDog DQoNCiBTb21lIGVycmF0YSByZWxhdGVkIHRvIEZvckNFUyBkb2N1bWVudCB3ZXJlIGZvdW5kIGJ5 IHRoZQ0KICAgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0LiAgVGhlIGVycmF0YSBoYXMgYmVlbiByZXBv cnRlZCB0byByZWxhdGVkIElFVEYNCiAgIFJGQ3MuDQoNCg0KdGhhbmtzLA0KV2VpbWluZw0KDQoN Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IFdhbmcsV2VpbWluZyANCiAg VG86IGFkcmlhbkBvbGRkb2cuY28udWsgOyAnSmFtYWwgSGFkaSBTYWxpbScgDQogIENjOiBmb3Jj ZXNAaWV0Zi5vcmcgOyBkcmFmdC1pZXRmLWZvcmNlcy1pbnRlcm9wQHRvb2xzLmlldGYub3JnIA0K ICBTZW50OiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDg6MTYgUE0NCiAgU3ViamVjdDogUmU6IFtm b3JjZXNdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWZvcmNlcy1pbnRlcm9wDQoNCg0KICBIaSBB ZHJpYW4gYW5kIGFsbCwNCg0KICBJIHRoaW5rIG1vc3Qgb2YgdGhlIGlzc3VlcyByYWlzZWQgYnkg QUQgYXJlIGJlZW4gYWRkcmVzc2VkIGFuZCB3ZSBhcmUgZ29pbmcgdG8gZm9ybSBhIG5ldyAwNyB2 ZXJzaW9uIHZlcnkgc29vbi4gVGhlIDA3IGJldGEgdmVyc2lvbiBhbmQgYSBkaWZmIGZpbGUgdG8g djA2IGluIHRoZSBhdHRhY2htZW50IGFyZSBmb3IgeW91ciByZXZpZXcgYWdhaW4uDQoNCiAgdGhh bmtzIHZlcnkgbXVjaC4NCiAgV2VpbWluZw0KDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gDQogIEZyb206ICJBZHJpYW4gRmFycmVsIiA8YWRyaWFuQG9sZGRvZy5jby51az4NCg0KICA+ IEhpIGFsbCwNCiAgPiANCiAgPj4gPiBJIG5vdyBoYXZlIG1vcmUgcXVlc3Rpb24gdGhhdCwgaWYg d2Ugc2hvdWxkIHBvaW50IG91dCB0aGUgZGVmZXJlbmNlDQogID4+ID4gYmV0d2VlbiB0aGUgdGVz dGVkIHZlcnNpb24gYW5kIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50Pw0KICA+ PiA+IE9yLCBzaGFsbCB3ZSBhbHNvIG1lbnRpb24gd2hhdCB0ZXN0ZWQgaXMgc3RpbGwgb3Igbm90 IGluIGV4aXN0ZW5zZSBpbg0KICA+PiA+IGN1cnJlbnQgdmVyc2lvbiwgb3Igd2hhdCBjaGFuZ2Ug aGFzIGhhcHBlbmVkPw0KICA+PiA+DQogID4+ID4gSSBkbyBob3BlIGF1dGhvcnMgY2FuIHNob3cg eW91ciBzdWdnZXN0aW9ucyB0byBzb2x2ZSB0aGUgaXNzdWUuDQogID4+IA0KICA+PiBJIHRoaW5r IHdlIHBvaW50IHRvIHRoZSBSRkNzLCBpZiB0aGV5IGV4aXN0IGFuZCBtZW50aW9uIHNwZWNpZmlj IHZlcnNpb25zDQogID4+IG9mIHRoZSBkcmFmdHMgcHJlLVJGQy4gSSBhbSBub3Qgc3VyZSBpZiB0 aGUgeG1sIHdpbGwgYWxsb3cgeW91IHRvIHVzZQ0KICA+IG9ic29sZXRlZA0KICA+PiBkb2N1bWVu dHMgYXMgcmVmZXJlbmNlczsgYW5kIGlmIHlvdSByZWZlcmVuY2UgdGhlbSAtIHdoZXRoZXIgdGhl eSBhcmUNCiAgPj4gZ3VhcmFudGVlZCB0byBiZSBhY2Nlc3NpYmxlIHdoZW4gc29tZW9uZSBuZWVk cyB0byByZWZlcmVuY2UgdGhlbS4gDQogID4+IEV4YW1wbGUsIGluIDIgeWVhcnMgZnJvbSBub3cs IHdpbGwgc29tZW9uZSBiZSBhYmxlIHRvIGFjY2VzcyBjZWhhIGRyYWZ0DQogID4+IHZlcnNpb24g MyBvbiB0aGUgaWV0ZiB3ZWIgc2l0ZT8NCiAgPiANCiAgPiBJIHRoaW5rIGl0IGlzIHJlYWxseSBp bXBvcnRhbnQgdG8gcmVmZXJlbmNlIHRoZW0uIExpa2UgSm9lbCBzYXlzIChhbmQgdW5saWtlDQog ID4gd2hhdCB0aGUgYm9pbGVycGxhdGUgc2F5czstKSBJLWRzIHNlZW0gdG8gcGVyc2lzdCBvbiB0 aGUgaW50ZXJ3ZWIgZm9yIGV2ZXIuIFlvdQ0KICA+IHNob3VsZG4ndCBwdXQgdGhlbSBpbiBhcyBu b3JtYXRpdmUgcmVmZXJlbmNlcywgYnV0IHlvdSBzaG91bGQgcHV0IHRoZW0gaW4gYXMNCiAgPiBz cGVjaWZpYyBudW1iZXJlZCBhbmQgZGF0ZWQgdmVyc2lvbi4gSSB3b3VsZCBhbHNvIHJlY29tbWVu ZCBhZGRpbmcgYW4gUkZDIGVkaXRvcg0KICA+IG5vdGUgZm9yIGVhY2ggb25lIGFzIGZvbGxvd3M6 DQogID4gDQogID4gT0xEDQogID4gICBbSS1ELmlldGYtZm9yY2VzLWNlaGFdDQogID4gICAgICAg ICAgICAgIE9nYXdhLCBLLiwgV2FuZywgVy4sIEhhbGVwbGlkaXMsIEUuLCBhbmQgSi4gU2FsaW0s ICJGb3JDRVMNCiAgPiAgICAgICAgICAgICAgSW50cmEtTkUgSGlnaCBBdmFpbGFiaWxpdHkiLCBk cmFmdC1pZXRmLWZvcmNlcy1jZWhhLTA1DQogID4gICAgICAgICAgICAgICh3b3JrIGluIHByb2dy ZXNzKSwgSmFudWFyeSAyMDEzLg0KICA+IA0KICA+ICAgW0ktRC5pZXRmLWZvcmNlcy1sZmItbGli XQ0KICA+ICAgICAgICAgICAgICBXYW5nLCBXLiwgSGFsZXBsaWRpcywgRS4sIE9nYXdhLCBLLiwg TGksIEMuLCBhbmQgSi4NCiAgPiAgICAgICAgICAgICAgSGFscGVybiwgIkZvckNFUyBMb2dpY2Fs IEZ1bmN0aW9uIEJsb2NrIChMRkIpIExpYnJhcnkiLA0KICA+ICAgICAgICAgICAgICBkcmFmdC1p ZXRmLWZvcmNlcy1sZmItbGliLTEwICh3b3JrIGluIHByb2dyZXNzKSwNCiAgPiAgICAgICAgICAg ICAgSmFudWFyeSAyMDEzLg0KICA+IE5FVw0KICA+ICAgW0ktRC5pZXRmLWZvcmNlcy1jZWhhLTAw XQ0KICA+ICAgICAgICAgICAgICBPZ2F3YSwgSy4sIFdhbmcsIFcuLCBIYWxlcGxpZGlzLCBFLiwg YW5kIEouIFNhbGltLCAiRm9yQ0VTDQogID4gICAgICAgICAgICAgIEludHJhLU5FIEhpZ2ggQXZh aWxhYmlsaXR5IiwgZHJhZnQtaWV0Zi1mb3JjZXMtY2VoYS0wMCwNCiAgPiAgICAgICAgICAgICAg T2N0b2JlciAyMDEwLCB3b3JrIGluIHByb2dyZXNzLg0KICA+ICAgICAgICAgICAgICBbUkZDIEVk aXRvciBOb3RlLiBUaGlzIHJlZmVyZW5jZSBpcyBpbnRlbmRlZCB0byBpbmRpY2F0ZSBhDQogID4g ICAgICAgICAgICAgIHNwZWNpZmljIHZlcnNpb24gb2YgYW4gSW50ZXJuZXQtRHJhZnQgdGhhdCB3 YXMgdXNlZCBkdXJpbmcNCiAgPiAgICAgICAgICAgICAgaW50ZXJvcCB0ZXN0aW5nLiBQbGVhc2Ug RG8gTk9UIHVwZGF0ZSB0aGlzIHJlZmVyZW5jZSB0byBhIA0KICA+ICAgICAgICAgICAgICBtb3Jl IHJlY2VudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBvciB0byBhbiBSRkMuIFBsZWFzZQ0KICA+ICAg ICAgICAgICAgICByZW1vdmUgdGhpcyBub3RlIGJlZm9yZSBwdWJsaWNhdGlvbi5dDQogID4gDQog ID4gICBbSS1ELmlldGYtZm9yY2VzLWxmYi1saWItMDNdDQogID4gICAgICAgICAgICAgIFdhbmcs IFcuLCBIYWxlcGxpZGlzLCBFLiwgT2dhd2EsIEsuLCBMaSwgQy4sIGFuZCBKLg0KICA+ICAgICAg ICAgICAgICBIYWxwZXJuLCAiRm9yQ0VTIExvZ2ljYWwgRnVuY3Rpb24gQmxvY2sgKExGQikgTGli cmFyeSIsDQogID4gICAgICAgICAgICAgIGRyYWZ0LWlldGYtZm9yY2VzLWxmYi1saWItMDMsIERl Y2VtYmVyIDIwMTAsIHdvcmsgaW4gDQogID4gICAgICAgICAgICAgIHByb2dyZXNzLg0KICA+ICAg ICAgICAgICAgICANCiAgPiAgICAgICAgICAgICAgW1JGQyBFZGl0b3IgTm90ZS4gVGhpcyByZWZl cmVuY2UgaXMgaW50ZW5kZWQgdG8gaW5kaWNhdGUgYQ0KICA+ICAgICAgICAgICAgICBzcGVjaWZp YyB2ZXJzaW9uIG9mIGFuIEludGVybmV0LURyYWZ0IHRoYXQgd2FzIHVzZWQgZHVyaW5nDQogID4g ICAgICAgICAgICAgIGludGVyb3AgdGVzdGluZy4gUGxlYXNlIERvIE5PVCB1cGRhdGUgdGhpcyBy ZWZlcmVuY2UgdG8gYSANCiAgPiAgICAgICAgICAgICAgbW9yZSByZWNlbnQgdmVyc2lvbiBvZiB0 aGUgZHJhZnQgb3IgdG8gYW4gUkZDLiBQbGVhc2UNCiAgPiAgICAgICAgICAgICAgcmVtb3ZlIHRo aXMgbm90ZSBiZWZvcmUgcHVibGljYXRpb24uXQ0KICA+IEVORA0KICA+IA0KICA+PiBTaW5jZSB0 aGUgQUQgaGFzIGdyYWNpb3VzbHkgb2ZmZXJlZCB0byBjb21lIHVwIHdpdGggc29tZSBsYW5ndWFn ZSwgd2h5DQogID4+IGRvbnQgd2UgbGV0IGhpbSBkbyB0aGF0IGZvciB1cz8NCiAgPiANCiAgPiBP SywgaGVyZSB3ZSBnby4uLg0KICA+IA0KICA+IE9MRCAgIA0KICA+ICAgVGhpcyBkb2N1bWVudCBj YXB0dXJlcyByZXN1bHRzIG9mIHRoZSBzZWNvbmQgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0IG9mDQog ID4gICB0aGUgRm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gKEZvckNF Uykgd2hpY2ggdG9vaw0KICA+ICAgcGxhY2UgRmVicnVhcnkgMjQtMjUsIDIwMTEgaW4gdGhlIElu dGVybmV0IFRlY2hub2xvZ3kgTGFiIChJVEwpIG9mDQogID4gICBaaGVqaWFuZyBHb25nc2hhbmcg VW5pdmVyc2l0eSwgQ2hpbmEuICBUaGUgdGVzdCBpbnZvbHZlZCBzZXZlcmFsDQogID4gICBkb2N1 bWVudHMgbmFtZWx5OiBGb3JDRVMgcHJvdG9jb2wgW1JGQzU4MTBdICwgRm9yQ0VTIEZFIG1vZGVs DQogID4gICBbUkZDNTgxMl0gLCBGb3JDRVMgVE1MIFtSRkM1ODExXSAsIEZvckNFUyBMRkIgTGli cmFyeQ0KICA+ICAgW0ktRC5pZXRmLWZvcmNlcy1sZmItbGliXSBhbmQgRm9yQ0VTIENFIEhBIHNw ZWNpZmljYXRpb24NCiAgPiAgIFtJLUQuaWV0Zi1mb3JjZXMtY2VoYV0uICBUaHJlZSBpbmRlcGVu ZGVudCBGb3JDRVMgaW1wbGVtZW50YXRpb25zDQogID4gICBwYXJ0aWNpcGF0ZWQgaW4gdGhlIHRl c3QuDQogID4gTkVXDQogID4gICBUaGlzIGRvY3VtZW50IGNhcHR1cmVzIHJlc3VsdHMgb2YgdGhl IHNlY29uZCBpbnRlcm9wZXJhYmlsaXR5IHRlc3Qgb2YNCiAgPiAgIHRoZSBGb3J3YXJkaW5nIGFu ZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbiAoRm9yQ0VTKSB3aGljaCB0b29rDQogID4gICBw bGFjZSBGZWJydWFyeSAyNC0yNSwgMjAxMSBpbiB0aGUgSW50ZXJuZXQgVGVjaG5vbG9neSBMYWIg KElUTCkgb2YNCiAgPiAgIFpoZWppYW5nIEdvbmdzaGFuZyBVbml2ZXJzaXR5LCBDaGluYS4gIFRo ZSB0ZXN0IGludm9sdmVkIHByb3RvY29sDQogID4gICBlbGVtZW50cyBkZXNjcmliZWQgaW4gc2V2 ZXJhbCBkb2N1bWVudHMgbmFtZWx5OiANCiAgPiANCiAgPiAgIC0gVGhlIEZvckNFUyBwcm90b2Nv bCBbUkZDNTgxMF0NCiAgPiAgIC0gVGhlIEZvckNFUyBGb3J3YXJkaW5nIEVsZW1lbnQgbW9kZWwg W1JGQzU4MTJdDQogID4gICAtIFRoZSBGb3JDRVMgVHJhbnNwb3J0IE1hcHBpbmcgTGF5ZXIgW1JG QzU4MTFdLg0KICA+ICAgDQogID4gICBUaGUgdGVzdCBhbHNvIGludm9sdmVkIHByb3RvY29sIGVs ZW1lbnRzIGRlc2NyaWJlZCBpbiB0aGUgdGhlbi0NCiAgPiAgIGN1cnJlbnQgdmVyc2lvbnMgb2Yg dHdvIEludGVybmV0LURyYWZ0cy4gIEFsdGhvdWdoIHRoZXNlIGRvY3VtZW50cw0KICA+ICAgaGF2 ZSBzdWJzZXF1ZW50bHkgYmVlbiByZXZpc2VkIGFuZCBhZHZhbmNlZCwgaXQgaXMgaW1wb3J0YW50 IHRvIA0KICA+ICAgdW5kZXJzdGFuZCB3aGljaCB2ZXJzaW9ucyBvZiB0aGUgd29yayB3ZXJlIHVz ZWQgZHVyaW5nIHRoaXMgdGVzdC4NCiAgPiANCiAgPiAgIC0gRm9yQ0VTIExvZ2ljYWwgRnVuY3Rp b24gQmxvY2sgTGlicmFyeSBbSS1ELmlldGYtZm9yY2VzLWxmYi1saWItMDNdDQogID4gICAtIEZv ckNFUyBJbnRyYS1OZXR3b3JrIEVsZW1lbnQgSGlnaCBBdmFpbGFiaWxpdHkgc3BlY2lmaWNhdGlv bg0KICA+ICAgICBbSS1ELmlldGYtZm9yY2VzLWNlaGEtMDBdLg0KICA+ICAgDQogID4gICBUaHJl ZSBpbmRlcGVuZGVudCBGb3JDRVMgaW1wbGVtZW50YXRpb25zIHBhcnRpY2lwYXRlZCBpbiB0aGUg dGVzdC4NCiAgPiBFTkQNCiAgPiANCiAgPj4gPj4gSSBoYXZlIGEgcGVyc29uYWwgZGlzbGlrZSBv ZiByZXBlYXRlZCBkZWZpbml0aW9ucyBjb3BpZWQgZnJvbSBvdGhlcg0KICA+PiA+PiBkb2N1bWVu dHMuIFRoZXkgY2FuIGNhdXNlIGFsbCBzb3J0cyBvZiBmdW4gaWYgeW91IG1ha2UgYSBtaXN0YWtl IHdoZW4NCiAgPj4gPj4geW91IGNvcHkgdGhlIHRleHQhICBTbyBJIHdvdWxkIHByZWZlciBzZWN0 aW9uIDIuMi4gc2ltcGx5IHRvIHBvaW50IGF0DQogID4+ID4+IHRoZSBkZWZpbml0aW9ucyBmcm9t IG90aGVyIFJGQ3MuDQogID4+ID4gDQogID4+ID4gQWdyZWVkIGluIHRoaXMgY2FzZS4NCiAgPj4N CiAgPj4gSW4gZ2VuZXJhbCBJIGhhdmUgdGhlIG9wcG9zaXRlIHRhc3RlIDstPiBJIHdvdWxkIHJh dGhlciBoYXZlIHRoZQ0KICA+PiBjb250ZXh0IGluIHBsYWNlIHNvIGkgY2FuIGNvcnJlbGF0ZSBp bnN0ZWFkIG9mIGdvaW5nIGFuZCByZWFkaW5nIA0KICA+PiBzb21lIG90aGVyIGRvYyBlbHNld2hl cmUuDQogID4+IFtZZXMsIG9uZSBjb3VsZCBtYWtlIGEgbWlzdGFrZSBpbiBjb3B5aW5nLiBCdXQg YWxzbyBvbmUgY291bGQgZml4IHByZXZpb3VzbHkNCiAgPj4gZXJyb25vdXMgYW5kIHByb3ZpZGUg bW9yZSBleHRlbmRlZCBpbmZvcm1hdGlvbiBzdWNoIGFzIHRoZSBDRUhBIGRvY3VtZW50DQogID4+ IGRvZXMgd2hlbiBpdCBwcm92aWRlcyBjb250ZXh0IGZvciBIQSBkZXJpdmVkIGZyb20gUkZDIDU4 MTAuXQ0KICA+IA0KICA+IExpa2UgSSBzYWlkLCBJJ2xsIGxldCB5J2FsbCBkZWNpZGUgd2hhdCB0 byBkbyBoZXJlIHNpbmNlIEkgZG9uJ3QgZmVlbCBzdHJvbmdseQ0KICA+IGVub3VnaC4NCiAgPiAN CiAgPiBDYW4gSSBqdXN0IG5vdGUsIGhvd2V2ZXIsIHRoYXQgaWYgeW91IGFyZSAiZml4aW5nIiBh IGRlZmluaXRpb24gdGhhdCBpcyBhbHJlYWR5DQogID4gaW4gYSBwdWJsaXNoZWQgUkZDLCB5b3Ug YXJlIGNyZWF0aW5nIGEgbmljZSBsaXR0bGUgbWVzcyB1bmxlc3MgeW91IGFsc28gZml4IHRoZQ0K ICA+IGRlZmluaXRpb24gaW4gdGhlIFJGQy4gVGhhdCBmaXggY291bGQgYmUgdGhyb3VnaCBhbiBF cnJhdGEgUmVwb3J0IGZvciBhDQogID4gdHlwb2dyYXBoaWNhbCBlcnJvciwgb3IgYnkgdXBkYXRp bmcgdGhlIHB1Ymxpc2hlZCBSRkMuIEJ1dCBzaW1wbHkgcHVibGlzaGluZyBhDQogID4gbmV3IFJG QyB3aXRoIGEgZGlmZmVyZW50IGRlZmluaXRpb24gaXMgbm90IGEgZ29vZCBpZGVhLg0KICA+IA0K ICA+IEFuZCBvbmUgb3RoZXIgdGhpbmc6IFdlaW1pbmcncyBpbml0aWFsIHJlc3BvbnNlIGRpZG4n dCBpbmNsdWRlIGFueSByZXNwb25zZSB0bw0KICA+IG15IGlzc3VlcyB3aXRoIFJGQyAyMTE5IGxh bmd1YWdlLg0KICA+IA0KICA+IE9uY2UgYWdhaW4sIHRoYW5rcyBmb3IgYWxsIHRoZSB3b3JrLg0K ICA+IA0KICA+IENoZWVycywNCiAgPiBBZHJpYW4NCiAgPiANCiAgPiANCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQogIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogIGZvcmNlcyBtYWlsaW5nIGxpc3QNCiAgZm9yY2VzQGlldGYub3JnDQogIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzDQo= ------=_NextPart_000_0538_01CE3A7A.072799E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTQxMiI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+DQo8RElWPjxGT05UIHNpemU9NCBmYWNl PSYjMjM0MzU7JiMyMDMwNzs+SGkgQWRyaWFuIGFuZCBhbGwsPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT00IGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5JIHdlbnQgYmFjayBjaGVja2Vk IHRoZSBwcm9jZXNzLCBpdCBzZWVtcyB3ZSByZXBvcnRlZCANCnNldmVyYWwgZXJyYXRhLCBidXQg bm90IGFjdHVhbGx5IGFjY2VwdGVkLCB3aGljaCBpbmNsdWRlZDogPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjEuIFNlY3Rpb24gNy4xLjEgKFJGQyA1ODEwKSBwYXJ0 IHRoYXQgc2F5czo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsgDQpXaGVuIGEgdGFibGUg aXMgcmVmZXJyZWQgdG8gaW4gdGhlIFBBVEggKElEcykgb2YgYSANClBBVEgtREFUQS08QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRMViwgdGhlbiB0 aGUgDQpGVUxMREFUQS1UTFYncyAiViIgd2lsbCBjb250YWluIHRoYXQgdGFibGUncyANCnJvdzxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udGVu dCBwcmVmaXhlZCBieSBpdHMgDQozMi1iaXQgaW5kZXgvc3Vic2NyaXB0LiZuYnNwOyBPbiB0aGUg DQpvdGhlcjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgaGFuZCwgdGhlIFBBVEggbWF5IA0KY29udGFpbiBhbiBpbmRleCBwb2ludGluZyB0byBhIHJv dyBpbiANCnRhYmxlOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgaW4gc3VjaCBhIGNhc2UsIHRoZSANCkZVTExEQVRBLVRMVidzICJWIiB3aWxsIG9u bHkgY29udGFpbiANCnRoZTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgY29udGVudCB3aXRoIHRoZSBpbmRleCANCmluIG9yZGVyIHRvIGF2b2lkIGFt YmlndWl0eS48QlI+PEJSPkF0IHRoZSBlbmQgb2YgdGhlIHRleHQ6ICJ0aGUgRlVMTERBVEEtVExW J3MgDQoiViIgd2lsbCBvbmx5IGNvbnRhaW4gdGhlPEJSPmNvbnRlbnQgd2l0aCB0aGUgaW5kZXgg LiI8QlI+SXQgc2hvdWxkIGJlICJ0aGUgDQpGVUxMREFUQS1UTFYncyAiViIgd2lsbCBvbmx5IGNv bnRhaW4gdGhlIGNvbnRlbnQgd2l0aG91dDxCUj50aGUgaW5kZXggDQouIjxCUj48QlI+Mi4gQW5k IGFsc28gc29tZXRoaW5nIG9mIGxlc3NlciBpbXBvcnRhbmNlLiBQYWdlIDEwOSAoUkZDIDU4MTAp LiBGb3IgDQojNS48QlI+U2F5cyBmb3IgUmVzdWx0OjxCUj5PUEVSPVNFVC1UTFY8QlI+U2hvdWxk IGhhdmUgDQpiZWVuOjxCUj5PUEVSPVNFVC1SRVNQT05TRS1UTFY8QlI+PC9ESVY+DQo8RElWPjxG T05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+My4mbmJzcDs8Rk9OVCBzaXplPTM+IFRo ZXJlIGFyZSBzZXZlcmFsIHBsYWNlcyBpbiANCnRhYmxlIDMgb2YgcmZjNTgxMCB3aGVyZSB0aGUg dGV4dCBzYXlzICJhbiBjb21wb25lbnQiLiA8L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PkFzIGEgcmVzdWx0LCB3PC9GT05UPjxGT05UIHNp emU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+ZSBhcmUgbm90IA0KZ29pbmcgdG8gYW5kIHRoZSBy ZXBvcnRzIGxpc3QgaW4gdGhlIGRvY3VtZW50LCByYXRoZXIsIGp1c3Qga2VlcCB0aGUgdGV4dDog DQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQz NTsmIzIwMzA3Oz48Rk9OVCBzaXplPTM+Jm5ic3A7U29tZSBlcnJhdGEgcmVsYXRlZCB0byBGb3JD RVMgDQpkb2N1bWVudCB3ZXJlIGZvdW5kIGJ5IHRoZTxCUj4mbmJzcDsmbmJzcDsgaW50ZXJvcGVy YWJpbGl0eSB0ZXN0LiZuYnNwOyBUaGUgDQplcnJhdGEgaGFzIGJlZW4gcmVwb3J0ZWQgdG8gcmVs YXRlZCBJRVRGPEJSPiZuYnNwOyZuYnNwOyANClJGQ3MuPC9GT05UPjwvRk9OVD48L0RJVj48Rk9O VCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjxGT05UIHNpemU9Mz48L0ZPTlQ+PC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjxGT05UIHNp emU9Mz48Rk9OVCBzaXplPTI+PC9GT05UPjxGT05UIA0Kc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7 PjxGT05UIHNpemU9Mz48Rk9OVCBzaXplPTI+PC9GT05UPg0KPERJVj48Rk9OVCBzaXplPTI+PC9G T05UPjwvRk9OVD48L0ZPTlQ+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48Rk9O VCBzaXplPTM+PEZPTlQgDQpzaXplPTI+PC9GT05UPjxGT05UIHNpemU9Mj48L0ZPTlQ+PC9GT05U PjwvRk9OVD4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQz NTsmIzIwMzA3Oz48Rk9OVCBzaXplPTM+PEZPTlQgDQpzaXplPTI+dGhhbmtzLDwvRk9OVD48L0ZP TlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7 PjxGT05UIHNpemU9Mz48Rk9OVCANCnNpemU9Mj5XZWltaW5nPC9GT05UPjwvRk9OVD48L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+LS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRF Ui1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklH SFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgQkFDS0dST1VORDogI2U0ZTRlNDsgZm9u dC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9d213YW5nMjAwMUBob3Rt YWlsLmNvbSANCiAgaHJlZj0ibWFpbHRvOndtd2FuZzIwMDFAaG90bWFpbC5jb20iPldhbmcsV2Vp bWluZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7 Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPWFkcmlhbkBvbGRkb2cuY28udWsgDQogIGhyZWY9Im1haWx0 bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9BPiA7IDxBIA0KICB0 aXRsZT1oYWRpQG1vamF0YXR1LmNvbSBocmVmPSJtYWlsdG86aGFkaUBtb2phdGF0dS5jb20iPidK YW1hbCBIYWRpIFNhbGltJzwvQT4gDQogIDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg JiMyMzQzNTsmIzIwMzA3OyI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1mb3JjZXNAaWV0Zi5vcmcgDQog IGhyZWY9Im1haWx0bzpmb3JjZXNAaWV0Zi5vcmciPmZvcmNlc0BpZXRmLm9yZzwvQT4gOyA8QSAN CiAgdGl0bGU9ZHJhZnQtaWV0Zi1mb3JjZXMtaW50ZXJvcEB0b29scy5pZXRmLm9yZyANCiAgaHJl Zj0ibWFpbHRvOmRyYWZ0LWlldGYtZm9yY2VzLWludGVyb3BAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0 LWlldGYtZm9yY2VzLWludGVyb3BAdG9vbHMuaWV0Zi5vcmc8L0E+IA0KICA8L0RJVj4NCiAgPERJ ViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBNb25kYXks IEFwcmlsIDE1LCAyMDEzIDg6MTYgUE08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYj MjM0MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBSZTogW2ZvcmNlc10gQUQgcmV2aWV3IG9m IA0KICBkcmFmdC1pZXRmLWZvcmNlcy1pbnRlcm9wPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPkhp IEFkcmlhbiBhbmQgYWxsLDxCUj48QlI+SSB0aGluayBtb3N0IG9mIHRoZSBpc3N1ZXMgcmFpc2Vk IGJ5IA0KICBBRCBhcmUgYmVlbiBhZGRyZXNzZWQgYW5kIHdlIGFyZSBnb2luZyB0byBmb3JtIGEg bmV3IDA3IHZlcnNpb24gdmVyeSBzb29uLiBUaGUgDQogIDA3IGJldGEgdmVyc2lvbiBhbmQgYSBk aWZmIGZpbGUgdG8gdjA2IGluIHRoZSBhdHRhY2htZW50IGFyZSBmb3IgeW91ciByZXZpZXcgDQog IGFnYWluLjxCUj48QlI+dGhhbmtzIHZlcnkgbXVjaC48QlI+V2VpbWluZzxCUj48QlI+LS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgPEJSPkZyb206ICJBZHJpYW4gRmFycmVsIiAmbHQ7 PEEgDQogIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNv LnVrPC9BPiZndDs8QlI+PEJSPiZndDsgSGkgDQogIGFsbCw8QlI+Jmd0OyA8QlI+Jmd0OyZndDsg Jmd0OyBJIG5vdyBoYXZlIG1vcmUgcXVlc3Rpb24gdGhhdCwgaWYgd2Ugc2hvdWxkIA0KICBwb2lu dCBvdXQgdGhlIGRlZmVyZW5jZTxCUj4mZ3Q7Jmd0OyAmZ3Q7IGJldHdlZW4gdGhlIHRlc3RlZCB2 ZXJzaW9uIGFuZCB0aGUgDQogIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQ/PEJSPiZn dDsmZ3Q7ICZndDsgT3IsIHNoYWxsIHdlIGFsc28gbWVudGlvbiANCiAgd2hhdCB0ZXN0ZWQgaXMg c3RpbGwgb3Igbm90IGluIGV4aXN0ZW5zZSBpbjxCUj4mZ3Q7Jmd0OyAmZ3Q7IGN1cnJlbnQgdmVy c2lvbiwgDQogIG9yIHdoYXQgY2hhbmdlIGhhcyBoYXBwZW5lZD88QlI+Jmd0OyZndDsgJmd0OzxC Uj4mZ3Q7Jmd0OyAmZ3Q7IEkgZG8gaG9wZSANCiAgYXV0aG9ycyBjYW4gc2hvdyB5b3VyIHN1Z2dl c3Rpb25zIHRvIHNvbHZlIHRoZSBpc3N1ZS48QlI+Jmd0OyZndDsgPEJSPiZndDsmZ3Q7IA0KICBJ IHRoaW5rIHdlIHBvaW50IHRvIHRoZSBSRkNzLCBpZiB0aGV5IGV4aXN0IGFuZCBtZW50aW9uIHNw ZWNpZmljIA0KICB2ZXJzaW9uczxCUj4mZ3Q7Jmd0OyBvZiB0aGUgZHJhZnRzIHByZS1SRkMuIEkg YW0gbm90IHN1cmUgaWYgdGhlIHhtbCB3aWxsIA0KICBhbGxvdyB5b3UgdG8gdXNlPEJSPiZndDsg b2Jzb2xldGVkPEJSPiZndDsmZ3Q7IGRvY3VtZW50cyBhcyByZWZlcmVuY2VzOyBhbmQgaWYgDQog IHlvdSByZWZlcmVuY2UgdGhlbSAtIHdoZXRoZXIgdGhleSBhcmU8QlI+Jmd0OyZndDsgZ3VhcmFu dGVlZCB0byBiZSBhY2Nlc3NpYmxlIA0KICB3aGVuIHNvbWVvbmUgbmVlZHMgdG8gcmVmZXJlbmNl IHRoZW0uIDxCUj4mZ3Q7Jmd0OyBFeGFtcGxlLCBpbiAyIHllYXJzIGZyb20gDQogIG5vdywgd2ls bCBzb21lb25lIGJlIGFibGUgdG8gYWNjZXNzIGNlaGEgZHJhZnQ8QlI+Jmd0OyZndDsgdmVyc2lv biAzIG9uIHRoZSANCiAgaWV0ZiB3ZWIgc2l0ZT88QlI+Jmd0OyA8QlI+Jmd0OyBJIHRoaW5rIGl0 IGlzIHJlYWxseSBpbXBvcnRhbnQgdG8gcmVmZXJlbmNlIA0KICB0aGVtLiBMaWtlIEpvZWwgc2F5 cyAoYW5kIHVubGlrZTxCUj4mZ3Q7IHdoYXQgdGhlIGJvaWxlcnBsYXRlIHNheXM7LSkgSS1kcyAN CiAgc2VlbSB0byBwZXJzaXN0IG9uIHRoZSBpbnRlcndlYiBmb3IgZXZlci4gWW91PEJSPiZndDsg c2hvdWxkbid0IHB1dCB0aGVtIGluIGFzIA0KICBub3JtYXRpdmUgcmVmZXJlbmNlcywgYnV0IHlv dSBzaG91bGQgcHV0IHRoZW0gaW4gYXM8QlI+Jmd0OyBzcGVjaWZpYyBudW1iZXJlZCANCiAgYW5k IGRhdGVkIHZlcnNpb24uIEkgd291bGQgYWxzbyByZWNvbW1lbmQgYWRkaW5nIGFuIFJGQyBlZGl0 b3I8QlI+Jmd0OyBub3RlIA0KICBmb3IgZWFjaCBvbmUgYXMgZm9sbG93czo8QlI+Jmd0OyA8QlI+ Jmd0OyBPTEQ8QlI+Jmd0OyZuYnNwOyZuYnNwOyANCiAgW0ktRC5pZXRmLWZvcmNlcy1jZWhhXTxC Uj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBPZ2F3YSwgSy4sIFdhbmcsIFcuLCBIYWxl cGxpZGlzLCBFLiwgYW5kIEouIFNhbGltLCANCiAgIkZvckNFUzxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KICBJbnRyYS1ORSBIaWdoIEF2YWlsYWJpbGl0eSIsIA0KICBkcmFmdC1pZXRm LWZvcmNlcy1jZWhhLTA1PEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICh3b3JrIGlu IHByb2dyZXNzKSwgSmFudWFyeSAyMDEzLjxCUj4mZ3Q7IDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IA0K ICBbSS1ELmlldGYtZm9yY2VzLWxmYi1saWJdPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogIFdhbmcsIFcuLCBIYWxlcGxpZGlzLCBFLiwgT2dhd2EsIEsuLCBMaSwgQy4sIGFuZCANCiAg Si48QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgSGFscGVybiwgIkZvckNFUyBMb2dp Y2FsIEZ1bmN0aW9uIEJsb2NrIChMRkIpIA0KICBMaWJyYXJ5Iiw8QlI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCiAgZHJhZnQtaWV0Zi1mb3JjZXMtbGZiLWxpYi0xMCAod29yayBpbiANCiAg cHJvZ3Jlc3MpLDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBKYW51YXJ5IDIwMTMu PEJSPiZndDsgTkVXPEJSPiZndDsmbmJzcDsmbmJzcDsgDQogIFtJLUQuaWV0Zi1mb3JjZXMtY2Vo YS0wMF08QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgT2dhd2EsIEsuLCBXYW5nLCBX LiwgSGFsZXBsaWRpcywgRS4sIGFuZCBKLiBTYWxpbSwgDQogICJGb3JDRVM8QlI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCiAgSW50cmEtTkUgSGlnaCBBdmFpbGFiaWxpdHkiLCANCiAgZHJh ZnQtaWV0Zi1mb3JjZXMtY2VoYS0wMCw8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAg T2N0b2JlciAyMDEwLCB3b3JrIGluIA0KICBwcm9ncmVzcy48QlI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCiAgW1JGQyBFZGl0b3IgTm90ZS4gVGhpcyByZWZlcmVuY2UgaXMgaW50ZW5kZWQg dG8gaW5kaWNhdGUgDQogIGE8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgc3BlY2lm aWMgdmVyc2lvbiBvZiBhbiBJbnRlcm5ldC1EcmFmdCB0aGF0IHdhcyB1c2VkIA0KICBkdXJpbmc8 QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgaW50ZXJvcCB0ZXN0aW5nLiBQbGVhc2Ug RG8gTk9UIHVwZGF0ZSB0aGlzIHJlZmVyZW5jZSB0byBhIA0KICA8QlI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCiAgbW9yZSByZWNlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgb3IgdG8gYW4g UkZDLiANCiAgUGxlYXNlPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHJlbW92ZSB0 aGlzIG5vdGUgYmVmb3JlIHB1YmxpY2F0aW9uLl08QlI+Jmd0OyA8QlI+Jmd0OyZuYnNwOyZuYnNw OyANCiAgW0ktRC5pZXRmLWZvcmNlcy1sZmItbGliLTAzXTxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KICBXYW5nLCBXLiwgSGFsZXBsaWRpcywgRS4sIE9nYXdhLCBLLiwgTGksIEMuLCBh bmQgDQogIEouPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIEhhbHBlcm4sICJGb3JD RVMgTG9naWNhbCBGdW5jdGlvbiBCbG9jayAoTEZCKSANCiAgTGlicmFyeSIsPEJSPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQogIGRyYWZ0LWlldGYtZm9yY2VzLWxmYi1saWItMDMsIERlY2Vt YmVyIDIwMTAsIHdvcmsgaW4gDQogIDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBw cm9ncmVzcy48QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQogIFtSRkMgRWRpdG9yIE5vdGUuIFRoaXMgcmVmZXJlbmNlIGlzIGlu dGVuZGVkIHRvIGluZGljYXRlIA0KICBhPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQog IHNwZWNpZmljIHZlcnNpb24gb2YgYW4gSW50ZXJuZXQtRHJhZnQgdGhhdCB3YXMgdXNlZCANCiAg ZHVyaW5nPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIGludGVyb3AgdGVzdGluZy4g UGxlYXNlIERvIE5PVCB1cGRhdGUgdGhpcyByZWZlcmVuY2UgdG8gYSANCiAgPEJSPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQogIG1vcmUgcmVjZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0IG9y IHRvIGFuIFJGQy4gDQogIFBsZWFzZTxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBy ZW1vdmUgdGhpcyBub3RlIGJlZm9yZSBwdWJsaWNhdGlvbi5dPEJSPiZndDsgRU5EPEJSPiZndDsg PEJSPiZndDsmZ3Q7IFNpbmNlIA0KICB0aGUgQUQgaGFzIGdyYWNpb3VzbHkgb2ZmZXJlZCB0byBj b21lIHVwIHdpdGggc29tZSBsYW5ndWFnZSwgd2h5PEJSPiZndDsmZ3Q7IA0KICBkb250IHdlIGxl dCBoaW0gZG8gdGhhdCBmb3IgdXM/PEJSPiZndDsgPEJSPiZndDsgT0ssIGhlcmUgd2UgZ28uLi48 QlI+Jmd0OyANCiAgPEJSPiZndDsgT0xEJm5ic3A7Jm5ic3A7IDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7 IFRoaXMgZG9jdW1lbnQgY2FwdHVyZXMgcmVzdWx0cyANCiAgb2YgdGhlIHNlY29uZCBpbnRlcm9w ZXJhYmlsaXR5IHRlc3Qgb2Y8QlI+Jmd0OyZuYnNwOyZuYnNwOyB0aGUgRm9yd2FyZGluZyBhbmQg DQogIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0aW9uIChGb3JDRVMpIHdoaWNoIHRvb2s8QlI+Jmd0 OyZuYnNwOyZuYnNwOyBwbGFjZSANCiAgRmVicnVhcnkgMjQtMjUsIDIwMTEgaW4gdGhlIEludGVy bmV0IFRlY2hub2xvZ3kgTGFiIChJVEwpIA0KICBvZjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IFpoZWpp YW5nIEdvbmdzaGFuZyBVbml2ZXJzaXR5LCBDaGluYS4mbmJzcDsgVGhlIHRlc3QgDQogIGludm9s dmVkIHNldmVyYWw8QlI+Jmd0OyZuYnNwOyZuYnNwOyBkb2N1bWVudHMgbmFtZWx5OiBGb3JDRVMg cHJvdG9jb2wgDQogIFtSRkM1ODEwXSAsIEZvckNFUyBGRSBtb2RlbDxCUj4mZ3Q7Jm5ic3A7Jm5i c3A7IFtSRkM1ODEyXSAsIEZvckNFUyBUTUwgDQogIFtSRkM1ODExXSAsIEZvckNFUyBMRkIgTGli cmFyeTxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IFtJLUQuaWV0Zi1mb3JjZXMtbGZiLWxpYl0gDQogIGFu ZCBGb3JDRVMgQ0UgSEEgc3BlY2lmaWNhdGlvbjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IA0KICBbSS1E LmlldGYtZm9yY2VzLWNlaGFdLiZuYnNwOyBUaHJlZSBpbmRlcGVuZGVudCBGb3JDRVMgDQogIGlt cGxlbWVudGF0aW9uczxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IHBhcnRpY2lwYXRlZCBpbiB0aGUgdGVz dC48QlI+Jmd0OyANCiAgTkVXPEJSPiZndDsmbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBjYXB0 dXJlcyByZXN1bHRzIG9mIHRoZSBzZWNvbmQgDQogIGludGVyb3BlcmFiaWxpdHkgdGVzdCBvZjxC Uj4mZ3Q7Jm5ic3A7Jm5ic3A7IHRoZSBGb3J3YXJkaW5nIGFuZCBDb250cm9sIA0KICBFbGVtZW50 IFNlcGFyYXRpb24gKEZvckNFUykgd2hpY2ggdG9vazxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IHBsYWNl IEZlYnJ1YXJ5IA0KICAyNC0yNSwgMjAxMSBpbiB0aGUgSW50ZXJuZXQgVGVjaG5vbG9neSBMYWIg KElUTCkgb2Y8QlI+Jmd0OyZuYnNwOyZuYnNwOyANCiAgWmhlamlhbmcgR29uZ3NoYW5nIFVuaXZl cnNpdHksIENoaW5hLiZuYnNwOyBUaGUgdGVzdCBpbnZvbHZlZCANCiAgcHJvdG9jb2w8QlI+Jmd0 OyZuYnNwOyZuYnNwOyBlbGVtZW50cyBkZXNjcmliZWQgaW4gc2V2ZXJhbCBkb2N1bWVudHMgbmFt ZWx5OiANCiAgPEJSPiZndDsgPEJSPiZndDsmbmJzcDsmbmJzcDsgLSBUaGUgRm9yQ0VTIHByb3Rv Y29sIA0KICBbUkZDNTgxMF08QlI+Jmd0OyZuYnNwOyZuYnNwOyAtIFRoZSBGb3JDRVMgRm9yd2Fy ZGluZyBFbGVtZW50IG1vZGVsIA0KICBbUkZDNTgxMl08QlI+Jmd0OyZuYnNwOyZuYnNwOyAtIFRo ZSBGb3JDRVMgVHJhbnNwb3J0IE1hcHBpbmcgTGF5ZXIgDQogIFtSRkM1ODExXS48QlI+Jmd0OyZu YnNwOyZuYnNwOyA8QlI+Jmd0OyZuYnNwOyZuYnNwOyBUaGUgdGVzdCBhbHNvIGludm9sdmVkIA0K ICBwcm90b2NvbCBlbGVtZW50cyBkZXNjcmliZWQgaW4gdGhlIHRoZW4tPEJSPiZndDsmbmJzcDsm bmJzcDsgY3VycmVudCB2ZXJzaW9ucyANCiAgb2YgdHdvIEludGVybmV0LURyYWZ0cy4mbmJzcDsg QWx0aG91Z2ggdGhlc2UgZG9jdW1lbnRzPEJSPiZndDsmbmJzcDsmbmJzcDsgDQogIGhhdmUgc3Vi c2VxdWVudGx5IGJlZW4gcmV2aXNlZCBhbmQgYWR2YW5jZWQsIGl0IGlzIGltcG9ydGFudCB0byAN CiAgPEJSPiZndDsmbmJzcDsmbmJzcDsgdW5kZXJzdGFuZCB3aGljaCB2ZXJzaW9ucyBvZiB0aGUg d29yayB3ZXJlIHVzZWQgZHVyaW5nIA0KICB0aGlzIHRlc3QuPEJSPiZndDsgPEJSPiZndDsmbmJz cDsmbmJzcDsgLSBGb3JDRVMgTG9naWNhbCBGdW5jdGlvbiBCbG9jayANCiAgTGlicmFyeSBbSS1E LmlldGYtZm9yY2VzLWxmYi1saWItMDNdPEJSPiZndDsmbmJzcDsmbmJzcDsgLSBGb3JDRVMgDQog IEludHJhLU5ldHdvcmsgRWxlbWVudCBIaWdoIEF2YWlsYWJpbGl0eSANCiAgc3BlY2lmaWNhdGlv bjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBbSS1ELmlldGYtZm9yY2VzLWNl aGEtMDBdLjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IFRocmVlIA0K ICBpbmRlcGVuZGVudCBGb3JDRVMgaW1wbGVtZW50YXRpb25zIHBhcnRpY2lwYXRlZCBpbiB0aGUg dGVzdC48QlI+Jmd0OyANCiAgRU5EPEJSPiZndDsgPEJSPiZndDsmZ3Q7ICZndDsmZ3Q7IEkgaGF2 ZSBhIHBlcnNvbmFsIGRpc2xpa2Ugb2YgcmVwZWF0ZWQgDQogIGRlZmluaXRpb25zIGNvcGllZCBm cm9tIG90aGVyPEJSPiZndDsmZ3Q7ICZndDsmZ3Q7IGRvY3VtZW50cy4gVGhleSBjYW4gY2F1c2Ug DQogIGFsbCBzb3J0cyBvZiBmdW4gaWYgeW91IG1ha2UgYSBtaXN0YWtlIHdoZW48QlI+Jmd0OyZn dDsgJmd0OyZndDsgeW91IGNvcHkgdGhlIA0KICB0ZXh0ISZuYnNwOyBTbyBJIHdvdWxkIHByZWZl ciBzZWN0aW9uIDIuMi4gc2ltcGx5IHRvIHBvaW50IGF0PEJSPiZndDsmZ3Q7IA0KICAmZ3Q7Jmd0 OyB0aGUgZGVmaW5pdGlvbnMgZnJvbSBvdGhlciBSRkNzLjxCUj4mZ3Q7Jmd0OyAmZ3Q7IDxCUj4m Z3Q7Jmd0OyAmZ3Q7IA0KICBBZ3JlZWQgaW4gdGhpcyBjYXNlLjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7 Jmd0OyBJbiBnZW5lcmFsIEkgaGF2ZSB0aGUgb3Bwb3NpdGUgDQogIHRhc3RlIDstJmd0OyBJIHdv dWxkIHJhdGhlciBoYXZlIHRoZTxCUj4mZ3Q7Jmd0OyBjb250ZXh0IGluIHBsYWNlIHNvIGkgY2Fu IA0KICBjb3JyZWxhdGUgaW5zdGVhZCBvZiBnb2luZyBhbmQgcmVhZGluZyA8QlI+Jmd0OyZndDsg c29tZSBvdGhlciBkb2MgDQogIGVsc2V3aGVyZS48QlI+Jmd0OyZndDsgW1llcywgb25lIGNvdWxk IG1ha2UgYSBtaXN0YWtlIGluIGNvcHlpbmcuIEJ1dCBhbHNvIG9uZSANCiAgY291bGQgZml4IHBy ZXZpb3VzbHk8QlI+Jmd0OyZndDsgZXJyb25vdXMgYW5kIHByb3ZpZGUgbW9yZSBleHRlbmRlZCAN CiAgaW5mb3JtYXRpb24gc3VjaCBhcyB0aGUgQ0VIQSBkb2N1bWVudDxCUj4mZ3Q7Jmd0OyBkb2Vz IHdoZW4gaXQgcHJvdmlkZXMgDQogIGNvbnRleHQgZm9yIEhBIGRlcml2ZWQgZnJvbSBSRkMgNTgx MC5dPEJSPiZndDsgPEJSPiZndDsgTGlrZSBJIHNhaWQsIEknbGwgbGV0IA0KICB5J2FsbCBkZWNp ZGUgd2hhdCB0byBkbyBoZXJlIHNpbmNlIEkgZG9uJ3QgZmVlbCBzdHJvbmdseTxCUj4mZ3Q7IA0K ICBlbm91Z2guPEJSPiZndDsgPEJSPiZndDsgQ2FuIEkganVzdCBub3RlLCBob3dldmVyLCB0aGF0 IGlmIHlvdSBhcmUgImZpeGluZyIgYSANCiAgZGVmaW5pdGlvbiB0aGF0IGlzIGFscmVhZHk8QlI+ Jmd0OyBpbiBhIHB1Ymxpc2hlZCBSRkMsIHlvdSBhcmUgY3JlYXRpbmcgYSBuaWNlIA0KICBsaXR0 bGUgbWVzcyB1bmxlc3MgeW91IGFsc28gZml4IHRoZTxCUj4mZ3Q7IGRlZmluaXRpb24gaW4gdGhl IFJGQy4gVGhhdCBmaXggDQogIGNvdWxkIGJlIHRocm91Z2ggYW4gRXJyYXRhIFJlcG9ydCBmb3Ig YTxCUj4mZ3Q7IHR5cG9ncmFwaGljYWwgZXJyb3IsIG9yIGJ5IA0KICB1cGRhdGluZyB0aGUgcHVi bGlzaGVkIFJGQy4gQnV0IHNpbXBseSBwdWJsaXNoaW5nIGE8QlI+Jmd0OyBuZXcgUkZDIHdpdGgg YSANCiAgZGlmZmVyZW50IGRlZmluaXRpb24gaXMgbm90IGEgZ29vZCBpZGVhLjxCUj4mZ3Q7IDxC Uj4mZ3Q7IEFuZCBvbmUgb3RoZXIgdGhpbmc6IA0KICBXZWltaW5nJ3MgaW5pdGlhbCByZXNwb25z ZSBkaWRuJ3QgaW5jbHVkZSBhbnkgcmVzcG9uc2UgdG88QlI+Jmd0OyBteSBpc3N1ZXMgDQogIHdp dGggUkZDIDIxMTkgbGFuZ3VhZ2UuPEJSPiZndDsgPEJSPiZndDsgT25jZSBhZ2FpbiwgdGhhbmtz IGZvciBhbGwgdGhlIA0KICB3b3JrLjxCUj4mZ3Q7IDxCUj4mZ3Q7IENoZWVycyw8QlI+Jmd0OyBB ZHJpYW48QlI+Jmd0OyA8QlI+Jmd0OyANCiAgPFA+DQogIDxIUj4NCg0KICA8UD48L1A+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Zm9yY2VzIG1haWxp bmcgDQogIGxpc3Q8QlI+Zm9yY2VzQGlldGYub3JnPEJSPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZm9yY2VzPEJSPjwvQkxPQ0tRVU9URT48L0RJVj48L0JPRFk+PC9IVE1M Pg0K ------=_NextPart_000_0538_01CE3A7A.072799E0-- From internet-drafts@ietf.org Mon Apr 15 18:46:01 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE0E21E803F; Mon, 15 Apr 2013 18:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE5-sWeqJA8z; Mon, 15 Apr 2013 18:46:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8C621F93B7; Mon, 15 Apr 2013 18:46:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130416014600.24139.54649.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2013 18:46:00 -0700 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-interop-07.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 01:46:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separation= Working Group of the IETF. Title : Interoperability Report for Forwarding and Control Eleme= nt Separation (ForCES) Author(s) : Weiming Wang Kentaro Ogawa Evangelos Haleplidis Ming Gao Jamal Hadi Salim Filename : draft-ietf-forces-interop-07.txt Pages : 28 Date : 2013-04-15 Abstract: This document captures results of the second Forwarding and Control Element Separation (ForCES) interoperability test which took place on February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. RFC 6053 reported the results of the first ForCES interoperability test, and this document updates RFC 6053 by providing further interoperability results. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-interop There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-interop-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-forces-interop-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wmwang2001@hotmail.com Mon Apr 15 18:47:07 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A5A21E803A for ; Mon, 15 Apr 2013 18:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.026 X-Spam-Level: X-Spam-Status: No, score=0.026 tagged_above=-999 required=5 tests=[AWL=2.625, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URaENFBaBy7n for ; Mon, 15 Apr 2013 18:47:07 -0700 (PDT) Received: from blu0-omc4-s12.blu0.hotmail.com (blu0-omc4-s12.blu0.hotmail.com [65.55.111.151]) by ietfa.amsl.com (Postfix) with ESMTP id EABD721E8039 for ; Mon, 15 Apr 2013 18:47:06 -0700 (PDT) Received: from BLU0-SMTP462 ([65.55.111.136]) by blu0-omc4-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Apr 2013 18:47:06 -0700 X-EIP: [VcrHe4k7deHDmLOE+JE6ol1PsM3eo/aM] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([183.156.119.53]) by BLU0-SMTP462.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Apr 2013 18:47:05 -0700 From: "Wang,Weiming" To: Date: Tue, 16 Apr 2013 09:47:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 16 Apr 2013 01:47:05.0331 (UTC) FILETIME=[4C577430:01CE3A44] Subject: [forces] Fw: New Version Notification for draft-ietf-forces-interop-07.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 01:47:07 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZz4NCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtZm9yY2VzLWludGVy b3AtMDcudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdlaW1pbmcgV2Fu ZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogZHJhZnQt aWV0Zi1mb3JjZXMtaW50ZXJvcA0KUmV2aXNpb246IDA3DQpUaXRsZTogSW50ZXJvcGVyYWJpbGl0 eSBSZXBvcnQgZm9yIEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0aW9uIChG b3JDRVMpDQpDcmVhdGlvbiBkYXRlOiAyMDEzLTA0LTE1DQpHcm91cDogZm9yY2VzDQpOdW1iZXIg b2YgcGFnZXM6IDI4DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtZm9yY2VzLWludGVyb3AtMDcudHh0DQpTdGF0dXM6ICAgICAg ICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1mb3JjZXMtaW50 ZXJvcA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWZvcmNlcy1pbnRlcm9wLTA3DQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZm9yY2VzLWludGVyb3AtMDcNCg0KQWJzdHJhY3Q6 DQogICBUaGlzIGRvY3VtZW50IGNhcHR1cmVzIHJlc3VsdHMgb2YgdGhlIHNlY29uZCBGb3J3YXJk aW5nIGFuZCBDb250cm9sDQogICBFbGVtZW50IFNlcGFyYXRpb24gKEZvckNFUykgaW50ZXJvcGVy YWJpbGl0eSB0ZXN0IHdoaWNoIHRvb2sgcGxhY2Ugb24NCiAgIEZlYnJ1YXJ5IDI0LTI1LCAyMDEx IGluIHRoZSBJbnRlcm5ldCBUZWNobm9sb2d5IExhYiAoSVRMKSBvZiBaaGVqaWFuZw0KICAgR29u Z3NoYW5nIFVuaXZlcnNpdHksIENoaW5hLiAgUkZDIDYwNTMgcmVwb3J0ZWQgdGhlIHJlc3VsdHMg b2YgdGhlDQogICBmaXJzdCBGb3JDRVMgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0LCBhbmQgdGhpcyBk b2N1bWVudCB1cGRhdGVzIFJGQw0KICAgNjA1MyBieSBwcm92aWRpbmcgZnVydGhlciBpbnRlcm9w ZXJhYmlsaXR5IHJlc3VsdHMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From wmwang@zjsu.edu.cn Mon Apr 15 16:45:16 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CCB21E8037 for ; Mon, 15 Apr 2013 16:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dQYs1Kpo+WC for ; Mon, 15 Apr 2013 16:45:14 -0700 (PDT) Received: from mail.zjgsu.edu.cn (ucmail.zjgsu.edu.cn [124.160.64.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DC321F93CD for ; Mon, 15 Apr 2013 16:45:11 -0700 (PDT) Received: from WmwangHome (unknown [183.156.119.53]) by mailportal (Coremail) with SMTP id rBCI85D7JHwAkWxRABJ6AA--.63808S2; Tue, 16 Apr 2013 07:45:05 +0800 (CST) Message-ID: <0ED4332616414DB784324F70BA0E26ED@WmwangHome> From: "Weiming Wang" To: "Wang,Weiming" , , "'Jamal Hadi Salim'" References: <048e01ce36fb$46d1d150$d47573f0$@olddog.co.uk><082101ce390e$e42be390$ac83aab0$@olddog.co.uk> Date: Tue, 16 Apr 2013 07:45:09 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04B4_01CE3A76.51C3A010" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-CM-TRANSID: rBCI85D7JHwAkWxRABJ6AA--.63808S2 X-Coremail-Antispam: 1Uf129KBjvJXoW3Gr4xWF1DXFWDKryfCryrtFb_yoW3GrWkpF WrXa4jkr4kAw1rAwn7tw4jyr4Y93yfKrWUGF95Kry09398u3W0qr12kr1Y9F9rCrWrXa1I vw409F4rZa4DZrJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UU U817k0a2IF6w4kM7kC6x804xWl14x267AKxVWUJVW8JwAFxVCF77xC6IxKo4kEV4yl1I0E scIYIxCEI4klw4CSwwAFIxvE14AKwVWUJVWUGwAqx4xG62kEwI0EbcxfMcIj6xIIjxv20x vE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k0 4243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1lc7CjxVAaw2AFwI0_JF0_Jw1l42xK82 IYc2Ij64vIr41lx4CE17CEb7AF67AKxVWUAVWUtwCIccxYrVCFb41lIxkGc2Ij64vIr4Uv cSsGvfC2KfnxnUUI43ZEXa7xR_UUUUUUUUU== X-CM-SenderInfo: pzpzt03j6ptxvoo2ywlvxovvfxof0/ X-Mailman-Approved-At: Tue, 16 Apr 2013 08:18:55 -0700 Cc: forces@ietf.org, draft-ietf-forces-interop@tools.ietf.org Subject: Re: [forces] AD review of draft-ietf-forces-interop X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 23:45:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04B4_01CE3A76.51C3A010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgQWRyaWFuIGFuZCBhbGwsDQoNCkkgd2VudCBiYWNrIGNoZWNrZWQgdGhlIHByb2Nlc3MsIGl0 IHNlZW1zIHdlIHJlcG9ydGVkIHNldmVyYWwgZXJyYXRhLCBidXQgbm90IGFjdHVhbGx5IGFjY2Vw dGVkLCB3aGljaCBpbmNsdWRlZDogDQoNCg0KMS4gU2VjdGlvbiA3LjEuMSAoUkZDIDU4MTApIHBh cnQgdGhhdCBzYXlzOg0KICAgICogIFdoZW4gYSB0YWJsZSBpcyByZWZlcnJlZCB0byBpbiB0aGUg UEFUSCAoSURzKSBvZiBhIFBBVEgtREFUQS0NCiAgICAgICAgIFRMViwgdGhlbiB0aGUgRlVMTERB VEEtVExWJ3MgIlYiIHdpbGwgY29udGFpbiB0aGF0IHRhYmxlJ3Mgcm93DQogICAgICAgICBjb250 ZW50IHByZWZpeGVkIGJ5IGl0cyAzMi1iaXQgaW5kZXgvc3Vic2NyaXB0LiAgT24gdGhlIG90aGVy DQogICAgICAgICBoYW5kLCB0aGUgUEFUSCBtYXkgY29udGFpbiBhbiBpbmRleCBwb2ludGluZyB0 byBhIHJvdyBpbiB0YWJsZTsNCiAgICAgICAgIGluIHN1Y2ggYSBjYXNlLCB0aGUgRlVMTERBVEEt VExWJ3MgIlYiIHdpbGwgb25seSBjb250YWluIHRoZQ0KICAgICAgICAgY29udGVudCB3aXRoIHRo ZSBpbmRleCBpbiBvcmRlciB0byBhdm9pZCBhbWJpZ3VpdHkuDQoNCkF0IHRoZSBlbmQgb2YgdGhl IHRleHQ6ICJ0aGUgRlVMTERBVEEtVExWJ3MgIlYiIHdpbGwgb25seSBjb250YWluIHRoZQ0KY29u dGVudCB3aXRoIHRoZSBpbmRleCAuIg0KSXQgc2hvdWxkIGJlICJ0aGUgRlVMTERBVEEtVExWJ3Mg IlYiIHdpbGwgb25seSBjb250YWluIHRoZSBjb250ZW50IHdpdGhvdXQNCnRoZSBpbmRleCAuIg0K DQoyLiBBbmQgYWxzbyBzb21ldGhpbmcgb2YgbGVzc2VyIGltcG9ydGFuY2UuIFBhZ2UgMTA5IChS RkMgNTgxMCkuIEZvciAjNS4NClNheXMgZm9yIFJlc3VsdDoNCk9QRVI9U0VULVRMVg0KU2hvdWxk IGhhdmUgYmVlbjoNCk9QRVI9U0VULVJFU1BPTlNFLVRMVg0KDQozLiAgVGhlcmUgYXJlIHNldmVy YWwgcGxhY2VzIGluIHRhYmxlIDMgb2YgcmZjNTgxMCB3aGVyZSB0aGUgdGV4dCBzYXlzICJhbiBj b21wb25lbnQiLiANCg0KQXMgYSByZXN1bHQsIHdlIGFyZSBub3QgZ29pbmcgdG8gYW5kIHRoZSBy ZXBvcnRzIGxpc3QgaW4gdGhlIGRvY3VtZW50LCByYXRoZXIsIGp1c3Qga2VlcCB0aGUgdGV4dDog DQoNCiBTb21lIGVycmF0YSByZWxhdGVkIHRvIEZvckNFUyBkb2N1bWVudCB3ZXJlIGZvdW5kIGJ5 IHRoZQ0KICAgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0LiAgVGhlIGVycmF0YSBoYXMgYmVlbiByZXBv cnRlZCB0byByZWxhdGVkIElFVEYNCiAgIFJGQ3MuDQoNCg0KdGhhbmtzLA0KV2VpbWluZw0KDQoN Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IFdhbmcsV2VpbWluZyANCiAg VG86IGFkcmlhbkBvbGRkb2cuY28udWsgOyAnSmFtYWwgSGFkaSBTYWxpbScgDQogIENjOiBmb3Jj ZXNAaWV0Zi5vcmcgOyBkcmFmdC1pZXRmLWZvcmNlcy1pbnRlcm9wQHRvb2xzLmlldGYub3JnIA0K ICBTZW50OiBNb25kYXksIEFwcmlsIDE1LCAyMDEzIDg6MTYgUE0NCiAgU3ViamVjdDogUmU6IFtm b3JjZXNdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWZvcmNlcy1pbnRlcm9wDQoNCg0KICBIaSBB ZHJpYW4gYW5kIGFsbCwNCg0KICBJIHRoaW5rIG1vc3Qgb2YgdGhlIGlzc3VlcyByYWlzZWQgYnkg QUQgYXJlIGJlZW4gYWRkcmVzc2VkIGFuZCB3ZSBhcmUgZ29pbmcgdG8gZm9ybSBhIG5ldyAwNyB2 ZXJzaW9uIHZlcnkgc29vbi4gVGhlIDA3IGJldGEgdmVyc2lvbiBhbmQgYSBkaWZmIGZpbGUgdG8g djA2IGluIHRoZSBhdHRhY2htZW50IGFyZSBmb3IgeW91ciByZXZpZXcgYWdhaW4uDQoNCiAgdGhh bmtzIHZlcnkgbXVjaC4NCiAgV2VpbWluZw0KDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gDQogIEZyb206ICJBZHJpYW4gRmFycmVsIiA8YWRyaWFuQG9sZGRvZy5jby51az4NCg0KICA+ IEhpIGFsbCwNCiAgPiANCiAgPj4gPiBJIG5vdyBoYXZlIG1vcmUgcXVlc3Rpb24gdGhhdCwgaWYg d2Ugc2hvdWxkIHBvaW50IG91dCB0aGUgZGVmZXJlbmNlDQogID4+ID4gYmV0d2VlbiB0aGUgdGVz dGVkIHZlcnNpb24gYW5kIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50Pw0KICA+ PiA+IE9yLCBzaGFsbCB3ZSBhbHNvIG1lbnRpb24gd2hhdCB0ZXN0ZWQgaXMgc3RpbGwgb3Igbm90 IGluIGV4aXN0ZW5zZSBpbg0KICA+PiA+IGN1cnJlbnQgdmVyc2lvbiwgb3Igd2hhdCBjaGFuZ2Ug aGFzIGhhcHBlbmVkPw0KICA+PiA+DQogID4+ID4gSSBkbyBob3BlIGF1dGhvcnMgY2FuIHNob3cg eW91ciBzdWdnZXN0aW9ucyB0byBzb2x2ZSB0aGUgaXNzdWUuDQogID4+IA0KICA+PiBJIHRoaW5r IHdlIHBvaW50IHRvIHRoZSBSRkNzLCBpZiB0aGV5IGV4aXN0IGFuZCBtZW50aW9uIHNwZWNpZmlj IHZlcnNpb25zDQogID4+IG9mIHRoZSBkcmFmdHMgcHJlLVJGQy4gSSBhbSBub3Qgc3VyZSBpZiB0 aGUgeG1sIHdpbGwgYWxsb3cgeW91IHRvIHVzZQ0KICA+IG9ic29sZXRlZA0KICA+PiBkb2N1bWVu dHMgYXMgcmVmZXJlbmNlczsgYW5kIGlmIHlvdSByZWZlcmVuY2UgdGhlbSAtIHdoZXRoZXIgdGhl eSBhcmUNCiAgPj4gZ3VhcmFudGVlZCB0byBiZSBhY2Nlc3NpYmxlIHdoZW4gc29tZW9uZSBuZWVk cyB0byByZWZlcmVuY2UgdGhlbS4gDQogID4+IEV4YW1wbGUsIGluIDIgeWVhcnMgZnJvbSBub3cs IHdpbGwgc29tZW9uZSBiZSBhYmxlIHRvIGFjY2VzcyBjZWhhIGRyYWZ0DQogID4+IHZlcnNpb24g MyBvbiB0aGUgaWV0ZiB3ZWIgc2l0ZT8NCiAgPiANCiAgPiBJIHRoaW5rIGl0IGlzIHJlYWxseSBp bXBvcnRhbnQgdG8gcmVmZXJlbmNlIHRoZW0uIExpa2UgSm9lbCBzYXlzIChhbmQgdW5saWtlDQog ID4gd2hhdCB0aGUgYm9pbGVycGxhdGUgc2F5czstKSBJLWRzIHNlZW0gdG8gcGVyc2lzdCBvbiB0 aGUgaW50ZXJ3ZWIgZm9yIGV2ZXIuIFlvdQ0KICA+IHNob3VsZG4ndCBwdXQgdGhlbSBpbiBhcyBu b3JtYXRpdmUgcmVmZXJlbmNlcywgYnV0IHlvdSBzaG91bGQgcHV0IHRoZW0gaW4gYXMNCiAgPiBz cGVjaWZpYyBudW1iZXJlZCBhbmQgZGF0ZWQgdmVyc2lvbi4gSSB3b3VsZCBhbHNvIHJlY29tbWVu ZCBhZGRpbmcgYW4gUkZDIGVkaXRvcg0KICA+IG5vdGUgZm9yIGVhY2ggb25lIGFzIGZvbGxvd3M6 DQogID4gDQogID4gT0xEDQogID4gICBbSS1ELmlldGYtZm9yY2VzLWNlaGFdDQogID4gICAgICAg ICAgICAgIE9nYXdhLCBLLiwgV2FuZywgVy4sIEhhbGVwbGlkaXMsIEUuLCBhbmQgSi4gU2FsaW0s ICJGb3JDRVMNCiAgPiAgICAgICAgICAgICAgSW50cmEtTkUgSGlnaCBBdmFpbGFiaWxpdHkiLCBk cmFmdC1pZXRmLWZvcmNlcy1jZWhhLTA1DQogID4gICAgICAgICAgICAgICh3b3JrIGluIHByb2dy ZXNzKSwgSmFudWFyeSAyMDEzLg0KICA+IA0KICA+ICAgW0ktRC5pZXRmLWZvcmNlcy1sZmItbGli XQ0KICA+ICAgICAgICAgICAgICBXYW5nLCBXLiwgSGFsZXBsaWRpcywgRS4sIE9nYXdhLCBLLiwg TGksIEMuLCBhbmQgSi4NCiAgPiAgICAgICAgICAgICAgSGFscGVybiwgIkZvckNFUyBMb2dpY2Fs IEZ1bmN0aW9uIEJsb2NrIChMRkIpIExpYnJhcnkiLA0KICA+ICAgICAgICAgICAgICBkcmFmdC1p ZXRmLWZvcmNlcy1sZmItbGliLTEwICh3b3JrIGluIHByb2dyZXNzKSwNCiAgPiAgICAgICAgICAg ICAgSmFudWFyeSAyMDEzLg0KICA+IE5FVw0KICA+ICAgW0ktRC5pZXRmLWZvcmNlcy1jZWhhLTAw XQ0KICA+ICAgICAgICAgICAgICBPZ2F3YSwgSy4sIFdhbmcsIFcuLCBIYWxlcGxpZGlzLCBFLiwg YW5kIEouIFNhbGltLCAiRm9yQ0VTDQogID4gICAgICAgICAgICAgIEludHJhLU5FIEhpZ2ggQXZh aWxhYmlsaXR5IiwgZHJhZnQtaWV0Zi1mb3JjZXMtY2VoYS0wMCwNCiAgPiAgICAgICAgICAgICAg T2N0b2JlciAyMDEwLCB3b3JrIGluIHByb2dyZXNzLg0KICA+ICAgICAgICAgICAgICBbUkZDIEVk aXRvciBOb3RlLiBUaGlzIHJlZmVyZW5jZSBpcyBpbnRlbmRlZCB0byBpbmRpY2F0ZSBhDQogID4g ICAgICAgICAgICAgIHNwZWNpZmljIHZlcnNpb24gb2YgYW4gSW50ZXJuZXQtRHJhZnQgdGhhdCB3 YXMgdXNlZCBkdXJpbmcNCiAgPiAgICAgICAgICAgICAgaW50ZXJvcCB0ZXN0aW5nLiBQbGVhc2Ug RG8gTk9UIHVwZGF0ZSB0aGlzIHJlZmVyZW5jZSB0byBhIA0KICA+ICAgICAgICAgICAgICBtb3Jl IHJlY2VudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBvciB0byBhbiBSRkMuIFBsZWFzZQ0KICA+ICAg ICAgICAgICAgICByZW1vdmUgdGhpcyBub3RlIGJlZm9yZSBwdWJsaWNhdGlvbi5dDQogID4gDQog ID4gICBbSS1ELmlldGYtZm9yY2VzLWxmYi1saWItMDNdDQogID4gICAgICAgICAgICAgIFdhbmcs IFcuLCBIYWxlcGxpZGlzLCBFLiwgT2dhd2EsIEsuLCBMaSwgQy4sIGFuZCBKLg0KICA+ICAgICAg ICAgICAgICBIYWxwZXJuLCAiRm9yQ0VTIExvZ2ljYWwgRnVuY3Rpb24gQmxvY2sgKExGQikgTGli cmFyeSIsDQogID4gICAgICAgICAgICAgIGRyYWZ0LWlldGYtZm9yY2VzLWxmYi1saWItMDMsIERl Y2VtYmVyIDIwMTAsIHdvcmsgaW4gDQogID4gICAgICAgICAgICAgIHByb2dyZXNzLg0KICA+ICAg ICAgICAgICAgICANCiAgPiAgICAgICAgICAgICAgW1JGQyBFZGl0b3IgTm90ZS4gVGhpcyByZWZl cmVuY2UgaXMgaW50ZW5kZWQgdG8gaW5kaWNhdGUgYQ0KICA+ICAgICAgICAgICAgICBzcGVjaWZp YyB2ZXJzaW9uIG9mIGFuIEludGVybmV0LURyYWZ0IHRoYXQgd2FzIHVzZWQgZHVyaW5nDQogID4g ICAgICAgICAgICAgIGludGVyb3AgdGVzdGluZy4gUGxlYXNlIERvIE5PVCB1cGRhdGUgdGhpcyBy ZWZlcmVuY2UgdG8gYSANCiAgPiAgICAgICAgICAgICAgbW9yZSByZWNlbnQgdmVyc2lvbiBvZiB0 aGUgZHJhZnQgb3IgdG8gYW4gUkZDLiBQbGVhc2UNCiAgPiAgICAgICAgICAgICAgcmVtb3ZlIHRo aXMgbm90ZSBiZWZvcmUgcHVibGljYXRpb24uXQ0KICA+IEVORA0KICA+IA0KICA+PiBTaW5jZSB0 aGUgQUQgaGFzIGdyYWNpb3VzbHkgb2ZmZXJlZCB0byBjb21lIHVwIHdpdGggc29tZSBsYW5ndWFn ZSwgd2h5DQogID4+IGRvbnQgd2UgbGV0IGhpbSBkbyB0aGF0IGZvciB1cz8NCiAgPiANCiAgPiBP SywgaGVyZSB3ZSBnby4uLg0KICA+IA0KICA+IE9MRCAgIA0KICA+ICAgVGhpcyBkb2N1bWVudCBj YXB0dXJlcyByZXN1bHRzIG9mIHRoZSBzZWNvbmQgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0IG9mDQog ID4gICB0aGUgRm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gKEZvckNF Uykgd2hpY2ggdG9vaw0KICA+ICAgcGxhY2UgRmVicnVhcnkgMjQtMjUsIDIwMTEgaW4gdGhlIElu dGVybmV0IFRlY2hub2xvZ3kgTGFiIChJVEwpIG9mDQogID4gICBaaGVqaWFuZyBHb25nc2hhbmcg VW5pdmVyc2l0eSwgQ2hpbmEuICBUaGUgdGVzdCBpbnZvbHZlZCBzZXZlcmFsDQogID4gICBkb2N1 bWVudHMgbmFtZWx5OiBGb3JDRVMgcHJvdG9jb2wgW1JGQzU4MTBdICwgRm9yQ0VTIEZFIG1vZGVs DQogID4gICBbUkZDNTgxMl0gLCBGb3JDRVMgVE1MIFtSRkM1ODExXSAsIEZvckNFUyBMRkIgTGli cmFyeQ0KICA+ICAgW0ktRC5pZXRmLWZvcmNlcy1sZmItbGliXSBhbmQgRm9yQ0VTIENFIEhBIHNw ZWNpZmljYXRpb24NCiAgPiAgIFtJLUQuaWV0Zi1mb3JjZXMtY2VoYV0uICBUaHJlZSBpbmRlcGVu ZGVudCBGb3JDRVMgaW1wbGVtZW50YXRpb25zDQogID4gICBwYXJ0aWNpcGF0ZWQgaW4gdGhlIHRl c3QuDQogID4gTkVXDQogID4gICBUaGlzIGRvY3VtZW50IGNhcHR1cmVzIHJlc3VsdHMgb2YgdGhl IHNlY29uZCBpbnRlcm9wZXJhYmlsaXR5IHRlc3Qgb2YNCiAgPiAgIHRoZSBGb3J3YXJkaW5nIGFu ZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbiAoRm9yQ0VTKSB3aGljaCB0b29rDQogID4gICBw bGFjZSBGZWJydWFyeSAyNC0yNSwgMjAxMSBpbiB0aGUgSW50ZXJuZXQgVGVjaG5vbG9neSBMYWIg KElUTCkgb2YNCiAgPiAgIFpoZWppYW5nIEdvbmdzaGFuZyBVbml2ZXJzaXR5LCBDaGluYS4gIFRo ZSB0ZXN0IGludm9sdmVkIHByb3RvY29sDQogID4gICBlbGVtZW50cyBkZXNjcmliZWQgaW4gc2V2 ZXJhbCBkb2N1bWVudHMgbmFtZWx5OiANCiAgPiANCiAgPiAgIC0gVGhlIEZvckNFUyBwcm90b2Nv bCBbUkZDNTgxMF0NCiAgPiAgIC0gVGhlIEZvckNFUyBGb3J3YXJkaW5nIEVsZW1lbnQgbW9kZWwg W1JGQzU4MTJdDQogID4gICAtIFRoZSBGb3JDRVMgVHJhbnNwb3J0IE1hcHBpbmcgTGF5ZXIgW1JG QzU4MTFdLg0KICA+ICAgDQogID4gICBUaGUgdGVzdCBhbHNvIGludm9sdmVkIHByb3RvY29sIGVs ZW1lbnRzIGRlc2NyaWJlZCBpbiB0aGUgdGhlbi0NCiAgPiAgIGN1cnJlbnQgdmVyc2lvbnMgb2Yg dHdvIEludGVybmV0LURyYWZ0cy4gIEFsdGhvdWdoIHRoZXNlIGRvY3VtZW50cw0KICA+ICAgaGF2 ZSBzdWJzZXF1ZW50bHkgYmVlbiByZXZpc2VkIGFuZCBhZHZhbmNlZCwgaXQgaXMgaW1wb3J0YW50 IHRvIA0KICA+ICAgdW5kZXJzdGFuZCB3aGljaCB2ZXJzaW9ucyBvZiB0aGUgd29yayB3ZXJlIHVz ZWQgZHVyaW5nIHRoaXMgdGVzdC4NCiAgPiANCiAgPiAgIC0gRm9yQ0VTIExvZ2ljYWwgRnVuY3Rp b24gQmxvY2sgTGlicmFyeSBbSS1ELmlldGYtZm9yY2VzLWxmYi1saWItMDNdDQogID4gICAtIEZv ckNFUyBJbnRyYS1OZXR3b3JrIEVsZW1lbnQgSGlnaCBBdmFpbGFiaWxpdHkgc3BlY2lmaWNhdGlv bg0KICA+ICAgICBbSS1ELmlldGYtZm9yY2VzLWNlaGEtMDBdLg0KICA+ICAgDQogID4gICBUaHJl ZSBpbmRlcGVuZGVudCBGb3JDRVMgaW1wbGVtZW50YXRpb25zIHBhcnRpY2lwYXRlZCBpbiB0aGUg dGVzdC4NCiAgPiBFTkQNCiAgPiANCiAgPj4gPj4gSSBoYXZlIGEgcGVyc29uYWwgZGlzbGlrZSBv ZiByZXBlYXRlZCBkZWZpbml0aW9ucyBjb3BpZWQgZnJvbSBvdGhlcg0KICA+PiA+PiBkb2N1bWVu dHMuIFRoZXkgY2FuIGNhdXNlIGFsbCBzb3J0cyBvZiBmdW4gaWYgeW91IG1ha2UgYSBtaXN0YWtl IHdoZW4NCiAgPj4gPj4geW91IGNvcHkgdGhlIHRleHQhICBTbyBJIHdvdWxkIHByZWZlciBzZWN0 aW9uIDIuMi4gc2ltcGx5IHRvIHBvaW50IGF0DQogID4+ID4+IHRoZSBkZWZpbml0aW9ucyBmcm9t IG90aGVyIFJGQ3MuDQogID4+ID4gDQogID4+ID4gQWdyZWVkIGluIHRoaXMgY2FzZS4NCiAgPj4N CiAgPj4gSW4gZ2VuZXJhbCBJIGhhdmUgdGhlIG9wcG9zaXRlIHRhc3RlIDstPiBJIHdvdWxkIHJh dGhlciBoYXZlIHRoZQ0KICA+PiBjb250ZXh0IGluIHBsYWNlIHNvIGkgY2FuIGNvcnJlbGF0ZSBp bnN0ZWFkIG9mIGdvaW5nIGFuZCByZWFkaW5nIA0KICA+PiBzb21lIG90aGVyIGRvYyBlbHNld2hl cmUuDQogID4+IFtZZXMsIG9uZSBjb3VsZCBtYWtlIGEgbWlzdGFrZSBpbiBjb3B5aW5nLiBCdXQg YWxzbyBvbmUgY291bGQgZml4IHByZXZpb3VzbHkNCiAgPj4gZXJyb25vdXMgYW5kIHByb3ZpZGUg bW9yZSBleHRlbmRlZCBpbmZvcm1hdGlvbiBzdWNoIGFzIHRoZSBDRUhBIGRvY3VtZW50DQogID4+ IGRvZXMgd2hlbiBpdCBwcm92aWRlcyBjb250ZXh0IGZvciBIQSBkZXJpdmVkIGZyb20gUkZDIDU4 MTAuXQ0KICA+IA0KICA+IExpa2UgSSBzYWlkLCBJJ2xsIGxldCB5J2FsbCBkZWNpZGUgd2hhdCB0 byBkbyBoZXJlIHNpbmNlIEkgZG9uJ3QgZmVlbCBzdHJvbmdseQ0KICA+IGVub3VnaC4NCiAgPiAN CiAgPiBDYW4gSSBqdXN0IG5vdGUsIGhvd2V2ZXIsIHRoYXQgaWYgeW91IGFyZSAiZml4aW5nIiBh IGRlZmluaXRpb24gdGhhdCBpcyBhbHJlYWR5DQogID4gaW4gYSBwdWJsaXNoZWQgUkZDLCB5b3Ug YXJlIGNyZWF0aW5nIGEgbmljZSBsaXR0bGUgbWVzcyB1bmxlc3MgeW91IGFsc28gZml4IHRoZQ0K ICA+IGRlZmluaXRpb24gaW4gdGhlIFJGQy4gVGhhdCBmaXggY291bGQgYmUgdGhyb3VnaCBhbiBF cnJhdGEgUmVwb3J0IGZvciBhDQogID4gdHlwb2dyYXBoaWNhbCBlcnJvciwgb3IgYnkgdXBkYXRp bmcgdGhlIHB1Ymxpc2hlZCBSRkMuIEJ1dCBzaW1wbHkgcHVibGlzaGluZyBhDQogID4gbmV3IFJG QyB3aXRoIGEgZGlmZmVyZW50IGRlZmluaXRpb24gaXMgbm90IGEgZ29vZCBpZGVhLg0KICA+IA0K ICA+IEFuZCBvbmUgb3RoZXIgdGhpbmc6IFdlaW1pbmcncyBpbml0aWFsIHJlc3BvbnNlIGRpZG4n dCBpbmNsdWRlIGFueSByZXNwb25zZSB0bw0KICA+IG15IGlzc3VlcyB3aXRoIFJGQyAyMTE5IGxh bmd1YWdlLg0KICA+IA0KICA+IE9uY2UgYWdhaW4sIHRoYW5rcyBmb3IgYWxsIHRoZSB3b3JrLg0K ICA+IA0KICA+IENoZWVycywNCiAgPiBBZHJpYW4NCiAgPiANCiAgPg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQoNCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCiAgZm9yY2VzIG1haWxpbmcgbGlzdA0KICBmb3JjZXNAaWV0Zi5vcmcNCiAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXMNCg== ------=_NextPart_000_04B4_01CE3A76.51C3A010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTQxMiI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT00IGZhY2U9JiMyMzQz NTsmIzIwMzA3Oz5IaSBBZHJpYW4gYW5kIGFsbCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNp emU9NCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBzaXplPTQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7Pkkgd2VudCBiYWNrIGNoZWNrZWQgdGhlIHBy b2Nlc3MsIGl0IHNlZW1zIHdlIHJlcG9ydGVkIA0Kc2V2ZXJhbCBlcnJhdGEsIGJ1dCBub3QgYWN0 dWFsbHkgYWNjZXB0ZWQsIHdoaWNoIGluY2x1ZGVkOiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9NCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+MS4gU2VjdGlvbiA3LjEuMSAoUkZDIDU4MTApIHBhcnQgdGhhdCBz YXlzOjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyANCldoZW4gYSB0YWJsZSBpcyByZWZl cnJlZCB0byBpbiB0aGUgUEFUSCAoSURzKSBvZiBhIA0KUEFUSC1EQVRBLTxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVExWLCB0aGVuIHRoZSANCkZV TExEQVRBLVRMVidzICJWIiB3aWxsIGNvbnRhaW4gdGhhdCB0YWJsZSdzIA0Kcm93PEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb250ZW50IHByZWZp eGVkIGJ5IGl0cyANCjMyLWJpdCBpbmRleC9zdWJzY3JpcHQuJm5ic3A7IE9uIHRoZSANCm90aGVy PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBoYW5k LCB0aGUgUEFUSCBtYXkgDQpjb250YWluIGFuIGluZGV4IHBvaW50aW5nIHRvIGEgcm93IGluIA0K dGFibGU7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBpbiBzdWNoIGEgY2FzZSwgdGhlIA0KRlVMTERBVEEtVExWJ3MgIlYiIHdpbGwgb25seSBjb250 YWluIA0KdGhlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBjb250ZW50IHdpdGggdGhlIGluZGV4IA0KaW4gb3JkZXIgdG8gYXZvaWQgYW1iaWd1aXR5 LjxCUj48QlI+QXQgdGhlIGVuZCBvZiB0aGUgdGV4dDogInRoZSBGVUxMREFUQS1UTFYncyANCiJW IiB3aWxsIG9ubHkgY29udGFpbiB0aGU8QlI+Y29udGVudCB3aXRoIHRoZSBpbmRleCAuIjxCUj5J dCBzaG91bGQgYmUgInRoZSANCkZVTExEQVRBLVRMVidzICJWIiB3aWxsIG9ubHkgY29udGFpbiB0 aGUgY29udGVudCB3aXRob3V0PEJSPnRoZSBpbmRleCANCi4iPEJSPjxCUj4yLiBBbmQgYWxzbyBz b21ldGhpbmcgb2YgbGVzc2VyIGltcG9ydGFuY2UuIFBhZ2UgMTA5IChSRkMgNTgxMCkuIEZvciAN CiM1LjxCUj5TYXlzIGZvciBSZXN1bHQ6PEJSPk9QRVI9U0VULVRMVjxCUj5TaG91bGQgaGF2ZSAN CmJlZW46PEJSPk9QRVI9U0VULVJFU1BPTlNFLVRMVjxCUj48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz4zLiZuYnNwOzxGT05UIHNpemU9Mz4gVGhlcmUgYXJl IHNldmVyYWwgcGxhY2VzIGluIA0KdGFibGUgMyBvZiByZmM1ODEwIHdoZXJlIHRoZSB0ZXh0IHNh eXMgImFuIGNvbXBvbmVudCIuIDwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBm YWNlPSYjMjM0MzU7JiMyMDMwNzs+QXMgYSByZXN1bHQsIHc8L0ZPTlQ+PEZPTlQgc2l6ZT0yIGZh Y2U9JiMyMzQzNTsmIzIwMzA3Oz5lIGFyZSBub3QgDQpnb2luZyB0byBhbmQgdGhlIHJlcG9ydHMg bGlzdCBpbiB0aGUgZG9jdW1lbnQsIHJhdGhlciwganVzdCBrZWVwIHRoZSB0ZXh0OiANCjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAz MDc7PjxGT05UIHNpemU9Mz4mbmJzcDtTb21lIGVycmF0YSByZWxhdGVkIHRvIEZvckNFUyANCmRv Y3VtZW50IHdlcmUgZm91bmQgYnkgdGhlPEJSPiZuYnNwOyZuYnNwOyBpbnRlcm9wZXJhYmlsaXR5 IHRlc3QuJm5ic3A7IFRoZSANCmVycmF0YSBoYXMgYmVlbiByZXBvcnRlZCB0byByZWxhdGVkIElF VEY8QlI+Jm5ic3A7Jm5ic3A7IA0KUkZDcy48L0ZPTlQ+PC9GT05UPjwvRElWPjxGT05UIHNpemU9 MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PEZPTlQgc2l6ZT0zPjwvRk9OVD48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PEZPTlQgc2l6ZT0zPjxG T05UIHNpemU9Mj48L0ZPTlQ+PEZPTlQgDQpzaXplPTI+PC9GT05UPjwvRk9OVD48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PEZPTlQg c2l6ZT0zPjxGT05UIHNpemU9Mj48L0ZPTlQ+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+PC9G T05UPjwvRk9OVD48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjxGT05UIHNpemU9 Mz48Rk9OVCANCnNpemU9Mj48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+PC9GT05U PiZuYnNwOzwvRElWPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAz MDc7PjxGT05UIHNpemU9Mz48Rk9OVCANCnNpemU9Mj50aGFua3MsPC9GT05UPjwvRk9OVD48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PEZPTlQg c2l6ZT0zPjxGT05UIA0Kc2l6ZT0yPldlaW1pbmc8L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6 ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4 OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZP TlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7OyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9y OiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT13bXdhbmcyMDAxQGhvdG1haWwuY29t IA0KICBocmVmPSJtYWlsdG86d213YW5nMjAwMUBob3RtYWlsLmNvbSI+V2FuZyxXZWltaW5nPC9B PiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRv OjwvQj4gPEEgdGl0bGU9YWRyaWFuQG9sZGRvZy5jby51ayANCiAgaHJlZj0ibWFpbHRvOmFkcmlh bkBvbGRkb2cuY28udWsiPmFkcmlhbkBvbGRkb2cuY28udWs8L0E+IDsgPEEgDQogIHRpdGxlPWhh ZGlAbW9qYXRhdHUuY29tIGhyZWY9Im1haWx0bzpoYWRpQG1vamF0YXR1LmNvbSI+J0phbWFsIEhh ZGkgU2FsaW0nPC9BPiANCiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1 OyYjMjAzMDc7Ij48Qj5DYzo8L0I+IDxBIHRpdGxlPWZvcmNlc0BpZXRmLm9yZyANCiAgaHJlZj0i bWFpbHRvOmZvcmNlc0BpZXRmLm9yZyI+Zm9yY2VzQGlldGYub3JnPC9BPiA7IDxBIA0KICB0aXRs ZT1kcmFmdC1pZXRmLWZvcmNlcy1pbnRlcm9wQHRvb2xzLmlldGYub3JnIA0KICBocmVmPSJtYWls dG86ZHJhZnQtaWV0Zi1mb3JjZXMtaW50ZXJvcEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1m b3JjZXMtaW50ZXJvcEB0b29scy5pZXRmLm9yZzwvQT4gDQogIDwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IE1vbmRheSwgQXByaWwg MTUsIDIwMTMgODoxNiBQTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsm IzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFJlOiBbZm9yY2VzXSBBRCByZXZpZXcgb2YgDQogIGRy YWZ0LWlldGYtZm9yY2VzLWludGVyb3A8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+SGkgQWRyaWFu IGFuZCBhbGwsPEJSPjxCUj5JIHRoaW5rIG1vc3Qgb2YgdGhlIGlzc3VlcyByYWlzZWQgYnkgDQog IEFEIGFyZSBiZWVuIGFkZHJlc3NlZCBhbmQgd2UgYXJlIGdvaW5nIHRvIGZvcm0gYSBuZXcgMDcg dmVyc2lvbiB2ZXJ5IHNvb24uIFRoZSANCiAgMDcgYmV0YSB2ZXJzaW9uIGFuZCBhIGRpZmYgZmls ZSB0byB2MDYgaW4gdGhlIGF0dGFjaG1lbnQgYXJlIGZvciB5b3VyIHJldmlldyANCiAgYWdhaW4u PEJSPjxCUj50aGFua3MgdmVyeSBtdWNoLjxCUj5XZWltaW5nPEJSPjxCUj4tLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KICA8QlI+RnJvbTogIkFkcmlhbiBGYXJyZWwiICZsdDs8QSANCiAg aHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPmFkcmlhbkBvbGRkb2cuY28udWs8L0E+ Jmd0OzxCUj48QlI+Jmd0OyBIaSANCiAgYWxsLDxCUj4mZ3Q7IDxCUj4mZ3Q7Jmd0OyAmZ3Q7IEkg bm93IGhhdmUgbW9yZSBxdWVzdGlvbiB0aGF0LCBpZiB3ZSBzaG91bGQgDQogIHBvaW50IG91dCB0 aGUgZGVmZXJlbmNlPEJSPiZndDsmZ3Q7ICZndDsgYmV0d2VlbiB0aGUgdGVzdGVkIHZlcnNpb24g YW5kIHRoZSANCiAgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudD88QlI+Jmd0OyZndDsg Jmd0OyBPciwgc2hhbGwgd2UgYWxzbyBtZW50aW9uIA0KICB3aGF0IHRlc3RlZCBpcyBzdGlsbCBv ciBub3QgaW4gZXhpc3RlbnNlIGluPEJSPiZndDsmZ3Q7ICZndDsgY3VycmVudCB2ZXJzaW9uLCAN CiAgb3Igd2hhdCBjaGFuZ2UgaGFzIGhhcHBlbmVkPzxCUj4mZ3Q7Jmd0OyAmZ3Q7PEJSPiZndDsm Z3Q7ICZndDsgSSBkbyBob3BlIA0KICBhdXRob3JzIGNhbiBzaG93IHlvdXIgc3VnZ2VzdGlvbnMg dG8gc29sdmUgdGhlIGlzc3VlLjxCUj4mZ3Q7Jmd0OyA8QlI+Jmd0OyZndDsgDQogIEkgdGhpbmsg d2UgcG9pbnQgdG8gdGhlIFJGQ3MsIGlmIHRoZXkgZXhpc3QgYW5kIG1lbnRpb24gc3BlY2lmaWMg DQogIHZlcnNpb25zPEJSPiZndDsmZ3Q7IG9mIHRoZSBkcmFmdHMgcHJlLVJGQy4gSSBhbSBub3Qg c3VyZSBpZiB0aGUgeG1sIHdpbGwgDQogIGFsbG93IHlvdSB0byB1c2U8QlI+Jmd0OyBvYnNvbGV0 ZWQ8QlI+Jmd0OyZndDsgZG9jdW1lbnRzIGFzIHJlZmVyZW5jZXM7IGFuZCBpZiANCiAgeW91IHJl ZmVyZW5jZSB0aGVtIC0gd2hldGhlciB0aGV5IGFyZTxCUj4mZ3Q7Jmd0OyBndWFyYW50ZWVkIHRv IGJlIGFjY2Vzc2libGUgDQogIHdoZW4gc29tZW9uZSBuZWVkcyB0byByZWZlcmVuY2UgdGhlbS4g PEJSPiZndDsmZ3Q7IEV4YW1wbGUsIGluIDIgeWVhcnMgZnJvbSANCiAgbm93LCB3aWxsIHNvbWVv bmUgYmUgYWJsZSB0byBhY2Nlc3MgY2VoYSBkcmFmdDxCUj4mZ3Q7Jmd0OyB2ZXJzaW9uIDMgb24g dGhlIA0KICBpZXRmIHdlYiBzaXRlPzxCUj4mZ3Q7IDxCUj4mZ3Q7IEkgdGhpbmsgaXQgaXMgcmVh bGx5IGltcG9ydGFudCB0byByZWZlcmVuY2UgDQogIHRoZW0uIExpa2UgSm9lbCBzYXlzIChhbmQg dW5saWtlPEJSPiZndDsgd2hhdCB0aGUgYm9pbGVycGxhdGUgc2F5czstKSBJLWRzIA0KICBzZWVt IHRvIHBlcnNpc3Qgb24gdGhlIGludGVyd2ViIGZvciBldmVyLiBZb3U8QlI+Jmd0OyBzaG91bGRu J3QgcHV0IHRoZW0gaW4gYXMgDQogIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCBidXQgeW91IHNob3Vs ZCBwdXQgdGhlbSBpbiBhczxCUj4mZ3Q7IHNwZWNpZmljIG51bWJlcmVkIA0KICBhbmQgZGF0ZWQg dmVyc2lvbi4gSSB3b3VsZCBhbHNvIHJlY29tbWVuZCBhZGRpbmcgYW4gUkZDIGVkaXRvcjxCUj4m Z3Q7IG5vdGUgDQogIGZvciBlYWNoIG9uZSBhcyBmb2xsb3dzOjxCUj4mZ3Q7IDxCUj4mZ3Q7IE9M RDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IA0KICBbSS1ELmlldGYtZm9yY2VzLWNlaGFdPEJSPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIE9nYXdhLCBLLiwgV2FuZywgVy4sIEhhbGVwbGlkaXMs IEUuLCBhbmQgSi4gU2FsaW0sIA0KICAiRm9yQ0VTPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQogIEludHJhLU5FIEhpZ2ggQXZhaWxhYmlsaXR5IiwgDQogIGRyYWZ0LWlldGYtZm9yY2Vz LWNlaGEtMDU8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgKHdvcmsgaW4gcHJvZ3Jl c3MpLCBKYW51YXJ5IDIwMTMuPEJSPiZndDsgPEJSPiZndDsmbmJzcDsmbmJzcDsgDQogIFtJLUQu aWV0Zi1mb3JjZXMtbGZiLWxpYl08QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgV2Fu ZywgVy4sIEhhbGVwbGlkaXMsIEUuLCBPZ2F3YSwgSy4sIExpLCBDLiwgYW5kIA0KICBKLjxCUj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBIYWxwZXJuLCAiRm9yQ0VTIExvZ2ljYWwgRnVu Y3Rpb24gQmxvY2sgKExGQikgDQogIExpYnJhcnkiLDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KICBkcmFmdC1pZXRmLWZvcmNlcy1sZmItbGliLTEwICh3b3JrIGluIA0KICBwcm9ncmVz cyksPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIEphbnVhcnkgMjAxMy48QlI+Jmd0 OyBORVc8QlI+Jmd0OyZuYnNwOyZuYnNwOyANCiAgW0ktRC5pZXRmLWZvcmNlcy1jZWhhLTAwXTxC Uj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBPZ2F3YSwgSy4sIFdhbmcsIFcuLCBIYWxl cGxpZGlzLCBFLiwgYW5kIEouIFNhbGltLCANCiAgIkZvckNFUzxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KICBJbnRyYS1ORSBIaWdoIEF2YWlsYWJpbGl0eSIsIA0KICBkcmFmdC1pZXRm LWZvcmNlcy1jZWhhLTAwLDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBPY3RvYmVy IDIwMTAsIHdvcmsgaW4gDQogIHByb2dyZXNzLjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KICBbUkZDIEVkaXRvciBOb3RlLiBUaGlzIHJlZmVyZW5jZSBpcyBpbnRlbmRlZCB0byBpbmRp Y2F0ZSANCiAgYTxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBzcGVjaWZpYyB2ZXJz aW9uIG9mIGFuIEludGVybmV0LURyYWZ0IHRoYXQgd2FzIHVzZWQgDQogIGR1cmluZzxCUj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBpbnRlcm9wIHRlc3RpbmcuIFBsZWFzZSBEbyBOT1Qg dXBkYXRlIHRoaXMgcmVmZXJlbmNlIHRvIGEgDQogIDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KICBtb3JlIHJlY2VudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBvciB0byBhbiBSRkMuIA0K ICBQbGVhc2U8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgcmVtb3ZlIHRoaXMgbm90 ZSBiZWZvcmUgcHVibGljYXRpb24uXTxCUj4mZ3Q7IDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IA0KICBb SS1ELmlldGYtZm9yY2VzLWxmYi1saWItMDNdPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogIFdhbmcsIFcuLCBIYWxlcGxpZGlzLCBFLiwgT2dhd2EsIEsuLCBMaSwgQy4sIGFuZCANCiAg Si48QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgSGFscGVybiwgIkZvckNFUyBMb2dp Y2FsIEZ1bmN0aW9uIEJsb2NrIChMRkIpIA0KICBMaWJyYXJ5Iiw8QlI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCiAgZHJhZnQtaWV0Zi1mb3JjZXMtbGZiLWxpYi0wMywgRGVjZW1iZXIgMjAx MCwgd29yayBpbiANCiAgPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHByb2dyZXNz LjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCiAgW1JGQyBFZGl0b3IgTm90ZS4gVGhpcyByZWZlcmVuY2UgaXMgaW50ZW5kZWQg dG8gaW5kaWNhdGUgDQogIGE8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgc3BlY2lm aWMgdmVyc2lvbiBvZiBhbiBJbnRlcm5ldC1EcmFmdCB0aGF0IHdhcyB1c2VkIA0KICBkdXJpbmc8 QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgaW50ZXJvcCB0ZXN0aW5nLiBQbGVhc2Ug RG8gTk9UIHVwZGF0ZSB0aGlzIHJlZmVyZW5jZSB0byBhIA0KICA8QlI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCiAgbW9yZSByZWNlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgb3IgdG8gYW4g UkZDLiANCiAgUGxlYXNlPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHJlbW92ZSB0 aGlzIG5vdGUgYmVmb3JlIHB1YmxpY2F0aW9uLl08QlI+Jmd0OyBFTkQ8QlI+Jmd0OyA8QlI+Jmd0 OyZndDsgU2luY2UgDQogIHRoZSBBRCBoYXMgZ3JhY2lvdXNseSBvZmZlcmVkIHRvIGNvbWUgdXAg d2l0aCBzb21lIGxhbmd1YWdlLCB3aHk8QlI+Jmd0OyZndDsgDQogIGRvbnQgd2UgbGV0IGhpbSBk byB0aGF0IGZvciB1cz88QlI+Jmd0OyA8QlI+Jmd0OyBPSywgaGVyZSB3ZSBnby4uLjxCUj4mZ3Q7 IA0KICA8QlI+Jmd0OyBPTEQmbmJzcDsmbmJzcDsgPEJSPiZndDsmbmJzcDsmbmJzcDsgVGhpcyBk b2N1bWVudCBjYXB0dXJlcyByZXN1bHRzIA0KICBvZiB0aGUgc2Vjb25kIGludGVyb3BlcmFiaWxp dHkgdGVzdCBvZjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IHRoZSBGb3J3YXJkaW5nIGFuZCANCiAgQ29u dHJvbCBFbGVtZW50IFNlcGFyYXRpb24gKEZvckNFUykgd2hpY2ggdG9vazxCUj4mZ3Q7Jm5ic3A7 Jm5ic3A7IHBsYWNlIA0KICBGZWJydWFyeSAyNC0yNSwgMjAxMSBpbiB0aGUgSW50ZXJuZXQgVGVj aG5vbG9neSBMYWIgKElUTCkgDQogIG9mPEJSPiZndDsmbmJzcDsmbmJzcDsgWmhlamlhbmcgR29u Z3NoYW5nIFVuaXZlcnNpdHksIENoaW5hLiZuYnNwOyBUaGUgdGVzdCANCiAgaW52b2x2ZWQgc2V2 ZXJhbDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IGRvY3VtZW50cyBuYW1lbHk6IEZvckNFUyBwcm90b2Nv bCANCiAgW1JGQzU4MTBdICwgRm9yQ0VTIEZFIG1vZGVsPEJSPiZndDsmbmJzcDsmbmJzcDsgW1JG QzU4MTJdICwgRm9yQ0VTIFRNTCANCiAgW1JGQzU4MTFdICwgRm9yQ0VTIExGQiBMaWJyYXJ5PEJS PiZndDsmbmJzcDsmbmJzcDsgW0ktRC5pZXRmLWZvcmNlcy1sZmItbGliXSANCiAgYW5kIEZvckNF UyBDRSBIQSBzcGVjaWZpY2F0aW9uPEJSPiZndDsmbmJzcDsmbmJzcDsgDQogIFtJLUQuaWV0Zi1m b3JjZXMtY2VoYV0uJm5ic3A7IFRocmVlIGluZGVwZW5kZW50IEZvckNFUyANCiAgaW1wbGVtZW50 YXRpb25zPEJSPiZndDsmbmJzcDsmbmJzcDsgcGFydGljaXBhdGVkIGluIHRoZSB0ZXN0LjxCUj4m Z3Q7IA0KICBORVc8QlI+Jmd0OyZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGNhcHR1cmVzIHJl c3VsdHMgb2YgdGhlIHNlY29uZCANCiAgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0IG9mPEJSPiZndDsm bmJzcDsmbmJzcDsgdGhlIEZvcndhcmRpbmcgYW5kIENvbnRyb2wgDQogIEVsZW1lbnQgU2VwYXJh dGlvbiAoRm9yQ0VTKSB3aGljaCB0b29rPEJSPiZndDsmbmJzcDsmbmJzcDsgcGxhY2UgRmVicnVh cnkgDQogIDI0LTI1LCAyMDExIGluIHRoZSBJbnRlcm5ldCBUZWNobm9sb2d5IExhYiAoSVRMKSBv ZjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IA0KICBaaGVqaWFuZyBHb25nc2hhbmcgVW5pdmVyc2l0eSwg Q2hpbmEuJm5ic3A7IFRoZSB0ZXN0IGludm9sdmVkIA0KICBwcm90b2NvbDxCUj4mZ3Q7Jm5ic3A7 Jm5ic3A7IGVsZW1lbnRzIGRlc2NyaWJlZCBpbiBzZXZlcmFsIGRvY3VtZW50cyBuYW1lbHk6IA0K ICA8QlI+Jmd0OyA8QlI+Jmd0OyZuYnNwOyZuYnNwOyAtIFRoZSBGb3JDRVMgcHJvdG9jb2wgDQog IFtSRkM1ODEwXTxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IC0gVGhlIEZvckNFUyBGb3J3YXJkaW5nIEVs ZW1lbnQgbW9kZWwgDQogIFtSRkM1ODEyXTxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IC0gVGhlIEZvckNF UyBUcmFuc3BvcnQgTWFwcGluZyBMYXllciANCiAgW1JGQzU4MTFdLjxCUj4mZ3Q7Jm5ic3A7Jm5i c3A7IDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7IFRoZSB0ZXN0IGFsc28gaW52b2x2ZWQgDQogIHByb3Rv Y29sIGVsZW1lbnRzIGRlc2NyaWJlZCBpbiB0aGUgdGhlbi08QlI+Jmd0OyZuYnNwOyZuYnNwOyBj dXJyZW50IHZlcnNpb25zIA0KICBvZiB0d28gSW50ZXJuZXQtRHJhZnRzLiZuYnNwOyBBbHRob3Vn aCB0aGVzZSBkb2N1bWVudHM8QlI+Jmd0OyZuYnNwOyZuYnNwOyANCiAgaGF2ZSBzdWJzZXF1ZW50 bHkgYmVlbiByZXZpc2VkIGFuZCBhZHZhbmNlZCwgaXQgaXMgaW1wb3J0YW50IHRvIA0KICA8QlI+ Jmd0OyZuYnNwOyZuYnNwOyB1bmRlcnN0YW5kIHdoaWNoIHZlcnNpb25zIG9mIHRoZSB3b3JrIHdl cmUgdXNlZCBkdXJpbmcgDQogIHRoaXMgdGVzdC48QlI+Jmd0OyA8QlI+Jmd0OyZuYnNwOyZuYnNw OyAtIEZvckNFUyBMb2dpY2FsIEZ1bmN0aW9uIEJsb2NrIA0KICBMaWJyYXJ5IFtJLUQuaWV0Zi1m b3JjZXMtbGZiLWxpYi0wM108QlI+Jmd0OyZuYnNwOyZuYnNwOyAtIEZvckNFUyANCiAgSW50cmEt TmV0d29yayBFbGVtZW50IEhpZ2ggQXZhaWxhYmlsaXR5IA0KICBzcGVjaWZpY2F0aW9uPEJSPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIFtJLUQuaWV0Zi1mb3JjZXMtY2VoYS0wMF0u PEJSPiZndDsmbmJzcDsmbmJzcDsgPEJSPiZndDsmbmJzcDsmbmJzcDsgVGhyZWUgDQogIGluZGVw ZW5kZW50IEZvckNFUyBpbXBsZW1lbnRhdGlvbnMgcGFydGljaXBhdGVkIGluIHRoZSB0ZXN0LjxC Uj4mZ3Q7IA0KICBFTkQ8QlI+Jmd0OyA8QlI+Jmd0OyZndDsgJmd0OyZndDsgSSBoYXZlIGEgcGVy c29uYWwgZGlzbGlrZSBvZiByZXBlYXRlZCANCiAgZGVmaW5pdGlvbnMgY29waWVkIGZyb20gb3Ro ZXI8QlI+Jmd0OyZndDsgJmd0OyZndDsgZG9jdW1lbnRzLiBUaGV5IGNhbiBjYXVzZSANCiAgYWxs IHNvcnRzIG9mIGZ1biBpZiB5b3UgbWFrZSBhIG1pc3Rha2Ugd2hlbjxCUj4mZ3Q7Jmd0OyAmZ3Q7 Jmd0OyB5b3UgY29weSB0aGUgDQogIHRleHQhJm5ic3A7IFNvIEkgd291bGQgcHJlZmVyIHNlY3Rp b24gMi4yLiBzaW1wbHkgdG8gcG9pbnQgYXQ8QlI+Jmd0OyZndDsgDQogICZndDsmZ3Q7IHRoZSBk ZWZpbml0aW9ucyBmcm9tIG90aGVyIFJGQ3MuPEJSPiZndDsmZ3Q7ICZndDsgPEJSPiZndDsmZ3Q7 ICZndDsgDQogIEFncmVlZCBpbiB0aGlzIGNhc2UuPEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IElu IGdlbmVyYWwgSSBoYXZlIHRoZSBvcHBvc2l0ZSANCiAgdGFzdGUgOy0mZ3Q7IEkgd291bGQgcmF0 aGVyIGhhdmUgdGhlPEJSPiZndDsmZ3Q7IGNvbnRleHQgaW4gcGxhY2Ugc28gaSBjYW4gDQogIGNv cnJlbGF0ZSBpbnN0ZWFkIG9mIGdvaW5nIGFuZCByZWFkaW5nIDxCUj4mZ3Q7Jmd0OyBzb21lIG90 aGVyIGRvYyANCiAgZWxzZXdoZXJlLjxCUj4mZ3Q7Jmd0OyBbWWVzLCBvbmUgY291bGQgbWFrZSBh IG1pc3Rha2UgaW4gY29weWluZy4gQnV0IGFsc28gb25lIA0KICBjb3VsZCBmaXggcHJldmlvdXNs eTxCUj4mZ3Q7Jmd0OyBlcnJvbm91cyBhbmQgcHJvdmlkZSBtb3JlIGV4dGVuZGVkIA0KICBpbmZv cm1hdGlvbiBzdWNoIGFzIHRoZSBDRUhBIGRvY3VtZW50PEJSPiZndDsmZ3Q7IGRvZXMgd2hlbiBp dCBwcm92aWRlcyANCiAgY29udGV4dCBmb3IgSEEgZGVyaXZlZCBmcm9tIFJGQyA1ODEwLl08QlI+ Jmd0OyA8QlI+Jmd0OyBMaWtlIEkgc2FpZCwgSSdsbCBsZXQgDQogIHknYWxsIGRlY2lkZSB3aGF0 IHRvIGRvIGhlcmUgc2luY2UgSSBkb24ndCBmZWVsIHN0cm9uZ2x5PEJSPiZndDsgDQogIGVub3Vn aC48QlI+Jmd0OyA8QlI+Jmd0OyBDYW4gSSBqdXN0IG5vdGUsIGhvd2V2ZXIsIHRoYXQgaWYgeW91 IGFyZSAiZml4aW5nIiBhIA0KICBkZWZpbml0aW9uIHRoYXQgaXMgYWxyZWFkeTxCUj4mZ3Q7IGlu IGEgcHVibGlzaGVkIFJGQywgeW91IGFyZSBjcmVhdGluZyBhIG5pY2UgDQogIGxpdHRsZSBtZXNz IHVubGVzcyB5b3UgYWxzbyBmaXggdGhlPEJSPiZndDsgZGVmaW5pdGlvbiBpbiB0aGUgUkZDLiBU aGF0IGZpeCANCiAgY291bGQgYmUgdGhyb3VnaCBhbiBFcnJhdGEgUmVwb3J0IGZvciBhPEJSPiZn dDsgdHlwb2dyYXBoaWNhbCBlcnJvciwgb3IgYnkgDQogIHVwZGF0aW5nIHRoZSBwdWJsaXNoZWQg UkZDLiBCdXQgc2ltcGx5IHB1Ymxpc2hpbmcgYTxCUj4mZ3Q7IG5ldyBSRkMgd2l0aCBhIA0KICBk aWZmZXJlbnQgZGVmaW5pdGlvbiBpcyBub3QgYSBnb29kIGlkZWEuPEJSPiZndDsgPEJSPiZndDsg QW5kIG9uZSBvdGhlciB0aGluZzogDQogIFdlaW1pbmcncyBpbml0aWFsIHJlc3BvbnNlIGRpZG4n dCBpbmNsdWRlIGFueSByZXNwb25zZSB0bzxCUj4mZ3Q7IG15IGlzc3VlcyANCiAgd2l0aCBSRkMg MjExOSBsYW5ndWFnZS48QlI+Jmd0OyA8QlI+Jmd0OyBPbmNlIGFnYWluLCB0aGFua3MgZm9yIGFs bCB0aGUgDQogIHdvcmsuPEJSPiZndDsgPEJSPiZndDsgQ2hlZXJzLDxCUj4mZ3Q7IEFkcmlhbjxC Uj4mZ3Q7IDxCUj4mZ3Q7DQogIDxQPg0KICA8SFI+DQoNCiAgPFA+PC9QPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPmZvcmNlcyBtYWlsaW5nIA0KICBs aXN0PEJSPmZvcmNlc0BpZXRmLm9yZzxCUj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ZvcmNlczxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_04B4_01CE3A76.51C3A010-- From stbryant@cisco.com Mon Apr 22 04:09:44 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006AF21F8E84; Mon, 22 Apr 2013 04:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0Y3gt2EoktE; Mon, 22 Apr 2013 04:09:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D05D21F86AD; Mon, 22 Apr 2013 04:09:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stewart Bryant" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130422110943.27822.1770.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 04:09:43 -0700 Cc: forces@ietf.org, forces-chairs@tools.ietf.org Subject: [forces] Stewart Bryant's No Objection on charter-ietf-forces-03-06: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 11:09:44 -0000 Stewart Bryant has entered the following ballot position for charter-ietf-forces-03-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The binding in the following sentence does not look right, suggest: Old The ForCES working group is now working on a set of additions to the model, protocol, and libraries based on the experience gained from developing the standards and from many efforts using this architecture. New Drawing on the experience gained from developing the standards and from many efforts using this architecture, the ForCES working group is now working on a set of additions to the model, the protocol, and the libraries. End The text says "standards effort documents", surely this should be "Standards Track documents"? From stephen.farrell@cs.tcd.ie Mon Apr 22 10:57:23 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8E221F93C8; Mon, 22 Apr 2013 10:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O21XKfGw8ule; Mon, 22 Apr 2013 10:57:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7BA21F939C; Mon, 22 Apr 2013 10:57:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130422175722.22660.65064.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 10:57:22 -0700 Cc: forces@ietf.org, forces-chairs@tools.ietf.org Subject: [forces] Stephen Farrell's No Objection on charter-ietf-forces-03-06: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 17:57:23 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-forces-03-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Two questions about this. ForCES security is currently dependent = on SCTP/IPsec (RFC5811). I would love to know if that gets used and if folks are happy with it. (To the extent they're ever happy with security gank:-) If they are then great. If not, then perhaps more work is needed? Also, I wondered if this re-charter might mean that the ForCES protocol will in future be more likely to be used in situations = where security is more likely to be needed, but I couldn't figure that out from the charter. Is that the case? From adrian@olddog.co.uk Mon Apr 22 13:31:01 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFFA21E8053; Mon, 22 Apr 2013 13:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2ucrvhMB5gk; Mon, 22 Apr 2013 13:31:01 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id DBE3521E804E; Mon, 22 Apr 2013 13:31:00 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3MKUvFI028746; Mon, 22 Apr 2013 21:30:57 +0100 Received: from 950129200 (50-76-52-228-ip-static.hfc.comcastbusiness.net [50.76.52.228]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3MKUt7D028740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Apr 2013 21:30:56 +0100 From: "Adrian Farrel" To: "'Stewart Bryant'" , "'The IESG'" References: <20130422110943.27822.1770.idtracker@ietfa.amsl.com> In-Reply-To: <20130422110943.27822.1770.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 21:30:52 +0100 Message-ID: <00b901ce3f98$4a89b240$df9d16c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ3t7vrH/IPrcO2uj3YOjO3sK1U5pePwPwQ Content-Language: en-gb Cc: forces@ietf.org, forces-chairs@tools.ietf.org Subject: Re: [forces] Stewart Bryant's No Objection on charter-ietf-forces-03-06: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 20:31:01 -0000 Thanks Stewart, I picked these up and put them in the charter text in the datatracker Adrian > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: 22 April 2013 12:10 > To: The IESG > Cc: forces@ietf.org; forces-chairs@tools.ietf.org > Subject: Stewart Bryant's No Objection on charter-ietf-forces-03-06: (with > COMMENT) > > Stewart Bryant has entered the following ballot position for > charter-ietf-forces-03-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The binding in the following sentence does not look right, suggest: > > Old > The ForCES working group is now working on a set of additions to the > model, > protocol, and libraries based on the experience gained from developing > the > standards and from many efforts using this architecture. > New > Drawing on the experience gained from developing the > standards and from many efforts using this architecture, > the ForCES working group is now working on a set of additions to the > model, > the protocol, and the libraries. > End > > The text says "standards effort documents", surely this should be > "Standards Track documents"? From adrian@olddog.co.uk Mon Apr 22 13:32:28 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985F121E8097; Mon, 22 Apr 2013 13:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMMlK7e2GRlr; Mon, 22 Apr 2013 13:32:28 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id E1A3E21E8053; Mon, 22 Apr 2013 13:32:27 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3MKWPNB030210; Mon, 22 Apr 2013 21:32:26 +0100 Received: from 950129200 (50-76-52-230-ip-static.hfc.comcastbusiness.net [50.76.52.230]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3MKWED4030095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Apr 2013 21:32:21 +0100 From: "Adrian Farrel" To: Date: Mon, 22 Apr 2013 21:32:12 +0100 Message-ID: <00ba01ce3f98$7e1be7e0$7a53b7a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4/mG+uNMQYiJcyTqSwKmYBoiLmkg== Content-Language: en-gb Cc: forces-chairs@tools.ietf.org, 'The IESG' Subject: [forces] Security in ForCES: Stephen Farrell's No Objection on charter-ietf-forces-03-06: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 20:32:28 -0000 Hi all, it would be really helpful if some of you could express an opinion on = Stephen's questions. Thanks, Adrian > Two questions about this. ForCES security is currently dependent > on SCTP/IPsec (RFC5811). >=20 > I would love to know if that gets used and if folks are happy with > it. (To the extent they're ever happy with security gank:-) If they > are then great. If not, then perhaps more work is needed? >=20 > Also, I wondered if this re-charter might mean that the ForCES > protocol will in future be more likely to be used in situations > where security is more likely to be needed, but I couldn't figure > that out from the charter. Is that the case? From jmh@joelhalpern.com Mon Apr 22 13:47:11 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8670621E80E8; Mon, 22 Apr 2013 13:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN+5yhTyZk8p; Mon, 22 Apr 2013 13:47:10 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6170121E80B4; Mon, 22 Apr 2013 13:47:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 445C01D22C1; Mon, 22 Apr 2013 13:47:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [172.23.230.193] (unknown [66.129.246.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C43781C0521; Mon, 22 Apr 2013 13:47:09 -0700 (PDT) Message-ID: <5175A1CB.7090900@joelhalpern.com> Date: Mon, 22 Apr 2013 16:47:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pete Resnick References: <20130422203201.3335.28502.idtracker@ietfa.amsl.com> In-Reply-To: <20130422203201.3335.28502.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org, forces-chairs@tools.ietf.org, The IESG Subject: Re: [forces] Pete Resnick's No Objection on charter-ietf-forces-03-07: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 20:47:11 -0000 They are additions to the existing protocol, not replacements thereof. Yours, Joel On 4/22/2013 4:32 PM, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > charter-ietf-forces-03-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > No objection to this, but a question: > > Are the extensions (both to the model and the protocol) expected to > create full replacements for the current specs, or are the current specs > stable and these are simply additions to the protocol? I mostly wonder > whether the current specs could be declared full Internet Standard at > this point and the extensions move on from there, or if this is a recycle > of the current specs. > > > From adrian@olddog.co.uk Mon Apr 22 14:08:34 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A4021E804D; Mon, 22 Apr 2013 14:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcepL8E3MjfB; Mon, 22 Apr 2013 14:08:33 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 81E4021E8045; Mon, 22 Apr 2013 14:08:33 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3ML8VIZ025794; Mon, 22 Apr 2013 22:08:31 +0100 Received: from 950129200 ([66.129.246.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3ML8QYw025769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Apr 2013 22:08:30 +0100 From: "Adrian Farrel" To: "'Pete Resnick'" , "'The IESG'" References: <20130422203201.3335.28502.idtracker@ietfa.amsl.com> In-Reply-To: <20130422203201.3335.28502.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 22:08:24 +0100 Message-ID: <00c501ce3f9d$899b3a30$9cd1ae90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHzmVWa63UXBtMlABmN8GeU4nqic5iYBOiw Content-Language: en-gb Cc: forces@ietf.org, forces-chairs@tools.ietf.org Subject: Re: [forces] Pete Resnick's No Objection on charter-ietf-forces-03-07: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 21:08:34 -0000 The plan is currently for some deltas. They should be relatively easily documented separately, so the plan is = for separate documents. But I would not rule out revising the base specs *if* the need arises. A > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf = Of Pete > Resnick > Sent: 22 April 2013 21:32 > To: The IESG > Cc: forces@ietf.org; forces-chairs@tools.ietf.org > Subject: Pete Resnick's No Objection on charter-ietf-forces-03-07: = (with > COMMENT) >=20 > Pete Resnick has entered the following ballot position for > charter-ietf-forces-03-07: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > No objection to this, but a question: >=20 > Are the extensions (both to the model and the protocol) expected to > create full replacements for the current specs, or are the current = specs > stable and these are simply additions to the protocol? I mostly wonder > whether the current specs could be declared full Internet Standard at > this point and the extensions move on from there, or if this is a = recycle > of the current specs. From presnick@qti.qualcomm.com Mon Apr 22 13:32:02 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B517621E80A6; Mon, 22 Apr 2013 13:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DECRVTyUo1zu; Mon, 22 Apr 2013 13:32:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D74821E8053; Mon, 22 Apr 2013 13:32:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130422203201.3335.28502.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 13:32:01 -0700 X-Mailman-Approved-At: Mon, 22 Apr 2013 14:41:25 -0700 Cc: forces@ietf.org, forces-chairs@tools.ietf.org Subject: [forces] Pete Resnick's No Objection on charter-ietf-forces-03-07: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 20:32:03 -0000 Pete Resnick has entered the following ballot position for charter-ietf-forces-03-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to this, but a question: Are the extensions (both to the model and the protocol) expected to create full replacements for the current specs, or are the current specs stable and these are simply additions to the protocol? I mostly wonder whether the current specs could be declared full Internet Standard at this point and the extensions move on from there, or if this is a recycle of the current specs. From hadi@mojatatu.com Mon Apr 22 14:50:17 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4D321E803D for ; Mon, 22 Apr 2013 14:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBZn7dWsVbfy for ; Mon, 22 Apr 2013 14:50:16 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C224121F8AD1 for ; Mon, 22 Apr 2013 14:50:07 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id ox1so777188veb.4 for ; Mon, 22 Apr 2013 14:50:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=1Aw+NIzZ+gUfJvi7Y0xn6BGaRWXPfeMX09ofhdVlbro=; b=pTqSZG1gUgO3Y6ESUj1INZcocfGs9o+bNiFqFDSstqqdNJeBypAH58ZOANP4kQ6RlN 0sMALhNS+qKws5ZHUCjSPh9+A3U51jmXv3jXZdPfD8n0jfUlK6T5dZc0TnDzLxdpe8JH 4ghtT1kbSDMf7sII7o82mZv3Efpdkkh0QKFr/gB+CbebnoaIJqDFNIebtG8VHrijYJxP 48JuxqIt8Kfj1/Ow5WKNBWaUkPxWq3Lvr3gsHtCYoSjD7yDfkQvayKsa+HUcptr9s8ZL HIxaRETfnSx1UahFFjpHQwl4n4YOR1SEBsOD3qBevjpdITVKR4NMBx4/wmK+Zbih/8XR DDHg== X-Received: by 10.52.170.143 with SMTP id am15mr17262340vdc.87.1366667407150; Mon, 22 Apr 2013 14:50:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.253.100 with HTTP; Mon, 22 Apr 2013 14:49:47 -0700 (PDT) In-Reply-To: <20130422175722.22660.65064.idtracker@ietfa.amsl.com> References: <20130422175722.22660.65064.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Mon, 22 Apr 2013 17:49:47 -0400 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=e89a8ff24c715465ee04dafa0d4b X-Gm-Message-State: ALoCoQnr9YJT9vJq98YPdTL3O7bIll5aO4gZ7H7low+hH83J4ZWniEv+wXwhWhrOQ7VE+H4jcyCD Cc: "forces@ietf.org" , "forces-chairs@tools.ietf.org" , The IESG Subject: Re: [forces] Stephen Farrell's No Objection on charter-ietf-forces-03-06: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 21:50:17 -0000 --e89a8ff24c715465ee04dafa0d4b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 22, 2013 at 1:57 PM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > charter-ietf-forces-03-06: No Objection > > > Two questions about this. ForCES security is currently dependent > on SCTP/IPsec (RFC5811). > > I would love to know if that gets used and if folks are happy with > it. (To the extent they're ever happy with security gank:-) If they > are then great. If not, then perhaps more work is needed? > > Not used as much I am afraid. We definetely had interops working with IPSec; and i have seen at least one spot where it was used in a deployment. Also, I wondered if this re-charter might mean that the ForCES > protocol will in future be more likely to be used in situations > where security is more likely to be needed, but I couldn't figure > that out from the charter. Is that the case? > > Indeed this would be the case. The original intent for ForCES was a single "box" deployed by a vendor/operator. Evolution is driving us towards multiple users possibly still within the same vendor/operator. IPSec could be painful from an admin perspective. When the documents were being published TLS/SCTP was still pre-publication so it was not considered a candidate. There was a proposal to use it recently (which i put forward) but was cut out of the final list since we are trying to focus on a short-term charter. cheers, jamal > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > --e89a8ff24c715465ee04dafa0d4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Mon, Apr 22, 2013 at 1:57 PM, Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:
Stephen Farrell has entered the following ba= llot position for
charter-ietf-forces-03-06: No Objection


Two questions about this. ForCES security is currently dependent
on SCTP/IPsec (RFC5811).

I would love to know if that gets used and if folks are happy with
it. (To the extent they're ever happy with security gank:-) If they
are then great. If not, then perhaps more work is needed?



Not used as much = I am afraid.
We definetely had interops working with IPSec;= and i have seen
at least one spot where it was used in a d= eployment.


Also, I wondered if this re-charter might mean that the ForCES
protocol will in future be more likely to be used in situations
where security is more likely to be needed, but I couldn't figure
that out from the charter. Is that the case?


Indeed this would be the case. T= he original intent for ForCES was
a single "box" = deployed by a vendor/operator. Evolution is driving us
towards multiple users possibly still within the same vendor/operator.

IPSec could be painful from an admin persp= ective.=A0
When the documents were being published TLS/SCTP= was still=A0
pre-publication so it was not considered a candidate. There was = a
proposal to use it recently (which i put forward) but was= cut out of
the final list since we are trying to focus on = a short-term charter.


cheers,
jamal



=A0

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

--e89a8ff24c715465ee04dafa0d4b-- From vumip1@gmail.com Mon Apr 22 16:23:59 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171B01F0D1F for ; Mon, 22 Apr 2013 16:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZtYY4-H1i+O for ; Mon, 22 Apr 2013 16:23:55 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2C37A1F0D1E for ; Mon, 22 Apr 2013 16:23:51 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t11so18351wey.6 for ; Mon, 22 Apr 2013 16:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=z8Fo2zLbzmcUOBrwPBmJf27U5cnjBSjfswmwVyD0DEM=; b=qLs957eW4r8Yv2Xu04vTZW/Kg6GdCToSPe0yV4mqiFzaFXo4RqtDnef/DqpbCoIH98 l/LEIfqLHHFTHT+ppfF+U7hZCAfNIupsIQRHp9mIBE+EJo95aSgutfdmUyOiEUFi+2y9 TAXLWK6GRyzMbObniBMkgcAlMMLHKdvRj4Y9HrIVN0zTuSYmdVYxEECb6dQWaUnv+coI y8kPpcd/cRa0ops2pfK5QK3Z7We2SqUnCqDyzRRWThlFnUQhiGUIHZ+lFsSZA2hCX03M YjfK7IOzsj4li0XIGsF5Wm3nUITKE6qihCCxvAPSiiFaHh+sivF6W5zdcvFeGZDecN5V 0SWQ== MIME-Version: 1.0 X-Received: by 10.194.157.138 with SMTP id wm10mr57048636wjb.28.1366673031358; Mon, 22 Apr 2013 16:23:51 -0700 (PDT) Received: by 10.216.111.193 with HTTP; Mon, 22 Apr 2013 16:23:51 -0700 (PDT) Date: Mon, 22 Apr 2013 19:23:51 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: draft-ietf-forces-ceha@tools.ietf.org Content-Type: multipart/mixed; boundary=089e013c67468ef07804dafb5c60 Cc: forces@ietf.org Subject: [forces] Fwd: Comments on ForCES Intra-NE High Availability, draft-ietf-forces-ceha-06 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 23:23:59 -0000 --089e013c67468ef07804dafb5c60 Content-Type: multipart/alternative; boundary=089e013c67468ef07504dafb5c5e --089e013c67468ef07504dafb5c5e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Comments on the CE HA draft ForCES Intra-NE High Availability, draft-ietf-forces-ceha-06 ( http://www.ietf.org/id/draft-ietf-forces-ceha-06.txt ) (1)Please avoid using Acronyms in the Abstract (2)If you have used an XML validator, include the results of validation of the XML files in the Appendix of the draft (3)Change the Title of Section 1 to =93Definitions and Acronyms=94 (4)Add a list of Acronyms in updated Section 1; CE, CCM, FE, FEM, NE, HB, TML, =85 etc. (5)Add RFC 2119 under the =93Normative=94 ref. Section (6)For subsections in Sec. 2, 3, and 4, use i, ii, iii, etc. or a, b, c, etc. instead of 1, 2, 3, and so on (7)Replace =93High Availability=94 by =93HA=94 throughout the draft (8)In Sec. 4.1, under 1, please consider adding +6, +7, and +8, and Reserve these for future use (9)In Sec. 4.1 under 2, please consider adding, +3, and Reserve it for future use (10) The are many partially complete or incomplete sentence in the draft ... PLEASE correct these sentences =85 a few examples are as follows.. (a) In Section 3.1 of this document draft, we discuss further details of these knobs. further (b) It should be noted that in this default setup, which MUST be implemented by CEs and FEs needing requiring HA, the Fr plane is out of scope (and if available is proprietary to an implementation). (c ) Figure 3 illustrates the defined state machine that facilitates connection the recovery of connection state. (d) To put the two together, if a path to a primary CE is down, the TML would take care of failing over tohelp recover from a failure using a backup path, if one is available. (e) + 0 (No HA Mode)represents that tThe FE is not running in HA mode + 1 (HA Mode - Cold Standby) represents that tThe FE is in HA mode cold Standby + and 2 (HA Mode - Hot Standby) represents that tThe FE is in HA mode hot Standby Thanks. Best. Bhumip --089e013c67468ef07504dafb5c5e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Comments on the CE HA draft

ForCES Intra-N= E High Availability, draft-ietf-forces-ceha-06

( http://www.ietf.org/id/draft-ietf-forces-ceha-06.txt )<= /p>

=A0

=A0

(1)Please avoid usi= ng Acronyms in the Abstract

(2)If you have use= d an XML validator, include the results of validation of the XML files in t= he Appendix of the draft

(3)Change the Titl= e of Section 1 to =93Definitions and Acronyms=94

(4)Add a list of A= cronyms in updated Section 1; CE, CCM, FE, FEM, NE, HB, TML, =85 etc.

(5)Add RFC 2119 un= der the =93Normative=94 ref. Section

(6)For subsections= in Sec. 2, 3, and 4, use i, ii, iii, etc. or a, b, c, etc. instead of 1, 2= , 3, and so on

(7)Replace =93High= Availability=94 by =93HA=94 throughout the draft

(8)In Sec. 4.1, un= der 1, please consider adding +6, +7, and +8,=A0 and Res= erve these for future use

(9)In Sec. 4.1 und= er 2, please consider adding, +3, and Reserve it for future use= =A0

(10) The are many partially complete = or incomplete sentence in the draft ... PLEASE correct these sentences =85 = a few examples are as follows..

(a) In Section 3.1 of this document draft, we discuss further deta=
ils of these=
 knobs. further 
=A0
=A0=A0=A0=A0=A0 (b) I=
t should be noted that in this default setup, which
=A0=A0=A0=A0=A0 MUST be implemented by CEs and FEs =
needing requiring HA, th=
e Fr plane is out of scope (and if available is proprietary to an implement=
ation).
=A0
(c ) Figure 3 illustrates the defined state machine that=
 facilitates
=A0=A0 connection =A0=A0the recovery of connection state<=
/span>.
=A0
(d) To put the two together, if a path to a primary CE is down, the =
TML


=A0=A0 would take care of failing over to<=
font color=3D"#008080">help recover from a failure using a backup path, if one is available.


=A0
(e)
=A0 +=A0 0 (No HA Mode)represents th=
at t<=
/ins>The FE is not running in HA mode


=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0 1 (HA Mode - Cold Standby) represents that tThe FE is in HA mode cold Standby

=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0 and 2 (HA Mode - Hot Standby) represents that tTh=
e FE is in HA mode hot Standby



Thanks.


=A0


Best.


=A0


Bhumip


=A0


--089e013c67468ef07504dafb5c5e--
--089e013c67468ef07804dafb5c60
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; 
	name="Comments-on-CEHA-Draft-20Apr13.docx"
Content-Disposition: attachment; 
	filename="Comments-on-CEHA-Draft-20Apr13.docx"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hfu9tdi80

UEsDBBQABgAIAAAAIQAwySgMcgEAAKUFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0
VMluwjAQvVfqP0S+Vomhh6qqCBy6HFuk0g8w9gSsepPHbH/fSaBR1UKQClwiJeO3+OXZg9HammwJ
EbV3JesXPZaBk15pNyvZx+Qlv2cZJuGUMN5ByTaAbDS8vhpMNgEwI7TDks1TCg+co5yDFVj4AI4m
lY9WJHqNMx6E/BQz4Le93h2X3iVwKU81BxsOnqASC5Oy5zV93jqJYJBlj9uFtVbJRAhGS5HIKV86
9Usl3ykUhGzW4FwHvCEbjO9VqCeHBXa4N4omagXZWMT0KizZ4CsfFVdeLiztoeim2ePTV5WW0OJr
thC9BETK3JqinVih3bf/gz7cwk4hEvL8RlrqoyYwbQzg+R1sebvkKaxx9AE5leNkfajrp0Dl9D8C
xKSh7c/B/BFSovQvsfkdc9f2myomOnTAm2f/5AwamqOSFZ3LiZgaOFnvT/1b6qMmVjB9v1j6P8i7
jLT9kz7+I4zvO6tG72kdby7Z4RcAAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgC
X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2j
ILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyM
Maui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03
Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1
nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQCzvosdCQEAALYD
AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAKyTz0rEMBDG74LvEOZu0666iGy6FxH2qvUB0nb6B5ukJLNq396hsNsuLvXS
S2C+kO/7zTDZ7X9MJ77Qh9ZZBUkUg0BbuLK1tYKP7PXuCUQgbUvdOYsKBgywT29vdm/YaeJHoWn7
INjFBgUNUf8sZSgaNDpErkfLN5XzRhOXvpa9Lj51jXITx1vp5x6QXniKQ6nAH8p7ENnQc/L/3q6q
2gJfXHE0aOlKhAxIxJ0F9tS+RlJwUiLmBHkdYbMqAg0dz3ACGOul+GTNeHs0OXqewURwlpYgtmtC
EK8HTgBjKcczWWJ4XJOhcpYynXczjrO0BPGwJsQ35u9/VnImnkDkxW9LfwEAAP//AwBQSwMEFAAG
AAgAAAAhAA7IIf3EEgAAmJgAABEAAAB3b3JkL2RvY3VtZW50LnhtbOxd3W7jNha+X2DfgfBViubH
8m+SbVw4jo0ZdGY2yKRAd+9ki461I0teSY4nveqD7N7ug/VJ9jsUZYsSJTvKpLELFejElmTxkDzn
O78kf/jx69xhj9wPbM+9qhmn9Rrj7sSzbPfhqvbz/ejkvMaC0HQt0/FcflV74kHtx95f//LD6tLy
Jss5d0OGV7jB5SPuzsJwcXl2FkxmfG4Gp96Cu7g59fy5GeKr/3A2N/0vy8XJxJsvzNAe244dPp01
6vVOTb7Gu6otffdSvuJkbk98L/CmIf3k0ptO7QmXf+Jf+Lu0G/3yRpIsWjzzuQMaPDeY2Ysgftu8
7NvQxVn8kseiTjzOnfi51WKX1izfXGE+5k5E9srzrYXvTXgQ4OpNdHP9RqNe1LYcQHrF+he7kKC2
GVMyN213/RrijtT8ryfvFJN3FrV9Rq/adARj0QMvjT3rif4u2OoSvGjdXdXq9e6wabRbtfjSDZ+a
SyekO81296JpiF/69LOwN/DmxIsB81wWzjgbDNm7PsPITcMfzugB+hfP4t9FpiH5uvyG5J3bVNuL
26h1cxwIKswxHnw0nauaw6chEb7wgqvahdGpnRU9YJw3G8VPNLqt8+Inmp1Oq/iJVvu8XvxEu3Wx
hdJOy9hCabfZ2ELpeaO1hVIM2BZKDXDHFlKN+sXFFloN46K+hVijAXKLR81odlvbyG112oJcYkXJ
LcHCnEB+wSTgUQ4QA/SuLh2b5KiBF8ovd0sHF8xl6EVU+BHP+SOPuB0/Dia2fVUbeEvf5j77xFf0
S24GYT+wzavavT3nAV1md97chLiuLmd9N8j+ZAJOTb5FcGzwK54XHN2QXQx+HVCziWskWEQUiVZE
HNDJmw59H8+FTwuQHyy443wOTT+UncAdIea31G9FnPe2ewQiI88fDD8rgIJOa3s7dK2D7iup40vi
UUzfwucB9x95rcfeu6FvnnwCutoPM9Z/NG3HjLR4alQEMu4vs2I29T08ZumOHCivCt13YvNwegID
DNbCyYTPzJN6J90/0kwHOFHqPO2i1xWwiWc1a1XIO5Wyr5R91parlP1WZf/gm/Okrj9QfDlSAUaj
56mjWTVPBg3s+etRp7bvPZ861mBmkpkmP90La23MH+DXwf4jy070Yd87YrtB6N/zrzk6nb37x+3w
7sP7Tz+xGnVq/Xiii7E+UJTEwfS7Jz3v1Wp1SipfxFps6yzXCDgNvwrHWDcUB9NrvQVXE4Kr61g8
x4cvogFfmL4ZckVK4+5FLNxvtrqDawWDPodPDsdTQq29g6z7cDe/SDdl/xxK8rjK8vU64AMIi8fl
8KedR07lweByHh5/p/ggu9julZlOgaNYdpXwYmWmV2b6tphcJWKUJcgRoCrsnUlZVGFvJcS9utwe
9q5ErBKxGhS0SPlVmaVEMuqbZZa0ItbpGzedGxp5kVFKGIrqHRHPvR50Bo2hcIriXJXiFH2wg/AW
nhVCO4tZ5Bi5y3mUk7KdRyc2wGQyDPfeW/E1Qzpj6x/Emb48vVPlhRU7tsoLiyqCorxwE3lxsBsl
iQ8xLxwFE/c6w3vrIHXOmfno2RZbUoEN66MCyX2aB8yOSkv6YwQbzckOdSUqAN0loGlUN9ptlFZF
oFVBU45lXpWspGuJ9tawqKDpNWtrKBT6fsqevCWbmY+cLZUAWirGKWFn38P4OcFBQl+X/fLxw9b8
W25VEQV6D2UQeghe2ZYZen5qSreVFR3o9ObX1xzSrOkzT7Y7cZYWFwWoKJlCsSrqUadMzjAqjdMs
7UsDQJS7DobNUbupJGz2MyeDLlGJLYno1HZQXRgbRgvUe1v2V/Q5xctKPw9FMvVzLLou0qpKH5/p
mrYG9UG9W9l/W0prK/uvsv9e06wiqZXu6N6r0x5KddyHSLnc2yES+cDhz3xCK1iYwUKP/f7bf+Bi
2q4tFrXAirLWvuvvv/13O1ypoJR0V9U7lbtauau0ruWQV1hU7upr4mpudX3fspjJHETZCb2SkbXl
Ak4QtzaI9jes4Tpmg8HHYzbCh9EQHz7hw7vrjAuRcZUOrgS1d//xwzEA/H8KSm+tOd17pZVjQ/Nw
cqr0VGs+q1qn0kepZYXVir/UgFT66M1W/O1/ZkePRKSPFCBKhVJlnmbvcbZ3NxqwBpIDbOlaWAZK
8Rm4A5/Eynv7kcP+Z3fpju59r/RzxqenaytB6ZJWiXSGrfPhdRxpSSoR9U7l1FROTeXUvOmy8f1X
IrQAnAXLccAnCvIcqNbQ42sUPUJMH8GlU9Y4Zs1jEUtqHaMggqfVZcb3KszKHYw+tVPzq+/mZvXf
3uvS3jGzbfof/5D7xcDJ5jEbH7OJvEArprhpkWNuHCfmPfCwqYoyHFpFm++t9Vvdi+sq2VHtz6KU
+1XeWuWtxaWz0eYygBW5D0XYu+MLB3uPkBOT2WmEnJnxk7jVp8/hzPeWDzNvGT4nOds9b1wPmjrH
QL1TOQaVY1A5BpVjkL8CSBTnSXO5dQrbKYrB4MMiqiaeYI9Bm8IypkUbK7LvO8fs+25kVX9/fsyE
eX0X7bFEEAYrG1v2sOkyXPqo9Qv4dutLxaxkmEO9U6FZhWYVmlVoVohm+rjA+w3ESYRDbECPcIA3
GTSIUc0OU5DG1ECC1qVUHcckqI3a3WZrFBtvFahVoFaBWgVqJUDtHokyE0YWtkZ9YthTJ7RNx3li
tD+1w0PU2Pmobl5/C7DFMLbH5nHFs2KXrdSdZg6lnFsP9qLCmZ2enqowjT7uf6Tz9sOw/3mIOfR9
lEdKgzqeuoCqbFCDNMWOuPyrSdMcCA4wA2gox/FWQWpWM6Hfw6suOlWrbYrrirSqWE2WJlVx+9y4
bhmKKpYPE6doV1m/Q7XTrc/h42DTdBR9RQutbdSrYm0rds6+qnXj7YZlQAixadyzLawRoZawHfLM
w9bB17Pl3F6wn2Zm4GIb2gAbsGNfetSRYQvlutE8qbdOjIt74+Ky3rqs1/8pF2iLd1IvE6W/OYuR
jszvMgKAJtZblCd6mvOGyGoSRbrNU4OC6+HMDtIvtTgtLaf+iZEs2z8hmxr65KUbjnJyLI2KUuL0
MNrN3zZvvcE/CYR8Mt4xL7pCr9hMTeMlU5NHOl3PGVqBUcdsxZllB5NlAAFe+nCffXV0QSpoLPN+
HmJ748xcbTosooffeq4KOgzmUbBph571onDCF9cbp3Ft0w+xx/6r9KOnAs+G4A3Dt1+Da8oxfMw/
hfzua+SrYM4yM5Y9fiAfW9U7ws1JCO83x1YcwvFNsRXTne3tzUWzVdee6qDeEb2Vl2h8d+4ttbod
2Zn4TxGnlAEnFVvB3B6Ns9pBPN57H7IACQnHYmPOXI8Km8OZGUZ2I+Dfis6yYAEPlwtA2MyezBRa
9n/oPv78+Z56Z5MJRWdvoI/IygyGMKegyUf4q/RIqBDwFyk5kQx+NuAYdaHEaYRjIZQaLcEmhRrN
5VwEYAsFfIOLYoOGF5FZwDw+//fS9ikcrAzTBiKFpR323vWPyYRlIx/BFtPFgGNRKVJdxYsssSfO
9flFraB9tVlp2Ie9YIJTe9gRTaE9xT4YYoN/LDZCqzCEFzhkAsc4PNFyI6zSXs+9OEfnuwzYv6H0
6wWo3+3faIsBb5Q7EfZEl2gIS2NP70iZXLwpfViEzpkIexOmbpGZ80O1/iTHTGIj+4HyCE1mO86S
9i4J4fIQSwGFsJOMRQc8wdWdm5MZvkZANcXhJDibiR5VerAfw6r3WYHoCq1JxLkopdqMTi7ibJij
EHGQ+nHlGj2iTT5bZEUb5TycJKlFUp8eoh0ZEuySGlvtD3djSOVNGcCD0+7hRLIn5amkn2GU85F2
HSFY2YlZE7KhkJIheAfYG9Tbo4bwj9KblKl3SgMP8DuyeTbaCyc1lTHn5DDJ7d/ppSTz8V+BhkkL
eNho01b38aXkHkctnOC13phN9Ew+/CJI1cv+kZU1xWKayOdNtBz27j22kMUi4cqDLnvg4G8f1XHQ
eIgChjOh36DwbJxXRzYNqT/LW7mRKkb4Is0RGk2naJRkxEQdslcemCwoagU3fWBD2FuR+ap080VK
KPUmACGmRwQ8ynnRFNRBRIdYKWUM1uuNdiM6HC6G29D8wtmE4rwQ7ilMGjK7CGQwz0RY/Bx9jhge
V+jVCWkq5yRryBSbfSSIxCbn3FkwCXts6ntzik+Cyij7D1qVwUvjj14g8IqxOcFZi4KfBWvjAEfw
sfKuzeBlqMp5bfrnNEphb20n7oCFIwUXkoKh3imNhYV4pbbxiq0LTqKxOeKqLUfkCQRM4lP3OdVo
8mHxkgj1F8oulrr4ajwoMVk501vSPPiesXqKM7Qws5t9cPTJo9MbP3pWaugUgSwXOGp0M7ghWP9m
WG/2W5HD1PO5OPKMTtgjt13p2Y7ip/xGobtclGUnuvMoTaBtOddb0/pNFExOjFuMovfU9/gLfVYg
FV9IKsijFWoV0RHmL12XIBmLDjDvc8y7MnzEu28nMW/b+jZ5jeJYpbU8BNdQxvpFSv5ISi07YQMP
wS9YFa41fsqYZgm1Wi7GouHHrVLMdpCOcm6ihppvJR0biYBTkrHHYstH9N3oN/uDUYRgOeiemmkp
inKWlJtvy/Rv2/rrixykQhntFwldgyXE7h3QdLvUIbvKSkT6NXyekTo956UUqmplYLYBCATwG1yA
AV+KwvMdtPt2HIhc9WdHfhvZ1l8BB2ae2gGwK4ZqnZL+s8PAH2bAa0HI6BidmwHxJg24nF1UK5z3
hepIR3dUYoVHI9/wLOMdrUV2PqwqNE1uc6Oc29yI3GZNdAdtEE0OysjuOG0iwK1b84Ff+9z8Is6C
hiczVT0Z/EThvGhs6C15oeh+vEVkn2JsSK+jroMi0Sk0THSznNstu0mk6EhUpy8xI2g4vx4CJyIL
QuVDRUHcRknnJBvUiFT71pHN7Je7AVXdAIg56on4v9gtLqpLQaoSVVEIiwRiT7m4XIUs9du/sw+j
62d79zeRk/AsAZGpGCJx57yLTkBK+lm5AqLFA1XAXzGcoG19WDc6XW0+S6UrijFGDz9rXKnVCHmk
rXj0kIaAhM4u51u2cjxy2TnBqnqrQoWNHI5PvqZ3D6wJFkhsnYx9gA/CYcGSI4uNCk/kxOZeEKL4
00TA9wQxX1ycL117IpKblP0cI9Ed5eopHhyv6qHcvkeZ8Cgry0QGNQVoiUEq5/C0cpBheN7pXjQK
jf645Ey7aS0IowFWMEIZsR1EPp8L1Tsv5kKtDKic/kdL4Nu2Xr9ut7vatJJKlxh5+fAL5X+Wln+F
dRJt5JkABUnaRjn3Ow9A1NGRqqgz7A6vIy851uO//PLLJclr/J0+A+6iKzRcG+ltlnOc8ihMEJM3
XAqQgCSdwO4w6vdUdLou6Iw2W6RCHfa+/6mP3MMDtmQkk4+Ccre+F3qINjBv/C/krtMUZENx2oFW
LyblUr1Tmjc1Or9ZzmuU05NvFOdNToaXtUHvbG7tg/cAteKw0dIV+/fi47XjTb6wIxhZqTKaF8UG
VA0pWFz6D81y2WENJ0vBSjBhLEj9kM2xHfEc3VvNOLRtuFa1tF/ZSkR544dTUgdW38Zor8BT1Gra
02qW87SeM1I55g2LiwglFpFrUuR1NMs5S0lKC6ytAVYxo2YNlX7OE/KJKGYMABxUxBZZQGmciJFK
vLIXQQ6j85yDy7MzcVC56ZrioHIzCOwHl2oIgzMsCpjw+M8pXK70a9+UKyIrOHe6FFpzBDeLBthN
itYH7PLj3fJn2BCcPLYdTDcVil9RoLTirBopEkekRRsHFhIFJeodoTe+ka/YLOeuS6P8+XpDmeod
hiY5MeqglR6FGOm0ravVkMnW1Tuv07pa9Z5sXb0jWv9m9fCFA6KuN7679ROH1Wg4VX18Jzo1J09W
50dOwxpGV5yo2m02zqN1YnnHaf65z4/8vwAAAAD//6RSy26DMBD8lcg/kAQCaVFASmnaUyuU9Acc
Y4glsJHXFDVf311Dmqg59NCTvQ+PZ3Z2NiSfvElZIyvHMOgMpGy5iqOYzbPNfEgcP0K2GRLouFC6
xhZeOWlTtqD2RmmZsjD+CfZ9gwneO0Pvh0TpktoQnWBXizFrC0tF+2K0A4IEoVTKctNbJe3sXQ4E
Ljm4LSiesg/VSqD0bG9arql42mq4fyKQ/S2K5wBn7Pcqg+l/OOf07U0OlXpSeHZEjk6i2GGbBVXu
UfAijNaP4ZJ+96lnWfG+QWG/KwWlnvI4D3bMg4xyryP8Y2z/IzFqlsIV9sL0nuIB65Rd78JltBpZ
1gca1IBGBQE6hfcT3qOHi2td/cYJ0pluMpPwVX26eIvh0Thn2mv5xnnCk7yk3VmjERhWxvhVmsK6
d9NmeQnCNGQSTQ1Xinp8ujTi1Sq/Vbh8hXICWdIGYhUHB164vx5N+eUv+KRvpXbZNwAAAP//AwBQ
SwMEFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYU
vw/YdyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6
bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgq
nASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI6MZs
ablWW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i1vaAT8CP
huS+8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sFfQNgah7X6/W6
vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlsliiBmQfG3P4tdpqY3PZ
wRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iYs+1K+BrA12oZfIaCaCii
S7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/QVLW9D1MMGTGj
9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX1XhZxv/6wye//Px5
NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQzVnElJyNxvhXDCNPyis0klDjB
mksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq
5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlboLkUd
TCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQfEuaY8TqeKBxXkRzimJUNfgOr
qErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3Q
JCpjP5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiINAsQPTMR2pdQqp0KHNPk78oxo1CP
bQxcXDmGAvji68cVkfW2FuJN2JOqMmH7RPldhDtZdLtcBPTtr7lbeJLsEQjz+Y3nXcl9V3K9/3zJ
XZTPZy20s9oKZVf3DbYpNi1yvLBDHlPGBmrKyA1pmmQJ+0TQh0G9zpwOSXFiSiN4zOq6gwsFNmuQ
4OojqqJBhFNosOueJhLKjHQoUcolHOzMcCVtjYcmXdljYVMfGGw9kFjt8sAOr+jh/FxQkDG7TWgO
nzmjFU3grMxWrmREQe3XYVbXQp2ZW92IZkqdw61QGXw4rxoMFtaEBgRB2wJWXoXzuWYNBxPMSKDt
bvfe3C3GCxfpIhnhgGQ+0nrP+6hunJTHirkJgNip8JE+5J1itRK3lib7BtzO4qQyu8YCdrn33sRL
eQTPvKTz9kQ6sqScnCxBR22v1VxuesjHadsbw5kWHuMUvC51z4dZCBdDvhI27E9NZpPlM2+2csXc
JKjDNYW1+5zCTh1IhVRbWEY2NMxUFgIs0Zys/MtNMOtFKWAj/TWkWFmDYPjXpAA7uq4l4zHxVdnZ
pRFtO/ualVI+UUQMouAIjdhE7GNwvw5V0CegEq4mTEXQL3CPpq1tptzinCVd+fbK4Ow4ZmmEs3Kr
UzTPZAs3eVzIYN5K4oFulbIb5c6vikn5C1KlHMb/M1X0fgI3BSuB9oAP17gCI52vbY8LFXGoQmlE
/b6AxsHUDogWuIuFaQgquEw2/wU51P9tzlkaJq3hwKf2aYgEhf1IRYKQPShLJvpOIVbP9i5LkmWE
TESVxJWpFXtEDgkb6hq4qvd2D0UQ6qaaZGXA4E7Gn/ueZdAo1E1OOd+cGlLsvTYH/unOxyYzKOXW
YdPQ5PYvRKzYVe16szzfe8uK6IlZm9XIswKYlbaCVpb2rynCObdaW7HmNF5u5sKBF+c1hsGiIUrh
vgfpP7D/UeEz+2VCb6hDvg+1FcGHBk0Mwgai+pJtPJAukHZwBI2THbTBpElZ02atk7ZavllfcKdb
8D1hbC3ZWfx9TmMXzZnLzsnFizR2ZmHH1nZsoanBsydTFIbG+UHGOMZ80ip/deKje+DoLbjfnzAl
TTDBNyWBofUcmDyA5LcczdKNvwAAAP//AwBQSwMEFAAGAAgAAAAhANkMPuiYAwAAVgkAABEAAAB3
b3JkL3NldHRpbmdzLnhtbJxW247bNhB9L9B/MPRcr6m7LMQb6Nqm2G2LOvkASqJtYUlRIGl73a/v
UBLjXZQJgj6ZOmfmcGZIzvjDx1dGVxciZM+HneM+IGdFhpZ3/XDcOV8+1+vEWUmFhw5TPpCdcyPS
+fj4808frqkkSoGZXIHEIFO+c85iSGV7IgzLNetbwSU/qHXLWcoPh74ly4+zeIidc1JqTDebxemB
j2QAtQMXDCv5wMVxM3uWvD0zMqiNh1C0EYRiBQHLUz9Ko8b+rxpsdTIil+8lcWHU2F1d9D3LJd0r
F91Xjx8JTzuMgrdESqgso3O6DPeDkZH0R3Tmej71jcDi9kbkEY7tH87Z6pqORLRQUDhzDzkbTcDG
/LBXWBGg5UgonS5BSwmG7a/pUWDGMBzajEw+HTngM1WfcbNXfASjC4YAYyPZnrDArSJiP+IW1Ao+
KMGpsev4H1wVnI0CEp6DgMsyYjVpw53spA5ML/7mXBk3hPww3vru7KHZO4OQF3p2JooLN7P65GEY
ezbGjdyoLKxM5mdFbWXKKE+2NubbUQcFKlBs8wkTNw+s+USZW0alzSeqgqTK7Uxc5dao4ciSzBp1
nHh54dvU4jys3cDKVL4bWpkEeRmqbD6J7+V1ZGOyIN7m1upkFQpiu08VlpG1bnkRFZ41ggKFtWe9
B0Xl16G1BuXWD5A10zKLs9J6CmWF/MzqUyE3iq0+lRd+ozpVEsVba9Q1csMwsVW0DlBclVYmjP1g
uiGb+eHBC2SpbpF/CbOq4RWv2PzUC8wa0ePVs26i8GxZ2oiXvB8M3xBo5uQtsz83hlyvZ0IyTGkN
ncIQ0D9npuvlWJLDJEyfsTjelaeuxVJhRaEv/f5VTfc5In4V/DzOqleBx09DB7DZ0A2CRa8f1FPP
DC7Pzd54DdBL31DnofvzIrTg5l6ga6pg/BFdoSc8HE1fIsP6y16bXtOWir0ekeQZjyO0RDBpju7O
of3xpFzdZxV8dVi8TB/N0Vs4b+LgS3PTB251ZmC9LLTBvASrZXHHfIP5dywwWHDHQoOFdywyWKSx
0w2GBwyHFxhFZqnxA6eUX0n3mwF3zn+guQjyhEcC56pnB1wwnk7AMkzk6pKSV5hMpOsV/PsY+47h
153jo3h6NIs1xTd+Vu9stZI2Ht+hqw4rDHNuOqp3znB0MOnex3JNO9L2cCH3N9bcR9XDHDjtpdqT
Eaaa4gJSnsbdL5Py/Q/R478AAAD//wMAUEsDBBQABgAIAAAAIQA0tmytrAEAACMPAAAUAAAAd29y
ZC93ZWJTZXR0aW5ncy54bWzsV8lugzAQvVfqPyDfW8xmDCqpFFU99dTlAxxwEkvYg2w3tP36TkiX
dDmUQ9QcODHMxvM8xvZcXD7pNthI6xSYikTnlATS1NAos6rIw/31GSeB88I0ogUjK/IsHbmcnZ5c
9GUvF3fSe/R0AWYxrrQVWXvflWHo6rXUwp1DJw3almC18PhqVyEsl6qWV1A/aml8GFPKQitb4RGB
W6vOkbds/V+y9WCbzkItnUMgut3l00IZMkOMjdq4t2fQl6qpSFIkLE7yjA/2BTTPV2qDto1ocf0k
3HprYW/k0r9r6Yf2Vq3Wv6jvofvpOwfvQX/TI555Y7ff8J8xBitL0NG9VATrj0Inaqz1INfQAtZV
PHrYwWj3kI2LXHxBNC7W7q98TGg4kDAseid+pYPTOOEF5WyiY8xPcCg6ooilOU+zfGqPUU15OD5y
GheUJtHUH0fRH3h0pHnGsnzi4yj4YJxmKacsnvg4Cj7ytOA8SfnUH8dxfvCcFYxm0/1qzJ21Lw91
nsdRzLfX3YxO+9V/7Ve7MWQYC6HzSqsXeQ12bqF30uL8h/a90Xb2CgAA//8DAFBLAwQUAAYACAAA
ACEA4iUhKiwJAADARAAADwAAAHdvcmQvc3R5bGVzLnhtbNRbS3PbNhC+d6b/gcN7ar1lZ6JkHDtu
MpOkbiRPzzAJWZxQhEpScZxf38UCpChSIBYmfagvMkFgv8U+voVs7Jt3P7ex94OnWSSShT/8Y+B7
PAlEGCUPC/9udfPq3PeynCUhi0XCF/4Tz/x3b3//7c3j6yx/innmgYAke50u/E2e716fnWXBhm9Z
9ofY8QTerUW6ZTk8pg9nYr2OAn4tgv2WJ/nZaDCYnaU8ZjmAZ5tol/la2iNF2qNIw10qAp5loO02
VvK2LEr8t6BeKIJrvmb7OM/kY3qb6kf9hB83Iskz7/E1y4IoWoHisMVtlIj042WSRT684SzLL7OI
nXy5kbNOvgmyvCLtfRRG/plEzH6BzB8sXvijUTFyJTU4GotZ8lCM8eTV3bKqycIvh+5B7sJn6avl
pRR2htssPivb3R1tHp5QlR0LwHCAw9Y5BweCPyROHElHj+az4uHbPoYBts+FBkEBAFYVC481i4Nf
wctLFSXwlq8/i+A7D5c5vFj4iAWDd59u00ikUf608C8uJCYMLvk2+hiFIZdBqcfukk0U8n82PLnL
eHgY//sGQ0xLDMQ+yUH92RyjIM7CDz8DvpMhBqITJj38VS6IpdisgoMK7aODNmqghoqD/xaQQ+XD
kygbzmQaeah/KxDuet8ZaCR3VN0AynXSddxdxKS7iGl3ERi83Wwx764FkGdXj6jYqEQl3am5CFTw
Ve0wvmgJWbmiEUXWFY2gsa5oxIh1RSMkrCsaEWBd0XC4dUXDv9YVDXe2rggYElc9isZoDVJir6I8
5nJ9KwENO1KdLjXeLUvZQ8p2G08W1rrabWS53N/nNFWRTp9Plss8FcmD1SJQnWXqPpuTP2x3G5ZF
cKKxmH7U0fQrdh9z7880Cq1QUxV8jT3hweRkCbuNWcA3Ig556q34T+VRh/VfhbdUpwyrch3d+jl6
2OTecoMl1wo2MxjdbAkl/3OUoQ1ak2lm2IpNOMmHM0NcmoV/4WG03xamIZxGZorPHdxcg0AV2000
kS5qZpd1F9IBlC2ocuG+BZRP0F8VF3f50scU/VUpeqZ8gv6qcD1TPsZHu3+dmeaapd89UnrNnXP3
SsQiXe/jIges9DB3zuASgrYF5yQu5ZNIYu6cwUf06V0GAXxzo8Spsy8OPOqA4uwOhYLJRt+Ls1Nq
tDd02JGzg2pYIwesblzrAORMut/4j0j+4cm1GCBLl2dNazqPDRaAEkQ6Q/+9F7n9DD0ycB4V5VMC
fy7JuEdDGxsyj4qm40nVOwcfdyt8DkDdKqADULdS6ABkiA/zmaesiXSQ7sXRAcuZlssqhmFHZua5
MzOXQG4loKe6STh/GbLXHAvNuklAcXZQs24SUJy9U6tlZd0kYPVWNwlYhqph9lGVU1025Vw3q0Dl
SYCwo37ImwDUD3kTgPohbwJQd/K2g/RH3gQsZ24oObVK3gQgnOLyVb8EqpI3AciZGxTb6b8ZFXUP
pbR/ue2BvAkozg5qkjcBxdk7JvImYOEUl0ioYZVUR8Dqh7wJQP2QNwGoH/ImAPVD3gSgfsibANSd
vO0g/ZE3AcuZG0pOrZI3AciZHkqgKnkTgHCKCzecJG/M+hcnbwKKs4Oa5E1AcfZOjVDLQyoBy9lB
NaySvAlYOMUlGDQWBrfLpvohb8KO+iFvAlA/5E0A6oe8CUDdydsO0h95E7CcuaHk1Cp5E4Cc6aEE
qpI3AciZG06SNybji5M3AcXZQU3yJqA4e6dGqCXPEbCcHVTDKsmbgIXx0pm8CUA45blALjvqh7wJ
O+qHvAlA/ZA3Aag7edtB+iNvApYzN5ScWiVvApAzPZRAVfImADlzw0nyxhx5cfImoDg7qEneBBRn
79QItSRvApazg2pYJdURsPohbwIQBmZn8iYA4ZRnAGEWubipH/Im7Kgf8iYAdSdvO0h/5E3AcuaG
klOr5E0AcqaHEqhK3gQgZ26Q92zhvij5eurQEATUewbFrQYy4MjgJCqg3uA3vuYpdDJx++2QjoDF
Dh0QDeFB3eJ7Ib57tIvdY0OAkKGi+zgSeKX7CW/pVBoRxvOWToLVX1feR9UA01iHIXV88wa6h6rt
QtieJBuHQM/8aQctO7viZrmUBg1Csq9LtwBhH9onaAjSbT1ysezzgYnYVKWH8f+2GhV/h563sJgz
GMw/jIfTiW5wQpFNJYINaBFAr1SLEvoqfHk7CS/C11Uy3JdHtQ7NGoVy+t784XSl5h3d3oQhsKFB
71zeEW/RGe+Qt1rPwynK300FoW0LVbJpWN63wtn5fawa0eCXT4l0BbT94f/WlMvDn0yJhfdXPI6/
MGxby8XOPDXm61y9HQ6wTtZE3Ys8F1vz+hSvkaMmpwSAiavKqEe5CbPtk/32nqfQB9Zi/69C1hfs
VzsOXHUjVrm7zDzQHuOaanWzbkdJVabRx9WXz7cpV42bOQ8beskJ3tEM1PCeQVveX7LLrpF20FL4
vRivi7+CpLIF1vH5DdGOs3c8nV+MdZ7o9kYIemz8hM8CWkaHdMNOZNBrOJzp8DJMGJ6PdYumScRo
PjlvlzGezZBTIG4MKJPp+aBdxnRyYdF0NhlaNJ2PRxZNz0cTi6ZgMIumQ6BRi6rDwcWFRdfh8AJy
V1GEwWjDEahrmTKeT2zqTmZTVFfmsY6WrN4Ui4SkW2JBIESPfDjdEqvbb+HjqK944V+JfRpBD81X
/iglFD3FC38VbaGFGoa9b2LL8CIs9hQ3lgQQsVUpaJ5KM7Heavar0kyMY7A3aH1uY6ijqhbsMyDI
pay99fJ6MnHrla3BDd4hv2sEcbJS4r7a6EJ53VyDzLyAZvg/++bA0HAkSqWRmtRcvkFDki1utqcT
9WoTB7LhoiDdAfzc3Miwx454/KYD7f3Hiu6L2bKVH84qoL09cE+XL1lKy9NXw0D4Re7w+pSVqufF
pl3gMjkuMp8kZ5fD69m1mqVrUYTHG1l+Fv4cOv5QQgAtktBTt2ex7pFTm8YlrjX7PYtjIRLs0aun
pH6nGvhsG66mXkXoIYmbFqGeQyD1jk7cg/fTKVztRY20nV6GfVdsA+QqI1Bz62FA0qp+Qj0OjFqc
DqqMqsbsgUll1LqB2zzXlUcrWMrkZEeavWZg1IN5X8jeRXZkb/8DAAD//wMAUEsDBBQABgAIAAAA
IQBkUfSAhQEAAPoCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAACMkt9PwjAQx99N/B+Wvm/dDzS6wEjQ8KIkJmI0vpX2YJW1a9rC2H9vt8Fg
kQffenfffu7u246nB1F4e9CGl3KCoiBEHkhaMi43E/SxnPsPyDOWSEaKUsIE1WDQNLu9GVOV0lLD
my4VaMvBeI4kTUrVBOXWqhRjQ3MQxAROIV1xXWpBrAv1BitCt2QDOA7DeyzAEkYswQ3QVz0RHZGM
9ki100ULYBRDAQKkNTgKInzWWtDCXL3QVi6UgttauZ2O416yGe2KvfpgeC+sqiqoknYMN3+Evxav
7+2qPpeNVxRQNmY0tdwWkI3x+ehOZrf6AWq7dB+4AtVAbKmzWb4TXHkvOTGSrLjJW8Cp2vi+hboq
NTOOMYgchIGhmivrXrPrMEg4dUGMXbjnXXNgs/pas7+ipqeGPW/+SJbctV372C3a+trND8xzTqWd
r6fKZ/L0vJyjLA6jxA9HfvS4jOM0HqVh+N0sN7jfONclxHHMfxDjeBknqYMOiCdA59Pwt2a/AAAA
//8DAFBLAwQUAAYACAAAACEArpxrH84CAADICgAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbLSWW2/a
MBTH3yftO6BIlbaHkgshAdS0atcideqmaeo+gEkMseZLZJtQvn2PcyukaZQi8ULA5/rL+dvm6uaF
0VGOpSKCR5Y7dqwR5rFICN9E1r/n5eXMGimNeIKo4Diy9lhZN9dfv1ztFnzLVliC4whycLXIwZxq
nS1sW8UpZkiNRYY5GNdCMqThp9zYDMn/2+wyFixDmqwIJXpve44TWFUaEVlbyRdViktGYimUWGsT
shDrNYlx9agj5JC6ZeS9iLcMc11UtCWm0IPgKiWZqrOxU7MBYlonyfsgckZrv102pFoi0Q7eM6Nl
2zshk0yKGCsFq/elscnoOn21qxdoUjQRQ1o4rll3whDhTRojj9b8m+GNYXh2Wds2qd5A4F1cg5jQ
SmmJYv17y0ZHvx6TyHIKF65IArYcURBqMH+Y3i4DyzbBbEs1ecI5ps/7DNc+6X4lSfLL2Kixlb6a
ZbT2uA3vZ7PQ+1FaaG4MBB6mInzVGY0j6yEIvYlzd1v0AFtB6jrcLeNgHyxZs5jgmDBUFYNcz/il
sX27cL83tX7GdR6K17pczv5Iw0O4ATXLkRV6RS8p4ptiT04Cx/jau0XlLMsYuRRcKwhLCYewBK8R
kFeuhQ+EQD8m/yGp+0bq+M7ccdz5QFIqdlg+Ya2xbKAOaS+8cbM+ENb1/V7abgTvHcJdsQL7HLa3
OZbczyD9FQzxpvMjokkXkSSb9OP5eS4MzIylHqA7OxpgN9KkjeQsT0Tq0+OF38XTK0dvBu0f4rT0
2I3jt3FAZJBEnzihPtFNP40EBCcgTd8hnUt0QRdRv+j8SevUGCQ6uILrQ688Cs4jurCLp1d0U2jH
9NbsoUGiC9s45xPd7PNIYetYGIQEf8aOJ+SeS3TzLqJ+0QV+62j4QHRwRBzc9uY+ghsUuODTXPbl
WX3g8Wguw+LWrw9O8CxuQHiW/0CvXwEAAP//AwBQSwMEFAAGAAgAAAAhACUKcaTkAQAALAYAABIA
AAB3b3JkL2ZvbnRUYWJsZS54bWy0lNFuozAQRd9X2n9Aft9iCNs0UUnVdpvHfVixH+DAECxhG3mc
0Pz9DjZpK6VIYaUmCkou48lwfK/vH15VGx3BojQ6Z8kNZxHo0lRS73P2t9j+uGMROqEr0RoNOTsB
sofN92/3/bo22mFE6zWubc4a57p1HGPZgBJ4YzrQdK82VglHP+0+NnUtS/hlyoMC7eKU89vYQisc
/Tc2skM2duuv6dYbW3XWlIBIw6o29FNCarYZp4v6tRaKpi6kAox+Qx/9MUqEgk5og5BQzVG0OeMp
vW/5gv/kGX1S+paxeOhUNsIiuLdCHuRaKNmezqr1fX19J13ZnPWjsFLsWghrUO7pxgF3PGcvnPP0
8WXLgpLk7JmU5V2WjEpKQ4XXalQWbwptEw3m+/iSZOv7kEJ9xlV+zjjs0wWRZ9HKnZUe1SWJrScw
EMmIA11nkMBeIob6K0k8DgOnH0lkg8CXTxck/HMTv2kSfDWXhDlYCXZwxwSNJTFY0Typp5LNoqFM
BVZ/gqOWr1BNuSLsJj3nuysWFyy+wBWFaMjHExieKB6DHYaAZP9vCm1cYQ9QnDqYE5fR1GcMH20e
AvQelytMwn3I5sRFUVqmyAwHRuAyHCDz4jL/4Pg8LpxnXxOX8QTBzT8AAAD//wMAUEsDBBQABgAI
AAAAIQBeJjfCjgEAAOECAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAJyST0/jMBDF7yvxHaLcW6flzxY0NUJFiMMuVGqAs2VPEgvHtmzD0m+/
Y9KGrPZGTjNvrOc3vxiuP3pTvGOI2tl1uZhXZYFWOqVtuy6f6rvZqixiElYJ4yyuyz3G8pqf/IBt
cB5D0hgLsrBxXXYp+SvGouywF3FOY0uTxoVeJGpDy1zTaIm3Tr71aBNbVtUFw4+EVqGa+dGwHByv
3tN3TZWTOV98rveeAnOosfdGJOQPOY4BNgpQuyRMrXvkqwvSxw62osXIl8CGAl5cUJGfnq+ADSVs
OhGETESPL6uzc2ATAW68N1qKRGD5by2Di65JxeMngiIbAJseAcKyQ/kWdNrzCti0hV/aUpTFT2BD
RdmCaIPwXeRnOeDYwU4KgxtanjfCRAT2JcDG9V7YPb/HPwZTmm2FfBVBFQed8h8O5Atf45Ov3W2G
dnD6V5xs/6JTt/NCZlynl5dTDpMR7AgXKlrsaPglwD39qGDyrcTQtqiOZ/4fZLLPw4vli+W8ou8T
5VEjHuNT4n8BAAD//wMAUEsBAi0AFAAGAAgAAAAhADDJKAxyAQAApQUAABMAAAAAAAAAAAAAAAAA
AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MAAABOAgAACwAAAAAA
AAAAAAAAAACrAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAs76LHQkBAAC2AwAAHAAAAAAA
AAAAAAAAAADPBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQABgAIAAAAIQAO
yCH9xBIAAJiYAAARAAAAAAAAAAAAAAAAABoJAAB3b3JkL2RvY3VtZW50LnhtbFBLAQItABQABgAI
AAAAIQCWta3ilgYAAFAbAAAVAAAAAAAAAAAAAAAAAA0cAAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQ
SwECLQAUAAYACAAAACEA2Qw+6JgDAABWCQAAEQAAAAAAAAAAAAAAAADWIgAAd29yZC9zZXR0aW5n
cy54bWxQSwECLQAUAAYACAAAACEANLZsrawBAAAjDwAAFAAAAAAAAAAAAAAAAACdJgAAd29yZC93
ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEA4iUhKiwJAADARAAADwAAAAAAAAAAAAAAAAB7
KAAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAGRR9ICFAQAA+gIAABEAAAAAAAAAAAAA
AAAA1DEAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAK6cax/OAgAAyAoAABIAAAAA
AAAAAAAAAAAAkDQAAHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAIAAAAIQAlCnGk5AEAACwG
AAASAAAAAAAAAAAAAAAAAI43AAB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEAXiY3
wo4BAADhAgAAEAAAAAAAAAAAAAAAAACiOQAAZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADAAMAAED
AABmPAAAAAA=
--089e013c67468ef07804dafb5c60--

From hadi@mojatatu.com  Mon Apr 22 17:02:00 2013
Return-Path: 
X-Original-To: forces@ietfa.amsl.com
Delivered-To: forces@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E54711E80E1 for ; Mon, 22 Apr 2013 17:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level: 
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDsuT+7BGyF0 for ; Mon, 22 Apr 2013 17:01:59 -0700 (PDT)
Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 68A8011E80BA for ; Mon, 22 Apr 2013 17:01:59 -0700 (PDT)
Received: by mail-vb0-f42.google.com with SMTP id p12so40855vbe.29 for ; Mon, 22 Apr 2013 17:01:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=RzpelHkjwBNgXjqV1Dy6vv/TQj82M21NWE4PJ8wCqCg=; b=k9hA9ci8miqYH/zSHG15yRznrd8EfYrYwnkjRxKl7ZYKzGNuZVO9qY3JWojKsF0j4P uEV62Z2mHffXjGnE4IiyENlePAVNtUW/vh3aJKfIaAA+fLeieUmt54ocC9I1QJQ2phyU KYJM2QKwX84IYH/2UqRLMy9bu3kG8jvgicl7Y6142rYl0quxI0cGioj4MwncZKMCSZ42 5uYS1giN/bkSSXxf1ICsAf1V/ihyc8RQupq+U6ZxlqifLKhzPZ0dquSzWEYgbLz/sIyp l+LhqJqzk9sfn5qPzFrpM6F7ZvNNoyzkj2JY9yKQVbzih7L1j91iWujlyAnqbPJhUL8e XbeQ==
X-Received: by 10.58.164.131 with SMTP id yq3mr20839756veb.31.1366675318821; Mon, 22 Apr 2013 17:01:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.253.100 with HTTP; Mon, 22 Apr 2013 17:01:38 -0700 (PDT)
In-Reply-To: 
References: 
From: Jamal Hadi Salim 
Date: Mon, 22 Apr 2013 20:01:38 -0400
Message-ID: 
To: "B.Khasnabish@ieee.org" 
Content-Type: multipart/alternative; boundary=047d7b671ed0e6f19f04dafbe474
X-Gm-Message-State: ALoCoQkJwh5DW4jsGqz8x6xfzfO6IwGtYpiSzM5Dg8TJrJrTykYhahYgzuAl/ST7h+sX7opXygB8
Cc: "forces@ietf.org" , draft-ietf-forces-ceha@tools.ietf.org
Subject: Re: [forces] Comments on ForCES Intra-NE High Availability, draft-ietf-forces-ceha-06
X-BeenThere: forces@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: ForCES WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 00:02:00 -0000

--047d7b671ed0e6f19f04dafbe474
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Thanks Bhumip.
The authors will look at these and likely publish a new version.
We really want to move forward and publish this document.

cheers,
jamal


On Mon, Apr 22, 2013 at 7:23 PM, B.Khasnabish@ieee.org wr=
ote:

>
> Comments on the CE HA draft
>
> ForCES Intra-NE High Availability, draft-ietf-forces-ceha-06
>
> ( http://www.ietf.org/id/draft-ietf-forces-ceha-06.txt )
>
>
>
>
>
> (1)Please avoid using Acronyms in the Abstract
>
> (2)If you have used an XML validator, include the results of validation
> of the XML files in the Appendix of the draft
>
> (3)Change the Title of Section 1 to =93Definitions and Acronyms=94
>
> (4)Add a list of Acronyms in updated Section 1; CE, CCM, FE, FEM, NE, HB,
> TML, =85 etc.
>
> (5)Add RFC 2119 under the =93Normative=94 ref. Section
>
> (6)For subsections in Sec. 2, 3, and 4, use i, ii, iii, etc. or a, b, c,
> etc. instead of 1, 2, 3, and so on
>
> (7)Replace =93High Availability=94 by =93HA=94 throughout the draft
>
> (8)In Sec. 4.1, under 1, please consider adding +6, +7, and +8,  and
> Reserve these for future use
>
> (9)In Sec. 4.1 under 2, please consider adding, +3, and Reserve it for
> future use
>
> (10) The are many partially complete or incomplete sentence in the draft
> ... PLEASE correct these sentences =85 a few examples are as follows..
>
> (a) In Section 3.1 of this document draft, we discuss further details of =
these knobs. further
>
>
>
>       (b) It should be noted that in this default setup, which
>
>       MUST be implemented by CEs and FEs needing requiring HA, the Fr pla=
ne is out of scope (and if available is proprietary to an implementation).
>
>
>
> (c ) Figure 3 illustrates the defined state machine that facilitates
>
>    connection   the recovery of connection state.
>
>
>
> (d) To put the two together, if a path to a primary CE is down, the TML
>
>    would take care of failing over tohelp recover from a failure using a =
backup path, if one is available.
>
>
>
> (e)
>
>   +  0 (No HA Mode)represents that tThe FE is not running in HA mode
>
>
>
>            +  1 (HA Mode - Cold Standby) represents that tThe FE is in HA=
 mode cold Standby
>
>
>
>            +  and 2 (HA Mode - Hot Standby) represents that tThe FE is in=
 HA mode hot Standby
>
> Thanks.
>
> Best.
>
> Bhumip
>
>

--047d7b671ed0e6f19f04dafbe474
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



Thanks Bhumip.
The authors will look at=
 these and likely publish a new version.
We really want to move f=
orward and publish this document.=A0



cheers,
jamal

On Mon, Apr 22, 2013 at 7:23 PM, B.Khasnabish@ieee.org <=
vumip1@gmail.com&=
gt; wrote:






Comments on the CE HA draft


ForCES Intra-N=
E High Availability, draft-ietf-forces-ceha-06 


( http://www.ietf.org/id/draft-ietf-forces-ceha-06.txt )





=A0


=A0




(1)Please avoid using Acronyms in the Abstract





(2)If y=
ou have used an XML validator, include the results of =
validation of the XML files in the Appendix of the draft





(3)Change the Title of Section 1 to =93Definitions and Acrony=
ms=94





(4)Add a list of Acronyms in updated Section 1; CE, CCM, FE, =
FEM, NE, HB, TML, =85 etc.





(5)Add RFC 2119 under the =93Normative=94 ref. Section 





(6)For subsections in Sec. 2, 3, and 4, use i, ii, iii, etc. =
or a, b, c, etc. instead of 1, 2, 3, and so on





(7)Replace =93High Availability=94 by =93HA=94 throughout the=
 draft





(8)In Sec. 4.1, under 1, please consider adding +6, +7, and +=
8,=A0 and Reserve these for future use





(9)In Sec. 4.1 under 2, please consider adding, +3, and Reser=
ve it for future use=A0 





(10) (a) In Section 3.1 of this document draft,=
 we discuss further details of these knobs. f=
urther <=
/span>




<=
font color=3D"#008080">=A0
=A0=A0=A0=A0=
=A0 (b) It should be noted that in this default setup, which


=A0=A0=A0=A0=A0 MUST be implemented by CEs and FEs =
needing <=
/del>requiring HA, the Fr plane is out of scope (and if av=
ailable is proprietary to an implementation).




=A0
(c ) Figure 3 illustrates the defined state machine that=
 facilitates
=A0=A0 connection =A0=A0th=
e recovery of connection state.




=A0
(d) To put the two together, if a path to a pr=
imary CE is down, the TML


=A0=A0 would take care of failing over to=
help recover fro=
m a failure using a backup path, if one is available.



=A0
(e)
=A0 +=A0 0 (No H=
A Mode)rep=
resents that <=
font color=3D"#008080">tThe FE is not running=
 in HA mode




=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0 <=
/span>1 (HA Mode - Cold Standby) <=
font color=3D"#008080">represents that tThe F=
E is in HA mode cold Standby




=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=A0 <=
/span>and 2 (HA Mode - Hot Standby) represents that tThe FE is in HA mode h=
ot Standby





Thanks.


=A0


Best.


=A0


Bhumip


=A0

--047d7b671ed0e6f19f04dafbe474-- From adrian@olddog.co.uk Mon Apr 22 17:17:57 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D67F21E80B9 for ; Mon, 22 Apr 2013 17:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7Z4oMgRQBKx for ; Mon, 22 Apr 2013 17:17:56 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 94DD921E80B0 for ; Mon, 22 Apr 2013 17:17:55 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3N0HqAO020759; Tue, 23 Apr 2013 01:17:52 +0100 Received: from 950129200 ([66.129.246.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3N0HoDf020744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Apr 2013 01:17:51 +0100 From: "Adrian Farrel" To: Date: Tue, 23 Apr 2013 01:17:47 +0100 Message-ID: <014e01ce3fb7$fd0a5180$f71ef480$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4/t5ZmNi0N8Ou+QXyRHmaAD9e7UQ== Content-Language: en-gb Subject: [forces] Patrick Droz stepping down as ForCES co-chair X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 00:17:57 -0000 Hi ForCES, Patrick has been co-chair of ForCES since before I knew the WG existed! He has done a huge amount to move the work forward over the years. As we move to the next cycle for ForCES and approve the new charter, Patrick has decided that this is a perfect time to step down and make way for a new chair. I will work with Jamal and Stewart to select a new co-chair. Thanks to Patrick for all his work. Adrian From presnick@qti.qualcomm.com Wed Apr 24 14:21:08 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829EC21F8EB3; Wed, 24 Apr 2013 14:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXxE6s70KMlG; Wed, 24 Apr 2013 14:21:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED9121F85DC; Wed, 24 Apr 2013 14:21:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130424212108.26980.64669.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 14:21:08 -0700 Cc: forces@ietf.org, forces-chairs@tools.ietf.org Subject: [forces] Pete Resnick's No Objection on charter-ietf-forces-03-07: (with COMMENT) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 21:21:08 -0000 Pete Resnick has entered the following ballot position for charter-ietf-forces-03-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Since the changes in this charter are simply deltas to the current specs, it might also be nice if the WG did whatever work necessary (fix errata, delete unused bits, if any) to get the current specs to full Internet Standard. From vumip1@gmail.com Wed Apr 24 14:34:37 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9114521F86F0 for ; Wed, 24 Apr 2013 14:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Apu6o82ZRzKe for ; Wed, 24 Apr 2013 14:34:36 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 01D5921F8630 for ; Wed, 24 Apr 2013 14:34:35 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id l13so2610088wie.6 for ; Wed, 24 Apr 2013 14:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=Ju/drH1tRqmziKoHSUO48MgEli4TqFrW5I4SDp6tDUA=; b=TskQb9sZKnm6tp+o1/uNB3xDAiZP0cHlxfPFR7XA3a4y95OXoSjGvLTw25yGBhXnLj KKiS6TdLwdAfVwxhwRwHZ/dMl804u0aLDUPNWFtDuHfh68UnI2dN1UhlUe2FUpVtKGf4 SK6AfOstEbZdj2lAr/E50y0jnXBtG0iDWJsV+RETM+joPXZw+OLgGZkIslfSNz0plMWH TnikutWYsPWak9I+7Vu1gwnnfB6ZCW7c2AN1xkxlsepg4wlRRYdYiJ8DXOQqwjG1ZBx5 j5u46MFkZj+LaF90iuso7XQk34VuR6M5pGV8nE2GZQDRn2puQqkTkcLYlj2LwkK+mvKX hCpQ== MIME-Version: 1.0 X-Received: by 10.180.80.3 with SMTP id n3mr47839820wix.20.1366839275093; Wed, 24 Apr 2013 14:34:35 -0700 (PDT) Received: by 10.216.111.193 with HTTP; Wed, 24 Apr 2013 14:34:34 -0700 (PDT) In-Reply-To: <26167F038100474085B683008D19631317E7B8@UM-MBX-N01.um.umsystem.edu> References: <26167F038100474085B683008D19631317E7B8@UM-MBX-N01.um.umsystem.edu> Date: Wed, 24 Apr 2013 17:34:34 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: forces@ietf.org Content-Type: multipart/alternative; boundary=f46d041825387503ae04db22119d Subject: [forces] Fwd: Special Issue on Management of Software Defined Networks (SDNs) - Springer Journal of Network and Systems Management (JNSM) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 21:34:37 -0000 --f46d041825387503ae04db22119d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable FY and kind submission, if you are interested. Thanks. Best. Bhumip ---------- Forwarded message ---------- From: Choi, Baek-Young Date: Wed, Apr 24, 2013 at 3:48 PM Subject: Special Issue on Management of Software Defined Networks (SDNs) - Springer Journal of Network and Systems Management (JNSM) To: "cnom@inf.ufsc.br" , "ifip_nm@lists.utwente.nl" < ifip_nm@lists.utwente.nl> Cc: "B.Khasnabish@ieee.org" , "Choi, Baek-Young" < choiby@umkc.edu>, Nick Feamster Springer Journal of Network and Systems Management (JNSM), Special Issue on Management of Software Defined Networks (SDNs)**** Call for Paper Submission**** =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D **** Software Defined Networking attempts to use software defined packages or modules for implementing network features/functions and their control and management. SDN decouples physical networking infrastructure/resources from the services that utilize them so that a controlled level of flexibility in resources assignment can be achieved seamlessly for the desired services. It utilizes the concept of separating network control plane from the network traffic forwarding plane. The control plane can be physically distributed but it is logically centralized.**** ** ** Universally acceptable open Application Programming Interface (API) is required to expose the forwarding plane to the control plane. This API must be an open programmable interface to virtualized forwarding resources from different implementation and administration domains. Therefore, the required brokering and orchestration would be essential to successful implementation and deployment of SDN. **** ** ** In this special issue of JNSM, we look forward to publishing original research papers that are focused on network and system management aspects of SDN. The areas of interest include the following:**** **=B7 **Use cases focusing on Efficient Delivery of Emerging Servic= es* *** **=B7 **SDN Interoperability Framework **** **=B7 **Distributed Multi-Domain Control of Information Forwarding*= *** **=B7 **Control and Orchestration API **** **=B7 **Programming (Languages) and Debugging of SDN Elements and System**** **=B7 **Privacy and Security of Services and Control**** **=B7 **Auditability/Verifiability of Resources Allocation and Consumption **** **=B7 **Implementation Reports and Field Trials**** **=B7 **Management of OpenFlow based networks**** **=B7 **Orchestration and programmability of virtual resources (networking, computation and storage) and services**** ** ** *Submission guideline:* Authors are invited to submit clearly written, high quality original paper that is not under review by other journals or conferences. The instructions for manuscript preparation and submission can be found at http://www.springer.com/journal/10922. **** All manuscripts and any supplementary material should be submitted through editorial manger system at https://www.editorialmanager.com/jons/. The authors must select =93SI: Software Defined Networking=94 for the =93Articl= e Type=94 step in the submission process. **** Guest editors:**** Bhumip Khasnabish (b.khasnabish@ieee.org)**** Baek-Young Choi (choiby@umkc.edu) **** Nick Feamster (feamster@cc.gatech.edu) **** ** ** Schedule:**** Paper submission date:**** September 15, 2013**** Notification of acceptance:**** March 15, 2014**** Final paper due:**** August 15, 2014**** Publication date:**** December 2014**** ** ** ** ** ** ** --f46d041825387503ae04db22119d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
FY and kind submission, if you are interested.
=A0
Thanks.
=A0
Best.
=A0
Bhumip


=A0
---------- Forwarded message ----------
From:= Choi, Baek-Young <<= a href=3D"mailto:choiby@umkc.edu" target=3D"_blank">choiby@umkc.edu>=
Date: Wed, Apr 24, 2013 at 3:48 PM
Subject: Special Issue on Management = of Software Defined Networks (SDNs) - Springer Journal of Network and Syste= ms Management (JNSM)
To: "cnom@inf.ufsc.br" <cnom@inf.ufsc.br>, "ifip_nm@lists.utwente.nl"= ; <ifip_nm= @lists.utwente.nl>
Cc: "B.Khas= nabish@ieee.org" <B.Khasnabish@ieee.org>, "Choi, Baek-Young" &= lt;choiby@umkc.edu= >, Nick Feamster <feamster@cc.gatech.edu>


Springer Journal of Network and Systems Manage= ment (JNSM), Special Issue on Management of Software Defined Network= s (SDNs)

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Call for Paper Submission=

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

Software Defined Networ= king attempts to use software defined packages or modules for implementing = network features/functions and their control and management. SDN decouples = physical networking infrastructure/resources from the services that utilize= them so that a controlled level of flexibility in resources assignment can= be achieved seamlessly for the desired services. It utilizes the concept o= f separating network control plane from the network traffic forwarding plan= e. The control plane can be physically distributed but it is logically cent= ralized.

=A0

Universally acceptable = open Application Programming Interface (API) is required to expose the forw= arding plane to the control plane. This API must be an open programmable in= terface to virtualized forwarding resources from different implementation a= nd administration domains. Therefore, the required brokering and orchestrat= ion would be essential to successful implementation and deployment of SDN. =

=A0

In this special issue o= f JNSM, we look forward to publishing original research papers that are foc= used on network and system management aspects of SDN. The areas of interest= include the following:

=B7=A0=A0=A0=A0=A0=A0=A0=A0 U= se cases focusing on Efficient Delivery of Emerging Services<= /p>

=B7=A0=A0=A0=A0=A0=A0=A0=A0 S= DN Interoperability Framework

=B7=A0=A0=A0=A0=A0=A0=A0=A0 D= istributed Multi-Domain Control of Information Forwarding

=B7=A0=A0=A0=A0=A0=A0=A0=A0 C= ontrol and Orchestration API

=B7=A0=A0=A0=A0=A0=A0=A0=A0 P= rogramming (Languages) and Debugging of SDN Elements and System

=B7=A0=A0=A0=A0=A0=A0=A0=A0 P= rivacy and Security of Services and Control

=B7=A0=A0=A0=A0=A0=A0=A0=A0 A= uditability/Verifiability of Resources Allocation and Consumption

=B7=A0=A0=A0=A0=A0=A0=A0=A0 I= mplementation Reports and Field Trials

=B7=A0=A0=A0=A0=A0=A0=A0=A0 M= anagement of OpenFlow based networks

=B7=A0=A0=A0=A0=A0=A0=A0=A0 O= rchestration and programmability of virtual resources (networking, computat= ion and storage) and services

<= /u>=A0

Submission guideline:

Authors are invited to submit clearly written, high = quality original paper that is not under review by other journals or confer= ences. The instructions for manuscript preparation and submission can be fo= und at = http://www.springer.com/journal/10922.

All manuscripts and any supplementary material shoul= d be submitted through editorial manger system at https://www.editorialmanager.co= m/jons/.=A0 The authors must select =93SI: Software Defined Networking= =94 for the =93Article Type=94 step in the submission process.

Guest editors:

Bhumip Khasnabish (b.khasnabish@ieee.org= )

Baek-Young Choi (choiby@umkc.edu) <= u>

Nick Feamster (feamster@cc.gatech.edu= )=A0

=A0

Schedule:

<= /tr>

Pap= er submission date:

September=A0 15, 2013

=

Not= ification of acceptance:

March=A0 15, 2014

Fin= al paper due:

August 15, 2014

Pub= lication date:

December 2014

=A0

=A0

=A0

--f46d041825387503ae04db22119d-- From ietf-secretariat-reply@ietf.org Fri Apr 26 09:17:48 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1032021F9A17 for ; Fri, 26 Apr 2013 09:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6z2HZLRe6IY; Fri, 26 Apr 2013 09:17:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F68A21F9A18; Fri, 26 Apr 2013 09:17:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: forces@ietf.org, forces-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426161747.20760.23486.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 09:17:47 -0700 From: IETF Secretariat X-Mailman-Approved-At: Fri, 26 Apr 2013 09:38:36 -0700 Subject: [forces] State changed: charter-ietf-forces-03-07 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 16:17:48 -0000 State changed to External review. URL: http://datatracker.ietf.org/doc/charter-ietf-forces/ From johnsonhammond2@hushmail.com Sat Apr 27 10:00:47 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BC921F982D for ; Sat, 27 Apr 2013 10:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWrVWgEggctr for ; Sat, 27 Apr 2013 10:00:46 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id DBD1D21F97F4 for ; Sat, 27 Apr 2013 10:00:46 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id 83EC6E7C0C for ; Sat, 27 Apr 2013 17:00:46 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:00:46 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 30EA914DBDE; Sat, 27 Apr 2013 17:00:46 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:00:45 -0400 To: forces@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427170046.30EA914DBDE@smtp.hushmail.com> Subject: [forces] Biggest Fake Conference in Computer Science X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:19:44 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From iesg-secretary@ietf.org Mon Apr 29 07:20:31 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2985621F9DD1; Mon, 29 Apr 2013 07:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.95 X-Spam-Level: X-Spam-Status: No, score=-101.95 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBAYYGP-82TM; Mon, 29 Apr 2013 07:20:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3CE21F9D83; Mon, 29 Apr 2013 07:20:30 -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: 4.44.p4 Sender: Message-ID: <20130429142030.733.10596.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2013 07:20:30 -0700 Cc: forces@ietf.org Subject: [forces] Last Call: (Interoperability Report for Forwarding and Control Element Separation (ForCES)) to Informational RFC X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 14:20:31 -0000 The IESG has received a request from the Forwarding and Control Element Separation WG (forces) to consider the following document: - 'Interoperability Report for Forwarding and Control Element Separation (ForCES)' 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 2013-05-13. 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 This document captures results of the second Forwarding and Control Element Separation (ForCES) interoperability test which took place on February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. RFC 6053 reported the results of the first ForCES interoperability test, and this document updates RFC 6053 by providing further interoperability results. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-forces-interop/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-forces-interop/ballot/ No IPR declarations have been submitted directly on this I-D. From ehalep@gmail.com Tue Apr 30 07:02:20 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9E821F9A38 for ; Tue, 30 Apr 2013 07:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEvS5tlJHfkq for ; Tue, 30 Apr 2013 07:02:18 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1780B21F9A30 for ; Tue, 30 Apr 2013 07:02:17 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id e11so484117wgh.25 for ; Tue, 30 Apr 2013 07:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=1AUYI5HYAqfM+0g2O2dFduauV1OUeWNdQxU1xJw2K4w=; b=RhSRStj4vX1iURdg8RU8QMnn9rcKMhqXD/jT3kbXOJArlR+uKTY8NdfsfscM+2hgAP 0h8JkrCuHkO0GkTHqgPPbzovavexlAQQwZG5JRDwF1rWRyCVJ9bdLrVxW/NMvYDnl1VP 6zhjDrGJUGzhzo0vBfm46jFRC8PVA+9Gpni3FpNuv0UQzNUiE0BWd/mAQ/r5BbgKbM7E MUJbYU+ReH06qGN4mtoo4Axbe3GkIhy7Ow0WyGufqo3RIZM2AAbK3xBVDjnHAYG39CjA k1YnKz/tQyjMWCV76Q28ECwbaP23CQ8rblDKIeKau47wZ0rEQ3gLEyROuuMPvFrRUx7l R+2Q== X-Received: by 10.194.133.198 with SMTP id pe6mr103852251wjb.9.1367330534226; Tue, 30 Apr 2013 07:02:14 -0700 (PDT) Received: from EhalepXPS (ppp079166032088.access.hol.gr. [79.166.32.88]) by mx.google.com with ESMTPSA id c5sm3069308wiz.11.2013.04.30.07.02.11 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Apr 2013 07:02:12 -0700 (PDT) From: "Haleplidis Evangelos" To: "'B.Khasnabish@ieee.org'" , References: In-Reply-To: Date: Tue, 30 Apr 2013 17:02:11 +0300 Message-ID: <003301ce45ab$5067d7f0$f13787d0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01CE45C4.75B50FF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4/sIp08jeaR7dSTN+tmym58zj1DAF59NqQ Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] Fwd: Comments on ForCES Intra-NE High Availability, draft-ietf-forces-ceha-06 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 14:02:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0034_01CE45C4.75B50FF0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Greetings, =20 Thank you very much for your comments. These changes will appear on the next version of the document. =20 Please see inline for responses. =20 Regards, Evangelos Haleplidis. =20 From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf = Of B.Khasnabish@ieee.org Sent: Tuesday, April 23, 2013 2:24 AM To: draft-ietf-forces-ceha@tools.ietf.org Cc: forces@ietf.org Subject: [forces] Fwd: Comments on ForCES Intra-NE High Availability, draft-ietf-forces-ceha-06 =20 Comments on the CE HA draft ForCES Intra-NE High Availability, draft-ietf-forces-ceha-06=20 ( http://www.ietf.org/id/draft-ietf-forces-ceha-06.txt ) =20 =20 (1)Please avoid using Acronyms in the Abstract [=C5=C7] Ok. (2)If you have used an XML validator, include the results of validation = of the XML files in the Appendix of the draft [=C5=C7] We added a text stating: "The xml has been validated against = the schema defined in the [RFC5812]." (3)Change the Title of Section 1 to "Definitions and Acronyms" (4)Add a list of Acronyms in updated Section 1; CE, CCM, FE, FEM, NE, = HB, TML, . etc. [=C5=C7] Added most of your suggestion. Copied them from previous RFCs. (5)Add RFC 2119 under the "Normative" ref. Section=20 [=C5=C7] Done, thanks. (6)For subsections in Sec. 2, 3, and 4, use i, ii, iii, etc. or a, b, c, etc. instead of 1, 2, 3, and so on [=C5=C7] Is this needed? (7)Replace "High Availability" by "HA" throughout the draft [=C5=C7] Done. (8)In Sec. 4.1, under 1, please consider adding +6, +7, and +8, and = Reserve these for future use (9)In Sec. 4.1 under 2, please consider adding, +3, and Reserve it for future use =20 [=C5=C7] For 8 & 9, my current thinking is that they are unnecessary. = Tampering with the FEPO special values may result in non-interoperable = implementations of ForCES. Changes for these special values should be done within the = ForCES working group. Why do you think this is required? Anyone else's thoughts on this? (10) The are many partially complete or incomplete sentence in the draft = ... PLEASE correct these sentences . a few examples are as follows.. (a) In Section 3.1 of this draft, we discuss further details of these = knobs. [=C5=C7] I will keep the "document" word, as it is more generic. When = the draft becomes RFC, it would be best to have that word as document. Made the = rest of the change though. =20 (b) It should be noted that in this default setup, which MUST be implemented by CEs and FEs requiring HA, the Fr plane is = out of scope (and if available is proprietary to an implementation). =20 (c ) Figure 3 illustrates the defined state machine that facilitates the recovery of connection state. =20 (d) To put the two together, if a path to a primary CE is down, the TML would help recover from a failure using a backup path, if one is available. =20 (e) + 0 (No HA Mode)represents that the FE is not running in HA mode =20 + 1 (HA Mode - Cold Standby) represents that the FE is in HA mode cold Standby =20 + and 2 (HA Mode - Hot Standby) represents that the FE is in = HA mode hot Standby =20 [=C5=C7] Made these changes, thanks. =20 Thanks. =20 Best. =20 Bhumip =20 ------=_NextPart_000_0034_01CE45C4.75B50FF0 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable

Greetings,

 

Thank you very much for your comments.

These changes will appear on the next version of the = document.

 

Please see inline for responses.

 

Regards,

Evangelos Haleplidis.

 

From:= = forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On Behalf Of = B.Khasnabish@ieee.org
Sent: Tuesday, April 23, 2013 2:24 = AM
To: draft-ietf-forces-ceha@tools.ietf.org
Cc: = forces@ietf.org
Subject: [forces] Fwd: Comments on ForCES = Intra-NE High Availability, = draft-ietf-forces-ceha-06

 


Comments on the CE HA = draft

ForCES Intra-NE = High Availability, draft-ietf-forces-ceha-06

( http://www.= ietf.org/id/draft-ietf-forces-ceha-06.txt )

 

 

(1)Please avoid using Acronyms in the Abstract

[=C5=C7] Ok.

(2)If you have used an XML validator, include the results of = validation of the XML files in the Appendix of the draft

[=C5=C7] We added a text stating: “The xml has = been validated against the schema defined in the = [RFC5812].”

(3)Change the Title of Section 1 to “Definitions and = Acronyms”

(4)Add a list of Acronyms in updated Section 1; CE, CCM, FE, FEM, = NE, HB, TML, … etc.

[=C5=C7] Added most of your suggestion. Copied them = from previous RFCs.

(5)Add RFC 2119 under the “Normative” ref. = Section

[=C5=C7] Done, thanks.

(6)For subsections in Sec. 2, 3, and 4, use i, ii, iii, etc. or a, = b, c, etc. instead of 1, 2, 3, and so on

[=C5=C7] Is this needed?

(7)Replace “High Availability” by “HA” = throughout the draft

[=C5=C7] Done.

(8)In Sec. 4.1, under 1, please consider adding +6, +7, and = +8,  and Reserve these for future use

(9)In Sec. 4.1 under 2, please consider adding, +3, and Reserve it = for future use 

[=C5=C7] For 8 & 9, my current thinking is that = they are unnecessary. Tampering with the FEPO special values may result = in non-interoperable implementations of ForCES. Changes for these = special values should be done within the ForCES working = group.

Why do you think this is required? Anyone = else’s thoughts on this?

= (10) The are many partially complete or incomplete sentence in the = draft ... PLEASE correct these sentences … a few examples are as = follows..

(a) In Section 3.1 of this draft, we discuss further details =
of these =
knobs. =

[=C5=C7] I will keep the “document” word, as it is more =
generic. When the draft becomes RFC, it would be best to have that word =
as document. Made the rest of the change though.
 
      (b) It should be =
noted that in this default setup, which
      MUST be implemented by CEs =
and FEs requiring =
HA, the Fr plane is out of scope (and if available is =
proprietary to an implementation).
 
(c ) Figure 3 =
illustrates the defined state machine that =
facilitates
     the =
recovery =
of connection state.
 
(d) To put the two together, =
if a path to a primary CE is down, the TML
   would help recover from a failure using a =
backup path, if one is available.
 
(e)
=
  +  0 (No HA Mode)represents that =
the FE is =
not running in HA mode
 
          =
 +  1 (HA Mode - Cold Standby) represents that the FE is in HA mode =
cold Standby
 
          =
 +  and 2 (HA Mode - Hot Standby) represents that the FE is in HA mode =
hot Standby
 
 [=C5=C7] Made these changes, =
thanks.
 

Thanks.

 

Best.

 

Bhumip

 

------=_NextPart_000_0034_01CE45C4.75B50FF0-- From hadi@mojatatu.com Tue Apr 30 07:19:47 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFAD21F9961 for ; Tue, 30 Apr 2013 07:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fu3L49PnTy0 for ; Tue, 30 Apr 2013 07:19:42 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id EC25821F9361 for ; Tue, 30 Apr 2013 07:19:41 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id ha12so458680vcb.30 for ; Tue, 30 Apr 2013 07:19:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=2uMc2GNz6iTLmyYRwH9jfVniu/IctrqhNy0Or7PWaIQ=; b=n688bm1iMcFPC9vxKXix4wpS6QSKcivrkz5SwlKfq0ZV+a0vaZZVQs+dvm2Wr+kzKA umBggGnW799q8f2ocL/xvm9j9hiaVhc90Vhfn9jewvJbyJk97IqAWf/ysLnKOxDMhek/ PF/+2ZAMBHLHCXL+7r3agi9MsqSDhE1jqlMgddr3AIMHdhahNw9vL7VOuSNIFCjzo/22 GWgPVf7IXKhBtUd1/GgeO6QymuIpsHYhHEqeuj/ojHe6hkgMFLkXnahifU1lTPK9p9Vw X/7IUwMIpfCsWqyb9oa/XNIgTJtzWfA0CVQH8ADDPl/ULXX03efkOAK4rnLMT9g5rJ1V 85qg== X-Received: by 10.220.223.202 with SMTP id il10mr35363087vcb.4.1367331581373; Tue, 30 Apr 2013 07:19:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.154.5 with HTTP; Tue, 30 Apr 2013 07:19:21 -0700 (PDT) In-Reply-To: <003301ce45ab$5067d7f0$f13787d0$@com> References: <003301ce45ab$5067d7f0$f13787d0$@com> From: Jamal Hadi Salim Date: Tue, 30 Apr 2013 10:19:21 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: multipart/alternative; boundary=14dae9cdc48732c5c904db94b17b X-Gm-Message-State: ALoCoQlPayx8BHRujP9J70avudqtmYmN+Fl4fw1UncfwIIsOoAHJx20gW5/LS1EP78wb9e9p5w3X Cc: draft-ietf-forces-ceha@tools.ietf.org, "forces@ietf.org" Subject: Re: [forces] Fwd: Comments on ForCES Intra-NE High Availability, draft-ietf-forces-ceha-06 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 14:19:47 -0000 --14dae9cdc48732c5c904db94b17b Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2013 at 10:02 AM, Haleplidis Evangelos wr= ote: > > (8)In Sec. 4.1, under 1, please consider adding +6, +7, and +8, and > Reserve these for future use**** > > (9)In Sec. 4.1 under 2, please consider adding, +3, and Reserve it for > future use **** > > *[=C5=C7] For 8 & 9, my current thinking is that they are unnecessary. > Tampering with the FEPO special values may result in non-interoperable > implementations of ForCES. Changes for these special values should be don= e > within the ForCES working group.* > > *Why do you think this is required? Anyone else=A2s thoughts on this?* > Agree with Evangelos. There is no need to reserve fields for future use. It will infact cause interop problems if someone starts using those fields. cheers, jamal --14dae9cdc48732c5c904db94b17b Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 30, 2013 at 10:02 AM, Haleplidis Evangelos <ehalep@gmail.co= m> wrote:


<= p style=3D"margin-right:0cm;margin-bottom:0cm;margin-left:36.0pt;margin-bot= tom:.0001pt;line-height:150%"> (8)In Sec. 4.1, under 1, please consider adding +6, +7, and +8,= =A0 and Reserve these for future use<= /u>

(9)In Sec. 4.1 und= er 2, please consider adding, +3, and Reserve it for future use=A0 <= u>

= [=C5=C7] For 8 &= amp; 9, my current thinking is that they are unnecessary. Tampering with th= e FEPO special values may result in non-interoperable implementations of Fo= rCES. Changes for these special values should be done within the ForCES wor= king group.

Why do you think this = is required? Anyone else=A2s thoughts on this?



Agree wit= h Evangelos.
There is no need to reserve fields for future = use. It will infact cause interop problems if someone
starts using those fields.


cheers,
jamal
--14dae9cdc48732c5c904db94b17b--