From nobody Wed Jul 2 11:05:47 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF50D1B29E9 for ; Wed, 2 Jul 2014 11:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFM-VZxrkyJW for ; Wed, 2 Jul 2014 11:05:33 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8DD1B29E7 for ; Wed, 2 Jul 2014 11:05:33 -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 s62I5V7w012508; Wed, 2 Jul 2014 19:05:31 +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 s62I5UnE012489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Jul 2014 19:05:30 +0100 From: "Adrian Farrel" To: Date: Wed, 2 Jul 2014 19:05:25 +0100 Message-ID: <0a1001cf9620$33ad50b0$9b07f210$@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: Ac+WIC+NgctoqaxBTW2bQjSn444tCA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20794.001 X-TM-AS-Result: No--26.036-10.0-31-10 X-imss-scan-details: No--26.036-10.0-31-10 X-TMASE-MatchedRID: rR9SQp8n2dzTTjedRTCyDbdQIb8hCnY+I6PHNDZGGCLIs4CjQ/C5uf4e 8umIMMidY6tUF3tJ1RNBeZNJBGEM9lskZx2Stg46MN+B8zdlz9Gl9VzHf0qr7iJ8zskw0dbrFa7 HRpE9gWKxrVX356MkGAaGcaqUPs8Mr7LFFxtr9IhwUSK4/EeOxcMdI0UcXEHzSYPLE090cxeYhU 445v2ulLgAPqrTc+P5fyCgxZlZbsmx1vEkhJiHSgbts0Qkqy4287QrIQgH3y3owlt7Drx92x/XW BLkU7fuJN3ib+XNKT3iUJeel9TKS1gYIP9YyXCk5CghTisABMxMkOX0UoduuVwpnAAvAwazVhbD EH23DRMgfgnqxlBKuWCS+T+rnjXjEwj5hG6tMXi8coKUcaOOvdAXIk/QdO2+iJ71fA8tGWgfaPW DgV0yC7TBKVBe5KYm4QB4EAEGilnPvAv72Y9dJQL09KI3I2DpeJ1OirYwzAOIZavNxxGy/rWd0n DAWA79M/Coz7HXXowRA4hwIn2MDY4a2rhHAtuZiguiJuCNURdPn74Ug5EKEB9Oluq8LbzVVNga6 wjBFwk58CIn96icLWqoLlDvcYgFBAmO2z/4/ahVTfJWlqPdDApqOIpWiKGpfVkB/cv6Ul22FQsf k4g6XBQymtwePitJ5p1ou6mrnDCN5oBdM0qZo2V4UKBJcRgN4dlbo9hMrkq/xUIBoV49VhTBD7O X80sLDj+HA95t/BYojHEz99zyfLyBncIOpDt8AoNa2r+Edw0R5c83KIxTTgkXZTx0qGb5p/BUr7 rsER2qm5CrLaryEzQ6ArclbrzVDTV5tLHupd2eAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0ePs 7A07QKmARN5PTKc Archived-At: http://mailarchive.ietf.org/arch/msg/forces/npaAPNjCeSMqFj1bK8XTgy5lW3I Cc: forces@ietf.org Subject: [forces] AD review of draft-ietf-forces-model-extension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 18:05:37 -0000 Hi Evangelos, Thanks for holding the pen on this. I have done my usual AD review. Normally the purpose of the review is to catch issues that might surface in IETF last call and IESG evaluation, but in this case I feel I am also reviewing in place of ForCES WG last call as there was complete silence from the WG at that time and, indeed, I rather feel that a number of the comments I make below should have been caught by an active and engaged working group. Although most of my comments are editorial in nature, many of them significantly impact on the utility and purpose of the document, so I believe they need to be addressed before the document can advance. So I've place the I-D in "Revised I-D state" and will wait to see a new version. Cheers, Adrian ==== Can you clarify for me whether, after the publication of this document as an RFC, the extensions it defines are part of the ForCES model. That is, if you were to implement ForCES from scratch after its publication, would you be expected to include these features? If the answer is "yes" then this probably updates 5812. If "no" then we need to work some language to explain that the extensions are options. I think, looking at, for example, Section 3.1, that this document is making specific changes to 5812 as well as potentially defining some additions. That means it really does update 5812. To handle this you need: - An "updates" tag in the metadata at the head of the file - To make the statement in the Abstract "This document updates RFC 5812 by defining foo..." - Add a section (probably Section 1.1 inside the Introduction) that is called "Updates to RFC 5812" and provides an overview of the changes and additions (you can use forward pointers into the rest of the document). --- The nits noted by the Shepherd in his write-up need to be fixed. --- Abstract RFC5812 has defined the ForCES Model provides a formal way Maybe RFC5812 has defined the ForCES Model that provides a formal way --- Abstract Please expand "FE" on first use. --- Section 1.2 I am not a not a fan of repeating material from other documents. At best it means that the reviewer has to cross-check to make sure you haven't introduced any inconsistencies. At worst it means that an update or fix to one document has to be reproduced in the other document. Since I doubt that it makes sense to read this document without a thorough understanding of 5812 I think you could replace this section with a simple set of pointers such as: This document uses the terminology defined in the ForCES Model in [RFC5812]. In particular, the reader is expected to be familiar with the following terms: - FE Model - LFB (Logical Functional Block) Class (or type) - LFB Instance - LFB Model - Element - Attribute - LFB Metadata - ForCES Component - LFB Class Library --- The RFC Editor will want to place the Introduction as Section 1 in this document. It would be good if you could make this change before the document reaches them so that you can fix any related issues that may arise. --- Please be sure to expand all abbreviations that are not shown as "well known" in the list at http://www.rfc-editor.org/rfc-style-guide/ abbrev.expansion.txt on first use in the main body of text. --- In the Introduction, you say... Additionally backward compatibility is ensured as xml libraries produced with the earlier schema are still valid with the new one. How will an old implementation in the field that uses the old schema react to an xml library produced with the new schema? --- Section 3 Is this a "proposal" or does the WG have consensus? --- Section 3.1 However there are cases where complex metadata are used in the datapath, for example two simple use cases can be seen in the OpenFlow switch 1.1 [OpenFlowSpec1.1] and beyond: 1. The Action Set metadata follows a packet inside the Flow Tables. The Action Set metadata is an array of actions to be performed at the end of the pipeline. 2. When a packet is received from a controller it may be accompanied by a list of actions to be performed on it prior to be sent on the flow table pipeline which is also an array. There are several issues with this text. a. Are you saying that the use case is "to be able to do what OpenFlow does"? Or is there some specific function that you need to be able to perform in the context of ForCES? b. "The Action Set metadata follows a packet inside the Flow Tables" is really hard to parse. It might, I suppose, make sense if I read the OpenFlow specification, but perhaps you could use just a few more words to explain what a Flow Table is, what a pipeline is, and what it means to "follow a packet". c. Isn't OpenFlow 1.1 rather an old version to be referencing? As you are making it a normative reference, it might be best to try to be up-to-date. d. I think s/prior to be sent/prior to being sent/ e. Probably s/flow table/Flow Table/ --- Figure 5 I think there are some indentation issues the fixing of which could make the schema fragment easier to read. --- Section 3.2 Additionally it appends to the declaration... What is "it"? --- Section 3.2 I think that I can work out what is meant to happen with Figure 5, but it would be cleaner if you gave the "before and after" fragments as you have done in the previous two cases. --- Section 3.2 Great and really helpful that you have provided an example in Figure 6, but you need to briefly note it somewhere in the text. --- Section 3.3 In the original schema, the access type can be only be defined on components of LFB and not on components in structs or arrays. s/be only/only/ s/LFB/an LFB/ --- Section 3.3 If by accident an access type for a component in a capability is defined, the access type MUST NOT be taken into account and MUST always be considered as read-only. It is polite of you, but "by accident" gives the impression that it can be done "on purpose" with a different result. I think you need: The access type for a component in a capability is always read-only per [RFC5812]. If an access type is provided for a component in a capability it MUST be ignored. --- Section 3.3 The example in Figure 9 helpfully shows the higher-level access type that applies to the whole struct as well as an example of the fine-grain access type applied to one of the components. However, the schema fragments in Figures 7 and 8 do not show the higher-level access type. I think it would be helpful if they did. As per Figure 6, it is great to have an example, but the text needs to make reference to it. --- Section 3.4 This event condition is particular useful s/particular/particularly/ --- Section 3.5 Experience however has proven valuable at least for debug reasons, to have statistics per LFB instance to monitor sent/received messages and errors for communication between CE and FE. That's a bit garbled. How about... Experience has shown that, at least for debug reasons, it would be useful to have statistics per LFB instance to monitor sent/received messages and errors in communication between CE and FE. --- Section 3.6 This document augments the derivedFrom part of the LFB class definition with a mandatory version attribute when the derivedFrom field is used. I don't see how this is backward compatible as described in the Introduction. There you say that XML libraries produced with the earlier schema are still valid with the new one. But this text and schema fragment seems to require that the version attribute is present which would mean that a user of the new schema would reject an older XML library. --- Section 3.6 Again, the example needs to be referred to from the text. --- Section 3.7 The following validation rules have been appended in the original schema in [RFC5812]: This is too ambiguous. In most sections when you use the past tense and refer to 5812 you are talking about stuff that is already in that RFC. However, if I take that interpretation of this text then this section is completely empty. So you must mean something else. --- Section 4 How am I supposed to read this section compared to Section 4.9 of 5812? There is no introductory text, and no explanation. I suspect that this is a complete replacement of Section 4.9 of 5812 in which case this document really does update 5812 in a fairly significant way. Or should you have incremented the model number? --- 6. IANA Considerations This specification requests that LFB Component ID 0 to be reserved. This statement is almost completely unhelpful to IANA! Which registry contains the LFB Component IDs? What information do you want IANA to record? Section 3.5 says both "reserve" which has specific meaning according to RFC 5226 and "for LFB properties" which seems to mean you want a specific assignment. Although Section 3.5 does talk about "disallowing" the value zero. Maybe you want a registry for Component ID values? Or maybe you are making a generic statement about the use of Component ID zero. In the former case you have some IANA work to do. In the latter case, you need to clarify the statement in 3.5 and change Section 6 to say that no IANA action is required. In the latter case, wouldn't this also be a good thing to capture in 3.7? --- Of course, what you say in Section 7 is true, but have you considered how the extensions in this document change the vulnerabilities described in 5812? I think a little text on each extension/change to say whether it increases or decreases the risks would be nice. --- Section 8.2 RFC 2119 should be a normative reference (or at least that is how you have used it in section 1.1). From nobody Thu Jul 3 06:34:04 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542251B29CB for ; Thu, 3 Jul 2014 06:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9erQcIsFArDj for ; Thu, 3 Jul 2014 06:34:02 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B840F1B29C4 for ; Thu, 3 Jul 2014 06:34:01 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so2318622wiv.10 for ; Thu, 03 Jul 2014 06:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=T8xYvkoJ3golCHvj78SlpIg0gg3VJfGf0P1P3ZCsa5Q=; b=b7lWKOrWqc8Rvgb/iofXOLSz2+dZvUaRu4dF5clrB2R3axh+IiyqCfZ38956TaFAkq sZyijM30Xk4C9wleVgCcBvDaI06IGhlAdhEs82WlmxDEypNg1+JLzzhqk6bzu11pep8C no5+czmYt+2NCLimlZqrExaWqZY161Kx6E/L5XCpLK41ZU1Gxble9WMqu/W4XZPAMq16 b1NTeuKvUEB/YvElHAgfOtmeMQ2AxOn53tLpHCDYwL5IYzCncj+rUPKxFN3Rc6dXSCt2 NGaUHJCk8U/If9If25DaBXMQxbj0wMfSnSP+91KtFc03WTVaiCdqlPDbmYky0Mzv7KgF yzwg== X-Received: by 10.194.109.170 with SMTP id ht10mr5191830wjb.72.1404394439993; Thu, 03 Jul 2014 06:33:59 -0700 (PDT) Received: from EhalepXPS (ppp079166067017.access.hol.gr. [79.166.67.17]) by mx.google.com with ESMTPSA id d12sm28552638wjx.0.2014.07.03.06.33.56 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Jul 2014 06:33:59 -0700 (PDT) From: "Haleplidis Evangelos" To: , References: <0a1001cf9620$33ad50b0$9b07f210$@olddog.co.uk> In-Reply-To: <0a1001cf9620$33ad50b0$9b07f210$@olddog.co.uk> Date: Thu, 3 Jul 2014 16:33:52 +0300 Message-ID: <000901cf96c3$70fe5920$52fb0b60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+WIC+NgctoqaxBTW2bQjSn444tCAAlYsjA Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/forces/uAbmEkThu8RfSENwSpgObPDa83Y Cc: forces@ietf.org Subject: Re: [forces] AD review of draft-ietf-forces-model-extension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 13:34:04 -0000 Greetings Adrian, Thank you very much for the review. Please see inline. I have snipped out all your questions that I agree = and would have answered with simply ok. I'll try to have it completed by tomorrow before the cut-off date. Regards, Evangelos Haleplidis. > Can you clarify for me whether, after the publication of this document > as an RFC, the extensions it defines are part of the ForCES model. = That > is, if you were to implement ForCES from scratch after its = publication, > would you be expected to include these features? >=20 > If the answer is "yes" then this probably updates 5812. If "no" then = we > need to work some language to explain that the extensions are options. >=20 > I think, looking at, for example, Section 3.1, that this document is > making specific changes to 5812 as well as potentially defining some > additions. That means it really does update 5812. >=20 > To handle this you need: > - An "updates" tag in the metadata at the head of the file > - To make the statement in the Abstract "This document updates RFC = 5812 > by defining foo..." > - Add a section (probably Section 1.1 inside the Introduction) that is > called "Updates to RFC 5812" and provides an overview of the changes > and additions (you can use forward pointers into the rest of the > document). >=20 [=C5=C7] The extensions are optional (will even change the version = attribute as such) thus it makes no reason for someone to implement them. If I implemented ForCES from scratch it would be useful to include these = features but not necessary. The goal was to be backwards compatible. However I agree with your assessment and also consider it is an update, there are a couple of features, like the new event description, default values and complex metadata, that I consider very useful. > In the Introduction, you say... >=20 > Additionally backward > compatibility is ensured as xml libraries produced with the earlier > schema are still valid with the new one. >=20 > How will an old implementation in the field that uses the old schema > react to an xml library produced with the new schema? >=20 > --- [=C5=C7] Assuming that the xml library produced uses none of the new = optional extensions, then there should be no issues. However if they use even = one, then an old implementation will not be able to understand the new xml library (at least the new parts). >=20 > Section 3 > Is this a "proposal" or does the WG have consensus? >=20 > --- [=C5=C7] It has WG consensus. Will remove the "proposal". >=20 > Section 3.1 >=20 > However there are cases where complex metadata are used in the > datapath, for example two simple use cases can be seen in the > OpenFlow switch 1.1 [OpenFlowSpec1.1] and beyond: >=20 > 1. The Action Set metadata follows a packet inside the Flow = Tables. > The Action Set metadata is an array of actions to be performed > at > the end of the pipeline. >=20 > 2. When a packet is received from a controller it may be > accompanied > by a list of actions to be performed on it prior to be sent on > the flow table pipeline which is also an array. >=20 > There are several issues with this text. >=20 > a. Are you saying that the use case is "to be able to do what OpenFlow > does"? Or is there some specific function that you need to be able > to > perform in the context of ForCES? [=C5=C7] No. These uses cases simply highlight the need for the complex metadata. For example, when we attempted to do an OF library using ForCES (http://tools.ietf.org/html/draft-haleplidis-forces-openflow-lib-03 - to which we need to allocate some time and update) we found that the use of these kinds of metadata are needed. >=20 > b. "The Action Set metadata follows a packet inside the Flow Tables" = is > really hard to parse. It might, I suppose, make sense if I read the > OpenFlow specification, but perhaps you could use just a few more > words to explain what a Flow Table is, what a pipeline is, and what > it means to "follow a packet". [=C5=C7] Thank you for this. Changed to: "The Action Set metadata is an = array of actions descriptors, which traverses the processing pipeline along with = the packet data." While descriptive it also removes the need to add more = info irrelevant to this document. >=20 > c. Isn't OpenFlow 1.1 rather an old version to be referencing? As you > are making it a normative reference, it might be best to try to be > up-to-date. >=20 [=C5=C7] Also, I'm moving the OF 1.1 into an informative reference. This = is an example use case. There is no reason for this be a normative reference. = In addition, OF1.1 first introduced the Action Sets, and that's the reason = for mentioning it, as well no changes in the action set has occurred since = that would invalidate the use case. That is the reason for the wording: = "OF1.1 and beyond" > Section 3.2 >=20 > Additionally it appends to the declaration... >=20 > What is "it"? >=20 > --- [=C5=C7] Thank you for this. "IT" is the specific extension >=20 > Section 3.6 >=20 > This document augments the derivedFrom part of the LFB class > definition with a mandatory version attribute when the derivedFrom > field is used. >=20 > I don't see how this is backward compatible as described in the > Introduction. There you say that XML libraries produced with the > earlier schema are still valid with the new one. But this text and > schema fragment seems to require that the version attribute is present > which would mean that a user of the new schema would reject an older > XML library. >=20 [=C5=C7] Thank you for this. You have a very valid point. In order to = address the issue, and still retain backwards compatibility we should probably = make the version attribute optional. That however does not resolve the issue = that Jamal pointed out. However we will include something along the following lines: "If the version attribute is not included then it is assumed that the version imported is always 1.0". This clearly solves the issue and retains compatibility. > Section 3.7 >=20 > The following validation rules have been appended in the original > schema in [RFC5812]: >=20 > This is too ambiguous. In most sections when you use the past tense = and > refer to 5812 you are talking about stuff that is already in that RFC. > However, if I take that interpretation of this text then this section > is completely empty. So you must mean something else. >=20 > --- [=C5=C7] The original schema in RFC5812 contains some validation rules. = We have introduced several new to validate the schema against more rules. Would = the following change be more accurate?: "In the new schema, we have introduced the following validation rules = that did not exist in original schema in [RFC5812]" >=20 > Section 4 >=20 > How am I supposed to read this section compared to Section 4.9 of = 5812? > There is no introductory text, and no explanation. >=20 > I suspect that this is a complete replacement of Section 4.9 of 5812 = in > which case this document really does update 5812 in a fairly > significant way. >=20 > Or should you have incremented the model number? [=C5=C7] We will increase the model number. >=20 > --- >=20 > 6. IANA Considerations >=20 > This specification requests that LFB Component ID 0 to be reserved. >=20 > This statement is almost completely unhelpful to IANA! >=20 > Which registry contains the LFB Component IDs? > What information do you want IANA to record? >=20 > Section 3.5 says both "reserve" which has specific meaning according = to > RFC 5226 and "for LFB properties" which seems to mean you want a > specific assignment. Although Section 3.5 does talk about = "disallowing" > the value zero. >=20 > Maybe you want a registry for Component ID values? Or maybe you are > making a generic statement about the use of Component ID zero. In the > former case you have some IANA work to do. In the latter case, you = need > to clarify the statement in 3.5 and change Section 6 to say that no > IANA action is required. >=20 > In the latter case, wouldn't this also be a good thing to capture in > 3.7? >=20 [EH] Thank you for this. We definitely don't need a registry for = Component ID values. We are making a specific statement that Component ID zero = MUST NOT be used.=20 I'm not certain, but I think that that does not constitutes an IANA considerations. I'll remove it from section 6. I will also try to see if = I can capture it in 3.7. > --- >=20 > Of course, what you say in Section 7 is true, but have you considered > how the extensions in this document change the vulnerabilities > described in 5812? I think a little text on each extension/change to > say whether it increases or decreases the risks would be nice. >=20 > --- [EH] I'm a little confused.=20 The changes have no effect on security, they are simply constructs to = write XML library definitions. They have no effect on security semantics with = the protocol, thus they do not affect security issues as it the case = described in 5812.=20 If that is satisfactory, I'll write that down in the security considerations. From nobody Thu Jul 3 16:22:21 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEA91B2ABA for ; Thu, 3 Jul 2014 16:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dU5qUDmtpLeh for ; Thu, 3 Jul 2014 16:22:15 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9B831B29CF for ; Thu, 3 Jul 2014 16:22:15 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db11so941547veb.40 for ; Thu, 03 Jul 2014 16:22:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=sR5Tnu1CFFPX2hluxRpkAKu4euSmNGXJjsQMDXVj9PE=; b=cEqe8/HTtvidtvWTxDi+2QLp85hMHy704NOFSBm3FuKT7NXkjz72vyAKb5b6RE8yXF hIASxZAjDm+XqqVXBupS8MFU56uM2i1sRj67tUj4LGhpV//4SkGFXkvisQhKEYsJ0SOh FHFpemk5ySfeJP1GBTJ4136jLGxI4BQd54ydBkAJcHjVF8iorUM36NSquJVSz4LF4kwj bwX7toyoaRXIKvFB/8XttqoF+dWGQIszdPf9/Jb0V75X3YtQGCyAiQUWUbEAEqfafE66 gdQbOHChZqkP9BzNcaspK/V8EfxsXJVxgCwVpECUTgOyl0CPEnyTuCuqndzAJiz7BcPN QCCg== X-Gm-Message-State: ALoCoQkOfeaMt7wY10pWWuBz7M4V6YxA8WNmM7B/Q+0C8MUYrrg0wzwKFJtUMF8lf5eepee8dDnZ X-Received: by 10.220.249.6 with SMTP id mi6mr79179vcb.33.1404429734911; Thu, 03 Jul 2014 16:22:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Thu, 3 Jul 2014 16:21:54 -0700 (PDT) In-Reply-To: <20140703231355.8939.25027.idtracker@ietfa.amsl.com> References: <20140703231355.8939.25027.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Thu, 3 Jul 2014 19:21:54 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/zJF2hZalepzJ4uFwHyA8NY7Lnn4 Subject: [forces] Fwd: New Version Notification for draft-joachimpillai-forces-interfelfb-04.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 23:22:17 -0000 ---------- Forwarded message ---------- From: Date: Thu, Jul 3, 2014 at 7:13 PM Subject: New Version Notification for draft-joachimpillai-forces-interfelfb-04.txt To: "Damascane M. Joachimpillai" , Jamal Hadi Salim A new version of I-D, draft-joachimpillai-forces-interfelfb-04.txt has been successfully submitted by Jamal Hadi Salim and posted to the IETF repository. Name: draft-joachimpillai-forces-interfelfb Revision: 04 Title: ForCES Inter-FE LFB Document date: 2014-07-03 Group: Individual Submission Pages: 21 URL: http://www.ietf.org/internet-drafts/draft-joachimpillai-forces-interfelfb-04.txt Status: https://datatracker.ietf.org/doc/draft-joachimpillai-forces-interfelfb/ Htmlized: http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-joachimpillai-forces-interfelfb-04 Abstract: Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model which provides a formal way to represent the capabilities, state, and configuration of forwarding elements(FEs) within the context of the ForCES protocol. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. The control elements (CEs) can control the FEs using the ForCES model definition. The ForCES WG charter has been extended to allow the LFB topology to be across FEs. This documents describes a non-intrusive way to extend the LFB topology across FEs. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Jul 3 16:28:20 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953271B2A4B for ; Thu, 3 Jul 2014 16:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lix8y-sZmSru for ; Thu, 3 Jul 2014 16:28:16 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63FA1B2A13 for ; Thu, 3 Jul 2014 16:28:15 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id oy12so958428veb.13 for ; Thu, 03 Jul 2014 16:28:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=aVJaEy0wzlXtueEZ0UoOADO3JvKw4kY47JKIYysfYow=; b=MwW2D6/n8rMt727Vhdq0leCTxXkGr5F+tGpOLAeX6+KZEcdKH+1/IAevugFJTIijIS VetNelkOQeccGGTok44kaSCQodiTcWcO3rXLYoikFVlOJS5o6SlwXa6W+lSktsv30WWa L2Frava0fPRlRIr9/wZZSRPc8peqTJiVuZjdWOTfbxu0kEfNjRR+8L3P0A1S60iGJTXn HvE1Nr1eEh7sWAKF+w3nVvgGn1PW1XG5zGyzDIBzG9fbgfA7DtF/Kd4GcGAl4ziCfVcq +5c8QSo6vmFOinAGE0QsLDE0QRwukCIETZqkBYn7B1XWZvnbzygxxkrTF1RSdBuP7lPN JKBA== X-Gm-Message-State: ALoCoQm5UKRK22FPPWgDw0/pZTYwt0ivH42IM2BuHFM2dNT91pUMKAaGyt3KpdXT75MURtet1DmC X-Received: by 10.58.198.67 with SMTP id ja3mr6458873vec.10.1404430094831; Thu, 03 Jul 2014 16:28:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Thu, 3 Jul 2014 16:27:54 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 3 Jul 2014 19:27:54 -0400 Message-ID: To: Adrian Farrel Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/qVT21XhU2oth5BIbfi7NylzKKo0 Cc: draft-ietf-forces-model-extension.all@tools.ietf.org, "forces@ietf.org" Subject: [forces] Protocol draft WAS (Re: AD review of draft-ietf-forces-model-extension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 23:28:17 -0000 Adrian, Thanks for the thorough review (as always). One question on one of your comments below applies to the protocol draft. The protocol draft WG LC just expired. I believe we need to use the update metadata for the protocol draft. There are also a couple of nits. It may make sense to make another release before shepherding starts. If we do that, would we need to redo the WG last call? cheers, jamal On Wed, Jul 2, 2014 at 2:05 PM, Adrian Farrel wrote: > Can you clarify for me whether, after the publication of this document > as an RFC, the extensions it defines are part of the ForCES model. That > is, if you were to implement ForCES from scratch after its publication, > would you be expected to include these features? > > If the answer is "yes" then this probably updates 5812. If "no" then we > need to work some language to explain that the extensions are options. > > I think, looking at, for example, Section 3.1, that this document is > making specific changes to 5812 as well as potentially defining some > additions. That means it really does update 5812. > > To handle this you need: > - An "updates" tag in the metadata at the head of the file > - To make the statement in the Abstract "This document updates RFC 5812 > by defining foo..." > - Add a section (probably Section 1.1 inside the Introduction) that is > called "Updates to RFC 5812" and provides an overview of the changes > and additions (you can use forward pointers into the rest of the > document). > From nobody Fri Jul 4 04:49:58 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218AE1B2840 for ; Fri, 4 Jul 2014 04:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJbILkIbYyZS for ; Fri, 4 Jul 2014 04:49:55 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E50A1B2858 for ; Fri, 4 Jul 2014 04:49:55 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id im17so1468953vcb.39 for ; Fri, 04 Jul 2014 04:49:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W1Ab43o1lL7GYs1JWWPQlPIkp12QLEQPS38r5Wu/WTg=; b=Q/QoH70H4lsfQE0RbTbE1ftJ+M+WmFN19eyLovZJay8epIxZch0gcik3Y8JiRxztiA I0/2OKuPRJb0GC8buzizWc9PXecrgG4tc2zAwZrzc+1tAwpZN2iY95y0xUZ1GAiMLuwy pPCAwun+7GNxPZIDmwIU3Z2Rc5pINYwRw8d7g5fiIPiXg7jyDXnNYM4m2O2l5q4MEpjJ vnzWNh/hbJLyHwPhAdiAGGHozWslq6/rD4KVda+Ddo4T0tyaC+5s/Aaq/OQZ1T9J/f5l oTYH0ivdk0deMUHGDOROE6eThD1vYir42fbPMXUGWTAjdqzKdcawpePc1FRmtsgc0gJ3 mnbg== X-Gm-Message-State: ALoCoQkHMqogixARsDe5w1KC2yOSgyT9wKLB4KVfLgOcVJ+9GQ2F6xMzm02bQuqmAAWNPHJW2Qe/ X-Received: by 10.58.29.164 with SMTP id l4mr9355175veh.8.1404474594340; Fri, 04 Jul 2014 04:49:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Fri, 4 Jul 2014 04:49:34 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Fri, 4 Jul 2014 07:49:34 -0400 Message-ID: To: Adrian Farrel Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/YCSzHyXKPj5WJ2dGSbutIETyFD0 Cc: draft-ietf-forces-model-extension.all@tools.ietf.org, "forces@ietf.org" Subject: Re: [forces] Protocol draft WAS (Re: AD review of draft-ietf-forces-model-extension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 11:49:57 -0000 I know it is holidays at the moment. I will upload a new version with the fixes now to beat the draft deadline and then await your responses. cheers, jamal On Thu, Jul 3, 2014 at 7:27 PM, Jamal Hadi Salim wrote: > Adrian, > > Thanks for the thorough review (as always). > One question on one of your comments below applies to the protocol > draft. The protocol draft WG LC just expired. > I believe we need to use the update metadata for the protocol draft. > There are also a couple of nits. It may make sense to make another release > before shepherding starts. > If we do that, would we need to redo the WG last call? > > cheers, > jamal > > On Wed, Jul 2, 2014 at 2:05 PM, Adrian Farrel wrote: > > >> Can you clarify for me whether, after the publication of this document >> as an RFC, the extensions it defines are part of the ForCES model. That >> is, if you were to implement ForCES from scratch after its publication, >> would you be expected to include these features? >> >> If the answer is "yes" then this probably updates 5812. If "no" then we >> need to work some language to explain that the extensions are options. >> >> I think, looking at, for example, Section 3.1, that this document is >> making specific changes to 5812 as well as potentially defining some >> additions. That means it really does update 5812. >> >> To handle this you need: >> - An "updates" tag in the metadata at the head of the file >> - To make the statement in the Abstract "This document updates RFC 5812 >> by defining foo..." >> - Add a section (probably Section 1.1 inside the Introduction) that is >> called "Updates to RFC 5812" and provides an overview of the changes >> and additions (you can use forward pointers into the rest of the >> document). >> > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From nobody Fri Jul 4 04:51:53 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABC41B288C; Fri, 4 Jul 2014 04:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xn-z-jUqOA4z; Fri, 4 Jul 2014 04:51:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7851B283B; Fri, 4 Jul 2014 04:51:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704115150.3914.91895.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 04:51:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/tkeFfMWuWGWvW0pulKlTq4hGBkg Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-protoextension-03.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 11:51:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Protocol Extensions Author : Jamal Hadi Salim Filename : draft-ietf-forces-protoextension-03.txt Pages : 23 Date : 2014-07-04 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 documents updates both RFC 5810 and RFC 7121. semantics to achieve that end goal. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-protoextension/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-protoextension-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-protoextension-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 15:57:54 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02091A0282; Fri, 4 Jul 2014 15:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzzhwMFi-ml7; Fri, 4 Jul 2014 15:57:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0791A026C; Fri, 4 Jul 2014 15:57:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704225742.15961.25950.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 15:57:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/Ozi3bVPyh-2bR_pZu_wDQaHGM3w Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-model-extension-03.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 22:57:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Model Extension Author : Evangelos Haleplidis Filename : draft-ietf-forces-model-extension-03.txt Pages : 29 Date : 2014-07-04 Abstract: Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model that provides a formal way to represent the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in a forwarding element (FE), what capabilities these functions support, and how these functions are or can be interconnected. RFC5812 has been around for two years and experience in its use has shown room for small extensions without a need to alter the protocol while retaining backward compatibility with older xml libraries. This document update RFC5812 and extends the model to allow complex datatypes for metadata, optional default values for datatypes, optional access types for structures and fixes an issue with LFB inheritance. The document also introduces two new features a new event condition BecomesEqualTo and LFB properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-model-extension/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-model-extension-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-model-extension-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 7 04:06:14 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D5F1B281E for ; Mon, 7 Jul 2014 04:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAOZ2xLmx3Z6 for ; Mon, 7 Jul 2014 04:06:11 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840381B2819 for ; Mon, 7 Jul 2014 04:06:11 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so6640357wiv.8 for ; Mon, 07 Jul 2014 04:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=Bqfu+BLOQ/EBWvIeAbIoMKf3bFDGE+qxwsuR8XeWZus=; b=HzCQy1fYqkJoga8cWXI69Y4FgbURRDdM6TC6sdrJiMYPBAapVGTUEqIqgLG95bYX1g tVT1MZrkvq84Pynn42CKnfCt56/JbX6wUcVvGS9wKKWtzlFWB8CvPIuZyvcb9Sd6aNOG UX7tUOEPNbPVNvJimqToHqEaH3h6nY9n8d0NHCURQcDTApUB8eVNURCOGrhdFu4cXx1G qOKCiUsXRbHKqM0E7indYG1L/uQhny1JMnzCWNPzsNmYxHnrSV7e8CoW7GM4mN9P3nBa 37HcXbkneVjZz5FBs4FqyFKiaCv7DEW/YhPeI71KDld4B1xrRbOXPXTA2zTH3wluOow1 OBtw== X-Received: by 10.180.36.225 with SMTP id t1mr36921246wij.38.1404731170110; Mon, 07 Jul 2014 04:06:10 -0700 (PDT) Received: from EhalepXPS (ppp079166079151.access.hol.gr. [79.166.79.151]) by mx.google.com with ESMTPSA id 20sm86908409wjt.42.2014.07.07.04.06.08 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Jul 2014 04:06:09 -0700 (PDT) From: "Haleplidis Evangelos" To: , Date: Mon, 7 Jul 2014 14:06:05 +0300 Message-ID: <00c801cf99d3$73968ff0$5ac3afd0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C9_01CF99EC.98E3C7F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+Z03ImNRlmbhYhQFW235Mk+uZ0Hg== Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/forces/XpNToqmtj8jmeAZyDWWLYN_HrJk Subject: [forces] Shepherding protocol extension draft X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 11:06:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C9_01CF99EC.98E3C7F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings Jamal, I am going to begin the shepherding process for the protocol extension draft. To start, I'll need to check if anyone has knowledge of any applicable IPR that has not been declared for this draft. Please respond to this email whether or not you are aware of any relevant IPR. If you are on the ForCES WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Regards, Evangelos Haleplidis. ------=_NextPart_000_00C9_01CF99EC.98E3C7F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings Jamal,

 

I am going to begin the = shepherding process for the protocol extension = draft.

 

To start, I’ll need to check if anyone has knowledge = of any applicable IPR that has not been declared for this = draft.

Please respond to this email whether or not you are aware = of any relevant IPR.

 

If you are on the ForCES WG email list but are not listed = as an author or contributor, then please explicitly respond only if you = are aware of any IPR that has not yet been disclosed in conformance with = IETF rules.

 

Regards,

Evangelos Haleplidis.

 

------=_NextPart_000_00C9_01CF99EC.98E3C7F0-- From nobody Mon Jul 7 05:23:38 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E9F1B283A for ; Mon, 7 Jul 2014 05:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvX8ov-KGPTm for ; Mon, 7 Jul 2014 05:23:36 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045741B282C for ; Mon, 7 Jul 2014 05:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=damascene.joachimpillai@verizon.com; q=dns/txt; s=corp; t=1404735816; x=1436271816; h=from:to:date:subject:message-id:mime-version; bh=qEjvyjgx3eRzUnNyKwoFjjC4M13HtrkFQpOp09UjVF0=; b=HIfGRpv++DFwS6Nv4FkNw+FvDLy3gqfAc5iZTdypsJlXiVrnGQUIHf0k /+I80ot/w5neAGGZyPZ8JR8ku/Llm7tt5mHW8CeysuT6xaqRYw0h/FetP 3921Ea0Ioo+2tIkUDhdKjRd3Wvy4XfXNKWMqFEv63tRHDXLkJjIS13Xv3 0=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe03.verizonbusiness.com with ESMTP; 07 Jul 2014 12:23:34 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="5.01,617,1400025600"; d="scan'208,217";a="793053820" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 07 Jul 2014 12:23:30 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Mon, 7 Jul 2014 08:23:20 -0400 To: "'forces@ietf.org'" Date: Mon, 7 Jul 2014 08:23:20 -0400 Thread-Topic: Call for Presentation at the IETF 90 Thread-Index: Ac+Z3cBLC13W7ranQoyTEIDpLQDsyw== Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0139EE8906@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB0139EE8906FHDP1LUMXC7V3_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/ySGtCXPEGD7jPZBcbtJ4o0DH00U Subject: [forces] Call for Presentation at the IETF 90 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 12:23:37 -0000 --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB0139EE8906FHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would like to see if anyone is interested in presenting at the upcoming I= ETF 90. If so please drop Jamal and I a small note on the topic. The meetin= g is scheduled for Monday July 21st 15:20 in Manitoba Room. Thanks, DJ --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB0139EE8906FHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I would li= ke to see if anyone is interested in presenting at the upcoming IETF 90. If= so please drop Jamal and I a small note on the topic. The meeting is sched= uled for Monday July 21st 15:20 in Manitoba Room.

 

Thanks,

DJ

= --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB0139EE8906FHDP1LUMXC7V3_-- From nobody Mon Jul 7 08:52:05 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33F81A0015 for ; Mon, 7 Jul 2014 08:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 248RUQ895-ne for ; Mon, 7 Jul 2014 08:52:02 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F781A0166 for ; Mon, 7 Jul 2014 08:52:02 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id jx11so4237934veb.20 for ; Mon, 07 Jul 2014 08:52:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=4mmIjohLnLWnIz21HUFJtIWpOapn78Q6JlfiAYFbuYw=; b=em0CzOTlZfD+YTQpCX+4hfZ/B5OjEv47oQVEqUt5D8zefGlyhnRAZjbIbdvDLKJZd1 yV4HI32Fu5+CufiIcNJW2JYeKCFoS4UwY+jcfZmqZSHMFI+SlQoV9PpO+0GNOYQrM+ES rHqhlOZqovPVnxpc54FCqOR80UwF3noqxfYKFNVyS79i6PdK9hBaqF66A1SGDGoqDvKI 7mfhr+rnFzeBWXoJvc/Rq4ksGbhYT+6chmyOI/aJKf4ZofuJUEoh04rw4dg52lGd7FWC KMij9Ofqmw2HgqIcbbecdYdexgXA/WvAaRVHZNWrRTKzbcc3IedMBjuoatcRFX4NBSce W5xw== X-Gm-Message-State: ALoCoQlLvBwAuvjL3Erh1S41fXrq1i7f7YGo1u67acOEOB1ScCznIQYUJf4BeEdSVRsszzZ18k1w X-Received: by 10.52.119.196 with SMTP id kw4mr916482vdb.75.1404748321649; Mon, 07 Jul 2014 08:52:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Mon, 7 Jul 2014 08:51:41 -0700 (PDT) In-Reply-To: <00c801cf99d3$73968ff0$5ac3afd0$@com> References: <00c801cf99d3$73968ff0$5ac3afd0$@com> From: Jamal Hadi Salim Date: Mon, 7 Jul 2014 11:51:41 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/forces/yC41HKVP8Z0dGh7M4mhhEU6lktc Cc: "forces@ietf.org" , draft-ietf-forces-protoextension@tools.ietf.org Subject: Re: [forces] Shepherding protocol extension draft X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 15:52:04 -0000 Greetings Evangelos, To the best of my knowledge there is no known IPR against this document. cheers, jamal On Mon, Jul 7, 2014 at 7:06 AM, Haleplidis Evangelos wro= te: > Greetings Jamal, > > > I am going to begin the shepherding process for the protocol extension > draft. > > > To start, I=E2=80=99ll need to check if anyone has knowledge of any appli= cable IPR > that has not been declared for this draft. > > Please respond to this email whether or not you are aware of any relevant > IPR. > > > If you are on the ForCES WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any = IPR > that has not yet been disclosed in conformance with IETF rules. > > > > Regards, > > Evangelos Haleplidis. > > > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From nobody Mon Jul 7 13:16:36 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB5F1A0515 for ; Mon, 7 Jul 2014 13:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKtYB-VzMVYs for ; Mon, 7 Jul 2014 13:12:53 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251C61B28FC for ; Mon, 7 Jul 2014 13:11:46 -0700 (PDT) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s67K9GLU032491; Mon, 7 Jul 2014 13:11:45 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1myy3sg4gq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 07 Jul 2014 13:11:45 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Jul 2014 13:11:44 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Mon, 7 Jul 2014 13:11:44 -0700 From: ramki Krishnan To: "forces@ietf.org" Date: Mon, 7 Jul 2014 13:11:43 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+aHtco6CSCRSj9SQmnsz9pyqRybAAAHPhgAAAG3VAAAAZV0A== Message-ID: 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_C7634EB63EFD984A978DFB46EA5174F2C14FDB858BHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-07_03:2014-07-07,2014-07-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407070211 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/4NC4cOfs3zrP1dsq_JzTn1JXu-8 X-Mailman-Approved-At: Mon, 07 Jul 2014 13:16:32 -0700 Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: [forces] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 20:12:55 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB858BHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Overview of proposed IRTF Network Functions Virtualization Research Group (= NFVRG) Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services = that utilize a virtualized infrastructure. Network functions that are tradi= tionally implemented in dedicated hardware appliances will need to be decom= posed and executed in virtual machines running in data centers. One key goa= l of this new area is to reduce capital and operating expenditures for futu= re deployments for networks and associated services. Another important goal= is for the network operators to be able to offer value added cloud service= s to their customers. Finally, new business models will open for the provis= ion of network services. The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network fun= ctions. The Network Functions Virtualization Research Group (NFVRG) will br= ing together researchers and grow the community around the world in both ac= ademia and industry to explore this new research area through workshops, re= search group meetings etc. at premier conferences such as IEEE ICC, IEEE Gl= obecom and inviting special issues in well-known journals. Some of the key = topics of research include virtualization of fixed and mobile network infra= structures, new network architectures based on virtualized network function= s, virtualization of the home and enterprise network environments, co-exist= ence with non-virtualized infrastructure and services, and application to g= rowing areas of concern such as Internet of Things (IoT) and next generatio= n content distribution. The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful input= to other related standards efforts in ETSI or other standards bodies. More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/w= iki/nfvrg First face-to-face Meeting in Toronto The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would rea= lly appreciate active discussions in the mailing list nfvrg@irtf.org. Thanks, Ramki on behalf of the NFVRG co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB858BHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Overview of proposed IRTF Network Functions Virtualiz= ation Research Group (NFVRG)

 

Network Function Virtualization (NFV) is a key emerging = area for network operators, hardware and software vendors, cloud service pr= oviders, and in general network practitioners and researchers. This area re= quires exploring new directions and working collaboratively on how to creat= e network services that utilize a virtualized infrastructure. Network funct= ions that are traditionally implemented in dedicated hardware appliances wi= ll need to be decomposed and executed in virtual machines running in data c= enters. One key goal of this new area is to reduce capital and operating ex= penditures for future deployments for networks and associated services. Ano= ther important goal is for the network operators to be able to offer value = added cloud services to their customers. Finally, new business models will = open for the provision of network services.

 

The technologies enabling the= virtualization of network functions are currently in an early stage of, an= d they need researchers to develop new architectures, systems, and software= , and to explore tradeoffs and possibilities for leveraging virtualized inf= rastructure to provide support for network functions. The Network Functions= Virtualization Research Group (NFVRG) will bring together researchers and = grow the community around the world in both academia and industry to explor= e this new research area through workshops, research group meetings etc. at= premier conferences such as IEEE ICC, IEEE Globecom and inviting special i= ssues in well-known journals. Some of the key topics of research include vi= rtualization of fixed and mobile network infrastructures, new network archi= tectures based on virtualized network functions, virtualization of the home= and enterprise network environments, co-existence with non-virtualized inf= rastructure and services, and application to growing areas of concern such = as Internet of Things (IoT) and next generation content distribution.<= /o:p>

 

The= NFVRG will focus on research problems associated with these topics and on = bringing a research community together that can jointly address such proble= ms, concentrating on problems that relate not just to networking but also t= o computing and storage constraints in such environments. It is also hoped = that the outcome of the research will benefit standardization efforts that = can get spawned via IRTF & IETF BoF meetings and/or provide useful inpu= t to other related standards efforts in ETSI or other standards bodies.

 

M= ore details can be found at - http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg<= /a>

 

First face-to-face Meeting in Tor= onto

 

The fi= rst face-to-face meeting of the proposed NFVRG will be held along with the = IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm in th= e Canadian (C) Room (immediately after the SFC meeting). Please let us know= if you have research topics to present during the meeting. Would really ap= preciate active discussions in the mailing list nfvrg@irtf.org.

 

Thanks,

Ram= ki on behalf of the NFVRG co-chairs

= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB858BHQ1EXCH01corp_-- From nobody Mon Jul 7 15:04:30 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3E41B296F for ; Mon, 7 Jul 2014 15:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO1odq2Z8JqS for ; Mon, 7 Jul 2014 15:04:18 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07E31B296E for ; Mon, 7 Jul 2014 15:04:17 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so3965086wgg.21 for ; Mon, 07 Jul 2014 15:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=paxjomEmlMoSFwN6iSVCry3eUvDYwcTEX9qTP2ppnho=; b=sAym5xu+RCZSfoNW0GCczPBz+UQdp+FzDID20+jLdRirwo9TGtx0YRqiQdLkcqyBwV EEEGpz3AM+K21Ds9panMahJoosfOV1xbveDZPegk8Eq0GaDq6Z9+UBYJABVnoBAs2vK1 9MgbA3ioiI/VNMvuy/xUgirWeeo0HPxcbOwoEOkCWh/g3XRf0ARU+5aTZ9ENPswOwvhD vWfqnM/vDfWKTsfmyk+Zuv0xVn4xQESIo1eGP/WwEVvEMMqYkgX7wzgEKfHSfFGOO64+ tjNh/FQSR+wehnnoWo0zb4rhpxv8EaR47vrZOfaDPfiTKXmVRslfqS2jZsBK7y9gZED4 aDRg== X-Received: by 10.180.221.196 with SMTP id qg4mr39970699wic.66.1404770655901; Mon, 07 Jul 2014 15:04:15 -0700 (PDT) Received: from EhalepXPS (ppp079166079151.access.hol.gr. [79.166.79.151]) by mx.google.com with ESMTPSA id 10sm55012200wjr.22.2014.07.07.15.04.13 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Jul 2014 15:04:14 -0700 (PDT) From: "Haleplidis Evangelos" To: , , "'Adrian Farrel'" References: <00c801cf99d3$73968ff0$5ac3afd0$@com> In-Reply-To: <00c801cf99d3$73968ff0$5ac3afd0$@com> Date: Tue, 8 Jul 2014 01:04:09 +0300 Message-ID: <009001cf9a2f$6222ec30$2668c490$@com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0091_01CF9A48.87702430" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+Z03ImNRlmbhYhQFW235Mk+uZ0HgAWz7Og Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/forces/7utYU54Lh6ZnQ9-YhOJcox4Bll8 Subject: [forces] draft-ietf-forces-protoextension: Publication process started X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:04:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0091_01CF9A48.87702430 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0092_01CF9A48.87702430" ------=_NextPart_001_0092_01CF9A48.87702430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings to the list, Attached is the shepherd write-up for the draft-ietf-forces-protoextension With regards, Evangelos Haleplidis. ------=_NextPart_001_0092_01CF9A48.87702430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings to the = list,

 

Attached is = the shepherd write-up for the = draft-ietf-forces-protoextension


With = regards,

Evangelos = Haleplidis.

------=_NextPart_001_0092_01CF9A48.87702430-- ------=_NextPart_000_0091_01CF9A48.87702430 Content-Type: text/plain; name="writeup-protocol-extension.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="writeup-protocol-extension.txt" 1. Summary The document shepherd is Evangelos Haleplidis The responsible Area Director is Adrian Farrel This document extends the ForCES protocol document (RFC 5810) to allow table ranges for operations, introduces additional error codes, adds a new TLV for extended replies and clarifies how a message is = handled when that does not fit within a single protocol message. 2. Review and Consensus The extensions are straightforward, and there was no difficulty in = coming=20 to consensus on all points described. There were suggested extensions = for earlier versions of the document that were not included based on = discussions=20 in the WG for the sake of simplicity. At least one implementation has=20 validated some of the features described in the document. =20 We believe the working group is solidly behind this document.=20 3. Intellectual Property The author has confirmed conformance with BCP 78/79.=20 There are no IPR disclosures on the document. 4. Other Points a) There a number of spelling errors. Please use = https://tools.ietf.org/tools/idspell/webservice to fix. b) This document updates RFC5810.=20 1. Please write in the abstract also how it updates it. 2. Please specify in the introduction as well that this document updates = RFC5810.=20 Right now it reads that "this document describes a few extensions to the = ForCES Protocol". c) Similar to the Adrian's comments on the model extension draft: 1. Please put the introduction in section 1. 2. Please don't repeat material from RFC5810. Specify that you're using = terminology from RFC5810 and specify which terms=20 (in a bullet format without any content) that the reader should be = familiar with d) This document says that it updates RFC7121.=20 However the only change for RFC7121 is the FEPO LFB which change is = backwards compatible - therefore all the mechanics in RFC7121 are still = the same. Please clarify whether a change in the LFB results in the update of the = RFC as well.=20 e) While it already has been discussed in the mailing list (see thread: = http://www.ietf.org/mail-archive/web/forces/current/msg04823.html) you = have to make clear=20 1. Whether KEYSELECTOR TLV and RANGE TLV can coexist (Mailing list = consensus was NO for simplicity reasons) 2. Whether multiple RANGE TLVs can coexist within the same PATHDATA TLV 3. Whether after a PATHDATA TLV which has a RANGE (or KEYSELECTOR for = that matter) there can be another PATHDATA TLV f) There is a text marked with XXX in the IANA considerations. g) Please make the IANA considerations sections similar to the section = in RFC5810 since you're requesting different types of reservation in = order to make IANA's work easier. ------=_NextPart_000_0091_01CF9A48.87702430-- From nobody Tue Jul 8 07:15:32 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCF01B2ADB for ; Tue, 8 Jul 2014 07:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s-4bRdzWz4v for ; Tue, 8 Jul 2014 07:12:44 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319DE1B2AF1 for ; Tue, 8 Jul 2014 07:12:42 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s68DxsFH028832; Tue, 8 Jul 2014 07:12:42 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1n040g89eg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 08 Jul 2014 07:12:41 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 8 Jul 2014 07:12:41 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Tue, 8 Jul 2014 07:12:41 -0700 From: ramki Krishnan To: "forces@ietf.org" Date: Tue, 8 Jul 2014 07:12:36 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+aHtco6CSCRSj9SQmnsz9pyqRybAAAHPhgAAAG3VAAAAZV0AAlylWw Message-ID: 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_C7634EB63EFD984A978DFB46EA5174F2C14FDB8681HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-08_04:2014-07-08,2014-07-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407080148 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/ISmJ1qBBV88PzBN4BmcXNU69OVg X-Mailman-Approved-At: Tue, 08 Jul 2014 07:15:28 -0700 Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: Re: [forces] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:12:51 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8681HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The face-to-face meeting date is July 23rd and not July 30th. Sorry for the= confusion caused. Thanks, Ramki From: ramki Krishnan Sent: Monday, July 07, 2014 1:12 PM To: 'forces@ietf.org' Cc: DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com); dilikris@in.ibm.com Subject: Proposed IRTF Network Functions Virtualization Research Group (NFV= RG) - first face-to-face meeting at Toronto Overview of proposed IRTF Network Functions Virtualization Research Group (= NFVRG) Network Function Virtualization (NFV) is a key emerging area for network op= erators, hardware and software vendors, cloud service providers, and in gen= eral network practitioners and researchers. This area requires exploring ne= w directions and working collaboratively on how to create network services = that utilize a virtualized infrastructure. Network functions that are tradi= tionally implemented in dedicated hardware appliances will need to be decom= posed and executed in virtual machines running in data centers. One key goa= l of this new area is to reduce capital and operating expenditures for futu= re deployments for networks and associated services. Another important goal= is for the network operators to be able to offer value added cloud service= s to their customers. Finally, new business models will open for the provis= ion of network services. The technologies enabling the virtualization of network functions are curre= ntly in an early stage of, and they need researchers to develop new archite= ctures, systems, and software, and to explore tradeoffs and possibilities f= or leveraging virtualized infrastructure to provide support for network fun= ctions. The Network Functions Virtualization Research Group (NFVRG) will br= ing together researchers and grow the community around the world in both ac= ademia and industry to explore this new research area through workshops, re= search group meetings etc. at premier conferences such as IEEE ICC, IEEE Gl= obecom and inviting special issues in well-known journals. Some of the key = topics of research include virtualization of fixed and mobile network infra= structures, new network architectures based on virtualized network function= s, virtualization of the home and enterprise network environments, co-exist= ence with non-virtualized infrastructure and services, and application to g= rowing areas of concern such as Internet of Things (IoT) and next generatio= n content distribution. The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful input= to other related standards efforts in ETSI or other standards bodies. More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/w= iki/nfvrg First face-to-face Meeting in Toronto The first face-to-face meeting of the proposed NFVRG will be held along wit= h the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm= in the Canadian (C) Room (immediately after the SFC meeting). Please let u= s know if you have research topics to present during the meeting. Would rea= lly appreciate active discussions in the mailing list nfvrg@irtf.org. Thanks, Ramki on behalf of the NFVRG co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8681HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The face-to-face meeting date is July 23rd and not July 30th.= Sorry for the confusion caused.

=  

Thanks,

Ramki

 

From: ramki Krishnan
Sent: Monday, = July 07, 2014 1:12 PM
To: 'forces@ietf.org'
Cc: DIEGO L= OPEZ GARCIA (diego.r.lopez@telefonica.com); dilikris@in.ibm.com
Subje= ct: Proposed IRTF Network Functions Virtualization Research Group (NFVR= G) - first face-to-face meeting at Toronto

 

Overview of proposed IRTF Network Functions Virtua= lization Research Group (NFVRG)

 

Network Function Virtualization (NFV) is a key emergi= ng area for network operators, hardware and software vendors, cloud service= providers, and in general network practitioners and researchers. This area= requires exploring new directions and working collaboratively on how to cr= eate network services that utilize a virtualized infrastructure. Network fu= nctions that are traditionally implemented in dedicated hardware appliances= will need to be decomposed and executed in virtual machines running in dat= a centers. One key goal of this new area is to reduce capital and operating= expenditures for future deployments for networks and associated services. = Another important goal is for the network operators to be able to offer val= ue added cloud services to their customers. Finally, new business models wi= ll open for the provision of network services.

 

The technologies enabling = the virtualization of network functions are currently in an early stage of,= and they need researchers to develop new architectures, systems, and softw= are, and to explore tradeoffs and possibilities for leveraging virtualized = infrastructure to provide support for network functions. The Network Functi= ons Virtualization Research Group (NFVRG) will bring together researchers a= nd grow the community around the world in both academia and industry to exp= lore this new research area through workshops, research group meetings etc.= at premier conferences such as IEEE ICC, IEEE Globecom and inviting specia= l issues in well-known journals. Some of the key topics of research include= virtualization of fixed and mobile network infrastructures, new network ar= chitectures based on virtualized network functions, virtualization of the h= ome and enterprise network environments, co-existence with non-virtualized = infrastructure and services, and application to growing areas of concern su= ch as Internet of Things (IoT) and next generation content distribution.

 

= The NFVRG will focus on research problems associated with these topics and = on bringing a research community together that can jointly address such pro= blems, concentrating on problems that relate not just to networking but als= o to computing and storage constraints in such environments. It is also hop= ed that the outcome of the research will benefit standardization efforts th= at can get spawned via IRTF & IETF BoF meetings and/or provide useful i= nput to other related standards efforts in ETSI or other standards bodies.<= o:p>

 

More details can be found at - http://trac.tools.ietf.org/group/irtf/trac/wiki/nfv= rg

 

First face-to-face Meeting in = Toronto

 

T= he first face-to-face meeting of the proposed NFVRG will be held along with= the IETF meeting in Toronto on July 30th Wednesday from 11:30am to 1:00pm = in the Canadian (C) Room (immediately after the SFC meeting). Please let us= know if you have research topics to present during the meeting. Would real= ly appreciate active discussions in the mailing list nfvrg@irtf.org.

&nb= sp;

Thanks,

Ramki on behalf of the NFVRG co-chairs

= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FDB8681HQ1EXCH01corp_-- From nobody Wed Jul 9 02:43:00 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542F21A03CB for ; Wed, 9 Jul 2014 02:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ8KQ1C6Acur for ; Wed, 9 Jul 2014 02:42:58 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B031A03CA for ; Wed, 9 Jul 2014 02:42:57 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id il7so6818961vcb.27 for ; Wed, 09 Jul 2014 02:42:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+qCwbXvxA4/TNSX/G49l5NniaCgo+NEqiFdrJXL8X94=; b=PfjvEwp0R1hNyI5701XvLw2aDa2rfnSaVkABjbFPlwDgTnQ+iwVrMIuLczkIbZTbGe i4SWCONp44mQbaey3/7Dk1V4o0LdK5cO+x2+jVyAbFuI1VElzQJ6Fll7357y6bl3H6mv /JDwTNMX/nREF1xmE3w1vA8mcj07S9/oN8cl8sQa1WQTfX36pe+nqrYPN65KfP96N2OD 0VWBfe6BuiqEPRXnOM0rfZgAUktwisAll5Ovd6YJP0FMnU91Oj7jmsDnwZWETmho/UGs hQiFzwIgFhwvnGBTZZjaZ48IPH/A8fbUuS1Wd5MzAkTSQbU9sJM6HRCPlYSUGybEd9O2 EgLQ== X-Gm-Message-State: ALoCoQnUVINg41MbuxeQ32H3gH9PE8Wu3LHcpDeW1/JaSESG2n0s33rZ2niL46hExDfsxgu126S6 X-Received: by 10.58.30.35 with SMTP id p3mr38466802veh.25.1404898976772; Wed, 09 Jul 2014 02:42:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Wed, 9 Jul 2014 02:42:36 -0700 (PDT) In-Reply-To: <009001cf9a2f$6222ec30$2668c490$@com> References: <00c801cf99d3$73968ff0$5ac3afd0$@com> <009001cf9a2f$6222ec30$2668c490$@com> From: Jamal Hadi Salim Date: Wed, 9 Jul 2014 05:42:36 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/ImiDoASM6JTcFcQDCJOyCDzOsvE Cc: "forces@ietf.org" , draft-ietf-forces-protoextension@tools.ietf.org Subject: Re: [forces] draft-ietf-forces-protoextension: Publication process started X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 09:42:59 -0000 Greetings Evangelos, Thanks for your comments and the write up. I am going to upload this write up and let Adrian make the call whether he wants to see a new draft or not. cheers, jamal On Mon, Jul 7, 2014 at 6:04 PM, Haleplidis Evangelos wrote: > Greetings to the list, > > > > Attached is the shepherd write-up for the draft-ietf-forces-protoextension > > > With regards, > > Evangelos Haleplidis. From nobody Wed Jul 9 14:21:06 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7931B27B8 for ; Wed, 9 Jul 2014 14:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcmzZQ62Ira0 for ; Wed, 9 Jul 2014 14:21:04 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78CB1A0025 for ; Wed, 9 Jul 2014 14:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=damascene.joachimpillai@verizon.com; q=dns/txt; s=corp; t=1404940863; x=1436476863; h=from:to:date:subject:message-id:mime-version; bh=43tPFiLl3yhG6pQVZcxxqqLUIa3rE9FnLfIrlphcVPY=; b=fEpCwXyqHRmSq508mJ+Zs8VPM0E2fW6IE+wefbnRW0KpG0mXQBxUW1yK 4BQgjYZcDQS2Pz6QUkpz249fU3bghOxAFd9FCtCSKR4xTuAYupsF8iYBC nkiAUCrrMn81uHIVuN7i1pDNtv3+BjsCqa1Mcze5JhXWLm3EjTi4xVXIb A=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 09 Jul 2014 21:21:02 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="5.01,633,1400025600"; d="scan'208,217";a="768043109" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 09 Jul 2014 21:21:02 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Wed, 9 Jul 2014 17:21:02 -0400 To: "forces@ietf.org" Date: Wed, 9 Jul 2014 17:21:02 -0400 Thread-Topic: WG last call: draft-ietf-forces-protoextension Thread-Index: Ac+bu5WkdMvM9JxtS5O8ZfwKUH6Pjg== Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0139EE892A@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB0139EE892AFHDP1LUMXC7V3_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/kyQBWv34wx6VsriyWlxhGIXRO1M Subject: [forces] WG last call: draft-ietf-forces-protoextension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 21:21:05 -0000 --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB0139EE892AFHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jamal and I would like to start the two week working group last call for dr= aft-ietf-forces-packet-parallelization. The document may be found here: http://tools.ietf.org/html/draft-ietf-forces-packet-parallelization-00 The authors are advised to try to resolve as many of the comments as possib= le (on the mailing list) as they come in, but not to post the new version o= f the draft until the wglc is closed and the comments are resolved. This working group last call will end on July 23rd 2014. n DJ --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB0139EE892AFHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jamal and I w= ould like to start the two week working group last call for draft-ietf-forc= es-packet-parallelization.  The document may be found here:=

http://tools.ietf.org/html/draft-ietf-f= orces-packet-parallelization-00

<= o:p> 

The authors are advised to try = to resolve as many of the comments as possible (on the mailing list) as the= y come in, but not to post the new version of the draft until the wglc is c= losed and the comments are resolved.

=  

This working group last call w= ill end on July 23rd 2014.

<= o:p> 

n  DJ

<= /body>= --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB0139EE892AFHDP1LUMXC7V3_-- From nobody Wed Jul 9 15:22:03 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1E31A0065 for ; Wed, 9 Jul 2014 15:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MOpJQA9tFfr for ; Wed, 9 Jul 2014 15:22:00 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3668F1A0109 for ; Wed, 9 Jul 2014 15:22:00 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hy10so8918265vcb.1 for ; Wed, 09 Jul 2014 15:21:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=MILg65bufjShWIzdsJ55vl0b0L1da1KoGdVloxPzNpI=; b=kkNfQdeE1PefP5FiM3UV3OroxiyRuSXApJ9HL1Xgn8S5ToD5rq//Yw5fTZRTsgLH5a 0t61b8LtqsKjGk5wDi4Y5VpjdnftoHYkAsoL+FyZvNscQnuYI2b7kO6k8SfVugf9NVza 2j1kkMtCm5idTwF9VVeBV/1XDu1A6NxFAze4hofThoDvabLzNYp9qOeiC4M9wi3dnglz 7aRVKOXnFrS54efhmsR0czSIBi1vLORNzGWzmnBGV2/JQy2dgD14wVtiJwQmX5TDxUqi LkMT3+iMJb2fkCDGkw4RmPY2UUb9bj5C8+hOI2/PRdnu29CEWVw0L2jcQ3hzsmf7nUGk i0Xw== X-Gm-Message-State: ALoCoQkkyvUagsBjUisYbzRDDSJEOu/6t0vqS5VXOMfRUEpoCQJcyNJJRrrVQkzJLwxxD31hczQ2 X-Received: by 10.52.99.66 with SMTP id eo2mr499540vdb.82.1404944519344; Wed, 09 Jul 2014 15:21:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Wed, 9 Jul 2014 15:21:39 -0700 (PDT) From: Jamal Hadi Salim Date: Wed, 9 Jul 2014 18:21:39 -0400 Message-ID: To: "Joachimpillai, Damascene M" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/oTqWiefAB2JW7_9bnPs_hkwI5GA Cc: "forces@ietf.org" Subject: [forces] WG LC: draft-ietf-forces-packet-parallelization WAS(Re: WG last call: draft-ietf-forces-protoextension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 22:22:02 -0000 DJ, I think you meant to say in the subject line draft-ietf-forces-packet-parallelization ;-> cheers, jamal On Wed, Jul 9, 2014 at 5:21 PM, Joachimpillai, Damascene M wrote: > Jamal and I would like to start the two week working group last call for > draft-ietf-forces-packet-parallelization. The document may be found here: > > http://tools.ietf.org/html/draft-ietf-forces-packet-parallelization-00 > > > > The authors are advised to try to resolve as many of the comments as > possible (on the mailing list) as they come in, but not to post the new > version of the draft until the wglc is closed and the comments are resolved. > > > > This working group last call will end on July 23rd 2014. > > > > n DJ > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From nobody Thu Jul 10 05:55:09 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F2E1B28E6 for ; Thu, 10 Jul 2014 05:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chQ0zU-pKscT for ; Thu, 10 Jul 2014 05:55:03 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3DE1B28E1 for ; Thu, 10 Jul 2014 05:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=damascene.joachimpillai@verizon.com; q=dns/txt; s=corp; t=1404996902; x=1436532902; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7QdCozQqMaFd9v5jMBfhob1DtM6mZXY+G4FUi9so2Ls=; b=BC+vO9ngzPNrF+WE2rMcBecD19e+uEklNjt+HNdamc1eBA1q2EMbwxE4 7OH+Hv/OUN+T4WIFzLtAtQwpWOhs31qqiFg9Wc/SHqpvl3XpChT20Tkv/ MZGLw5/cdQX7zxVJYGOy3woIAwKy42vDrxNheoG/he8WsD4hWIxTOdCdH c=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 10 Jul 2014 12:55:01 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="5.01,637,1400025600"; d="scan'208";a="796892574" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi01.verizon.com with ESMTP; 10 Jul 2014 12:55:01 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Thu, 10 Jul 2014 08:55:01 -0400 To: 'Jamal Hadi Salim' Date: Thu, 10 Jul 2014 08:55:00 -0400 Thread-Topic: WG LC: draft-ietf-forces-packet-parallelization WAS(Re: [forces] WG last call: draft-ietf-forces-protoextension Thread-Index: Ac+bxDPaAkz1FLipRdu7u/mvr+JBCwAedZvQ Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB0139EE892E@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 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/oa7F0X14u7gNfY14EYMXxkMbq9w Cc: "forces@ietf.org" Subject: Re: [forces] WG LC: draft-ietf-forces-packet-parallelization WAS(Re: WG last call: draft-ietf-forces-protoextension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 12:55:04 -0000 UGFyZG9uIG15IG1pc3Rha2UuIEl0IHNob3VsZCBoYXZlIHJlYWQgV0cgTEM6IGRyYWZ0LWlldGYt Zm9yY2VzLXBhY2tldC1wYXJhbGxlbGl6YXRpb24NCg0KR29vZCB0byBzZWUgeW91IGFyZSBzdGls bCB1cCBKYW1hbCENCg0KLS0gREoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEphbWFsIEhhZGkgU2FsaW0gW21haWx0bzpoYWRpQG1vamF0YXR1LmNvbV0gDQpTZW50OiBXZWRu ZXNkYXksIEp1bHkgMDksIDIwMTQgNjoyMiBQTQ0KVG86IEpvYWNoaW1waWxsYWksIERhbWFzY2Vu ZSBNDQpDYzogZm9yY2VzQGlldGYub3JnDQpTdWJqZWN0OiBXRyBMQzogZHJhZnQtaWV0Zi1mb3Jj ZXMtcGFja2V0LXBhcmFsbGVsaXphdGlvbiBXQVMoUmU6IFtmb3JjZXNdIFdHIGxhc3QgY2FsbDog ZHJhZnQtaWV0Zi1mb3JjZXMtcHJvdG9leHRlbnNpb24NCg0KREosDQoNCkkgdGhpbmsgeW91IG1l YW50IHRvIHNheSBpbiB0aGUgc3ViamVjdCBsaW5lIGRyYWZ0LWlldGYtZm9yY2VzLXBhY2tldC1w YXJhbGxlbGl6YXRpb24gOy0+DQoNCmNoZWVycywNCmphbWFsDQoNCk9uIFdlZCwgSnVsIDksIDIw MTQgYXQgNToyMSBQTSwgSm9hY2hpbXBpbGxhaSwgRGFtYXNjZW5lIE0gPGRhbWFzY2VuZS5qb2Fj aGltcGlsbGFpQHZlcml6b24uY29tPiB3cm90ZToNCj4gSmFtYWwgYW5kIEkgd291bGQgbGlrZSB0 byBzdGFydCB0aGUgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgDQo+IGZvciBkcmFm dC1pZXRmLWZvcmNlcy1wYWNrZXQtcGFyYWxsZWxpemF0aW9uLiAgVGhlIGRvY3VtZW50IG1heSBi ZSBmb3VuZCBoZXJlOg0KPg0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWZvcmNlcy1wYWNrZXQtcGFyYWxsZWxpemF0aW9uLTAwDQo+DQo+DQo+DQo+IFRoZSBhdXRob3Jz IGFyZSBhZHZpc2VkIHRvIHRyeSB0byByZXNvbHZlIGFzIG1hbnkgb2YgdGhlIGNvbW1lbnRzIGFz IA0KPiBwb3NzaWJsZSAob24gdGhlIG1haWxpbmcgbGlzdCkgYXMgdGhleSBjb21lIGluLCBidXQg bm90IHRvIHBvc3QgdGhlIA0KPiBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgdW50aWwgdGhlIHdn bGMgaXMgY2xvc2VkIGFuZCB0aGUgY29tbWVudHMgYXJlIHJlc29sdmVkLg0KPg0KPg0KPg0KPiBU aGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIHdpbGwgZW5kIG9uIEp1bHkgMjNyZCAyMDE0Lg0K Pg0KPg0KPg0KPiBuICBESg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBmb3JjZXMgbWFpbGluZyBsaXN0DQo+IGZvcmNlc0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcw0KPg0K From nobody Tue Jul 15 03:37:26 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9B11B2837 for ; Tue, 15 Jul 2014 03:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqGgKBAQZC2c for ; Tue, 15 Jul 2014 03:37:16 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077D91B27EA for ; Tue, 15 Jul 2014 03:37:15 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so3000701vcb.22 for ; Tue, 15 Jul 2014 03:37:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=OmDNPKcJel27vBPW3Pbs4zSO67xrNEWY/5RZDekRWxk=; b=D3vgeLn7CsDASY9Sr1ZGZiZ4OGQVhqTxvm/nbUekyaJyR7s9E9XjIFDamWVy9LG3Zi tz76SGh4CF1vCgtk2AZNjiNwFITNxz9oDIgAs/0dMvqNwpnQ5JGZQumaLibmA+wD/PRV 1dWduBRLtUPKooAyERRcQnDbzCvI6yq0Qb3FIN6/Wxx9M+Ac1y3Eriu4K4N/tWeolTXP Vuz5+pSpTXOhafEOLTcT5EABf2j9K8DovRZvU6vg1tzJFR25r43geb22wHrBD00wjedj M/Tm7lx1Spx2KfdH3EddubfCdX9r7enjEaecvICgR3rZ9odt3ibTtSbMmJyqfEQOUyAl 6JyQ== X-Gm-Message-State: ALoCoQlNiw8egnr6Adx9nGUWjyiYbIqYXWJzE6EatSxGBEUFtdRx+ZyUmnoUhL2vvGQ8BCIAX2Hy X-Received: by 10.52.121.112 with SMTP id lj16mr7092542vdb.29.1405420635062; Tue, 15 Jul 2014 03:37:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Tue, 15 Jul 2014 03:36:54 -0700 (PDT) From: Jamal Hadi Salim Date: Tue, 15 Jul 2014 06:36:54 -0400 Message-ID: To: Evangelos Haleplidis , Joel Halpern Content-Type: multipart/mixed; boundary=089e01184dc2b6c81004fe38fdf8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/XU0cJy1qfA7-YdRLvyzYUB8EFBQ Cc: "forces@ietf.org" Subject: [forces] comments on draft-ietf-forces-packet-parallelization-00 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 10:37:20 -0000 --089e01184dc2b6c81004fe38fdf8 Content-Type: text/plain; charset=UTF-8 Evangelos/Joel, Since this doc is in WG LC i made a more thorough run of the text. There are a few editorial comments that i would urge a version -01. I have attached my comments against the draft. Issues i would like to highlight: 1) You need to explicitly state there can be only one instance per FE. 2) You need to define the concept of a "task" which is equivalent to your description of "work". A task is a grouping of packets or chunks initiated at the splitter and converged at the merger. All packets/chunks of the same task will have the same correlator. Or something along those lines. Once that is defined, text readability improves when it is used later. 3) You need to specify/suggest what should happen if threshold event counters are exceeded 4) The Merge LFB and MergeWaitType component: Is there a timeout period that a merger is supposed to wait for a task's packet/chunks to arrive before declaring a fail? cheer, jamal --089e01184dc2b6c81004fe38fdf8 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-forces-packet-parallelization-00-comments.txt" Content-Disposition: attachment; filename="draft-ietf-forces-packet-parallelization-00-comments.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hxn356js0 ClRoZSBjb21tZW50cyBmcm9tIEFkcmlhbiBvbiBkZWZpdGluaW9ucyBmb3IgdGhlIG1vZGVsIGRy YWZ0CmFwcGx5IGhlcmUgYXMgd2VsbC4KCj4zLiAgUGFja2V0IFBhcmFsbGVsaXphdGlvbgoKPiAg IFRoaXMgZG9jdW1lbnQgYWRkcmVzc2VzIHRoZSBmb2xsb3dpbmcgdHdvIHR5cGVzIG9mIHBhY2tl dAo+ICAgcGFyYWxsZWxpemF0aW9uOgoKPiAgIDEuICBGbG9vZCAtIHdoZXJlIGEgY29weSBvZiBh IHBhY2tldCBpcyBzZW50IHRvIG11bHRpcGxlIExGQnMgdG8gYmUKPiAgICAgICBwcm9jZXNzZWQg aW4gcGFyYWxsZWwuCgo+ICAgMi4gIFNwbGl0IC0gd2hlcmUgdGhlIHBhY2tldCB3aWxsIGJlIHNw bGl0IGluIGVxdWFsIHNpemUgY2h1bmtzCj4gICAgICAgc3BlY2lmaWVkIGJ5IHRoZSBDRSBhbmQg c2VudCB0byBtdWx0aXBsZSBMRkIgaW5zdGFuY2VzIHByb2JhYmx5Cj4gICAgICAgb2YgdGhlIHNh bWUgTEZCIGNsYXNzIHRvIGJlIHByb2Nlc3NlZCBpbiBwYXJhbGxlbC4KCj4gICBJdCBtdXN0IGJl IG5vdGVkIHRoYXQgdGhlIHByb2Nlc3Mgb2YgY29weWluZyB0aGUgcGFja2V0IGluIHRoZSBGbG9v ZAo+ICAgcGFyYWxsZWwgdHlwZSBpcyBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlZCBhbmQgaXMgbG9v c2VseSBkZWZpbmVkIGhlcmUuCgpzL2RlcGVuZGVkL2RlcGVuZGVudAoKPiAgIEFuIGltcGxlbWVu dG9yIG1heSBlaXRoZXIgZGVjaWRlIHRvIHBoeXNpY2FsIGNvcHkgdGhlIHBhY2tldCBhbmQgc2Vu ZAo+ICAgYWxsIHBhY2tldHMgb24gdGhlIHBhcmFsbGVsIHBhdGhzLCBvciBtYXkgZGVjaWRlIHRv IGxvZ2ljYWxseSBjb3B5Cj4gICB0aGUgcGFja2V0IGJ5IHNpbXBseSBzZW5kaW5nIGZvciBleGFt cGxlIHBvaW50ZXJzIG9mIHRoZSBzYW1lIHBhY2tldAo+ICAgcHJvdmlkZWQgdGhhdCB0aGUgbmVj ZXNzYXJ5IGludGVybG9ja3MgYXJlIHRha2VuIGludG8gYWNjb3VudC4gIFRoZQo+ICAgaW1wbGVt ZW50b3IgaGFzIHRvIHRha2UgaW50byBhY2NvdW50IHRoZSBkZXZpY2UncyBjaGFyYWN0ZXJpc3Rp Y3MgdG8KPiAgIGRlY2lkZSB3aGljaCBhcHByb2FjaCBmaXRzIGJldHMgdG8gdGhlIGhhcmR3YXJl LgoKcy9iZXRzL2Jlc3QKCj4gICBCb3RoIHBhcmFsbGVsIHBhY2tldCBkaXN0cmlidXRpb24gdHlw ZXMgY2FuIGN1cnJlbnRseSBiZSBhY2hpZXZlZAo+ICAgd2l0aCB0aGUgRm9yQ0VTIG1vZGVsLiAg VGhlIHNwbGl0dGVyIExGQiBoYXMgb25lIGdyb3VwIG91dHB1dCB0aGF0Cj4gICBwcm9kdWNlcyBl aXRoZXIgY2h1bmtzIG9yIHBhY2tldHMgdG8gYmUgc2VudCB0byBMRkJzIGZvciBwcm9jZXNzaW5n Cj4gICBhbmQgdGhlIG1lcmdlciBMRkIgaGFzIG9uZSBncm91cCBpbnB1dCB0aGF0IGV4cGVjdHMg ZWl0aGVyIHBhY2tldHMgb3IKPiAgIGNodW5rcyB0byBhZ2dyZWdhdGUgYWxsIHRoZSBwYXJhbGxl bCBwYWNrZXRzIG9yIGNodW5rcyBhbmQgcHJvZHVjZSBhCj4gICBzaW5nbGUgcGFja2V0LiAgRmln dXJlIDEgc2hvd3MgYW4gc2ltcGxlIGV4YW1wbGUgb2YgYSBzcGxpdCBwYXJhbGxlbAoKRWl0aGVy ICJhIHNpbXBsZSBleGFtcGxlIiBvciAiYW4gZXhhbXBsZSIKCj4gICBkYXRhcGF0aCBhbG9uZyB3 aXRoIHRoZSBzcGxpdHRlciBhbmQgbWVyZ2VyIExGQi4gIEZpZ3VyZSAyIHNob3dzIGFuCj4gICBl eGFtcGxlIG9mIGEgZmxvb2QgcGFyYWxsZWwgZGF0YXBhdGggYWxvbmcgd2l0aCB0aGUgc3BsaXR0 ZXIgYW5kCj4gICBtZXJnZXIgTEZCLgoKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLSsKPiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0+fCBSZWdleCBMRkIgIHwt LS0tKwo+ICAgICAgICArLS0tLS0tLS0tLSsgICB8ICAgICArLS0tLS0tLS0tLS0tKyAgICB8ICAg ICAgICstLS0tLS0tLS0tKwo+ICAgICAgICB8ICAgICAgICAgIHwtLS0rICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tPnwgICAgICAgICAgfAo+ICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICArLS0tLS0tLS0tLS0tKyAgICAgICAgICAgIHwgICAgICAgICAgfAo+ICAgIC0tLT58IFNwbGl0 dGVyIHwtLS0tLS0tLT58IFJlZ2V4IExGQiAgfC0tLS0tLS0tLS0tPnwgIE1lcmdlciAgfC0tLT4K PiAgICAgICAgfCAgIExGQiAgICB8ICAgICAgICAgKy0tLS0tLS0tLS0tLSsgICAgICAgICAgICB8 ICAgTEZCICAgIHwKPiAgICAgICAgfCAgICAgICAgICB8LS0tKyAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLT58ICAgICAgICAgIHwKPiAgICAgICAgKy0tLS0tLS0tLS0rICAgfCAgICAgKy0t LS0tLS0tLS0tLSsgICAgfCAgICAgICArLS0tLS0tLS0tLSsKPiAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0+fCBSZWdleCBMRkIgIHwtLS0tKwo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tKwoKPiAgICAgICAgICAgICAgICBGaWd1cmUgMTogU2ltcGxlIHNwbGl0 IHBhcmFsbGVsIHByb2Nlc3NpbmcKCj4gICAgICAgICstLS0tLS0tLS0tKyAgICArLS0tLS0tLS0t LS0tKyAgICArLS0tLS0tLSsgICAgKy0tLS0tLS0tLS0rCj4gICAgICAgIHwgICAgICAgICAgfCAg ICB8IENsYXNzaWZpZXIgfCAgICB8IE1ldGVyIHwgICAgfCAgICAgICAgICB8Cj4gICAgICAgIHwg ICAgICAgICAgfC0tLT58ICAgICBMRkIgICAgfC0tLT58ICBMRkIgIHwtLS0+fCAgICAgICAgICB8 Cj4gICAgLS0tPnwgU3BsaXR0ZXIgfCAgICArLS0tLS0tLS0tLS0tKyAgICArLS0tLS0tLSsgICAg fCAgTWVyZ2VyICB8LS0tPgo+ICAgICAgICB8ICAgTEZCICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICBMRkIgICAgfAo+ICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgKy0tLS0tLS0tLS0tLSsgICAgICAgICAgIHwgICAgICAgICAgfAo+ICAgICAgICB8ICAgICAg ICAgIHwtLS0tLS0tLS0+fCAgSVB2NCBUVEwgIHwtLS0tLS0tLS0tPnwgICAgICAgICAgfAo+ICAg ICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgfCAgRGVjcmVtZW50IHwgICAgICAgICAgICstLS0t LS0tLS0tKwo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICBMRkIgICAgIHwKPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0rCgo+ICAgICAgICAgICAg ICAgIEZpZ3VyZSAyOiBTaW1wbGUgZmxvb2QgcGFyYWxsZWwgcHJvY2Vzc2luZwoKCmZpZ3VyZSAx IGFuZCAyIGNvdWxkIGJlbmVmaXQgZnJvbSBpbmRpY2F0aW5nIHdoYXQgZ29lcyBvbgppbiB0aGUg ZGlyZWN0ZWQgYXJyb3dzIChQICsgTSkKCj4gICBUaGlzIHZlcnNpb24gb2YgdGhlIG1vZGVsbGlu ZyBmcmFtZXdvcmsgZG9lcyBub3QgYWxsb3cgZm9yIG5lc3RlZAo+ICAgcGFyYWxsZWwgZGF0YXBh dGggdG9wb2xvZ2llcy4gIFRoaXMgZGVjaXNpb24gd2FzIHJlYWNoZWQgYnkgdGhlCj4gICBhdXRo b3JzIGFuZCB0aGUgRm9yQ0VTIHdvcmtpbmcgZ3JvdXAgYXMgdGhlcmUgd2FzIG5vIHN0cm9uZyB1 c2UgY2FzZQo+ICAgb3IgbmVlZCBhdCB0aGUgdGltZS4gIFRoaXMgbGVkIHRvIGEgbW9yZSBzaW1w bGUgbWV0YWRhdGEgZGVmaW5pdGlvbgo+ICAgbmVlZGVkIHRvIGJlIHRyYW5zcG9ydGVkIGJldHdl ZW4gdGhlIHNwbGl0dGVyIGFuZCB0aGUgY29ycmVzcG9uZGluZwo+ICAgbWVyZ2VyLiAgSWYgdGhl cmUgaXMgYSBuZWVkIGZvciBuZXN0ZWQgcGFyYWxsZWwgZGF0YXBhdGhzIGEgbmV3Cj4gICB2ZXJz aW9uIG9mIGEgc3BsaXR0ZXIgYW5kIG1lcmdlciB3aWxsIGJlIG5lZWRlZCB0byBiZSBkZWZpbmVk IGFzIHdlbGwKPiAgIGFzIGFuIGF1Z21lbnRhdGlvbiB0byB0aGUgZGVmaW5lZCBtZXRhZGF0YS4K CgpUaGUgdGV4dCBiZWxvdyBpbnRyb2R1Y2VzIGEgY29yZSBkZXNjcmlwdGlvbjsgZm9yIHJlYWRh YmlsaXR5LAppdCB3b3VsZCBtYWtlIHNlbnNlIHRvIG1ha2UgdGhpcyBzZWN0aW9uIGJlbG93IGFz IDMuMSBhbmQgdGhlIAppbnRybyBzZWN0aW9uIG9uIHRoZSBvdGhlciBhdHRyaWJ1dGVzIGZ1cnRo ZXIgYmVsb3cgYXMgc2VjdGlvbiAzLjIKCgo+ICAgT25lIGltcG9ydGFudCBlbGVtZW50IHRvIGEg ZGV2ZWxvcGVyIGlzIHRoZSBhYmlsaXR5IHRvIGRlZmluZSB3aGljaAo+ICAgTEZCcyBjYW4gYmUg dXNlZCBpbiBhIHBhcmFsbGVsIG1vZGUsIHdpdGggd2hpY2ggb3RoZXIgTEZCcyBjYW4gdGhleQo+ ICAgYmUgcGFyYWxsZWxpemVkIHdpdGggYW5kIHRoZSBvcmRlciBvZiB0aGUgTEZCcyBjYW4gYmUg YXNzZW1ibGVkLgoKIiwgb3JkZXIgaW4gd2hpY2ggdGhlIExGQnMgY2FuIGJlIGFzc2VtYmxlZC4i Cgo+ICAgVGhpcyBpbmZvcm1hdGlvbiBtdXN0IGJlIGFjY2Vzc2libGUgaW4gdGhlIGNvcmUgTEZC cy4gIEhvd2V2ZXIKPiAgIGluc3RlYWQgb2YgYXBwZW5kaW5nIG9uZSBtb3JlIGNhcGFiaWxpdHkg aW4gdGhlIEZFT2JqZWN0IExGQiBhbmQKPiAgIGNoYW5naW5nIHRoZSBGRU9iamVjdCBMRkIsIHdl IG9wdGVkIGZvciBhbiBhbHRlcm5hdGl2ZS4gIFdlCj4gICBpbnRyb2R1Y2VkIGFuIGFkZGl0aW9u YWwgY29yZSBMRkIsIHRoZSBDb3JlUGFyYWxsZWxpemF0aW9uLCB0aGF0IHdpbGwKPiAgIG5vdCBo YXZlIGlucHV0IGFuZCBvdXRwdXQgcG9ydHMsIGJ1dCBzaW1wbHkgdGhlIGNhcGFiaWxpdHkgbmVj ZXNzYXJ5Cj4gICBmb3IgTEZCIHBhcmFsbGVsaXphdGlvbi4gIElmIHRoaXMgTEZCIGlzIG5vdCBz dXBwb3J0ZWQgaW4gdGhlCj4gICBGRU9iamVjdHMgTEZCJ3MgU3VwcG9ydGVkTEZCcyBjb21wb25l bnQgYW5kIG5vdCBpbnN0YW50aWF0ZWQgaW4gdGhlCj4gICBGRSwgdGhhdCBtZWFucyB0aGF0IHRo ZSBGRSBkb2VzIG5vdCBzdXBwb3J0IExGQiBwYXJhbGxlbGl6YXRpb24uCgpKdXN0IHRyeWluZyB0 byB0YW1lIHRoaXM6CgoiVG8gYWNjZXNzIHRoZSBwYXJhbGxlbGl6YXRpb24gZGV0YWlscywgd2Ug b3B0ZWQgZm9yIGRlZmluaW5nIGEgYnJhbmQKbmV3IExGQiBjbGFzcyAtIHRoZSBDb3JlUGFyYWxs ZWxpemF0aW9uIExGQi4gVGhpcyBjaG9pY2Ugd2FzIGFuIGFsdGVybmF0aXZlCnRvIG1ha2luZyB5 ZXQgYW5vdGhlciBjaGFuZ2UgdG8gdGhlIGNvcmUgRkVPYmplY3QgTEZCLgoKVGhlIENvcmVQYXJh bGxlbGl6YXRpb24gZXhpc3RzIG1lcmVseSB0byBkZWZpbmUgdGhlIGNhcGFiaWxpdGllcyBmb3Ig YW4KRkUncyBMRkIgcGFyYWxsZWxpemF0aW9uLiBUaGUgcHJlc2VuY2Ugb2YgYW4gaW5zdGFuY2Ug b2YgdGhpcyBMRkIgY2xhc3MKaW4gdGhlIEZFT2JqZWN0J3MgU3VwcG9ydGVkTEZCcyBjb21wb25l bnQgaW5kaWNhdGVzIHRvIHRoZSBDRSB0aGF0CnRoZSBzcGVjaWZpYyBGRSBzdXBwb3J0cyBwYXJh bGxlbGl6YXRpb24uCiIKCkluL291dHB1dCBwb3J0cyBhcmUganVzdCBhZGRpbmcgdW5uZWNlc3Nh cnkgaW5mb3JtYXRpb24gaW4gYW4gYWxyZWFkeQpvdmVybG9hZGVkIGRlc2NyaXB0aW9uLiBZb3Ug dGFsayBhYm91dCB0aGVtIGluIHRoZSBkZXRhaWxzIGxhdGVyLgoKUXVlc3Rpb24gdG8gdGhlIGF1 dGhvcnM6ClNob3VsZCB5b3Ugc2F5IHRoYXQgb25seSBvbmUgaW5zdGFuY2Ugb2YgdGhpcyBMRkIg Y2xhc3MgY2FuIGV4aXN0PwoKPiAgIFRoZSB0b3BvbG9neSBvZiB0aGUgcGFyYWxsZWwgZGF0YXBh dGggY2FuIGJlIGRlZmVycmVkIGFuZCBtYW5pcHVsYXRlZAo+ICAgZnJvbSB0aGUgRkVPYmplY3Qg TEZCJ3MgTEZCVG9wb2xvZ3kuCgpXZWxsLCBob3cgZG8gaSBzYXkgaG93IHBhcmFsbGVsaXphdGlv biBpcyBhY2hpZXZlZCBoZXJlPwoKPiAgIFRoZSBDb3JlUGFyYWxsZWxpemF0aW9uIHJlcXVpcmVz IG9ubHkgb25lIGNhcGFiaWxpdHkgaW4gb3JkZXIgdG8KPiAgIHNwZWNpZnkgZWFjaCBMRkIgdGhh dCBjYW4gYmUgdXNlZCBpbiBhIHBhcmFsbGVsIG1vZGU6CgoKcGVyaGFwcyB5b3Ugc2hvdWxkIGVt cGhhc2l6ZSB0aGUgbmF0dXJlIG9mIHRoaXMgY2FwYWJpbGl0eSBhcyAKYmVpbmcgYSBjb21wbGV4 IHN0cnVjdHVyZT8KCj4gICBvICBUaGUgTmFtZSBvZiB0aGUgTEZCLgoKPiAgIG8gIFRoZSBDbGFz cyBJRCBvZiB0aGUgTEZCLgoKPiAgIG8gIFRoZSBWZXJzaW9uIG9mIHRoZSBMRkIuCgo+ICAgbyAg VGhlIG51bWJlciBvZiBpbnN0YW5jZXMgdGhhdCBjbGFzcyBjYW4gc3VwcG9ydCBpbiBwYXJhbGxl bC4KCj4gICBvICBBIGxpc3Qgb2YgTEZCIGNsYXNzZXMgdGhhdCBjYW4gZm9sbG93IHRoaXMgTEZC IGNsYXNzIGluIGEgcGlwZWxpbmUKPiAgICAgIGZvciBhIHBhcmFsbGVsIHBhdGguCgo+ICAgbyAg QSBsaXN0IG9mIExGQiBjbGFzc2VzIHRoYXQgY2FuIGV4aXN0IGJlZm9yZSB0aGlzIExGQiBjbGFz cyBpbiBhCj4gICAgICBwaXBlbGluZSBmb3IgYSBwYXJhbGxlbCBwYXRoLgoKPiAgIG8gIEEgbGlz dCBvZiBMRkIgY2xhc3NlcyB0aGF0IGNhbiBwcm9jZXNzIHBhY2tldHMgb3IgY2h1bmtzIGluCj4g ICAgICBwYXJhbGxlbCB3aXRoIHRoaXMgTEZCIGNsYXNzLgoKCkFuZCB0aGlzIGlzIHdoZXJlIHNl Y3Rpb24gMy4yIGNhbiBiZWdpbi4uLi4KCj4gICBXaGlsZSB0aGUgRm9yQ0VTIG1vZGVsIGNhbm5v dCBkZXNjcmliZSBob3cgdGhlIHNwbGl0dGluZyBvciB0aGUKPiAgIG1lcmdpbmcgaXMgYWN0dWFs bHkgZG9uZSBhcyB0aGF0IGlzIGFuIGltcGxlbWVudGF0aW9uIGlzc3VlIG9mIHRoZQo+ICAgYWN0 dWFsIExGQiwgaG93ZXZlciB0aGlzIGRvY3VtZW50IGRlZmluZXMgb3BlcmF0aW9uYWwgcGFyYW1l dGVycyB0bwo+ICAgY29udHJvbCB0aGUgc3BsaXR0aW5nIGFuZCBtZXJnaW5nLCBuYW1lbHkgdGhl IHNpemUgb2YgdGhlIGNodW5rcywKPiAgIHdoYXQgaGFwcGVucyBpZiBhIHBhY2tldCBvciBjaHVu ayBoYXMgYmVlbiBtYXJrZWQgYXMgaW52YWxpZCBhbmQKPiAgIHdoZXRoZXIgdGhlIG1lcmdlIExG QiBzaG91bGQgd2FpdCBmb3IgYWxsIHBhY2tldHMgb3IgY2h1bmtzIHRvCj4gICBhcnJpdmUuIAoK Q2FuIHdlIGN1dCB0aGlzIGxvbmcgc2VudGVuY2UgZm9yIHJlYWRhYmlsaXR5PyBTb21ldGhpbmcg bGlrZToKIkl0IGlzIGV4cGVjdGVkIHRoYXQgdGhlIHNwbGl0dGluZyBhbmQgbWVyZ2luZyBtZWNo YW5pc21zIGFyZQphbiBpbXBsZW1lbnRhdGlvbiBpc3N1ZS4KVGhpcyBkb2N1bWVudCBwbGF5cyB0 aGUgcm9sZSBvZiBkZWZpbmluZyB0aGUgb3BlcmF0aW9uYWwgcGFyYW1ldGVycwpmb3IgdGhlIHNw bGl0dGluZyBhbmQgbWVyZ2luZywgbmFtZWx5OiB0aGUgc2l6ZSBvZiB0aGUgY2h1bmtzLAp3aGF0 IGhhcHBlbnMgaWYgYSBwYWNrZXQgb3IgY2h1bmsgaGFzIGJlZW4gbWFya2VkIGFzIGludmFsaWQg YW5kCndoZXRoZXIgdGhlIG1lcmdlIExGQiBzaG91bGQgd2FpdCBmb3IgYWxsIHBhY2tldHMgb3Ig Y2h1bmtzIHRvIGFycml2ZS4gIgoKPiBBZGRpdGlvbmFsbHkgdGhpcyBkb2N1bWVudCBkZWZpbmVz IG1ldGFkYXRhLCB3aGljaCBjb250YWluCj4gICBuZWNlc3NhcnkgaW5mb3JtYXRpb24gdG8gYXNz aXN0IHRoZSBtZXJnaW5nIHByb2NlZHVyZS4gIFRoZSBmb2xsb3dpbmcKPiAgIG1ldGFkYXRhIHNl dCBhcyBhIHN0cnVjdCBpcyBkZWZpbmVkOgoKCj4gICAxLiAgUGFyYWxsZWxUeXBlIC0gRmxvb2Qg b3Igc3BsaXQKCj4gICAyLiAgQ29ycmVsYXRvciAtIElkZW50aWZ5IHBhY2tldHMgb3IgY2h1bmtz IHRoYXQgYmVsb25nZWQgdG8gdGhlCj4gICAgICAgaW5pdGlhbCBwYWNrZXQgdGhhdCBlbnRlcmVk IHRoZSBTcGxpdHRlciBMRkIKCj4gICAzLiAgUGFyYWxsZWxOdW0gLSBOdW1iZXIgb2YgcGFja2V0 IG9yIGNodW5rIGZvciBzcGVjaWZpYyBDb3JyZWxhdG9yLgoKPiAgIDQuICBQYXJyYWxlbFBhcnRz Q291bnQgLSBUb3RhbCBudW1iZXIgb2YgcGFja2V0cyBvciBjaHVua3MgZm9yCj4gICAgICAgc3Bl Y2lmaWMgQ29ycmVsYXRvci4KCj4gICBUaGlzIG1ldGFkYXRhIGlzIHByb2R1Y2VkIGZyb20gdGhl IFNwbGl0dGVyIExGQiBhbmQgaXMgb3BhcXVlIHRvIExGQnMKPiAgIGluIHBhcmFsbGVsIHBhdGhz IGFuZCBpcyBwYXNzZWQgYWxvbmcgdG8gdGhlIG1lcmdlciBMRkIgd2l0aG91dCBiZWluZwo+ICAg Y29uc3VtZWQuCgoKQmVsb3cgd2FzIGhhcmQgdG8gcmVhZCAtIGFyZSB5b3UgZW51bWVyYXRpbmcg dGhpbmdzPwoKPiAgIEluIGNhc2Ugb2YgYSBwYWNrZXQvY2h1bmsgYmVpbmcgYnJhbmRlZCBpbnZh bGlkIGJ5IGFuIExGQiBpbiBhCgoiZGVlbWVkIiBzb3VuZHMgbW9yZSBkZXNjcmlwdGl2ZSB0aGFu ICJicmFuZGVkIgoKPiAgIHBhcmFsbGVsIHBhdGgsIGl0IE1VU1QgYmUgc2VudCBieSBhbiBvdXRw dXQgcG9ydCBvZiBzYWlkIExGQgoKWW91IG5lZWQgYSBwZXJpb2QuCgo+ICAgQW4gTEZCIGluc2lk ZSBhIHBhcmFsbGVsIHBhdGggZGVjaWRlcyB0aGF0IGEgcGFja2V0IG9yIGEgY2h1bmsgaGFzIHRv Cj4gICBiZSBkcm9wcGVkIGl0IE1BWSBkcm9wIGl0IGJ1dCB0aGUgbWV0YWRhdGEgTVVTVCBiZSBz ZW50IHRvIHRoZSBNZXJnZXIKPiAgIExGQidzIEludmFsaWRJbiBpbnB1dCBwb3J0IGZvciBtZXJn aW5nIHB1cnBvc2VzLgoKSXMgdGhhdCBzdXBwb3NlZCB0byBiZSBhIGJ1bGxldD8KCj4gICBBZGRp dGlvbmFsIG1ldGFkYXRhIHByb2R1Y2VkIGJ5IExGQnMgaW5zaWRlIGEgZGF0YXBhdGggTUFZIGJl Cj4gICBhZ2dyZWdhdGVkIHdpdGhpbiB0aGUgTWVyZ2VyIExGQiBhbmQgc2VudCBvbiBhZnRlciB0 aGUgbWVyZ2luZwo+ICAgcHJvY2Vzcy4gIEluIGNhc2Ugb2YgcmVjZWl2aW5nIHRoZSBzYW1lIG1l dGFkYXRhIGRlZmluaXRpb24gd2l0aAo+ICAgbXVsdGlwbGUgdmFsdWVzIHRoZSBtZXJnZXIgTEZC IE1VU1Qga2VlcCB0aGUgZmlyc3QgcmVjZWl2ZWQgZnJvbSBhCj4gICB2YWxpZCBwYWNrZXQgb3Ig Y2h1bmsuCgpBZ2FpbiBoYXJkIHRvIHBhcnNlIHRoZXJlLgoKPjQuICBQYXJhbGxlbCBCYXNlIFR5 cGVzCgpHZW5lcmFsbHkgaW4gdGhpcyBzZWN0aW9uIGkgZm91bmQgaXQgaGFyZCB0byByZWFkIHRo ZSB0ZXJtICJ3b3JrIgpiZWluZyBkZXNjcmliZWQuIEkgdGhpbmsgInRhc2siIHdvdWxkIGhhdmUg YmVlbiBhIGJldHRlciB0ZXJtaW5vbG9neS4KCkZyb20gYSBkZWZpbml0aW9uIHBlcnNwZWN0aXZl OgpBIHRhc2sgaXMgYSBzZXJpZXMgb2YgcGFyYWxsZWwgYWN0aXZpdHkgdGhhdCBpcyBnbHVlZCBi eSBhIGNvcnJlbGF0b3IuCk9yIHNvbWV0aGluZyBsaWtlIHRoYXQuCgo+NC4xLiAgRnJhbWUgVHlw ZXMKCj4gICBPbmUgZnJhbWUgdHlwZSBoYXMgYmVlbiBkZWZpbmVkIGluIHRoaXMgbGlicmFyeS4K Cj4gICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsKPiAgIHwgRnJhbWUgVHlwZSAgICB8IFN5bm9wc2lzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAo+ICAgfCBOYW1lICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Cj4gICAr LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsKPiAgIHwgQ2h1bmsgICAgICAgICB8IEEgY2h1bmsgaXMgYSBmcmFtZSB0aGF0 IGlzIHBhcnQgb2YgYW4gb3JpZ2luYWwgICAgfAo+ICAgfCAgICAgICAgICAgICAgIHwgbGFyZ2Vy IGZyYW1lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Cj4gICArLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsKCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBQYXJhbGxlbCBGcmFtZSBUeXBlcwoK NC4yLiAgRGF0YSBUeXBlcwoKPiAgIE9uZSBkYXRhIHR5cGUgaGFzIGJlZW4gZGVmaW5lZCBpbiB0 aGlzIGxpYnJhcnkuCgo+ICAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCj4gICB8IERhdGFUeXBlIE5hbWUgfCBUeXBl ICAgICAgICAgICAgICAgICAgIHwgU3lub3BzaXMgICAgICAgICAgICAgICAgIHwKPiAgICstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKwo+ICAgfCBQYXJhbGxlbFR5cGVzIHwgQXRvbWljIHVjaGFyLiBTcGVjaWFsICB8IFRo ZSB0eXBlIG9mICAgICAgICAgICAgICB8Cj4gICB8ICAgICAgICAgICAgICAgfCBWYWx1ZXMgRmxv b2QgKDApLCAgICAgIHwgcGFyYWxsZWxpemF0aW9uIHRoaXMgICAgIHwKPiAgIHwgICAgICAgICAg ICAgICB8IFNwbGl0ICgxKS4gICAgICAgICAgICAgfCBwYWNrZXQgd2lsbCBnbyB0aHJvdWdoICAg fAo+ICAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rCgo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBhcmFsbGVs IERhdGEgVHlwZXMKCjQuMy4gIE1ldGFEYXRhIFR5cGVzCgo+ICAgVGhlIGZvbGxvd2luZyBtZXRh ZGF0YSBzdHJ1Y3R1cmUgd2l0aCBJRCAxNiwgdXNpbmcgdGhlIEZvckNFUyBtb2RlbAo+ICAgZXh0 ZW5zaW9uIFtJLUQuaWV0Zi1mb3JjZXMtbW9kZWwtZXh0ZW5zaW9uXSwgaXMgZGVmaW5lZCBmb3Ig dGhlCj4gICBwYXJhbGxlbGl6YXRpb24gbGlicmFyeToKCj4gICArLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0rLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKPiAgIHwg ICBNZXRhZGF0YSBOYW1lICAgIHwgIFR5cGUgIHwgSUQgfCAgICAgICAgICAgIFN5bm9wc2lzICAg ICAgICAgICAgfAo+ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCj4gICB8ICAgIFBhcmFsbGVsVHlwZSAgICB8IHVj aGFyICB8IDEgIHwgIFRoZSB0eXBlIG9mIHBhcmFsbGVsaXphdGlvbiAgIHwKPiAgIHwgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgIHwgICAgfCB0aGlzIHBhY2tldCB3aWxsIGdvIHRocm91Z2gu IDAgfAo+ICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICB8ICAgIGZvciBmbG9v ZCwgMSBmb3Igc3BsaXQuICAgICB8Cj4gICB8ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8 ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKPiAgIHwgICAgIENvcnJlbGF0 b3IgICAgIHwgdWludDMyIHwgMiAgfCAgQW4gaWRlbnRpZmljYXRpb24gbnVtYmVyIHRvICAgfAo+ ICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICB8IHNwZWNpZnkgdGhhdCBwYWNr ZXRzIG9yIGNodW5rcyB8Cj4gICB8ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgIHwg IGJlbG9uZyB0byB0aGUgc2FtZSBwYXJhbGxlbCAgIHwKPiAgIHwgICAgICAgICAgICAgICAgICAg IHwgICAgICAgIHwgICAgfCAgICAgICAgICAgICB3b3JrLiAgICAgICAgICAgICAgfAo+ICAgfCAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8Cj4gICB8ICAgIFBhcmFsbGVsTnVtICAgICB8IHVpbnQzMiB8IDMgIHwgICBEZWZp bmVzIHRoZSBudW1iZXIgb2YgdGhlICAgIHwKPiAgIHwgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgIHwgICAgfCAgc3BlY2lmaWMgcGFja2V0IG9yIGNodW5rIG9mICAgfAo+ICAgfCAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgfCAgICB8ICAgdGhlIHNwZWNpZmljIHBhcmFsbGVsIElELiAg ICB8Cj4gICB8ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKPiAgIHwgUGFyYWxsZWxQYXJ0c0NvdW50IHwgdWludDMyIHwg NCAgfCAgRGVmaW5lcyB0aGUgdG90YWwgbnVtYmVyIG9mICAgfAo+ICAgfCAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgfCAgICB8ICAgcGFja2V0cyBvciBjaHVua3MgZm9yIHRoZSAgICB8Cj4g ICB8ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgIHwgICAgIHNwZWNpZmljIHBhcmFs bGVsIElELiAgICAgIHwKPiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKPiAgICAgICAgICAgICAgICAgICAgICBN ZXRhZGF0YSBTdHJ1Y3R1cmUgZm9yIE1lcmdpbmcKCj41LiAgUGFyYWxsZWwgTEZCcwoKPjUuMS4g IFNwbGl0dGVyCgo+ICAgQSBzcGxpdHRlciBMRkIgdGFrZXMgcGFydCBpbiBwYXJhbGxlbGl6aW5n IHRoZSBwcm9jZXNzaW5nIGRhdGFwYXRoIGJ5Cj4gICBzZW5kaW5nIGVpdGhlciB0aGUgc2FtZSBw YWNrZXQgb3IgY2h1bmtzIG9mIHRoZSBzYW1lIHBhY2tldCB0bwo+ICAgbXVsdGlwbGUgTEZCcy4K CkkgdGhpbmsgYSByZWZlcmVuY2UgdG8gb25lIG9mIHRoZSBlYXJsaWVyIGZpZ3VyZXMgaGVyZSB3 b3VsZCBpbXByb3ZlCnJlYWRhYmlsaXR5LgoKQWN0dWFsbHkgZXZlbiBiZXR0ZXIgYSBuZXcgZGlh Z3JhbSB3aGljaCBzaG93cyBhbGwgdGhlIHBvcnRzIG9mCnRoZSBzcGxpdHRlciB3b3VsZCBiZSB1 c2VmdWwuCgo+NS4xLjEuICBEYXRhIEhhbmRsaW5nCgo+ICAgVGhlIHNwbGl0dGVyIExGQiByZWNl aXZlcyBhbnkga2luZCBvZiBwYWNrZXQgdmlhIHRoZSBzaW5nbGV0b24gaW5wdXQsCj4gICBJbnB1 dC4gIAoKRm9yIGNvbnNpc3RlbmN5IHNha2UsIGNvdWxkIHlvdSBzdGljayB0byBuYW1pbmcgdGhh dCBwb3J0IHNvbWV0aGluZwpsaWtlICJTcGxpdHRlckluIj8KCj5EZXBlbmRpbmcgdXBvbiB0aGUg Q0UncyBjb25maWd1cmF0aW9uIG9mIHRoZSBQYXJhbGxlbFR5cGUKPiAgIGNvbXBvbmVudCwgaWYg dGhlIHBhcmFsbGVsIHR5cGUgaXMgb2YgdHlwZSBmbG9vZCAoMCksIHRoZSBzYW1lIHBhY2tldAo+ ICAgTVVTVCBiZSBzZW50IHRocm91Z2ggYWxsIG9mIHRoZSBncm91cCBvdXRwdXQgUGFyYWxsZWxP dXQncyBpbnN0YW5jZXMuCj4gICBJZiB0aGUgcGFyYWxsZWwgdHlwZSBpcyBvZiB0eXBlIHNwbGl0 ICgxKSwgdGhlIHBhY2tldCB3aWxsIGJlIHNwbGl0Cj4gICBpbnRvIHNhbWUgc2l6ZSBjaHVua3Mg ZXhjZXB0IHRoZSBsYXN0IHdoaWNoIE1BWSBiZSBzbWFsbGVyLCB3aXRoIHRoZQo+ICAgbWF4IHNp emUgYmVpbmcgZGVmaW5lZCBieSB0aGUgQ2h1bmtTaXplIGNvbXBvbmVudC4gIEFsbCBjaHVua3Mg d2lsbAo+ICAgYmUgc2VudCBvdXQgaW4gYSByb3VuZC1yb2JpbiBmYXNoaW9uIHRocm91Z2ggdGhl IGdyb3VwIG91dHB1dAo+ICAgUGFyYWxsZWxPdXQncyBpbnN0YW5jZXMuICBFYWNoIHBhY2tldCBv ciBjaHVuayB3aWxsIGJlIGFjY29tcGFuaWVkIGJ5Cj4gICB0aGUgZm9sbG93aW5nIG1ldGFkYXRh IHNldCBhcyBhIHN0cnVjdCA6Cgo+ICAgbyAgUGFyYWxsZWxUeXBlIC0gVGhlIHBhcmFsbGVsdHlw ZSBzcGxpdCBvciBmbG9vZC4KCj4gICBvICBQYXJhbGxlbCBJRCAtIGdlbmVyYXRlZCBieSB0aGUg c3BsaXR0ZXIgTEZCIHRvIGlkZW50aWZ5IHRoYXQKPiAgICAgIGNodW5rcyBvciBwYWNrZXRzIGJl bG9uZyB0byB0aGUgc2FtZSBwYXJhbGxlbCB3b3JrLgoKCiJ0YXNrIiB3b3VsZCBiZSBhIGJldHRl ciB0ZXJtIHRoYW4gIndvcmsiCgo+ICAgbyAgUGFyYWxsZWwgTnVtIC0gZWFjaCBjaHVuayBvciBw YWNrZXQgb2YgYSBwYXJhbGxlbCBpZCB3aWxsIGJlCj4gICAgICBhc3NpZ25lZCBhIG51bWJlciBp biBvcmRlciBmb3IgdGhlIG1lcmdlciBMRkIgdG8ga25vdyB3aGVuIGl0IGhhcwo+ICAgICAgZ2F0 aGVyZWQgdGhlbSBhbGwgYWxvbmcgd2l0aCB0aGUgUGFyYWxsZWxQYXJ0c0NvdW50IG1ldGFkYXRh LgoKPiAgIG8gIFBhcmFsbGVsUGFydHNDb3VudCAtIHRoZSBudW1iZXIgb2YgY2h1bmtzIG9yIHBh Y2tldHMgZm9yIHRoZQo+ICAgICAgc3BlY2lmaWMgcGFyYWxsZWwgaWQuCgo+NS4xLjIuICBDb21w b25lbnRzCgo+ICAgVGhpcyBMRkIgaGFzIG9ubHkgdHdvIGNvbXBvbmVudHMgc3BlY2lmaWVkLiAg VGhlIGZpcnN0IGlzIHRoZQo+ICAgUGFyYWxsZWxUeXBlLCBhbiB1aW50MzIgdGhhdCBkZWZpbmVz IGhvdyB0aGUgcGFja2V0IHdpbGwgYmUgcHJvY2Vzc2VkCj4gICBieSB0aGUgU3BsaXR0ZXIgTEZC LiAgVGhlIHNlY29uZCBpcyB0aGUgQ2h1bmtTaXplLCBhbiB1aW50MzIgdGhhdAo+ICAgc3BlY2lm aWVzIHRoZSBtYXhpbXVtIHNpemUgb2YgYSBjaHVuayB3aGVuIGEgcGFja2V0IGlzIHNwbGl0IGlu dG8KPiAgIG11bHRpcGxlIHNhbWUgc2l6ZSBjaHVua3MuCgo+NS4xLjMuICBDYXBhYmlsaXRpZXMK Cj4gICBUaGlzIExGQiBoYXMgb25seSBvbmUgY2FwYWJpbGl0eSBzcGVjaWZpZWQsIHRoZSBNaW5N YXhDaHVua1NpemUgYQo+ICAgc3RydWN0IG9mIGEgdWludDMyIHRvIHNwZWNpZnkgdGhlIG1pbmlt dW0gY2h1bmsgc2l6ZSBhbmQgYSB1aW50MzIgdG8KPiAgIHNwZWNpZnkgdGhlIG1heGltdW0gY2h1 bmsgc2l6ZS4KCiJhIHN0cnVjdCBvZiB0d28gdWludDMyIGNvbXBvbmVudHMgdG8gc3BlY2lmeSB0 aGUgbWluaW11bSBhbmQgbWF4aW11bQpjaHVuayBzaXplcyIKCj41LjEuNC4gIEV2ZW50cwoKPiAg IFRoaXMgTEZCIGhhcyBubyBldmVudHMgc3BlY2lmaWVkLgoKPjUuMi4gIE1lcmdlcgoKPiAgIEEg bWVyZ2VyIExGQiByZWNlaXZlcyBtdWx0aXBsZSBwYWNrZXRzIG9yIG11bHRpcGxlIGNodW5rcyBv ZiB0aGUgc2FtZQo+ICAgcGFja2V0IGFuZCBtZXJnZSB0aGVtIGludG8gb25lIG1lcmdlZCBwYWNr ZXQuCgpzb21lIHJlZHVuZGFuY3kgdGhlcmUsIG5vdCBxdWl0ZSBzdXJlIGhvdyBiZXN0IHRvIGhh bmRsZSBpdDoKIkEgbWVyZ2UgTEZCIGlzIHRoZSBzeW5jaHJvbml6YXRpb24gcG9pbnQgZm9yIG11 bHRpcGxlIHBhY2tldHMgb3IgCnBhY2tldCBjaHVua3MgZW1hbmF0aW5nIG91dCBvZiB0aGUgcGFy YWxsZWwgcGF0aCBhcyBpbGx1c3RyYXRlZCBpbgp4eHh4LiAiClNhbWUgY29tbWVudCBhcyB0aGUg c3BsaXR0ZXIgLSBhIGRpYWdyYW0gd2l0aCBhIGxpdHRsZSBtb3JlCm1pY3Jvc2NvcGljIGRldGFp bHMgd291bGQgaGVscC4KCj41LjIuMS4gIERhdGEgSGFuZGxpbmcKCj4gICBUaGUgTWVyZ2VyIExG QiByZWNlaXZlcyBlaXRoZXIgYSBwYWNrZXQgb3IgYSBjaHVuayB2aWEgdGhlIGdyb3VwCj4gICBp bnB1dCBQYXJhbGxlbEluLCBhbG9uZyB3aXRoIHRoZSBQYXJhbGxlbFR5cGUgbWV0YWRhdGEgdG8g aWRlbnRpZnkKPiAgIHdoZXRoZXIgd2hhdCB3YXMgcmVjZWl2ZWQgd2FzIGEgcGFja2V0IG9yIGEg Y2h1bmssIHRoZSBDb3JyZWxhdG9yLAo+ICAgdGhlIFBhcmFsbGVsTnVtIGFuZCB0aGUgUGFyYWxs ZWxQYXJ0c0NvdW50LgoKPiAgIEluIGNhc2UgdGhhdCBhbiBMRkIgaGFzIGRyb3BwZWQgYSBwYWNr ZXQgb3IgYSBjaHVuayB3aXRoaW4gYSBwYXJhbGxlbAoKPiAgIHBhdGggdGhlIG1lcmdlciBMRkIg TUFZIHJlY2VpdmUgb25seSB0aGUgbWV0YWRhdGEgb3IgYm90aCBtZXRhZGF0YQo+ICAgYW5kIHBh Y2tldCBvciBjaHVuayB0aHJvdWdoIHRoZSBJbnZhbGlkSW4gZ3JvdXAgaW5wdXQgcG9ydC4gCj4g SXQgIFNIT1VMRCByZWNlaXZlIGEgbWV0YWRhdGEgc3BlY2lmeWluZyB0aGUgZXJyb3IgY29kZS4g CgpXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIGludHJvZHVjZSB0aGUgY29uY2VwdCBvZiBhICJkb3du c3RyZWFtIiBMRkJzCmZvciBkZXNjcmlwdGlvbiBwdXJwb3Nlcz8gVGhlbiB0aGlzIHdvdWxkIHJl YWQgYXMgImluIGEgY2FzZSBvZiBhCmRvd25zdHJlYW0gTEZCIGRyb3BwaW5nIGEgcGFja2V0IG9y IGNodW5rLCB0aGUgbWVyZ2VyIExGQiBtYXkgdGhlbgpyZWNlaXZlIG9ubHkgdGhlIG1ldGFkYXRh IHNwZWNpZnlpbmcgdGhlIGVycm9yIGNvZGUgdmlhIGl0cyAKSW52YWxpZEluIGdyb3VwIGlucHV0 IHBvcnQuIgoKPiAgQ3VycmVudCBkZWZpbmVkCgoiQ3VycmVudGx5IiAKCj4gICBtZXRhZGF0YSdz IGluIHRoZSBCYXNlIExGQiBMaWJyYXJ5IFtSRkM2OTU2XSBhcmUgdGhlIEV4Y2VwdGlvbklEIGFu ZAo+ICAgdGhlIFZhbGlkYXRlRXJyb3JJRC4gIFRoZSBNZXJnZXIgTEZCIE1BWSBzdG9yZSB0aGUg cGFyYWxsZWwgbWV0YWRhdGEKPiAgIGFsb25nIHdpdGggdGhlIGV4Y2VwdGlvbiBtZXRhZGF0YSBh cyBhIHN0cmluZyBpbiB0aGUgb3B0aW9uYWwKPiAgIEludmFsaWRlTWV0YWRhdGFTZXRzIGFzIGEg bWVhbnMgZm9yIHRoZSBDRSB0byBkZWJ1ZyBlcnJvcnMgaW4gdGhlCj4gICBwYXJhbGxlbCBwYXRo LgoKPiAgIElmIHRoZSBNZXJnZVdhaXRUeXBlIGlzIHNldCB0byBmYWxzZSB0aGUgTWVyZ2VyIExG QiB3aWxsIGluaXRpYXRlIHRoZQo+ICAgbWVyZ2UgcHJvY2VzcyB1cG9uIHJlY2VpdmluZyB0aGUg Zmlyc3QgcGFja2V0LiAgSWYgZmFsc2UgaXQgd2lsbCB3YWl0Cj4gICBmb3IgYWxsIHBhY2tldCBp biB0aGUgQ29ycmVsYXRvciB0byBhcnJpdmUuCgo+ICAgSWYgb25lIHBhY2tldCBvciBjaHVuayBo YXMgYmVlbiByZWNlaXZlZCB0aHJvdWdoIHRoZSBJbnZhbGlkSW4gcG9ydAo+ICAgdGhlbiB0aGUg bWVyZ2luZyBwcm9jZWR1cmUgd2lsbCBiZSBvcGVyYXRlIGFzIGNvbmZpZ3VyZWQgYnkgdGhlCgpy ZW1vdmUgImJlIgoKPiAgIEludmFsaWRBY3Rpb24gY29tcG9uZW50LiAgSWYgdGhlIEludmFsaWRB Y3Rpb24gY29tcG9uZW50IGhhcyBiZWVuIHNldAoKSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgYXQg dGhpcyBwb2ludCB0byBiZSBleHBsaWNpdCBhbmQgcmVtaW5kIHRoZQpyZWFkZXIgd2hhdCAid2ls bCBvcGVyYXRlIGFzIGNvbmZpZ3VyZWQiIG1lYW5zLiAKCj4gICB0byAwIHRoZW4gaWYgb25lIHBh Y2tldCBvciBjaHVuayBpcyBub3QgdmFsaWQgYWxsIHdpbGwgZHJvcHBlZCwgZWxzZQo+ICAgdGhl IHByb2Nlc3Mgd2lsbCBpbml0aWF0ZS4gIE9uY2UgdGhlIG1lcmdpbmcgcHJvY2VzcyBoYXMgYmVl bgo+ICAgZmluaXNoZWQgdGhlIHJlc3VsdGluZyBwYWNrZXQgd2lsbCBiZSBzZW50IHZpYSB0aGUg c2luZ2xldG9uIG91dHB1dAoKcy9maW5pc2hlZC9jb21wbGV0ZWQKCj4gICBwb3J0IFBhY2tldE91 dHB1dC4KCj4gICBJZiB0aGUgTWVyZ2VyIExGQiByZWNlaXZlcyBkaWZmZXJlbnQgdmFsdWVzIGZv ciB0aGUgc2FtZSBtZXRhZGF0YQo+ICAgZnJvbSBkaWZmZXJlbnQgcGFja2V0cyBvciBjaHVua3Mg dGhhdCBoYXMgdGhlIHNhbWUgY29ycmVsYXRvciB0aGVuCj4gICB0aGUgTWVyZ2VyIExGQiB3aWxs IHVzZSB0aGUgZmlyc3QgbWV0YWRhdGEgZnJvbSBhIHBhY2tldCBvciBjaHVuawo+ICAgdGhhdCBl bnRlcmVkIHRoZSBMRkIgdGhyb3VnaCB0aGUgUGFyYWxsZWxJbiBpbnB1dCBwb3J0LgoKUGVyaGFw cyBmb3IgYmV0dGVyIHJlYWRhYmlsaXR5LCBwdXQgdGhlIGFib3ZlIHBvaW50cyB5b3UgYXJlIG1h a2luZwppbiBidWxsZXQgZm9ybT8KCgo+NS4yLjIuICBDb21wb25lbnRzCgo+ICAgVGhpcyBMRkIg aGFzIHRoZSBmb2xsb3dpbmcgY29tcG9uZW50cyBzcGVjaWZpZWQ6Cj4gICAxLiAgSW52YWxpZEFj dGlvbiAtIGEgdWNoYXIgZGVmaW5pbmcgd2hhdCB0aGUgTWVyZ2UgTEZCIHdpbGwgZG8gaWYgYW4K PiAgICAgICBpbnZhbGlkIGNodW5rIG9yIHBhY2tldCBpcyByZWNlaXZlZC4gIElmIHNldCB0byAw IChEcm9wQWxsKSB0aGUKPiAgICAgICBtZXJnZSB3aWxsIGJlIGNvbnNpZGVyZWQgaW52YWxpZCBh bmQgYWxsIGNodW5rcyBvciBwYWNrZXRzIHdpbGwKPiAgICAgICBiZSBkcm9wcGVkLiAgSWYgc2V0 IHRvIDEgKENvbnRpbnVlKSB0aGUgbWVyZ2Ugd2lsbCBjb250aW51ZS4KCkRvIHlvdSBhbnRpY2lw YXRlIHBvc3NpYmxlIGZ1dHVyZSB2YWx1ZXMgb3RoZXIgdGhhbiB0aG9zZSB0d28/Cm90aGVyd2lz ZSBhIGJvb2xlYW4gd291bGQgYmUgc3VmZmljaWVudAoKPiAgIDIuICBNZXJnZVdhaXRUeXBlIC0g YSBib29sZWFuLiAgSWYgdHJ1ZSB0aGUgTWVyZ2VyIExGQiB3aWxsIHdhaXQgZm9yCj4gICAgICAg YWxsIHBhY2tldHMgb3IgY2h1bmtzIHRvIGJlIHJlY2VpdmVkIHByaW9yIHRvIHNlbmRpbmcgb3V0 IGEKPiAgICAgICByZXNwb25zZS4gIElmIGZhbHNlLCB3aGVuIG9uZSBwYWNrZXQgb3IgYSBjaHVu ayB3aXRoIGEgcmVzcG9uc2UKPiAgICAgICBpcyByZWNlaXZlZCBieSB0aGUgbWVyZ2UgTEZCIGl0 IHdpbGwgc3RhcnQgd2l0aCB0aGUgbWVyZ2UKPiAgICAgICBwcm9jZXNzLgoKQSByZXNwb25zZSBp bXBsaWVzIHRoZXJlIHdhcyBhIHJlcXVlc3QuIFdoZXJlIGlzIHRoaXMgcmVzcG9uc2UgYmVpbmcg c2VudAp0byB3aGF0IHJlcXVlc3RpbmcgZW50aXR5PwpBbHNvIHdoYXQgaGFwcGVucyB1cG9uIGZh aWx1cmUgdG8gcmVjZWl2ZSBhbGwgY2h1bmtzPyBJcyB0aGVyZSBhIHRpbWVvdXQKcGVyaW9kPwoK PiAgIDMuICBJbnZhbGlkTWVyZ2VzQ291bnRlciAtIGEgdWludDMyIHRoYXQgY291bnRzIHRoZSBu dW1iZXIgb2YgbWVyZ2VzCj4gICAgICAgd2hlcmUgdGhlcmUgaXMgYXQgbGVhc3Qgb25lIHBhY2tl dCBvciBjaHVuayB0aGF0IGVudGVyZWQgdGhlCj4gICAgICAgbWVyZ2VyIExGQiB0aHJvdWdoIHRo ZSBJbnZhbGlkSW4gaW5wdXQgcG9ydC4KCj4gICA0LiAgSW52YWxpZEFsbENvdW50ZXIgLSBhIHVp bnQgMzIgdGhhdCBjb3VudHMgdGhlIG51bWJlciBvZiBtZXJnZXMKPiAgICAgICB3aGVyZSBhbGwg cGFja2V0cy9jaHVua3MgZW50ZXJlZCB0aGUgbWVyZ2VyIExGQiB0aHJvdWdoIHRoZQo+ICAgICAg IEludmFsaWRJbiBpbnB1dCBwb3J0LgoKV291bGQgSW52YWxpZFRvdGFsQ291bnRlciBiZSBhIGJl dHRlciBub3VuPyBhbHNvIHMvYWxsL3RvdGFsCgo+ICAgNS4gIEludmFsaWRJRENvdW50ZXJzIC0g YSBzdHJ1Y3Qgb2YgdHdvIGFycmF5cy4gIEVhY2ggYXJyYXkgaGFzIGEKPiAgICAgICB1aW50MzIg cGVyIHJvdy4gIEVhY2ggYXJyYXkgY291bnRzIG51bWJlciBvZiBpbnZhbGlkIG1lcmdlcyB3aGVy ZQo+ICAgICAgIGF0IGxlYXN0IG9uZSBwYWNrZXQgb3IgY2h1bmsgZW50ZXJlZCB0aHJvdWdoIElu dmFsaWRJRCBwZXIgZXJyb3IKPiAgICAgICBJRC4gIFRoZSBmaXJzdCBhcnJheSBpcyB0aGUgSW52 YWxpZEV4Y2VwdGlvbklEIGFuZCB0aGUgc2Vjb25kIGlzCj4gICAgICAgdGhlIEludmFsaWRWYWxp ZGF0ZUVycm9ySUQuCgpJcyB0aGVyZSBhbiB1cHBlciBib3VuZCB0byB0aGUgbnVtYmVyIG9mIGV4 Y3BldGlvbiBJRHMgb3IgaXMgdGhpcwphcnJheSBkeW5hbWljIGFuZCB0aGUgcm93cyBhcmUgY3Jl YXRlZCBvbiB0aGUgZmx5PwoKPiAgIDYuICBJbnZhbGlkZU1ldGFkYXRhU2V0cyAtIGFuIGFycmF5 IG9mIHN0cmluZ3MuICBBbiBvcHRpb25hbAo+ICAgICAgIGNvbXBvbmVudCB0aGF0IHN0b3JlcyBt ZXRhZGF0YSBzZXRzIGFsb25nIHdpdGggdGhlIGVycm9yIGlkIGFzIGEKPiAgICAgICBzdHJpbmcu ICBUaGlzIGNvdWxkIHByb3ZpZGUgYSBkZWJ1ZyBpbmZvcm1hdGlvbiB0byB0aGUgQ0UKPiAgICAg ICByZWdhcmRpbmcgZXJyb3JzIGluIHRoZSBwYXJhbGxlbCBwYXRocy4KCkl0IHdhc250IGNsZWFy IHRvIG1lIHdoYXQgdGhlIHV0aWxpdHkgb2YgdGhpcyBpcy4gCkF1ZGl0cyB0ZW5kIHRvIGJlIGEg c2VwYXJhdGUgc3Vic3lzdGVtIHdpdGhpbiBhIENFL0ZFIG5vdCB3aXRoaW4KTEZCcy4gU3VnZ2Vz dCB0byByZW1vdmUgaXQuCgo+NS4yLjMuICBDYXBhYmlsaXRpZXMKCj4gICBUaGlzIExGQiBoYXMg bm8gY2FwYWJpbGl0aWVzIHNwZWNpZmllZC4KCjUuMi40LiAgRXZlbnRzCgo+ICAgVGhpcyBMRkIg c3BlY2lmaWVzIG9ubHkgdHdvIGV2ZW50LiAgVGhlIGZpcnN0IGRldGVjdHMgd2hldGhlciB0aGUK PiAgIEludmFsaWRNZXJnZXNDb3VudGVyIGhhcyBleGNlZWRlZCBhIHNwZWNpZmljIHZhbHVlIGFu ZCB0aGUgc2Vjb25kCj4gICBkZXRlY3RzIHdoZXRoZXIgdGhlIEludmFsaWRBbGxDb3VudGVyIGhh cyBleGNlZWRlZCBhIHNwZWNpZmljIHZhbHVlLgo+ICAgQm90aCBlcnJvciByZXBvcnRzIHdpbGwg c2VuZCB0aGUgcmVzcGVjdGl2ZSBjb3VudGVyIHZhbHVlLgoKV2hhdCBoYXBwZW5zIHdoZW4gdGhl c2UgdmFsdWVzIGFyZSBleGNlZWRlZCAtIGlzIHRoZSBjb3VudGVyIHJlc2V0Cm9yIGlzIHRoaXMg YSBvbmUtc2hvdCBldmVudD8KCj41LjMuICBDb3JlUGFyYWxsZWxpemF0aW9uCgo+ICAgQSBjb3Jl IExGQiB0aGF0IHNwZWNpZmllcyB0aGF0IHRoZSBGRSBzdXBwb3J0cyBwYXJhbGxlbGl6YXRpb24s Cj4gICBpbnN0ZWFkIG9mIHVwZGF0aW5nIHRoZSBGRU9iamVjdCBMRkIKCkhvdyBhYm91dDoKIlRo ZSBDb3JlUGFyYWxsZWxpemF0aW9uIExGQiBjbGFzcyBzcGVjaWZpZXMgdGhlIHBhcmFsbGVsaXph dGlvbgpmdW5jdGlvbmFsaXR5IG9mIGEgc3BlY2lmaWMgRkUuIgoKSSBkb250IHNlZSB0aGUgcG9p bnQgb2YgcmVwZWF0aW5nIHlvdXIgZGVjaXNpb24gbm90IHRvIHVzZSAKRkVPYmplY3QgTEZCLgoK PjUuMy4xLiAgRGF0YSBIYW5kbGluZwoKPiAgIFRoZSBDb3JlUGFyYWxsZWxpemF0aW9uIGRvZXMg bm90IGhhbmRsZSBkYXRhLiAgSXQgaXMgYSBjb3JlIExGQiB0aGF0Cj4gICBoYXMgb25seSBvbmUg Y2FwYWJpbGl0eS4KCkkgZG9udCB0aGluayB0aGUgc2Vjb25kIHNlbnRlbmNlIGlzIG5lZWRlZC4K Cj41LjMuMi4gIENvbXBvbmVudHMKCj4gICBUaGlzIExGQiBoYXMgbm8gY29tcG9uZW50cyBzcGVj aWZpZWQuCgo+NS4zLjMuICBDYXBhYmlsaXRpZXMKCgo1LjMuNC4gIEV2ZW50cwoKPiAgIFRoaXMg TEZCIHNwZWNpZmllcyBubyBldmVudHMKCjYuICBYTUwgZm9yIFBhcmFsbGVsIExGQiBsaWJyYXJ5 Cgo+ICA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pgo+ICA8TEZCTGlicmFy eSB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpmb3JjZXM6bGZibW9kZWw6MS4wIgo+ICAg ICB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIgo+ ICAgICB4c2k6c2NoZW1hTG9jYXRpb249InVybjppZXRmOnBhcmFtczp4bWw6bnM6Zm9yY2VzOmxm Ym1vZGVsOjEuMCIKPiAgICAgcHJvdmlkZXM9IlBhcmFsbGVsIj4KPgo+Cj4gICAgICAgICAgICAg IDwvY29tcG9uZW50Pgo+ICAgICAgICAgICAgICA8Y29tcG9uZW50IGNvbXBvbmVudElEPSIyIj4K PiAgICAgICAgICAgICAgICAgPG5hbWU+Q29ycmVsYXRvcjwvbmFtZT4KPiAgICAgICAgICAgICAg ICAgPHN5bm9wc2lzPkFuIGlkZW50aWZpY2F0aW9uIG51bWJlciB0byBzcGVjaWZ5IHRoYXQKPiAg ICAgICAgICAgICAgICAgICAgcGFja2V0cyBvciBjaHVua3Mgb3JpZ2luYXRlIGZyb20gdGhlIHNh bWUgcGFja2V0Lgo+ICAgICAgICAgICAgICAgICA8L3N5bm9wc2lzPgo+ICAgICAgICAgICAgICAg ICA8dHlwZVJlZj51aW50MzI8L3R5cGVSZWY+CgpJZiB5b3Ugd2VyZSB0byB1c2UgdGhlIHRlcm0g InRhc2siIHRoZW4geW91IGNvdWxkIHNheToKIkEgdGFzayBpZGVudGlmaWNhdGlvbiBudW1iZXIg dGhhdCBpcyB1c2VkIHRvIGdyb3VwIHRvZ2V0aGVyIApwYWNrZXRzIG9yIGNodW5rcyB0aGF0IGJl bG9uZyB0byB0aGUgc2FtZSB0YXNrIgoKPiAgICAgICAgICAgPG91dHB1dFBvcnRzPgo+ICAgICAg ICAgICAgICA8b3V0cHV0UG9ydCBncm91cD0idHJ1ZSI+Cj4gICAgICAgICAgICAgICAgIDxuYW1l PlBhcmFsbGVsT3V0PC9uYW1lPgo+ICAgICAgICAgICAgICAgICA8c3lub3BzaXM+QW4gcGFyYWxs ZWwgb3V0cHV0IHBvcnQgdGhhdCBzZW5kcyB0aGUgc2FtZQoKIiBBIHBhcmFsbGVsIgoKVGhpcyBz ZWVtZWQgdG8gaGF2ZSBiZWVuIGN1dG5wYXN0ZWQgaW4gYSBmZXcgcGxhY2VzIC0gcGxlYXNlIGNo ZWNrIHJlc3QKb2YgeG1sLgoKPiAgICAgICAgICAgICAgICAgICAgcGFja2V0IHRvIGFsbCBvdXRw dXQgaW5zdGFuY2VzIG9yIGNodW5rcyBvZiB0aGUgc2FtZQo+ICAgICAgICAgICAgICAgICAgICBw YWNrZXQgZGlmZmVyZW50IGNodW5rIG9uIGVhY2ggaW5zdGFuY2UuPC9zeW5vcHNpcz4KPiAgICAg ICAgICAgICAgICAgPHByb2R1Y3Q+Cj4gICAgICAgICAgICAgICAgICAgIDxmcmFtZVByb2R1Y2Vk Pgo+ICAgICAgICAgICAgICAgICAgICAgICA8cmVmPkFyYml0cmFyeTwvcmVmPgo+ICAgICAgICAg ICAgICAgICAgICAgICA8cmVmPkNodW5rPC9yZWY+Cj4gICAgICAgICAgICAgICAgICAgIDwvZnJh bWVQcm9kdWNlZD4KPiAgICAgICAgICAgICAgICAgICAgPG1ldGFkYXRhUHJvZHVjZWQ+Cj4gICAg ICAgICAgICAgICAgICAgICAgIDxyZWY+UGFyYWxsZWxNZXRhZGF0YVNldDwvcmVmPgo+ICAgICAg ICAgICAgICAgICAgICA8L21ldGFkYXRhUHJvZHVjZWQ+Cj4gICAgICAgICAgICAgICAgIDwvcHJv ZHVjdD4KPiAgICAgICAgICAgICAgPC9vdXRwdXRQb3J0Pgo+ICAgICAgICAgICA8L291dHB1dFBv cnRzPgo+ICAgICAgICAgICA8Y29tcG9uZW50cz4KCgpBcmUgdGhlIGV2ZW50IGRlZmluaXRpb25z IGJlbG93IGN1dG5wYXN0ZSBlcnJvcnM/IFRoZXkgbG9vawp0aGUgc2FtZSB0byBtZS4KV2hlcmUg aXMgTWFueUludmFsaWRzIHRhbGtlZCBhYm91dD8KUGxlYXNlIGRvdWJsZSBjaGVjayB0aGUgeG1s IGFnYWluc3QgdGhlIHRleHQgdG8gbWFrZSBzdXJlCm5vIG1vcmUgbGVmdG92ZXJzIGZyb20gcGFz dCB2ZXJzaW9ucyByZW1haW4uCgo+ICAgICAgICAgICA8ZXZlbnRzIGJhc2VJRD0iMzAiPgo+ICAg ICAgICAgICAgICA8ZXZlbnQgZXZlbnRJRD0iMSI+Cj4gICAgICAgICAgICAgICAgIDxuYW1lPk1h bnlJbnZhbGlkczwvbmFtZT4KPiAgICAgICAgICAgICAgICAgPHN5bm9wc2lzPkFuIGV2ZW50IHRo YXQgc3BlY2lmaWVzIGlmIHRoZXJlIGFyZSB0b28gbWFueQo+ICAgICAgICAgICAgICAgICAgICBp bnZhbGlkczwvc3lub3BzaXM+Cj4gICAgICAgICAgICAgICAgIDxldmVudFRhcmdldD4KPiAgICAg ICAgICAgICAgICAgICAgPGV2ZW50RmllbGQ+SW52YWxpZENvdW50ZXI8L2V2ZW50RmllbGQ+Cj4g ICAgICAgICAgICAgICAgIDwvZXZlbnRUYXJnZXQ+Cj4gICAgICAgICAgICAgICAgIDxldmVudEdy ZWF0ZXJUaGFuPjwvZXZlbnRHcmVhdGVyVGhhbj4KPiAgICAgICAgICAgICAgICAgPGV2ZW50UmVw b3J0cz4KPiAgICAgICAgICAgICAgICAgICAgPGV2ZW50UmVwb3J0Pgo+ICAgICAgICAgICAgICAg ICAgICAgICA8ZXZlbnRGaWVsZD5JbnZhbGlkTWVyZ2VzQ291bnRlcjwvZXZlbnRGaWVsZD4KPiAg ICAgICAgICAgICAgICAgICAgPC9ldmVudFJlcG9ydD4KPiAgICAgICAgICAgICAgICAgPC9ldmVu dFJlcG9ydHM+Cj4gICAgICAgICAgICAgIDwvZXZlbnQ+Cj4gICAgICAgICAgICAgIDxldmVudCBl dmVudElEPSIyIj4KPiAgICAgICAgICAgICAgICAgPG5hbWU+TWFueUFsbEludmFsaWRzPC9uYW1l Pgo+ICAgICAgICAgICAgICAgICA8c3lub3BzaXM+QW4gZXZlbnQgdGhhdCBzcGVjaWZpZXMgaWYg dGhlcmUgYXJlIHRvbyBtYW55Cj4gICAgICAgICAgICAgICAgICAgIGludmFsaWRzPC9zeW5vcHNp cz4KPiAgICAgICAgICAgICAgICAgPGV2ZW50VGFyZ2V0Pgo+ICAgICAgICAgICAgICAgICAgICA8 ZXZlbnRGaWVsZD5JbnZhbGlkQ291bnRlcjwvZXZlbnRGaWVsZD4KPiAgICAgICAgICAgICAgICAg PC9ldmVudFRhcmdldD4KPiAgICAgICAgICAgICAgICAgPGV2ZW50R3JlYXRlclRoYW4+PC9ldmVu dEdyZWF0ZXJUaGFuPgo+ICAgICAgICAgICAgICAgICA8ZXZlbnRSZXBvcnRzPgo+ICAgICAgICAg ICAgICAgICAgICA8ZXZlbnRSZXBvcnQ+Cj4gICAgICAgICAgICAgICAgICAgICAgIDxldmVudEZp ZWxkPkludmFsaWRBbGxDb3VudGVyPC9ldmVudEZpZWxkPgo+ICAgICAgICAgICAgICAgICAgICA8 L2V2ZW50UmVwb3J0Pgo+ICAgICAgICAgICAgICAgICA8L2V2ZW50UmVwb3J0cz4KPiAgICAgICAg ICAgICAgPC9ldmVudD4KPiAgICAgICAgICAgPC9ldmVudHM+Cg== --089e01184dc2b6c81004fe38fdf8-- From nobody Tue Jul 15 10:16:35 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72081A0AC4 for ; Tue, 15 Jul 2014 10:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1M_bHIBKH5f for ; Tue, 15 Jul 2014 10:09:40 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFFDB1A0ABB for ; Tue, 15 Jul 2014 10:09:39 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so3778191wgh.10 for ; Tue, 15 Jul 2014 10:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xsY0pCLE8lPgrSYEMEK7FAUl3hf1T2VFsUlCzrmIALs=; b=04Z5Va6OA996a481wEvafxUrb/nqZvvqeMmMd2snmNRExxsZgJNDL/zlOfIFtTjGse Oem37fY2pmw1B58hCn/ZvugJdkjSlathGUQEXMPaPjP2Wp1HN24khVn8MN8HkyM61tfE uBp99HotnhSq+9s+HkqrJYNvIGqQIdbTgcAu1anechDr82qqIlN0hsLO5GyuK/XgjcYV QR7TV6xRL9uE626rGYtoY1rj1MIJfbXzdIQqvSoaU5EtAsRV3yst/XLtes5NM7pcmwbk sRpYE0ufE0XdiqXwrbxATYQGj8ojymGVpb5vNDyINZSjPGgVxJvdToSl3+7Yk7EjHs0f Fndg== MIME-Version: 1.0 X-Received: by 10.194.20.230 with SMTP id q6mr29576453wje.43.1405444178361; Tue, 15 Jul 2014 10:09:38 -0700 (PDT) Received: by 10.217.148.67 with HTTP; Tue, 15 Jul 2014 10:09:38 -0700 (PDT) Date: Tue, 15 Jul 2014 13:09:38 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: "forces@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d971b00c5dd04fe3e79fd Archived-At: http://mailarchive.ietf.org/arch/msg/forces/NS-HDq0egEjlEzLEfbOiUQM6ZO8 Subject: [forces] Requesting further comments/suggestions on IETF ForCES Logical Function Block (LFB) Subsidiary Management dratf X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 17:09:42 -0000 --047d7b5d971b00c5dd04fe3e79fd Content-Type: text/plain; charset=UTF-8 Dear All, We are planning to release updates to the LFB Subsidiary Management draft ( http://datatracker.ietf.org/doc/draft-khs-forces-lfb-subsidiary-management/ ) very soon. Kindly let us know ASAP if you have any further comments/suggestions. Many thanks in advance. Best. Draft Authors +++++++++++++++++++++++++++++++++++++++ Network Working Group B. Khasnabish Internet-Draft ZTE TX, Inc. Intended status: Standards Track E. Haleplidis Expires: August 14, 2014 University of Patras J. Hadi Salim Mojatatu Networks February 10, 2014 IETF ForCES Logical Function Block (LFB) Subsidiary Management draft-khs-forces-lfb-subsidiary-management-00.txt Abstract This document discusses ForCES Logical Function Block (LFB) Subsidiary Management (SM). Note that LFB SM is useful for introducing and supporting virtualization of ForCES Network Element (NE) including control Element (CE) and Forwarding Element (FE). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 14, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Khasnabish, et al. Expires August 14, 2014 [Page 1] Internet-Draft IETF ForCES LFB Subsidiary Management February 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Conventions and Definitions . . . . . . . . . . . . . . . 4 2. Use of Virtualized ForCES Elements . . . . . . . . . . . . . 5 2.1. Use of Virtualized CEs . . . . . . . . . . . . . . . . . 5 2.2. Use of Virtualized FEs . . . . . . . . . . . . . . . . . 6 3. Potential Scenarios . . . . . . . . . . . . . . . . . . . . . 6 3.1. Recovery from CE failure . . . . . . . . . . . . . . . . 6 3.2. Recovery from FE failure . . . . . . . . . . . . . . . . 6 3.3. Load Balancing . . . . . . . . . . . . . . . . . . . . . 6 3.4. Scalable/Robust Service Function Chaining . . . . . . . . 6 3.5. Orchestration . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Generic LFB Lifecycle Management . . . . . . . . . . . . 6 3.6.1. Booting a CE/FE . . . . . . . . . . . . . . . . . . . 7 3.6.2. Bootstrapping the Configuration . . . . . . . . . . . 7 3.6.3. Runtime Management . . . . . . . . . . . . . . . . . 7 4. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . 7 5. Reference Implementation . . . . . . . . . . . . . . . . . . 7 6. FEM Library . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Frame Definitions . . . . . . . . . . . . . . . . . . . . 7 6.2. Datatype Definitions . . . . . . . . . . . . . . . . . . 7 6.3. Metadata Definitions . . . . . . . . . . . . . . . . . . 8 6.4. FEM . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.4.1. Data Handling . . . . . . . . . . . . . . . . . . . . 8 6.4.2. Components . . . . . . . . . . . . . . . . . . . . . 8 6.4.3. Capabilities . . . . . . . . . . . . . . . . . . . . 9 6.4.4. Events . . . . . . . . . . . . . . . . . . . . . . . 9 7. XML for FEM LFB . . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 13 --047d7b5d971b00c5dd04fe3e79fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
=C2=A0
We are planning to release updates to=C2=A0the LFB
Subsidiary M= anagement draft
( http://datatracker.ietf.org= /doc/draft-khs-forces-lfb-subsidiary-management/ )
very soon.
=C2=A0
Kindly let us know ASAP if you have any =C2=A0
further comments/= suggestions.
=C2=A0
Many thanks in advance.
=C2=A0
Best.
=C2=A0
Draft Authors
=C2=A0
=C2=A0
++++++++++++++++++++++++++++++++++++++= +
Network Working Group=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 B. Khasnabish
Internet-Draft=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ZTE TX, Inc.
Intended status: Standards Track=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 E. Haleplidis
Expires: August 14, 2014=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 University of Patras
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 J. Hadi Salim
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Mojatatu Networks
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 February 10, 2014

=C2=A0=C2=A0=C2=A0=C2=A0 = IETF ForCES Logical Function Block (LFB) Subsidiary Management
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-khs-forces-lfb-su= bsidiary-management-00.txt

Abstract

=C2=A0=C2=A0 This document discusses ForCES Logical Function Block (LFB= )
=C2=A0=C2=A0 Subsidiary Management (SM).=C2=A0 Note that LFB SM is use= ful for
=C2=A0=C2=A0 introducing and supporting virtualization of ForCES= Network Element
=C2=A0=C2=A0 (NE) including control Element (CE) and Fo= rwarding Element (FE).

Status of This Memo

=C2=A0=C2=A0 This Internet-Draf= t is submitted in full conformance with the
=C2=A0=C2=A0 provisions of B= CP 78 and BCP 79.

=C2=A0=C2=A0 Internet-Drafts are working documents= of the Internet Engineering
=C2=A0=C2=A0 Task Force (IETF).=C2=A0 Note that other groups may also distr= ibute
=C2=A0=C2=A0 working documents as Internet-Drafts.=C2=A0 The list = of current Internet-
=C2=A0=C2=A0 Drafts is at http://datatracker.ietf.org/drafts/current/<= /a>.

=C2=A0=C2=A0 Internet-Drafts are draft documents valid for a maximum of= six months
=C2=A0=C2=A0 and may be updated, replaced, or obsoleted by o= ther documents at any
=C2=A0=C2=A0 time.=C2=A0 It is inappropriate to us= e Internet-Drafts as reference
=C2=A0=C2=A0 material or to cite them other than as "work in progress.= "

=C2=A0=C2=A0 This Internet-Draft will expire on August 14, 20= 14.

Copyright Notice

=C2=A0=C2=A0 Copyright (c) = 2014 IETF Trust and the persons identified as the
=C2=A0=C2=A0 document authors.=C2=A0 All rights reserved.

=C2=A0=C2= =A0 This document is subject to BCP 78 and the IETF Trust's Legal
= =C2=A0=C2=A0 Provisions Relating to IETF Documents
=C2=A0=C2=A0 (http://trustee.ietf.org/license-i= nfo) in effect on the date of
=C2=A0=C2=A0 publication of this document.=C2=A0 Please review these docume= nts
=C2=A0=C2=A0 carefully, as they describe your rights and restriction= s with respect
=C2=A0=C2=A0 to this document.=C2=A0 Code Components extr= acted from this document must
=C2=A0=C2=A0 include Simplified BSD Licens= e text as described in Section 4.e of

Khasnabish, et al. Expires August 14, 2014 [= Page 1]
Internet-Draft IETF ForCES LFB Subsidiary Manage= ment February 2014

=C2=A0=C2=A0 the Trust Legal Provisions= and are provided without warranty as
=C2=A0=C2=A0 described in the Simplified BSD License.

Table of= Contents

=C2=A0=C2=A0 1.=C2=A0 Introduction=C2=A0 . . . . . = . . . . . . . . . . . . . . . . . . .=C2=A0=C2=A0 2
=C2=A0=C2=A0=C2=A0= =C2=A0 1.1.=C2=A0 Scope . . . . . . . . . . . . . . . . . . . . . . . . . .= =C2=A0=C2=A0 3
=C2=A0=C2=A0=C2=A0=C2=A0 1.2.=C2=A0 Abbreviations . . . . . . . . . . . . .= . . . . . . . . .=C2=A0=C2=A0 3
=C2=A0=C2=A0=C2=A0=C2=A0 1.3.=C2=A0 Con= ventions and Definitions . . . . . . . . . . . . . . .=C2=A0=C2=A0 4
=C2= =A0=C2=A0 2.=C2=A0 Use of Virtualized ForCES Elements=C2=A0 . . . . . . . .= . . . . .=C2=A0=C2=A0 5
=C2=A0=C2=A0=C2=A0=C2=A0 2.1.=C2=A0 Use of Virtualized CEs=C2=A0 . . . . . = . . . . . . . . . . . .=C2=A0=C2=A0 5
=C2=A0=C2=A0=C2=A0=C2=A0 2.2.=C2= =A0 Use of Virtualized FEs=C2=A0 . . . . . . . . . . . . . . . . .=C2=A0=C2= =A0 6
=C2=A0=C2=A0 3.=C2=A0 Potential Scenarios . . . . . . . . . . . . = . . . . . . . . .=C2=A0=C2=A0 6
=C2=A0=C2=A0=C2=A0=C2=A0 3.1.=C2=A0 Recovery from CE failure=C2=A0 . . . . = . . . . . . . . . . . .=C2=A0=C2=A0 6
=C2=A0=C2=A0=C2=A0=C2=A0 3.2.=C2= =A0 Recovery from FE failure=C2=A0 . . . . . . . . . . . . . . . .=C2=A0=C2= =A0 6
=C2=A0=C2=A0=C2=A0=C2=A0 3.3.=C2=A0 Load Balancing=C2=A0 . . . . .= . . . . . . . . . . . . . . . .=C2=A0=C2=A0 6
=C2=A0=C2=A0=C2=A0=C2=A0 3.4.=C2=A0 Scalable/Robust Service Function Chaini= ng . . . . . . . .=C2=A0=C2=A0 6
=C2=A0=C2=A0=C2=A0=C2=A0 3.5.=C2=A0 Orc= hestration . . . . . . . . . . . . . . . . . . . . . .=C2=A0=C2=A0 6
=C2= =A0=C2=A0=C2=A0=C2=A0 3.6.=C2=A0 Generic LFB Lifecycle Management=C2=A0 . .= . . . . . . . . . .=C2=A0=C2=A0 6
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3.6.1.=C2=A0 Booting a CE/FE . . . . .= . . . . . . . . . . . . . .=C2=A0=C2=A0 7
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 3.6.2.=C2=A0 Bootstrapping the Configuration . . . . . . . . . . = .=C2=A0=C2=A0 7
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3.6.3.=C2=A0 Runtim= e Management=C2=A0 . . . . . . . . . . . . . . . . .=C2=A0=C2=A0 7
=C2=A0=C2=A0 4.=C2=A0 Testbed Platform=C2=A0 . . . . . . . . . . . . . . . = . . . . . . .=C2=A0=C2=A0 7
=C2=A0=C2=A0 5.=C2=A0 Reference Implementati= on=C2=A0 . . . . . . . . . . . . . . . . . .=C2=A0=C2=A0 7
=C2=A0=C2=A0 = 6.=C2=A0 FEM Library . . . . . . . . . . . . . . . . . . . . . . . . .=C2= =A0=C2=A0 7
=C2=A0=C2=A0=C2=A0=C2=A0 6.1.=C2=A0 Frame Definitions . . . . . . . . . . .= . . . . . . . . .=C2=A0=C2=A0 7
=C2=A0=C2=A0=C2=A0=C2=A0 6.2.=C2=A0 Dat= atype Definitions=C2=A0 . . . . . . . . . . . . . . . . . .=C2=A0=C2=A0 7=C2=A0=C2=A0=C2=A0=C2=A0 6.3.=C2=A0 Metadata Definitions=C2=A0 . . . . . = . . . . . . . . . . . . .=C2=A0=C2=A0 8
=C2=A0=C2=A0=C2=A0=C2=A0 6.4.=C2=A0 FEM . . . . . . . . . . . . . . . . . .= . . . . . . . . .=C2=A0=C2=A0 8
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6.= 4.1.=C2=A0 Data Handling . . . . . . . . . . . . . . . . . . . .=C2=A0=C2= =A0 8
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6.4.2.=C2=A0 Components=C2=A0= . . . . . . . . . . . . . . . . . . . . .=C2=A0=C2=A0 8
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6.4.3.=C2=A0 Capabilities=C2=A0 . . . = . . . . . . . . . . . . . . . . .=C2=A0=C2=A0 9
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 6.4.4.=C2=A0 Events=C2=A0 . . . . . . . . . . . . . . . . . . = . . . . .=C2=A0=C2=A0 9
=C2=A0=C2=A0 7.=C2=A0 XML for FEM LFB . . . . . = . . . . . . . . . . . . . . . . . .=C2=A0=C2=A0 9
=C2=A0=C2=A0 8.=C2=A0 Security Considerations . . . . . . . . . . . . . . .= . . . .=C2=A0 13
=C2=A0=C2=A0 9.=C2=A0 IANA Considerations . . . . . . = . . . . . . . . . . . . . . .=C2=A0 13
=C2=A0=C2=A0=C2=A0=C2=A0 9.1.=C2= =A0 LFB Class Names and LFB Class Identifiers . . . . . . . .=C2=A0 13
--047d7b5d971b00c5dd04fe3e79fd-- From nobody Tue Jul 15 19:09:08 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB46A1B29E9; Tue, 15 Jul 2014 18:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za5HDiCqiGyj; Tue, 15 Jul 2014 18:42:05 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0291B29E5; Tue, 15 Jul 2014 18:42:05 -0700 (PDT) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s6G1UKRq005530; Tue, 15 Jul 2014 18:42:04 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1n4uj9gj60-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 18:42:03 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 15 Jul 2014 18:42:03 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Tue, 15 Jul 2014 18:42:03 -0700 From: ramki Krishnan To: "nfvrg@ieft.org" , "sdn@irtf.org" , "nmrg@irtf.org" , "'sfc@ietf.org'" , "nvo3@ietf.org" , "i2rs@ietf.org" , "forces@ietf.org" , "pce@ietf.org" , "bmwg@ietf.org" Date: Tue, 15 Jul 2014 18:42:01 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+glo0SWV5Tpf8ORV2qBe787uS76g== Message-ID: 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_C7634EB63EFD984A978DFB46EA5174F2C14FFB95FCHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-15_07:2014-07-15,2014-07-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407160014 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/Gr-Na4CRDO_jJAGqhJrnBeFdoJc X-Mailman-Approved-At: Tue, 15 Jul 2014 19:09:06 -0700 Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: [forces] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 01:42:07 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB95FCHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find more information on NFVRG including charter at - http://trac.to= ols.ietf.org/group/irtf/trac/wiki/nfvrg Please find meeting location and agenda at - http://trac.tools.ietf.org/gro= up/irtf/trac/wiki/nfvrg-ietf-90 Thanks, Ramki on behalf of the co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB95FCHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please find more= information on NFVRG including charter at - http://trac.tools.ietf.org/group/irtf/t= rac/wiki/nfvrg

 

=

Please find meeting location and agenda at - http://t= rac.tools.ietf.org/group/irtf/trac/wiki/nfvrg-ietf-90

 

Thanks,

Ramki on behalf of the co-chairs

=
= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB95FCHQ1EXCH01corp_-- From nobody Thu Jul 17 04:50:25 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B77C1A0ADE for ; Thu, 17 Jul 2014 04:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4U-mu6F9KZP for ; Thu, 17 Jul 2014 04:50:21 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7521A0ADA for ; Thu, 17 Jul 2014 04:50:21 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hq11so2752062vcb.30 for ; Thu, 17 Jul 2014 04:50:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=MZSX0SqfX3NFNpk9NMZvgB2oQaAO+/F9t1BusBWgRSY=; b=N8cw4lS2u0gPcnHVF0Na6qAegcJwyCQgKFtBJbSMILL8P8f9J73/PjGHfFrD5AJGM/ VL7YF0NKNYE+GRMvjNgsRHP3SdP3Fj0hbpNoVLMrKnHtzbVQ6yGLcQn2EBBFklqiT3jc zvyS1bdzZrQji9mtfNckvhseeEWgH3XYgZlEg+gsxfgzm4RERXp9io09rWCTzrKkFv/P aDH3mkuHz5AAUcBzKa4NRy8OwfVPwWH34DVWPcfwvZApkvACXM8tj+1Eq8hME2DelVdu qZ+IrWFU3ZkjgKj7DbBZGGuyM4CqYVU0mKGeKEdThvGEkJFe4M53GYhn5lyiqGqRoOSk mgNw== X-Gm-Message-State: ALoCoQn17TrQ3skEv2Kyyb3HHq9wA4UGUuAe5fssSt038bavkIc1U16yWxgO2FwhBD0R7zMaly9c X-Received: by 10.52.227.41 with SMTP id rx9mr3455186vdc.92.1405597820647; Thu, 17 Jul 2014 04:50:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Thu, 17 Jul 2014 04:50:00 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 17 Jul 2014 07:50:00 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/7Ejtj14k5fMJD8MlQQ-jK2W47Co Subject: [forces] Agenda posted X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 11:50:23 -0000 The agenda has been posted. https://datatracker.ietf.org/meeting/90/agenda/forces/ For the presenters - please make sure you send DJ and myself the slides by sunday if possible. cheers, jamal From nobody Thu Jul 17 08:57:28 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ACF1B2AA2 for ; Tue, 15 Jul 2014 22:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6PoX3x022kj for ; Tue, 15 Jul 2014 22:58:47 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A9B1B2A75 for ; Tue, 15 Jul 2014 22:58:47 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s6G5pIpd023307; Tue, 15 Jul 2014 22:58:47 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1n335pj3nv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 22:58:46 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 15 Jul 2014 22:58:46 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::90ed:fc42:a7bb:9406]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Tue, 15 Jul 2014 22:58:46 -0700 From: ramki Krishnan To: "forces@ietf.org" Date: Tue, 15 Jul 2014 22:58:46 -0700 Thread-Topic: Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto Thread-Index: Ac+guv+G+bjtnov9QRygc2XWxIRR2w== Message-ID: 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_C7634EB63EFD984A978DFB46EA5174F2C14FFB9614HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-16_02:2014-07-15,2014-07-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407160073 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/wwXfxETfKcRMA3W2YD98NLenDz0 X-Mailman-Approved-At: Thu, 17 Jul 2014 08:57:25 -0700 Cc: "DIEGO LOPEZ GARCIA \(diego.r.lopez@telefonica.com\)" , "dilikris@in.ibm.com" Subject: [forces] Proposed IRTF Network Functions Virtualization Research Group (NFVRG) - first face-to-face meeting at Toronto X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 05:58:48 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9614HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find more information on NFVRG including charter at - http://trac.to= ols.ietf.org/group/irtf/trac/wiki/nfvrg Please find meeting location and agenda at - http://trac.tools.ietf.org/gro= up/irtf/trac/wiki/nfvrg-ietf-90 Thanks, Ramki on behalf of the co-chairs --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9614HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please find more= information on NFVRG including charter at - http://trac.tools.ietf.org/group/irtf/t= rac/wiki/nfvrg

 

=

Please find meeting location and agenda at - http://t= rac.tools.ietf.org/group/irtf/trac/wiki/nfvrg-ietf-90

 

Thanks,

Ramki on behalf of the co-chairs

=
= --_000_C7634EB63EFD984A978DFB46EA5174F2C14FFB9614HQ1EXCH01corp_-- From nobody Fri Jul 18 10:00:27 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8825E1A0ABE for ; Fri, 18 Jul 2014 10:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L5fNI1UKesU for ; Fri, 18 Jul 2014 10:00:14 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36B11B27A6 for ; Fri, 18 Jul 2014 10:00:11 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so7692611vcb.8 for ; Fri, 18 Jul 2014 10:00:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=GAUm7u5KXtbVG2kOGPrFLmfCQiLto7Go2sRohYl1PgA=; b=f/tLHDjGZX3jVL9TlaWHBeCnSpUDT6hfuwO0M9KeKKnn9jHh01VifBwRYD+UpQQi8X M5G84pSA8JamzGjCyAyvdz2bDUfUet/PA46fxq68n5iqHfvT6ACOKA7arWHWHCRIv9G1 6uBpVz/W4B9tudeRx82IAJOmRKxE3UBZfnvnAA8zy8N12pmN5OGqYisAngvFNPs5uRNr F4y+5y3nll+m/n7efpHJwXOQNy1coJ7CzLjPTMyDpvUduqHnOF9C3/F5Pg29da/KLtN0 45Wj18LZQgsKjn+sQYcgj1XDDhRYWbApjW6uk/bg53LK8PmjMFZdtqr8X5QcZPE7nFzC H9Hg== X-Gm-Message-State: ALoCoQnDBpkvSfY/s+oXbu4m1Td4eKTKYJXJeY2j5qex5rrPbpmlKMdvaHQHBmhuvJFRVQ/tfSjK X-Received: by 10.221.56.5 with SMTP id wa5mr4225748vcb.25.1405702810658; Fri, 18 Jul 2014 10:00:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Fri, 18 Jul 2014 09:59:50 -0700 (PDT) From: Jamal Hadi Salim Date: Fri, 18 Jul 2014 12:59:50 -0400 Message-ID: To: "forces@ietf.org" , "sdn@irtf.org" , nfvrg@irtf.org, vnfpool@ietf.org, nvo3@ietf.org, "i2rs@ietf.org" , sfc Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/6Aw4TBw-S3WeK2BVg6GbWpnxpdg Subject: [forces] BitsnBites ForCES PoC X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 17:00:15 -0000 Folks, I am sorry for spamming all these lists. You are being spammed because you are a cousin of ForCES. We are planning to have a ForCES based NFV/SDN PoC demonstration at the Bits and Bites event on Thursday night (1845-2100 at the Concert Hall). Given it is very hard to give a lot of details in the demo, Evangelos Haleplidis will present more details at the ForCES meeting Monday 15:20 at the Manitoba room. The official blurb is as follows: ------ SANA will demonstrate the proof-of-concept of the applicability of IETF's ForCES framework for both NFV management and SDN control. The ForCES data model will be utilized to describe VNFs, services and the infrastructure definition in a clear, formal and concise approach. The protocol will illustrate SDN control and NFV management of all modelled elements. The setup includes various NFV/SDN entities controlled and managed by the ForCES architecture execute under a singular simple programmatic API regardless of whether they are virtual or physical. The separation of hardware and software is illustrated by the same NF LFB data models implemented in: a)KVM virtual machines, b) Linux containers, c) linux kernel proper and d) ASIC based L2/3 (Broadcom chipset) in white box switches all working in unison. Infrastructure orchestration includes instantiating VMs, containers, applications and setup of basic network connectivity using appropriate ForCES LFBs. Service orchestration is again modelled by ForCES LFBs and both control and management activities for the services are driven by the ForCES protocol. We will illustrate 3GPP S/PGW simple connectivity (NAT-based) service and the advantages gained from (SDN) separating the datapath components of S/PGW from the control as well as (NFV) separation of hardware from software. This PoC is further illustrated in: http://nfvwiki.etsi.org/index.php?title=ForCES_Applicability_for_NFV_and_integrated_SDN -------- Apologies again for the mass email. cheers, jamal From nobody Fri Jul 18 11:53:11 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17481A00EC; Fri, 18 Jul 2014 11:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ3nMPABJmSY; Fri, 18 Jul 2014 11:21:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806F61A0091; Fri, 18 Jul 2014 11:21:09 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.0.990.7; Fri, 18 Jul 2014 18:21:07 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0990.007; Fri, 18 Jul 2014 18:21:07 +0000 From: John E Drake To: Jamal Hadi Salim Thread-Topic: [sfc] BitsnBites ForCES PoC Thread-Index: AQHPoqnB/0IwhlC/pky+GbkxV4TKYpumJMEQ Date: Fri, 18 Jul 2014 18:21:06 +0000 Message-ID: <5B1198B1-1EBF-40D6-BDE7-31A2AD498636@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.100.47] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(189002)(199002)(51704005)(24454002)(92726001)(83322001)(106116001)(74502001)(80022001)(79102001)(36756003)(101416001)(77982001)(110136001)(106356001)(19580395003)(19580405001)(16799955002)(81342001)(99396002)(82746002)(46102001)(15202345003)(87936001)(81542001)(50986999)(64706001)(76176999)(95666004)(54356999)(85852003)(99286002)(86362001)(15188155005)(83716003)(21056001)(74662001)(92566001)(76482001)(33656002)(31966008)(2656002)(15975445006)(4396001)(20776003)(83072002)(85306003)(105586002)(66066001)(107046002)(104396001)(19623215001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/forces/IXSe2zWCAfadSJvjOk8jrBedmAM X-Mailman-Approved-At: Fri, 18 Jul 2014 11:53:07 -0700 Cc: "vnfpool@ietf.org" , "i2rs@ietf.org" , "sdn@irtf.org" , sfc , "nvo3@ietf.org" , "nfvrg@irtf.org" , "forces@ietf.org" Subject: Re: [forces] [sfc] BitsnBites ForCES PoC X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 18:21:11 -0000 Shameless self-aggrandizement=20 Sent from my iPhone > On Jul 18, 2014, at 1:00 PM, "Jamal Hadi Salim" wrote= : >=20 > Folks, >=20 > I am sorry for spamming all these lists. You are being spammed because > you are a cousin of ForCES. >=20 > We are planning to have a ForCES based NFV/SDN PoC demonstration at the > Bits and Bites event on Thursday night (1845-2100 at the Concert Hall). > Given it is very hard to give a lot of details in the demo, Evangelos Hal= eplidis > will present more details at the ForCES meeting Monday 15:20 at the > Manitoba room. >=20 > The official blurb is as follows: > ------ > SANA will demonstrate the proof-of-concept of the applicability of > IETF's ForCES framework for both NFV management and SDN control. > The ForCES data model will be utilized to describe VNFs, services and the > infrastructure definition in a clear, formal and concise approach. > The protocol will illustrate SDN control and NFV management of all > modelled elements. >=20 > The setup includes various NFV/SDN entities controlled and managed by the > ForCES architecture execute under a singular simple programmatic API > regardless of whether they are virtual or physical. The > separation of hardware and software is illustrated by the same NF > LFB data models implemented in: > a)KVM virtual machines, b) Linux containers, c) linux kernel proper > and d) ASIC based L2/3 (Broadcom chipset) in white box switches > all working in unison. >=20 > Infrastructure orchestration includes instantiating VMs, containers, > applications and setup of basic network connectivity using appropriate > ForCES LFBs. > Service orchestration is again modelled by ForCES LFBs and > both control and management activities for the services are driven by > the ForCES protocol. >=20 > We will illustrate 3GPP S/PGW simple connectivity (NAT-based) service > and the advantages > gained from (SDN) separating the datapath components of S/PGW from the co= ntrol > as well as (NFV) separation of hardware from software. >=20 > This PoC is further illustrated in: > http://nfvwiki.etsi.org/index.php?title=3DForCES_Applicability_for_NFV_an= d_integrated_SDN > -------- >=20 > Apologies again for the mass email. >=20 > cheers, > jamal >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Sat Jul 19 07:34:57 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5FA1B2846 for ; Sat, 19 Jul 2014 07:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCWr810brIk5 for ; Sat, 19 Jul 2014 07:34:54 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21E31B2822 for ; Sat, 19 Jul 2014 07:34:53 -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 s6JEYpVN001275; Sat, 19 Jul 2014 15:34:51 +0100 Received: from 950129200 (dhcp-b3fb.meeting.ietf.org [31.133.179.251]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6JEYn1Y001242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 19 Jul 2014 15:34:50 +0100 From: "Adrian Farrel" To: "'Jamal Hadi Salim'" References: In-Reply-To: Date: Sat, 19 Jul 2014 15:34:53 +0100 Message-ID: <03ff01cfa35e$9bd589f0$d3809dd0$@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: AQFgTWvUKqqHDmumSVF242SjqpXsSJyGIcyQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20828.000 X-TM-AS-Result: No--4.072-10.0-31-10 X-imss-scan-details: No--4.072-10.0-31-10 X-TMASE-MatchedRID: u1zqiMeMcro4HKI/yaqRm2gws6g0ewz25IGsYdjJ9rr4JyR+b5tvoC1V nMFTtEXpKS1n4JcsMj4DeguC4DWa/eLt3Dq4XIHxt1AhvyEKdj59LQinZ4QefDuUMbK1NdLP+gt Hj7OwNO2OhzOa6g8KrcYAagDfMVYcIfLrWlYESHpXVFJlthv7iD3LVeZKBAINvhz+uegIleHkP2 yapUEP3KKWedUMQI938fsC+xPFkxvsNp90fT4EjuoLJh5uXtfs Archived-At: http://mailarchive.ietf.org/arch/msg/forces/fXy0lotX7NRfyewpXNYFFFNn6tw Cc: draft-ietf-forces-model-extension.all@tools.ietf.org, forces@ietf.org Subject: Re: [forces] Protocol draft WAS (Re: AD review of draft-ietf-forces-model-extension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 19 Jul 2014 14:34:55 -0000 Hi, > The protocol draft WG LC just expired. > I believe we need to use the update metadata for the protocol draft. > There are also a couple of nits. It may make sense to make another = release > before shepherding starts. > If we do that, would we need to redo the WG last call? No you don't. That sort of thing is mainly procedural and can just be = done. You can post on Monday morning. I think the WG will have time to object during IETF last call. A From nobody Sat Jul 19 07:40:12 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872271A0AB0 for ; Sat, 19 Jul 2014 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScCIgXClE5G4 for ; Sat, 19 Jul 2014 07:40:07 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582B01B2843 for ; Sat, 19 Jul 2014 07:40:07 -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 s6JEe5A1003059; Sat, 19 Jul 2014 15:40:05 +0100 Received: from 950129200 (dhcp-b3fb.meeting.ietf.org [31.133.179.251]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6JEe33D003036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 19 Jul 2014 15:40:05 +0100 From: "Adrian Farrel" To: "'Jamal Hadi Salim'" References: In-Reply-To: Date: Sat, 19 Jul 2014 15:40:07 +0100 Message-ID: <040301cfa35f$57046480$050d2d80$@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: AQFgTWvUKqqHDmumSVF242SjqpXsSAHiK5GBnHcQ59A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20828.000 X-TM-AS-Result: No--32.531-10.0-31-10 X-imss-scan-details: No--32.531-10.0-31-10 X-TMASE-MatchedRID: fE0JoqABJp1i5chShW9brMAmcZEx8XHJ9wGZvWYZl5f7I1hjCeCvFgLy tDvV39h+1DUmtBhG919O6CI7rIh2itcUNjoF7YuV2os3ueKAsFQbTwzYj2zQurKeTtOdjMy6kP4 zdNkkV9l1uXoaoJKcFdX0pCZz7OJTnjL/SgND35MmtTGirqG/D34yToAKzDgm2oLGTNKlb9cCAt rGaMw19Wq7tKTeRYmaRPdBDztq3wMy9zgULewwZhes/RxhysDb1Ga2L87qPQIgbNDlPT+rW6XHi w2T1clCQC4tUp/BxQRUXvwZbFIh0Ua2DXGqwZmfBEfU2vugRF2z5LIh2+IOfKk+681hx+HS+L29 6RNvdj2dhDZUQZn1rsrwwM67bcRVCI0sHVMvHhOdVNZaI2n6/0GV2YNiPCWm51ONI4UL++qjxYy RBa/qJaEwgORH8p/AjaPj0W1qn0SQZS2ujCtcuA== Archived-At: http://mailarchive.ietf.org/arch/msg/forces/JyBz2ruB9uKwDGhKPYgIGXXZpgM Cc: draft-ietf-forces-model-extension.all@tools.ietf.org, forces@ietf.org Subject: Re: [forces] Protocol draft WAS (Re: AD review of draft-ietf-forces-model-extension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 19 Jul 2014 14:40:09 -0000 OK. The changes look good to me. The WG has had time to think about the changes - the only one I thought = might have attracted attention was the change of the version umber to = 1.1, but silence fell. I'll move the document forward. Thanks, Adrian > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] > Sent: 04 July 2014 12:50 > To: Adrian Farrel > Cc: draft-ietf-forces-model-extension.all@tools.ietf.org; = forces@ietf.org > Subject: Re: [forces] Protocol draft WAS (Re: AD review of = draft-ietf-forces- > model-extension >=20 > I know it is holidays at the moment. I will upload a new version with = the > fixes now to beat the draft deadline and then await your responses. >=20 > cheers, > jamal >=20 > On Thu, Jul 3, 2014 at 7:27 PM, Jamal Hadi Salim = wrote: > > Adrian, > > > > Thanks for the thorough review (as always). > > One question on one of your comments below applies to the protocol > > draft. The protocol draft WG LC just expired. > > I believe we need to use the update metadata for the protocol draft. > > There are also a couple of nits. It may make sense to make another = release > > before shepherding starts. > > If we do that, would we need to redo the WG last call? > > > > cheers, > > jamal > > > > On Wed, Jul 2, 2014 at 2:05 PM, Adrian Farrel = wrote: > > > > > >> Can you clarify for me whether, after the publication of this = document > >> as an RFC, the extensions it defines are part of the ForCES model. = That > >> is, if you were to implement ForCES from scratch after its = publication, > >> would you be expected to include these features? > >> > >> If the answer is "yes" then this probably updates 5812. If "no" = then we > >> need to work some language to explain that the extensions are = options. > >> > >> I think, looking at, for example, Section 3.1, that this document = is > >> making specific changes to 5812 as well as potentially defining = some > >> additions. That means it really does update 5812. > >> > >> To handle this you need: > >> - An "updates" tag in the metadata at the head of the file > >> - To make the statement in the Abstract "This document updates RFC = 5812 > >> by defining foo..." > >> - Add a section (probably Section 1.1 inside the Introduction) that = is > >> called "Updates to RFC 5812" and provides an overview of the = changes > >> and additions (you can use forward pointers into the rest of the > >> document). > >> > > > > _______________________________________________ > > forces mailing list > > forces@ietf.org > > https://www.ietf.org/mailman/listinfo/forces From nobody Sat Jul 19 07:44:29 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A9F1B285A; Sat, 19 Jul 2014 07:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHDIaBbXyGdG; Sat, 19 Jul 2014 07:44:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C98861A01DC; Sat, 19 Jul 2014 07:44:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140719144421.18316.74215.idtracker@ietfa.amsl.com> Date: Sat, 19 Jul 2014 07:44:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/0Oz_4Z5p9W8X3FjiCmivn08QeR0 Cc: forces@ietf.org Subject: [forces] Last Call: (ForCES Model Extension) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 19 Jul 2014 14:44:23 -0000 The IESG has received a request from the Forwarding and Control Element Separation WG (forces) to consider the following document: - 'ForCES Model Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-09. This last call period is longer than usual to allow for overlap with IETF-90. 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 Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model that provides a formal way to represent the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in a forwarding element (FE), what capabilities these functions support, and how these functions are or can be interconnected. RFC5812 has been around for two years and experience in its use has shown room for small extensions without a need to alter the protocol while retaining backward compatibility with older xml libraries. This document update RFC5812 and extends the model to allow complex datatypes for metadata, optional default values for datatypes, optional access types for structures and fixes an issue with LFB inheritance. The document also introduces two new features a new event condition BecomesEqualTo and LFB properties. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-forces-model-extension/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-forces-model-extension/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sat Jul 19 08:49:35 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7991B2875 for ; Sat, 19 Jul 2014 08:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O1DKkdEcuWy for ; Sat, 19 Jul 2014 08:49:31 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC501B2871 for ; Sat, 19 Jul 2014 08:49:31 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hu12so9542266vcb.0 for ; Sat, 19 Jul 2014 08:49:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=i4S1z2mTtB/qsBdbxjFe+SJgGkuKG4fIykcmo9/mCMw=; b=mXu1wUPRXta8atiNj/JTlo6ebIMR+jdIdwI3yO5WxMHgckDZ2p/TC1qVA4VNlVongC PWGvFLCDB7gBZoZ2YWeeDY7ufqefE+f7exGtXvNDU6Wu8F6bZu+hwjotCFWOYex06p5x OnzUCd6hi40fnrhnro9F1l2ipMeUS/dJkqdmBpESXfJjAU8ntkH61U0JjvReCQsQeQVf elDFIvf7FbhaRU5OOgET/G7zdOVXPbIMmDGbvN7J91MWZi5LodmZLL7AvPSQdvhDEB9c Q/NalxvcQzPp8PdwEE4p5en1q7a4PSUTYRFLpW6hrTN86R7sKMLDuR79YOAmZwFMXuNC m49Q== X-Gm-Message-State: ALoCoQmBl5wCJnsFnOHgejQLF8LnjxrQvEIl1MM4l0kt5QU5StTRbIsdaNbfeHPijgMKReCJ8VoO X-Received: by 10.52.13.98 with SMTP id g2mr12755960vdc.46.1405784970517; Sat, 19 Jul 2014 08:49:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Sat, 19 Jul 2014 08:49:10 -0700 (PDT) In-Reply-To: <20140717144943.3305.13953.idtracker@ietfa.amsl.com> References: <20140717144943.3305.13953.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Sat, 19 Jul 2014 11:49:10 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/forces/QOKCDlrCp9o3QwEHGnu80AKdBMU Subject: [forces] Fwd: [Recentattendees] IETF 90 - Remote Participation X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 15:49:33 -0000 If you are remote i think this is a great way to attend. Please register first - it is free, it helps the organizers to track things. cheers, jamal ---------- Forwarded message ---------- From: IETF Secretariat Date: Thu, Jul 17, 2014 at 10:49 AM Subject: [Recentattendees] IETF 90 - Remote Participation To: recentattendees@ietf.org Can=E2=80=99t make it to Toronto? Participate remotely! The IETF offers a number of ways for remote attendees to audit or even contribute to IETF sessions throughout the meeting week. First, register for the meeting. There is no cost to register as a remote attendee and by registering you will insure that you receive important updates on agenda changes and other things of interest to meeting attendees. Please register here: http://www.ietf.org/meeting/register.html and select =E2=80=9Cremote participant=E2=80=9D as your registration type. General remote participation information can be found here: http://www.ietf.org/meeting/90/remote-participation.html. Below is a breakdown of some of the main services available. 1) Meetecho The Meetecho platform provides a synchronized view of the audio/video stream from the meeting room, which includes slides being presented and the presenter, as well as official IETF Jabber room. Meetecho will be supporting six of the eight concurrent working session tracks, along with both the Administrative and Technical plenaries. If you have a comment or a question, Meetecho enables you to ask it even if you are not in the room. In addition, Meetecho will be streaming many of the Sunday tutorials sessions. For more information on how to join a Meetecho session, or to watch a recording after the session has concluded, see here:http://ietf90.conf.meetecho.com/. 2) Audio Stream If you only want to listen to the sessions (or if the session you are interested in isn=E2=80=99t supported by Meetecho), the audio stream is a g= ood choice. All working sessions are streamed; see here for more channel-to-room assignments: http://www.ietf.org/meeting/90/remote-participation.html#audio. 3) Jabber Rooms All IETF meeting sessions have a corresponding Jabber room. See here for link to the meeting agenda with corresponding Jabber rooms: http://tools.ietf.org/agenda/90/. Whenever possible, an in-room volunteer monitors the Jabber room; this volunteer will stand at the microphone for remote attendees and relay their questions into the meeting room microphone so that people in the room can respond. More information on the IETF Jabber service is available here: http://www.ietf.org/jabber/. 4) Mailing Lists The 90attendees@ietf.org is for general discussion of things happening at the meeting; join the list if you want to hear about Toronto restaurants, meeting room temperatures and other topics of interest to those who are physically present at the meeting. Subscribe to 90attendees here: https://www.ietf.org/mailman/listinfo/90attendees. The 90all@ietf.org list is for important announcements only and is not a discussion list. You automatically subscribed when you register as a remote participant. Being on 90all is essential if you want to hear about changes to meeting agenda or other important announcements. Subscribe to 90all here: https://www.ietf.org/mailman/listinfo/90all. 5) Live Video and Text Streaming of the Technical Plenary on Monday, July 21st. The technical topic is network topology and geography. See http://www.ietf.org/live/ for more information. After the meeting we will be sending a survey to all remote participants to get feedback on their experience; if you participate remotely, we=E2=80=99d love to hear from you! And don=E2=80=99t forget to f= ollow @ietf on Twitter! Only 3 days until the Toronto IETF! _______________________________________________ Recentattendees mailing list Recentattendees@ietf.org https://www.ietf.org/mailman/listinfo/recentattendees From nobody Sat Jul 19 11:46:37 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DD21B29F7 for ; Sat, 19 Jul 2014 11:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.978 X-Spam-Level: ** X-Spam-Status: No, score=2.978 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, J_CHICKENPOX_37=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBGlPYqmNeKl for ; Sat, 19 Jul 2014 11:46:34 -0700 (PDT) Received: from BLU004-OMC4S19.hotmail.com (blu004-omc4s19.hotmail.com [65.55.111.158]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20AC71B29DF for ; Sat, 19 Jul 2014 11:46:34 -0700 (PDT) Received: from BLU436-SMTP154 ([65.55.111.136]) by BLU004-OMC4S19.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Sat, 19 Jul 2014 11:46:33 -0700 X-TMN: [c26ZV6XrqGQEw5mupQ1MchOp7Lb+Ydj6] X-Originating-Email: [chuanhuang_li@hotmail.com] Message-ID: Received: from RobinLee-PC ([221.12.10.218]) by BLU436-SMTP154.smtp.hotmail.com over TLS secured channel with Microsoft SMTPSVC(8.0.9200.16384); Sat, 19 Jul 2014 11:46:31 -0700 Date: Sun, 20 Jul 2014 02:46:26 +0800 From: =?utf-8?B?Q2h1YW5odWFuZw==?= To: "=?utf-8?B?Qi5LaGFzbmFiaXNoQGllZWUub3Jn?=" , "=?utf-8?B?Zm9yY2VzQGlldGYub3Jn?=" X-mailer: Foxmail 6, 15, 201, 23 [cn] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2014 18:46:31.0905 (UTC) FILETIME=[C2113510:01CFA381] Archived-At: http://mailarchive.ietf.org/arch/msg/forces/oCS7TUUxMh5IPjlOEHGAQDZxpSg Subject: Re: [forces] =?utf-8?q?Requesting_further_comments/suggestions_on_IET?= =?utf-8?q?F_ForCESLogical_Function_Block_=28LFB=29_Subsidiary_Mana?= =?utf-8?q?gement_dratf?= X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 18:46:35 -0000 Dear Bhumip, I think this work is very meaningful, and the WG should push it forward. I have some comments: 1: This draft is mainly for the use of virtulization, and aims to standardize an LFB to support this virtulization. I think we cannot call the LFB as "FEM" directly. Because real FEM is a logical entity responsible for generic FE management tasks, generally, its functions are more abundant,such as the settings of TML protocol parameters and secure parameters. The functions of FEM are open and extensible.They are just not as you defined "The LFB is an LFB that standardizes and assists creation of NEs." So, i suggest we need rename the standard LFB as "FEVM (FE Virtulization Management) ". There is inheritance relationship between FEM LFB and FEVM LFB. 2: I think Section 3 (Potential Scenarios) should pay more attention to the FEVM role in these scenarios. For example, in Section 3.1, we need describe the FEVM role in the recovery process, rather than the recovery method by using virtulization of CEs. 3:In my thought, FEVM needn't know which VFEs are in one VNE(Virtual NE), it only need know the VFE informations in physical FEs. Is it more reasonable that CEM has the visiblity to all VNE. At the same time, The component "NE" of the LFB rename to "VNE" may be better. Yours, Chuanhuang ======== 2014-07-16 01:16:36 ======== Dear All, We are planning to release updates to the LFB Subsidiary Management draft ( http://datatracker.ietf.org/doc/draft-khs-forces-lfb-subsidiary-management/ ) very soon. Kindly let us know ASAP if you have any further comments/suggestions. Many thanks in advance. Best. Draft Authors +++++++++++++++++++++++++++++++++++++++ Network Working Group B. Khasnabish Internet-Draft ZTE TX, Inc. Intended status: Standards Track E. Haleplidis Expires: August 14, 2014 University of Patras J. Hadi Salim Mojatatu Networks February 10, 2014 IETF ForCES Logical Function Block (LFB) Subsidiary Management draft-khs-forces-lfb-subsidiary-management-00.txt Abstract This document discusses ForCES Logical Function Block (LFB) Subsidiary Management (SM). Note that LFB SM is useful for introducing and supporting virtualization of ForCES Network Element (NE) including control Element (CE) and Forwarding Element (FE). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 14, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Khasnabish, et al. Expires August 14, 2014 [Page 1] Internet-Draft IETF ForCES LFB Subsidiary Management February 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Conventions and Definitions . . . . . . . . . . . . . . . 4 2. Use of Virtualized ForCES Elements . . . . . . . . . . . . . 5 2.1. Use of Virtualized CEs . . . . . . . . . . . . . . . . . 5 2.2. Use of Virtualized FEs . . . . . . . . . . . . . . . . . 6 3. Potential Scenarios . . . . . . . . . . . . . . . . . . . . . 6 3.1. Recovery from CE failure . . . . . . . . . . . . . . . . 6 3.2. Recovery from FE failure . . . . . . . . . . . . . . . . 6 3.3. Load Balancing . . . . . . . . . . . . . . . . . . . . . 6 3.4. Scalable/Robust Service Function Chaining . . . . . . . . 6 3.5. Orchestration . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Generic LFB Lifecycle Management . . . . . . . . . . . . 6 3.6.1. Booting a CE/FE . . . . . . . . . . . . . . . . . . . 7 3.6.2. Bootstrapping the Configuration . . . . . . . . . . . 7 3.6.3. Runtime Management . . . . . . . . . . . . . . . . . 7 4. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . 7 5. Reference Implementation . . . . . . . . . . . . . . . . . . 7 6. FEM Library . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Frame Definitions . . . . . . . . . . . . . . . . . . . . 7 6.2. Datatype Definitions . . . . . . . . . . . . . . . . . . 7 6.3. Metadata Definitions . . . . . . . . . . . . . . . . . . 8 6.4. FEM . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.4.1. Data Handling . . . . . . . . . . . . . . . . . . . . 8 6.4.2. Components . . . . . . . . . . . . . . . . . . . . . 8 6.4.3. Capabilities . . . . . . . . . . . . . . . . . . . . 9 6.4.4. Events . . . . . . . . . . . . . . . . . . . . . . . 9 7. XML for FEM LFB . . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 13 = = = = = = = = = = = = = = = = = = = = = = From nobody Sat Jul 19 19:34:26 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9701B2B5A for ; Sat, 19 Jul 2014 19:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eftJWdwp7FR2 for ; Sat, 19 Jul 2014 19:34:22 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E53B1B2B58 for ; Sat, 19 Jul 2014 19:34:22 -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 s6K2YKpW025687; Sun, 20 Jul 2014 03:34:20 +0100 Received: from 950129200 (dhcp-8be6.meeting.ietf.org [31.133.139.230]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6K2YI5i025678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Jul 2014 03:34:19 +0100 From: "Adrian Farrel" To: Date: Sun, 20 Jul 2014 03:34:22 +0100 Message-ID: <04b001cfa3c3$1e7bbe10$5b733a30$@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: Ac+jwxwikbywkV9jRiGWtPNbn4U1jw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20828.004 X-TM-AS-Result: No--15.537-10.0-31-10 X-imss-scan-details: No--15.537-10.0-31-10 X-TMASE-MatchedRID: EHuNGRDqB4HMXKkorvNQjq91/YHX0i1lFJFr2qlKix+638ZUY6gSdxch drJv3xSnN6PBFFzbf/joAfNbWO8hIpbQXYMzBE+ZiUPZPmKZOQnDHSNFHFxB8yf6nnnZywjVcfI Onh+76Cpl+gnpAozYk0aARViWquXLuBKKB37nRtpeKE2FT7r5rIUGhajERJYJZ+WosuKHchiOJm pFkiF2w3WvVVDZj+LtPj3MDfRZx0PoRPKKjGHPU9xajlW+zwxCIgHLa9slyWI38zfZwr5+SGlF7 OhYLlct+ZYDP6bUpNivWBlXOmcI2DQYriqcplwNW7gz/Gbgpl50vtIjqvX0hL/FQgGhXj1W3qv0 WIpOWK3d/R78GDAj0HtBxdKLkQVY+zoAW8R15l9DU5wIS9P5t6wxCUEjPydt/uymSAhGxLIeoQA GXdw2QvU+idfKdAMxH/8tLCuKdK/Qo7lIbG5ppOqwWVBfMuvo16H/l0XwR9uYFp2iw4hoIWX9DF IJTs1HfZUwNr3uCOB+/0O5q64pQM3Kh/1sQtIr9Ib/6w+1lWTfxawHWgG5xtqqof+gfD6RK2edZ De0Hrvi8zVgXoAltlwtzewu2M635MIx11wv+COQZS2ujCtcuA== Archived-At: http://mailarchive.ietf.org/arch/msg/forces/ixa-eQLZBC8RsepOUK7BN1_90zM Cc: forces@ietf.org Subject: [forces] AD review of draft-ietf-forces-protoextension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2014 02:34:25 -0000 Hi, I have done my usual AD review having received a publication request for this document. There are a few nits, and some larger concerns with the IANA section. I'll put the document into "Revised I-D Needed" state and wait to see a new revision. Thanks, Adrian === Abstract Typo s/1. s/1 s/ --- As usual, the RFC Editor will want the Introduction to be the first section in the document. Could you please shuffle the sections to help with that, and take care of any acronym expansions in the Introduction that will result. --- I am not too happy about the restatement of definitions from other sources instead of referencing them. This can cause discrepancies and be difficult to handle if there are updates or changes. I have not checked the definitions for consistency with the "various documents". I suggest that you only keep the definitions that are absolutely fundamental for this document, and even then you should point at the normative definitions. Note that the currently included terminology creates some issues. For example: ForCES Protocol - Protocol that runs in the Fp reference points in the ForCES Framework [RFC3746]. ...what is an "Fp reference point"? --- 4.1. Table Ranges We propose to add a Table-range TLV (type ID 0x117) that will be associated with the PATH-DATA TLV in the same manner the KEYINFO-TLV is. Proposal or definition? Similar in other sections. --- Section 6 needs work This document registers two new top Level TLVs and two new path flags and updates an IANA registered FE Protocol object Logical Functional Block (LFB). XXX: when this document is undergoing IANA review we should update https://www.iana.org/assignments/forces/forces.xml section on FEPO to have the new version reflected. I don't understand that paragraph. I don't see any mention of FEPO on that page and have no understanding of what version you're talking about. The following new TLVs are defined: o TABLERANGE-TLV (type ID 0x117) o EXTENDEDRESULT-TLV (type ID 0x118) Presume these come from the "TLV Types" sub-registry. Please note that. The following new path flags are defined: o F_SELTABRANGE (value 0x2 i.e bit 1) Trying to work out which registry this is from. I don't see Path Flags mentioned anywhere. Is this from the "Header Flags" sub-registry? If so, why 0x2 and not 0x1? The Defined Result Values are changed: o codes 0x21-0xFE are reserved. o codes 0x18-0x20 are defined by this document. o codes 0x100-0x200 are reserved for vendor use. Name that registry: "RESULT-TLV Result Values sub-registry"? Or are you doing something more sophisticated and combining the old registry with a new registry for the EXTENDEDRESULT-TLV Result Value? And... - Do you mean "reserved" or "unassigned"? - Would you like to clarify for IANA what assignments are being made for 0x18-0x20 - You are not changing the allocation rules for the range 0x18 to 0xfe so, notwithstanding this being a standards track document, we need to get DE approval for the allocations 0x18-0x20. Since Jamal is an author, that means Joel. - If you're doing the 32 bit thing then what about the values larger than 0x200? - What does "for vendor use" mean? Which 5226 policy do you intend to be applied? The text in 4.2.2 suggests FCFS. I suspect what you want here is - allocate 0x18-0x20 from the RESULT-TLV Result Values sub-registry - define a new sub-registry for EXTENDEDRESULT-TLV Result Values - state that 0x00-0xff is mirrored from the RESULT-TLV Result Values sub-registry and must not be allocated - define new allocation policies for 0x100-0xffff --- I think RFC 2119 is a normative reference. From nobody Sun Jul 20 04:07:28 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983D71B2B9B for ; Sun, 20 Jul 2014 04:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.851 X-Spam-Level: X-Spam-Status: No, score=0.851 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iB78VqDg1qS for ; Sun, 20 Jul 2014 04:07:19 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5635A1B2B9A for ; Sun, 20 Jul 2014 04:07:19 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so6465947wes.32 for ; Sun, 20 Jul 2014 04:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bLdQ4JA0r1iAcECPHdlO3SdToE18qzoIxaz7KJc0oyQ=; b=zdSVitduY0cVZLKIFXmVWxBuJhiQasUPeBhfY7I8avCZ7E7v7B3vWlU8oVXwuQYVJ6 99DkWuEq0FbGIWmHnZ7+rjufZnACILecjnWlAItGeoHykWNUPwKojUx0IdErFkRamKz0 MwLJKT+lNEqk8M69KnTq6GzE/Z6rrrj2WVCelEnUqJ1VdtL37h5Cj+hJ9gIhTAEOcxj/ ZL4THA9ryWYNpMDunYsu7ezkTlnb0Hsg96l9NHaHMRPZaMOQ7KnMx0BIDup1gy3AB9ui NeXpNruAQbnY6zQGcddeUhtsxLE+wNj2fz4DX8UAIrKAQzD5+6iTOi26mKb+skKuvPBf /LFg== MIME-Version: 1.0 X-Received: by 10.180.149.161 with SMTP id ub1mr23498574wib.32.1405854437895; Sun, 20 Jul 2014 04:07:17 -0700 (PDT) Received: by 10.217.148.10 with HTTP; Sun, 20 Jul 2014 04:07:17 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Jul 2014 07:07:17 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: Chuanhuang Content-Type: multipart/alternative; boundary=001a11c37e5660729b04fe9dfe5d Archived-At: http://mailarchive.ietf.org/arch/msg/forces/7611MY8V48LDcGjVzSWzNMpxiW0 Cc: "forces@ietf.org" Subject: Re: [forces] Requesting further comments/suggestions on IETF ForCESLogical Function Block (LFB) Subsidiary Management dratf X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 11:07:23 -0000 --001a11c37e5660729b04fe9dfe5d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BDear =E2=80=8BMr. Chuanhuang, Many thanks for your comments and support. We are updating the draft now, and plan to address the issues/concerns that you raise below in the next version. Yes, we are adding additional details for the main scenarios (recovery from FE and =E2=80=8BCE failures) , and plan to update the nomenclatures per your suggestions. Thanks again. Best. Bhumip On Sat, Jul 19, 2014 at 2:46 PM, Chuanhuang wrote: > Dear Bhumip, > > I think this work is very meaningful, and the WG should push it forward. > > I have some comments: > 1: This draft is mainly for the use of virtulization, and aims to > standardize an > LFB to support this virtulization. > > I think we cannot call the LFB as "FEM" directly. Because real FEM is a > logical > entity responsible for generic FE management tasks, generally, its > functions > are more abundant,such as the settings of TML protocol parameters and > secure > parameters. The functions of FEM are open and extensible.They are just no= t > as > you defined "The LFB is an LFB that standardizes and assists creation of > NEs." > So, i suggest we need rename the standard LFB as "FEVM (FE Virtulization > Management) ". > There is inheritance relationship between FEM LFB and FEVM LFB. > > 2: I think Section 3 (Potential Scenarios) should pay more attention to > the FEVM > role in these scenarios. For example, in Section 3.1, we need describe th= e > FEVM role > in the recovery process, rather than the recovery method by using > virtulization of CEs. > > 3:In my thought, FEVM needn't know which VFEs are in one VNE(Virtual NE), > it only > need know the VFE informations in physical FEs. Is it more reasonable tha= t > CEM has > the visiblity to all VNE. > At the same time, The component "NE" of the LFB rename to "VNE" may be > better. > > > Yours, > Chuanhuang > > =3D=3D=3D=3D=3D=3D=3D=3D 2014-07-16 01:16:36 =3D=3D=3D=3D=3D=3D=3D=3D > > Dear All, > > We are planning to release updates to the LFB > Subsidiary Management draft > ( > http://datatracker.ietf.org/doc/draft-khs-forces-lfb-subsidiary-managemen= t/ > ) > very soon. > > Kindly let us know ASAP if you have any > further comments/suggestions. > > Many thanks in advance. > > Best. > > Draft Authors > > > +++++++++++++++++++++++++++++++++++++++ > Network Working Group B. Khasnabish > Internet-Draft ZTE TX, Inc. > Intended status: Standards Track E. Haleplidis > Expires: August 14, 2014 University of Patras > J. Hadi Salim > Mojatatu Networks > February 10, 2014 > > IETF ForCES Logical Function Block (LFB) Subsidiary Management > draft-khs-forces-lfb-subsidiary-management-00.txt > > Abstract > > This document discusses ForCES Logical Function Block (LFB) > Subsidiary Management (SM). Note that LFB SM is useful for > introducing and supporting virtualization of ForCES Network Element > (NE) including control Element (CE) and Forwarding Element (FE). > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on August 14, 2014. > > Copyright Notice > > Copyright (c) 2014 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > > Khasnabish, et al. Expires August 14, 2014 [Page 1] > Internet-Draft IETF ForCES LFB Subsidiary Management February 2014 > > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 > 1.3. Conventions and Definitions . . . . . . . . . . . . . . . 4 > 2. Use of Virtualized ForCES Elements . . . . . . . . . . . . . 5 > 2.1. Use of Virtualized CEs . . . . . . . . . . . . . . . . . 5 > 2.2. Use of Virtualized FEs . . . . . . . . . . . . . . . . . 6 > 3. Potential Scenarios . . . . . . . . . . . . . . . . . . . . . 6 > 3.1. Recovery from CE failure . . . . . . . . . . . . . . . . 6 > 3.2. Recovery from FE failure . . . . . . . . . . . . . . . . 6 > 3.3. Load Balancing . . . . . . . . . . . . . . . . . . . . . 6 > 3.4. Scalable/Robust Service Function Chaining . . . . . . . . 6 > 3.5. Orchestration . . . . . . . . . . . . . . . . . . . . . . 6 > 3.6. Generic LFB Lifecycle Management . . . . . . . . . . . . 6 > 3.6.1. Booting a CE/FE . . . . . . . . . . . . . . . . . . . 7 > 3.6.2. Bootstrapping the Configuration . . . . . . . . . . . 7 > 3.6.3. Runtime Management . . . . . . . . . . . . . . . . . 7 > 4. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . 7 > 5. Reference Implementation . . . . . . . . . . . . . . . . . . 7 > 6. FEM Library . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 6.1. Frame Definitions . . . . . . . . . . . . . . . . . . . . 7 > 6.2. Datatype Definitions . . . . . . . . . . . . . . . . . . 7 > 6.3. Metadata Definitions . . . . . . . . . . . . . . . . . . 8 > 6.4. FEM . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 6.4.1. Data Handling . . . . . . . . . . . . . . . . . . . . 8 > 6.4.2. Components . . . . . . . . . . . . . . . . . . . . . 8 > 6.4.3. Capabilities . . . . . . . . . . . . . . . . . . . . 9 > 6.4.4. Events . . . . . . . . . . . . . . . . . . . . . . . 9 > 7. XML for FEM LFB . . . . . . . . . . . . . . . . . . . . . . . 9 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 > 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 > 9.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 13 > > > =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D = =3D =3D =3D =3D > > --001a11c37e5660729b04fe9dfe5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BDear =E2=80=8BMr. Chuanhuang,
= =C2=A0
Many thanks for your comments and support.
=C2=A0
We = are updating the draft now, and plan to address
the issues/concerns that you raise below in the next version.
=C2=A0
Yes, we are adding additional details for the main scena= rios
(recovery from FE and
=E2=80=8BCE failures) , and plan= to update the
nomenclatures per
your sugg= estions.
=C2=A0
=C2=A0
Thanks again.

Best.

Bhumip

=C2=A0


On Sat, Jul 19, 2014 at 2:46 PM, Chuanhuang <chuanhu= ang_li@hotmail.com> wrote:
Dear Bhumip,

I think this work is very meaningful, and the WG should push it forward.
I have some comments:
1: This draft is mainly for the use of virtulization, and aims to standardi= ze an
LFB to support this virtulization.

I think we cannot call the LFB as "FEM" directly. Because real FE= M is a logical
entity responsible for generic FE management tasks, generally, its function= s
are more abundant,such as the settings of TML protocol parameters and secur= e
parameters. The functions of FEM are open and extensible.They are just not = as
you defined "The LFB is an LFB that standardizes and assists creation = of NEs."
So, i suggest we need rename the standard LFB as "FEVM (FE Virtulizati= on Management) ".
There is inheritance relationship between FEM LFB and FEVM LFB.

2: I think Section 3 (Potential Scenarios) should pay more attention to the= FEVM
role in these scenarios. For example, in Section 3.1, we need describe the = FEVM role
in the recovery process, rather than the recovery method by using virtuliza= tion of CEs.

3:In my thought, FEVM needn't know which VFEs are in one VNE(Virtual NE= ), it only
need know the VFE informations in physical FEs. Is it more reasonable that = CEM has
the visiblity to all VNE.
At the same time, The component "NE" of the LFB rename to "V= NE" may be better.


Yours,
Chuanhuang

=3D=3D=3D=3D=3D=3D=3D=3D 2014-07-16 01:16:36 =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=

Dear All,

We are planning to release updates to the LFB
Subsidiary Management draft
( http://datatracker.ietf.org/doc/draft-khs-= forces-lfb-subsidiary-management/ )
very soon.

Kindly let us know ASAP if you have any
further comments/suggestions.

Many thanks in advance.

Best.

Draft Authors


+++++++++++++++++++++++++++++++++++++++
Network Working Group =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0B. Khasnabish
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0ZTE TX, Inc.
Intended status: Standards Track =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 E. Haleplidis
Expires: August 14, 2014 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0University of Patras
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0J. Hadi Salim=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mojatatu Networks
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0February 10, 2014

=C2=A0 =C2=A0 =C2=A0IETF ForCES Logical Function Bl= ock (LFB) Subsidiary Management
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft= -khs-forces-lfb-subsidiary-management-00.txt

Abstract

=C2=A0 =C2=A0This document discusses ForCES Logical Function Block (LFB) =C2=A0 =C2=A0Subsidiary Management (SM). =C2=A0Note that LFB SM is useful f= or
=C2=A0 =C2=A0introducing and supporting virtualization of ForCES Network El= ement
=C2=A0 =C2=A0(NE) including control Element (CE) and Forwarding Element (FE= ).

Status of This Memo

=C2=A0 =C2=A0This Internet-Draft is submitted in full conformance with the<= br> =C2=A0 =C2=A0provisions of BCP 78 and BCP 79.

=C2=A0 =C2=A0Internet-Drafts are working documents of the Internet Engineer= ing
=C2=A0 =C2=A0Task Force (IETF). =C2=A0Note that other groups may also distr= ibute
=C2=A0 =C2=A0working documents as Internet-Drafts. =C2=A0The list of curren= t Internet-
=C2=A0 =C2=A0Drafts is at http://datatracker.ietf.org/drafts/current/.
=C2=A0 =C2=A0Internet-Drafts are draft documents valid for a maximum of six= months
=C2=A0 =C2=A0and may be updated, replaced, or obsoleted by other documents = at any
=C2=A0 =C2=A0time. =C2=A0It is inappropriate to use Internet-Drafts as refe= rence
=C2=A0 =C2=A0material or to cite them other than as "work in progress.= "

=C2=A0 =C2=A0This Internet-Draft will expire on August 14, 2014.

Copyright Notice

=C2=A0 =C2=A0Copyright (c) 2014 IETF Trust and the persons identified as th= e
=C2=A0 =C2=A0document authors. =C2=A0All rights reserved.

=C2=A0 =C2=A0This document is subject to BCP 78 and the IETF Trust's Le= gal
=C2=A0 =C2=A0Provisions Relating to IETF Documents
=C2=A0 =C2=A0(http://trustee.ietf.org/license-info) in effect on the date of =C2=A0 =C2=A0publication of this document. =C2=A0Please review these docume= nts
=C2=A0 =C2=A0carefully, as they describe your rights and restrictions with = respect
=C2=A0 =C2=A0to this document. =C2=A0Code Components extracted from this do= cument must
=C2=A0 =C2=A0include Simplified BSD License text as described in Section 4.= e of

Khasnabish, et al. Expires August 14, 2014 [Page 1]
Internet-Draft IETF ForCES LFB Subsidiary Management February 2014

=C2=A0 =C2=A0the Trust Legal Provisions and are provided without warranty a= s
=C2=A0 =C2=A0described in the Simplified BSD License.

Table of Contents

=C2=A0 =C2=A01. =C2=A0Introduction =C2=A0. . . . . . . . . . . . . . . . . = . . . . . . . =C2=A0 2
=C2=A0 =C2=A0 =C2=A01.1. =C2=A0Scope . . . . . . . . . . . . . . . . . . . = . . . . . . . =C2=A0 3
=C2=A0 =C2=A0 =C2=A01.2. =C2=A0Abbreviations . . . . . . . . . . . . . . . = . . . . . . . =C2=A0 3
=C2=A0 =C2=A0 =C2=A01.3. =C2=A0Conventions and Definitions . . . . . . . . = . . . . . . . =C2=A0 4
=C2=A0 =C2=A02. =C2=A0Use of Virtualized ForCES Elements =C2=A0. . . . . . = . . . . . . . =C2=A0 5
=C2=A0 =C2=A0 =C2=A02.1. =C2=A0Use of Virtualized CEs =C2=A0. . . . . . . .= . . . . . . . . . =C2=A0 5
=C2=A0 =C2=A0 =C2=A02.2. =C2=A0Use of Virtualized FEs =C2=A0. . . . . . . .= . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A03. =C2=A0Potential Scenarios . . . . . . . . . . . . . . . . .= . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A03.1. =C2=A0Recovery from CE failure =C2=A0. . . . . . .= . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A03.2. =C2=A0Recovery from FE failure =C2=A0. . . . . . .= . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A03.3. =C2=A0Load Balancing =C2=A0. . . . . . . . . . . .= . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A03.4. =C2=A0Scalable/Robust Service Function Chaining . = . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A03.5. =C2=A0Orchestration . . . . . . . . . . . . . . . = . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A03.6. =C2=A0Generic LFB Lifecycle Management =C2=A0. . .= . . . . . . . . . =C2=A0 6
=C2=A0 =C2=A0 =C2=A0 =C2=A03.6.1. =C2=A0Booting a CE/FE . . . . . . . . . .= . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A0 =C2=A03.6.2. =C2=A0Bootstrapping the Configuration . .= . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A0 =C2=A03.6.3. =C2=A0Runtime Management =C2=A0. . . . . = . . . . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A04. =C2=A0Testbed Platform =C2=A0. . . . . . . . . . . . . . . = . . . . . . . =C2=A0 7
=C2=A0 =C2=A05. =C2=A0Reference Implementation =C2=A0. . . . . . . . . . . = . . . . . . . =C2=A0 7
=C2=A0 =C2=A06. =C2=A0FEM Library . . . . . . . . . . . . . . . . . . . . .= . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.1. =C2=A0Frame Definitions . . . . . . . . . . . . . = . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.2. =C2=A0Datatype Definitions =C2=A0. . . . . . . . .= . . . . . . . . . =C2=A0 7
=C2=A0 =C2=A0 =C2=A06.3. =C2=A0Metadata Definitions =C2=A0. . . . . . . . .= . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A0 =C2=A06.4. =C2=A0FEM . . . . . . . . . . . . . . . . . . . . = . . . . . . . =C2=A0 8
=C2=A0 =C2=A0 =C2=A0 =C2=A06.4.1. =C2=A0Data Handling . . . . . . . . . . .= . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A0 =C2=A0 =C2=A06.4.2. =C2=A0Components =C2=A0. . . . . . . . . = . . . . . . . . . . . . =C2=A0 8
=C2=A0 =C2=A0 =C2=A0 =C2=A06.4.3. =C2=A0Capabilities =C2=A0. . . . . . . . = . . . . . . . . . . . . =C2=A0 9
=C2=A0 =C2=A0 =C2=A0 =C2=A06.4.4. =C2=A0Events =C2=A0. . . . . . . . . . . = . . . . . . . . . . . . =C2=A0 9
=C2=A0 =C2=A07. =C2=A0XML for FEM LFB . . . . . . . . . . . . . . . . . . .= . . . . =C2=A0 9
=C2=A0 =C2=A08. =C2=A0Security Considerations . . . . . . . . . . . . . . .= . . . . =C2=A013
=C2=A0 =C2=A09. =C2=A0IANA Considerations . . . . . . . . . . . . . . . . .= . . . . =C2=A013
=C2=A0 =C2=A0 =C2=A09.1. =C2=A0LFB Class Names and LFB Class Identifiers . = . . . . . . . =C2=A013


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


--001a11c37e5660729b04fe9dfe5d-- From nobody Sun Jul 20 04:27:02 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F71F1B2BAC for ; Sun, 20 Jul 2014 04:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fShuxL_aHvf for ; Sun, 20 Jul 2014 04:26:59 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B361B2BAB for ; Sun, 20 Jul 2014 04:26:59 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id hy10so10250471vcb.4 for ; Sun, 20 Jul 2014 04:26:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p7f4HRgIiwdANh5wtjInlCLe0QjikSOMeULHWttcMb0=; b=aUjIwxzYeCTnFJevK2MtqlVIcHiLy0M4s9HSH8MtvqXLTxQIWLj7J2qaxolrtsyypb 1LqnEKh9/fKLmcnSepUCFxjKp81aJOfwOZ05F5nhoygls4aLa1WLuEcoaS3P2dma2XET 7+7dgJv76tAtk0vaL6YOAz5aP/3nEQ+TAHWudsvryglnSIcpbydYiCogAGbVd7CF848E iS5WKy4mpRuMMFNbiaBnP4Ns/o/O9pduZo5ZOalnkBNbozMR/oaCrh130CRWcTb5ocxV WDlmUh6p30i7lo1aVqrOpBBV+77uEMpIoXXWUf/Wr1ZnMdJ5st2t8f/CKvgY+JmKjQuW lG9w== X-Gm-Message-State: ALoCoQlh6p+22vZ/RBovB2+usWDxy+r2kfZlvkff5VBV/ejJmeXtYir984hV1i40ka9RJzMi2+Z3 X-Received: by 10.220.202.69 with SMTP id fd5mr8254420vcb.43.1405855618522; Sun, 20 Jul 2014 04:26:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Sun, 20 Jul 2014 04:26:38 -0700 (PDT) In-Reply-To: <04b001cfa3c3$1e7bbe10$5b733a30$@olddog.co.uk> References: <04b001cfa3c3$1e7bbe10$5b733a30$@olddog.co.uk> From: Jamal Hadi Salim Date: Sun, 20 Jul 2014 07:26:38 -0400 Message-ID: To: Adrian Farrel Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/_4WQe8p3qvsFGnMVtziF8hNROE0 Cc: "forces@ietf.org" , draft-ietf-forces-protoextension.all@tools.ietf.org Subject: Re: [forces] AD review of draft-ietf-forces-protoextension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 11:27:01 -0000 Thanks for your review Adrian. Appreciated as always. I will update the document this week sometime. cheers, jamal On Sat, Jul 19, 2014 at 10:34 PM, Adrian Farrel wrote: > Hi, > > I have done my usual AD review having received a publication request > for this document. There are a few nits, and some larger concerns with > the IANA section. > > I'll put the document into "Revised I-D Needed" state and wait to see a > new revision. > > Thanks, > Adrian > > === > > Abstract > Typo > s/1. s/1 s/ > > --- > > As usual, the RFC Editor will want the Introduction to be the first > section in the document. Could you please shuffle the sections to help > with that, and take care of any acronym expansions in the Introduction > that will result. > > --- > > I am not too happy about the restatement of definitions from other > sources instead of referencing them. This can cause discrepancies and > be difficult to handle if there are updates or changes. I have not > checked the definitions for consistency with the "various documents". > > I suggest that you only keep the definitions that are absolutely > fundamental for this document, and even then you should point at the > normative definitions. > > Note that the currently included terminology creates some issues. For > example: > > ForCES Protocol - Protocol that runs in the Fp reference points in > the ForCES Framework [RFC3746]. > > ...what is an "Fp reference point"? > > --- > > 4.1. Table Ranges > > We propose to add a Table-range TLV (type ID 0x117) that will be > associated with the PATH-DATA TLV in the same manner the KEYINFO-TLV > is. > > Proposal or definition? > Similar in other sections. > > --- > > Section 6 needs work > > This document registers two new top Level TLVs and two new path flags > and updates an IANA registered FE Protocol object Logical Functional > Block (LFB). > > XXX: when this document is undergoing IANA review we should update > https://www.iana.org/assignments/forces/forces.xml section on FEPO to > have the new version reflected. > > I don't understand that paragraph. I don't see any mention of FEPO on > that page and have no understanding of what version you're talking about. > > The following new TLVs are defined: > > o TABLERANGE-TLV (type ID 0x117) > > o EXTENDEDRESULT-TLV (type ID 0x118) > > Presume these come from the "TLV Types" sub-registry. Please note that. > > The following new path flags are defined: > > o F_SELTABRANGE (value 0x2 i.e bit 1) > > Trying to work out which registry this is from. I don't see Path Flags > mentioned anywhere. Is this from the "Header Flags" sub-registry? > > If so, why 0x2 and not 0x1? > > The Defined Result Values are changed: > > o codes 0x21-0xFE are reserved. > > o codes 0x18-0x20 are defined by this document. > > o codes 0x100-0x200 are reserved for vendor use. > > Name that registry: "RESULT-TLV Result Values sub-registry"? > Or are you doing something more sophisticated and combining the old > registry with a new registry for the EXTENDEDRESULT-TLV Result Value? > > And... > - Do you mean "reserved" or "unassigned"? > - Would you like to clarify for IANA what assignments are being made > for 0x18-0x20 > - You are not changing the allocation rules for the range 0x18 to > 0xfe so, notwithstanding this being a standards track document, we > need to get DE approval for the allocations 0x18-0x20. Since Jamal > is an author, that means Joel. > - If you're doing the 32 bit thing then what about the values larger > than 0x200? > - What does "for vendor use" mean? Which 5226 policy do you intend to > be applied? The text in 4.2.2 suggests FCFS. > > I suspect what you want here is > - allocate 0x18-0x20 from the RESULT-TLV Result Values sub-registry > - define a new sub-registry for EXTENDEDRESULT-TLV Result Values > - state that 0x00-0xff is mirrored from the RESULT-TLV Result Values > sub-registry and must not be allocated > - define new allocation policies for 0x100-0xffff > > --- > > I think RFC 2119 is a normative reference. > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From nobody Sat Jul 26 01:26:33 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF15D1A03C8; Sat, 26 Jul 2014 01:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zdEfeHDNkuC; Sat, 26 Jul 2014 01:26:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA511A03B5; Sat, 26 Jul 2014 01:26:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140726082629.9018.47699.idtracker@ietfa.amsl.com> Date: Sat, 26 Jul 2014 01:26:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/4Jh47kfeO8UKe40J1UCSNlPITm8 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-packet-parallelization-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 08:26:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Packet Parallelization Authors : Evangelos Haleplidis Joel Halpern Filename : draft-ietf-forces-packet-parallelization-01.txt Pages : 25 Date : 2014-07-26 Abstract: Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model provides a formal way to represent the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. Many network devices support parallel packet processing. This document describes how ForCES can model a network device's parallelization datapath. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-packet-parallelization/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-packet-parallelization-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-packet-parallelization-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 27 12:55:35 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684911A0242 for ; Sun, 27 Jul 2014 12:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.301 X-Spam-Level: X-Spam-Status: No, score=-5.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHTSGFiA6G91 for ; Sun, 27 Jul 2014 12:48:10 -0700 (PDT) Received: from kryten.ee.ucl.ac.uk (mail2.ee.ucl.ac.uk [128.40.38.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598061A010C for ; Sun, 27 Jul 2014 12:48:10 -0700 (PDT) Received: from alexgalissmbp2.home (host109-145-81-3.range109-145.btcentralplus.com [109.145.81.3]) (authenticated bits=0) by kryten.ee.ucl.ac.uk (8.14.5/8.14.3) with ESMTP id s6RJm3Bv007043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 Jul 2014 20:48:04 +0100 (BST) From: Alex Galis Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Jul 2014 20:47:58 +0100 Message-Id: <636DA8D1-8932-4D40-9535-A3A592FF9EBB@ucl.ac.uk> To: forces@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-UCL-EE-MailScanner-Information: Please contact the ISP for more information X-UCL-EE-MailScanner-ID: s6RJm3Bv007043 X-UCL-EE-MailScanner: Found to be clean X-UCL-EE-MailScanner-From: a.galis@ucl.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/forces/f8yjTOWFi_8Vv_Wd0L3TqgXhqE4 X-Mailman-Approved-At: Sun, 27 Jul 2014 12:55:34 -0700 Cc: Alex Galis Subject: Re: [forces] =?windows-1252?q?CfP_-_1st_IEEE_Conference_on_Network_So?= =?windows-1252?q?ftwarization_-=22Software-Defined_Infrastructures_for_Ne?= =?windows-1252?q?tworks=2C_Clouds_and_Services=94_-_London=2C_U=2EK=2E_?= =?windows-1252?q?=96_April_13-17=2C_2015=2C_http=3A//sites=2Eieee=2Eorg/n?= =?windows-1252?q?etsoft/?= X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 19:48:16 -0000 CALL FOR PAPERS 1st IEEE Conference on Network Softwarization =93Software-Defined Infrastructures for Networks, Clouds and Services=94 London, U.K. =96 April 13-17, 2015 http://sites.ieee.org/netsoft/ SCOPE=20 The IEEE International Conference on Network Softwarization (NetSoft = 2015) will be held April 13-17, 2015 in London, U.K. at the Cruciform = Building of University College London (UCL).=20 NetSoft 2015 will be the first of a series of annual events established = as part of the IEEE Software-Defined Networks initiative of the IEEE = Future Directions Committee to build an IEEE-wide community in this area = across multiple IEEE societies and councils = (http://sdn.ieee.org/about.html). Software-Defined Networking (SDN), = Network Function Virtualization (NFV), and Software-Defined Clouds could = be seen as different expressions of an overall transformation trend, = which is deeply impacting and Telecom and IT industries. This trend is = also transforming several other Industries, in using =94softwarization" = to optimize costs and processes and in bringing new values in = infrastructures. In particular, SDN, NFV and network programmability are = creating the conditions to reinvent network and cloud architectures, = accelerate service deployment and facilitate infrastructure management. = Accordingly, the theme of NetSoft 2015 is =93Software-Defined = Infrastructures for Networks, Clouds and Services=94. NetSoft is = intended to serve as the flagship IEEE forum for technical exchange on = software-defined infrastructures and services. TOPICS OF INTEREST=20 Authors are invited to submit papers that fall into the area of = software-defined and virtualized infrastructures. Topics of interest = include, but are not limited to, the following: =95 SDI Architectures, Application Programming Interfaces Protocols = & Programming languages=20 =95 SDN Switch/Router Architectures/Designs =95 Control Architectures/Network Programmability=20 =95 Verification/Debugging/ Auditing Tools=20 =95 Placement/Factoring of Control Logic =95 Efficient Network Virtualization in SDN =95 Network Function Virtualization (NFV)=20 =95 SDN Resource, Network and Service Management and Efficient = Operations =95 Traffic Engineering and QoS in SDN =95 Mobility/Security/Safety Support and Management in SDN =95 Service & Information Orchestration/Chaining and Life Cycle = Management =95 Energy Efficient and Green Software-defined Infrastructures=20 =95 Software-based Integration of Computing, Storage & Networks =95 Software-Defined Datacenters and Inter-datacenter Networks =95 SDN Support for Big Data Applications =95 SDN Applications to Enterprise, Home, Cellular =95 Software-Defined Optical Transport and Backbone Networks =95 SDN and Virtualization for RAN and 5G=20 =95 Performance Evaluation, Testbeds, and Experiences Benchmarking =95 Deployments and Interoperation with Legacy Systems=20 PAPER SUBMISSION=20 Authors are invited to submit original contributions (written in = English) in PDF format. Only original papers not published or submitted = for publication elsewhere can be submitted. Papers can be of two types: = full (up to 9 pages) or short (up to 5 pages) papers. Papers should be = in IEEE 2-column US-Letter style using IEEE Conference templates = (http://www.ieee.org/conferences_events/conferences/publishing/templates.h= tml) and submitted in PDF format via EDAS at: http://edas.info/N18361. = Papers exceeding these limits, multiple submissions, and = self-plagiarized papers will be rejected without further review. All = submitted papers will be subject to a peer-review process. The accepted = papers will be published in IEEE Xplore, provided that the authors do = present their paper at the conference.=20 IMPORTANT DATES=20 Paper Submission: 15th December 2014=09 Camera Ready Papers: 13th March 2015 Notification of Acceptance: 15th February 2015 GENERAL CO-CHAIRS=20 Prosper Chemouil, Orange Labs, France=20 George Pavlou, University College London, U.K.=20 TPC CO-CHAIRS=20 Raouf Boutaba, University of Waterloo, Canada Alex Galis, University College London, U.K.=20 IEEE Software-Defined Networks Group Chair: Antonio Manzalini, Telecom = Italia, Italy For more information, please visit: http://sites.ieee.org/netsoft/=20 =85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85=85= =85=85=85 Alex Galis Professor in Networked and Service Systems Communications and Information Systems Group Department of Electronic and Electrical Engineering University College London Torrington Place, London WC1E 7JE United Kingdom Skype: AlexGalis Phone +44-207-679 5738 Mobile +44-7768 493 095 Fax +44-20-7916 0388 /+44-20-7388 9325 E-mail: a.galis@ucl.ac.uk Personal Web Page: www.ee.ucl.ac.uk/~agalis Disclaimer: The information in this email and in any files transmitted with it is = intended only for the addressee and may contain confidential and/or = privileged material. Access to this email by anyone else is = unauthorized. If you receive this in error, please contact the sender = immediately and delete the material from any computer. If you are not = the intended recipient, any disclosure, copying, distribution or any = action taken or omitted to be taken in reliance on it, is strictly = prohibited. Statement and opinions expressed in this e-mail are those of = the sender, and do not necessarily reflect those of University College = London. From nobody Mon Jul 28 08:40:29 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF23D1B28CB for ; Mon, 28 Jul 2014 08:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EWxrUB1np4w for ; Mon, 28 Jul 2014 08:40:17 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED0F1B28C2 for ; Mon, 28 Jul 2014 08:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=damascene.joachimpillai@verizon.com; q=dns/txt; s=corp; t=1406562017; x=1438098017; h=from:to:cc:date:subject:message-id:mime-version; bh=jljh05+oD+64uwY21V4ZibAOiA3IbO0FOkTFthgdjts=; b=n5MmvIvJWVr1cqfQS3zc21VNe+LdDiZNopJ+2h3KW6L/iCeOhFXC3MUZ eKmh8Z2OmBEaE9SI3f2hvbmLaW5vUxNi00NMu7+SXZ62H39cC3+2lu+KD wfHmLy1ix3oYya7O+TSBuOL2lqbGVogEcXX42gt8OY+h44yG3/sLngQxT E=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe03.verizonbusiness.com with ESMTP; 28 Jul 2014 15:40:16 +0000 From: "Joachimpillai, Damascene M" X-IronPort-AV: E=Sophos;i="5.01,749,1400025600"; d="scan'208,217";a="783108502" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 28 Jul 2014 15:40:15 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Mon, 28 Jul 2014 11:40:15 -0400 To: "Haleplidis Evangelos (ehalep@gmail.com)" , "Joel M. Halpern" , "draft-ietf-forces-packet-parallelization@tools.ietf.org" Date: Mon, 28 Jul 2014 11:40:11 -0400 Thread-Topic: Sheparding draft-ietf-forces-packet-parallelization Thread-Index: Ac+qegp7bYvQkflmSMa973+2KUmTUA== Message-ID: <689CE984BDBA8B4CAF3EA6E2CDC5CACB013BF55A79@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB013BF55A79FHDP1LUMXC7V3_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/MsDU1WV17u7S_XXE9cwtvVraw6E Cc: "forces@ietf.org" , "forces-chairs@tools.ietf.org" Subject: [forces] Sheparding draft-ietf-forces-packet-parallelization X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:40:25 -0000 --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB013BF55A79FHDP1LUMXC7V3_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Evangelos/Joel, I am going to begin the shepherding process for this document, As part of t= hat process, I need to check if anyone has knowledge of any applicable IPR = that has not been declared for this draft. Please respond to this email whether or not you are aware of any relevant I= PR. If you are on the ForCES WG email list but are not listed as an author or c= ontributor, then please explicitly respond only if you are aware of any IPR= that has not yet been disclosed in conformance with IETF rules. Regards, DJ --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB013BF55A79FHDP1LUMXC7V3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Evangelos/Joe= l,

 

I am going to begin the shepherding process for this document, A= s part of that process, I need to check if anyone has knowledge of any appl= icable IPR that has not been declared for this draft.

 

Please respon= d to this email whether or not you are aware of any relevant IPR.

 

I= f you are on the ForCES WG email list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules.<= /p>

 

Reg= ards,

DJ

 

 

= --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB013BF55A79FHDP1LUMXC7V3_-- From nobody Mon Jul 28 08:51:06 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991981A0312 for ; Mon, 28 Jul 2014 08:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCN9i_BofUU1 for ; Mon, 28 Jul 2014 08:51:00 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D5F1A02EB for ; Mon, 28 Jul 2014 08:50:59 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-b6-53d61e28409d Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id AD.01.05330.82E16D35; Mon, 28 Jul 2014 11:55:52 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Mon, 28 Jul 2014 11:50:58 -0400 From: Joel Halpern To: "ehalep@gmail.com" , "jmh@joelhalpern.com" , "draft-ietf-forces-packet-parallelization@tools.ietf.org" , "damascene.joachimpillai@verizon.com" Thread-Topic: Sheparding draft-ietf-forces-packet-parallelization Thread-Index: Ac+qegp7bYvQkflmSMa973+2KUmTUAAAa6o7 Date: Mon, 28 Jul 2014 15:50:58 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB076031A4FAF@eusaamb101.ericsson.se> References: <689CE984BDBA8B4CAF3EA6E2CDC5CACB013BF55A79@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <689CE984BDBA8B4CAF3EA6E2CDC5CACB013BF55A79@FHDP1LUMXC7V31.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6BCE198E4EAEFC4CAB45D75826EFB076031A4FAFeusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLrHW1dD7lqwwblmfYvTi2cwW9x5NY3F 4sazO6wW+98/ZrR4+GY2m8XHU2+YHNg8ds66y+6xZMlPJo9zU74zeny5/JnNo/W7aABrFJdN SmpOZllqkb5dAlfGjzU/GAs6lCsmzZ/C3MC4Ua6LkYNDQsBE4snbzC5GTiBTTOLCvfVsXYxc HEICRxkldnUtY4ZwljNKLD/6kgWkik1AT2Lt+8dMIAkRgQVMEq+enmICSTALZEhsX3OMGcQW FnCQ+P5mLzuILSLgKLFo4TEWCNtI4se/p6wgm1kEVCXuLLDqYmTn4BXwlZhSDBIUEoiSaNsL No9TIFpiztwpYH2MQKd9P7UGao+4xK0n85kgThaQWLLnPDOELSrx8vE/VoiafIljt46D9fIK CEqcnPmEZQKjyCwk7bOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMXKUFqeW 5aYbGWxiBMbeMQk23R2Me15aHmIU4GBU4uF9wHo1WIg1say4MvcQozQHi5I476zaecFCAumJ JanZqakFqUXxRaU5qcWHGJk4OKUaGJ1aeA4JCr9+uPHIm3NrHGd3lrItZ3n/+EzQvsDn6mXr oy+n72VI+8D+g+/i6/8Kt/Y+ZnvXb5NksX/umc1W2/9cSmLbvuW8/4vV+Zlc+gzzLFrUG2Jv +zvwaWs8TtG6o8p9Y23siUMduxq6eAXTRBwNLSbkBSvYbdhxoqxh6xS2vZun7/5e3KjEUpyR aKjFXFScCABNiWn6ngIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/forces/u18GrUJI-RkWmSBxUDaw_xmXJx8 Cc: "forces@ietf.org" , "forces-chairs@tools.ietf.org" Subject: Re: [forces] Sheparding draft-ietf-forces-packet-parallelization X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:51:03 -0000 --_000_6BCE198E4EAEFC4CAB45D75826EFB076031A4FAFeusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All the IPR I know if has been declared. Yours, Joel Sent from my Android phone using TouchDown (www.nitrodesk.com) -----Original Message----- From: Joachimpillai, Damascene M [damascene.joachimpillai@verizon.com] Received: Monday, 28 Jul 2014, 11:41 To: Haleplidis Evangelos (ehalep@gmail.com) [ehalep@gmail.com]; Joel M. Hal= pern [jmh@joelhalpern.com]; draft-ietf-forces-packet-parallelization@tools.= ietf.org [draft-ietf-forces-packet-parallelization@tools.ietf.org] CC: forces@ietf.org [forces@ietf.org]; forces-chairs@tools.ietf.org [forces= -chairs@tools.ietf.org] Subject: Sheparding draft-ietf-forces-packet-parallelization Evangelos/Joel, I am going to begin the shepherding process for this document, As part of t= hat process, I need to check if anyone has knowledge of any applicable IPR = that has not been declared for this draft. Please respond to this email whether or not you are aware of any relevant I= PR. If you are on the ForCES WG email list but are not listed as an author or c= ontributor, then please explicitly respond only if you are aware of any IPR= that has not yet been disclosed in conformance with IETF rules. Regards, DJ --_000_6BCE198E4EAEFC4CAB45D75826EFB076031A4FAFeusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All the IPR I know if has been declared.
Yours,
Joel

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Joachimpillai, Damascene M [damascene.joachimpillai@verizon.co= m]
Received: Monday, 28 Jul 2014, 11:41
To: Haleplidis Evangelos (ehalep@gmail.com) [ehalep@gmail.com]; Joel= M. Halpern [jmh@joelhalpern.com]; draft-ietf-forces-packet-parallelization= @tools.ietf.org [draft-ietf-forces-packet-parallelization@tools.ietf.org] CC: forces@ietf.org [forces@ietf.org]; forces-chairs@tools.ietf.org = [forces-chairs@tools.ietf.org]
Subject: Sheparding draft-ietf-forces-packet-parallelization

Evangelos/Joel,

 

I am going to begin the shepherding process for t= his document, As part of that process, I need to check if anyone has knowle= dge of any applicable IPR that has not been declared for this draft.

 

Please respond to this email whether or not you a= re aware of any relevant IPR.

 

If you are on the ForCES WG email list but are no= t listed as an author or contributor, then please explicitly respond only i= f you are aware of any IPR that has not yet been disclosed in conformance w= ith IETF rules.

 

Regards,

DJ

 

 

--_000_6BCE198E4EAEFC4CAB45D75826EFB076031A4FAFeusaamb101erics_-- From nobody Mon Jul 28 12:34:03 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FE31A0AAD for ; Mon, 28 Jul 2014 12:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cVA1ipsqkLW for ; Mon, 28 Jul 2014 12:33:59 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3874D1A0460 for ; Mon, 28 Jul 2014 12:33:59 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so7887073wes.20 for ; Mon, 28 Jul 2014 12:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=BccntC4W9Ya1ISspQLsoQg9ilKIiUwvDUKcjXTmZNOU=; b=Td3wZrqsKJjU3qRWOlyXGa2+ogG6D8Erg+uci2HKsRFd6vjK9dZA29Re5fufZE8utv 95La03QEGHY9UzYo9sO7EG5gGABrfJ282EuwUA2SizAGltXxTlIk7SwL+9jAgaPCVnYX uEGmlsUs50VebOIAQQOkJoEy76YdTzVlYthOJdxAUob40pkWL4cBxWu+iigfsEEFQKCM hSO2vADJ//YeDDN+eF7CEBTjDN6qXP+iIKcY1zHsrHVeNp85QqnNUhnVRFrBW5bbho3L qj3cNduP9jNCVcKCb8d3fvHfzu0yQ95B96d3Q8FvE9aWxTlNT0Wrbrsulhvh8lx0irKk 4HCg== X-Received: by 10.180.12.76 with SMTP id w12mr9438012wib.4.1406576035452; Mon, 28 Jul 2014 12:33:55 -0700 (PDT) Received: from EhalepXPS (ppp079166038052.access.hol.gr. [79.166.38.52]) by mx.google.com with ESMTPSA id t6sm1402172wib.4.2014.07.28.12.33.53 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Jul 2014 12:33:54 -0700 (PDT) From: "Haleplidis Evangelos" To: , References: <689CE984BDBA8B4CAF3EA6E2CDC5CACB013BF55A79@FHDP1LUMXC7V31.us.one.verizon.com> <6BCE198E4EAEFC4CAB45D75826EFB076031A4FAF@eusaamb101.ericsson.se> In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB076031A4FAF@eusaamb101.ericsson.se> Date: Mon, 28 Jul 2014 22:33:50 +0300 Message-ID: <00af01cfaa9a$de015af0$9a0410d0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01CFAAB4.034E92F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+qegp7bYvQkflmSMa973+2KUmTUAAAa6o7AAe/I+A= Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/forces/8WSxtxs-yj-SVXq3yNVECmipGtI Cc: forces@ietf.org, forces-chairs@tools.ietf.org Subject: Re: [forces] Sheparding draft-ietf-forces-packet-parallelization X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 19:34:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B0_01CFAAB4.034E92F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings, Similar to Joel's response, all the IPR I know of has already been declared. With regards, Evangelos Haleplidis. From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Monday, July 28, 2014 6:51 PM To: ehalep@gmail.com; jmh@joelhalpern.com; draft-ietf-forces-packet-parallelization@tools.ietf.org; damascene.joachimpillai@verizon.com Cc: forces@ietf.org; forces-chairs@tools.ietf.org Subject: RE: Sheparding draft-ietf-forces-packet-parallelization All the IPR I know if has been declared. Yours, Joel Sent from my Android phone using TouchDown (www.nitrodesk.com) -----Original Message----- From: Joachimpillai, Damascene M [damascene.joachimpillai@verizon.com] Received: Monday, 28 Jul 2014, 11:41 To: Haleplidis Evangelos (ehalep@gmail.com) [ehalep@gmail.com]; Joel M. Halpern [jmh@joelhalpern.com]; draft-ietf-forces-packet-parallelization@tools.ietf.org [draft-ietf-forces-packet-parallelization@tools.ietf.org] CC: forces@ietf.org [forces@ietf.org]; forces-chairs@tools.ietf.org [forces-chairs@tools.ietf.org] Subject: Sheparding draft-ietf-forces-packet-parallelization Evangelos/Joel, I am going to begin the shepherding process for this document, As part of that process, I need to check if anyone has knowledge of any applicable IPR that has not been declared for this draft. Please respond to this email whether or not you are aware of any relevant IPR. If you are on the ForCES WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Regards, DJ ------=_NextPart_000_00B0_01CFAAB4.034E92F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings,

 

Similar to = Joel’s response, all the IPR I know of has already been = declared.

 

With = regards,

Evangelos Haleplidis.

 

From:= Joel = Halpern [mailto:joel.halpern@ericsson.com]
Sent: Monday, July = 28, 2014 6:51 PM
To: ehalep@gmail.com; jmh@joelhalpern.com; = draft-ietf-forces-packet-parallelization@tools.ietf.org; = damascene.joachimpillai@verizon.com
Cc: forces@ietf.org; = forces-chairs@tools.ietf.org
Subject: RE: Sheparding = draft-ietf-forces-packet-parallelization

 

All the IPR I know if has been = declared.
Yours,
Joel

Sent from my Android phone using = TouchDown (www.nitrodesk.com)

-----Orig= inal Message-----
From: Joachimpillai, Damascene M = [damascene.joachimpillai@verizon.com]
Received: Monday, 28 Jul = 2014, 11:41
To: Haleplidis Evangelos (ehalep@gmail.com) = [ehalep@gmail.com]; Joel M. Halpern [jmh@joelhalpern.com]; d= raft-ietf-forces-packet-parallelization@tools.ietf.org = [draft-ietf-forces-packet-parallelization@tools.ietf.org]
CC: = forces@ietf.org = [forces@ietf.org]; forces-chairs@tools.ietf.org= [forces-chairs@tools.ietf.org]
Subject: Sheparding = draft-ietf-forces-packet-parallelization

Evangelos/Joel,

 

I am going to begin the = shepherding process for this document, As part of that process, I need = to check if anyone has knowledge of any applicable IPR that has not been = declared for this draft.

 

Please respond to this email = whether or not you are aware of any relevant = IPR.

 

If you are on the ForCES WG email list but are not listed = as an author or contributor, then please explicitly respond only if you = are aware of any IPR that has not yet been disclosed in conformance with = IETF rules.

 

Regards,

DJ

 

 

<= /html> ------=_NextPart_000_00B0_01CFAAB4.034E92F0-- From nobody Wed Jul 30 03:05:19 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E684E1B2A83; Wed, 30 Jul 2014 03:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yy2Scy52v6tn; Wed, 30 Jul 2014 03:05:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B421A00E7; Wed, 30 Jul 2014 03:05:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140730100514.25565.91806.idtracker@ietfa.amsl.com> Date: Wed, 30 Jul 2014 03:05:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/uvkgfXJj5AoAEIS54QLqQO_97w0 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-protoextension-04.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 10:05:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Protocol Extensions Author : Jamal Hadi Salim Filename : draft-ietf-forces-protoextension-04.txt Pages : 23 Date : 2014-07-30 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 documents updates both RFC 5810 and RFC 7121 semantics to achieve that end goal. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-protoextension/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-protoextension-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-protoextension-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 30 12:59:59 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7C81A036E; Wed, 30 Jul 2014 12:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2rhSwp7SsCN; Wed, 30 Jul 2014 12:59:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3821A0359; Wed, 30 Jul 2014 12:59:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> Date: Wed, 30 Jul 2014 12:59:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/RnwFV2cZsfERRHYq9u7IvLwMgN8 Cc: forces@ietf.org Subject: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 30 Jul 2014 19:59:57 -0000 The IESG has received a request from the Forwarding and Control Element Separation WG (forces) to consider the following document: - 'ForCES Protocol Extensions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-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 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 documents updates both RFC 5810 and RFC 7121 semantics to achieve that end goal. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-forces-protoextension/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-forces-protoextension/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jul 31 14:15:05 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849681A0171 for ; Thu, 31 Jul 2014 14:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVpa9zYX1LZZ for ; Thu, 31 Jul 2014 14:15:03 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40091A010A for ; Thu, 31 Jul 2014 14:15:02 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id ij19so5277026vcb.11 for ; Thu, 31 Jul 2014 14:15:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=DSsyc86oyRc3vGlLSJdQOHjiGO6/4//xLRSao3mQiAE=; b=cJTadGLpfnRzRqfmDOukm4u49A5sZsDZ9qpkQwxrHdZtR0xJgmUj+AVawcNg4bn2l1 3NnfDkcvXxSLxsmGNNJLovLXIXyzcDNFqt/IVbxXg8eWWe06opLjJ50MqfIlkIIH5YML Rx7i9aNdisXSyrfInioMfBsO3n1diODAq0cyKIZgszwhpZR7F8WUjJflV7NiGeidM7Fq SJPNHugVkCgdR89HeAWyK5GE2JCieTOTE4sZ83fq3gS8kLT7SKKNrpufJZSqqwmvBFvB yy9bFvhJdt5+DZWDC2SukLxz55BxS33x1zlMduyfntHMRU1bJml96Va7xtfCUXGnUgFo gPIg== X-Gm-Message-State: ALoCoQlXu594Dm923WeoUJ99dxWds4gjshAIpjWuW7xXhuSE3YS4GZFyPVQmo+8We8mAluZ5r0f4 X-Received: by 10.221.56.5 with SMTP id wa5mr1165650vcb.25.1406841302052; Thu, 31 Jul 2014 14:15:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.208.107 with HTTP; Thu, 31 Jul 2014 14:14:41 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 31 Jul 2014 17:14:41 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/tEKVIWlq23YnsDmigjcuHEQ1yKI Cc: Yaakov Stein , lucasb Subject: [forces] Minutes posted X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 21:15:04 -0000 Folks, A preliminary draft of the minutes have been posted. Please review and send any corrections. Thanks to Lucas Bates for taking the minutes and Yaakov Stein for the jabber scribbing. http://www.ietf.org/proceedings/90/minutes/minutes-90-forces cheers, jamal