From internet-drafts@ietf.org Mon Jul 9 18:38:37 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E8D11E810A; Mon, 9 Jul 2012 18:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ektKWFJ6Ytge; Mon, 9 Jul 2012 18:38:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9340D11E80FD; Mon, 9 Jul 2012 18:38:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120710013836.10627.72744.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 18:38:36 -0700 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-interop-04.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 01:38:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separation= Working Group of the IETF. Title : Interoperability Report for Forwarding and Control Eleme= nt Separation (ForCES) Author(s) : Weiming Wang Kentaro Ogawa Evangelos Haleplidis Ming Gao Jamal Hadi Salim Filename : draft-ietf-forces-interop-04.txt Pages : 36 Date : 2012-07-09 Abstract: This document captures test results from the second Forwarding and control Element Separation (ForCES) interoperability test which took place on February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-interop There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-interop-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-forces-interop-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ehalep@gmail.com Wed Jul 11 13:07:39 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507D811E808E for ; Wed, 11 Jul 2012 13:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEMuWcdT1XTE for ; Wed, 11 Jul 2012 13:07:37 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD9C21F84A0 for ; Wed, 11 Jul 2012 13:07:36 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1220243wib.13 for ; Wed, 11 Jul 2012 13:08:06 -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:x-mailer:thread-index:content-language; bh=JW+OYxtl8JDBzGwbdpEuWq2rcgzBwx8JM/h+8Eucu8w=; b=gk56g2Ee6iBRNrSfIjYiLqvn9w2pDjVu3mtmhrvJv3A5VZQPXc6FM1FTHARE7ZByRS 3IrfVfakJy+sb4ssZa5B0tAmUuh6autZd1jaIZqs5fAC+S2nfG+SUEwQCj3+14YPF+DL g+XpzkzBg48BtdBPmn3kkYwqdFhT6F8L0hqk+uAk8SUvDXkRbuZgtY2N1uZMKU+O+xz8 e5khzxJhK0sDRDiFr1Jklyc4ZJlTMmI29BlWjyJX2arq5yrHIb9vanfMj7sPyWLmpNTR AAp8YxYyrvDUBGu/Rg6ng++B00WFgdmeJ8+1jfCW5SesjUljqlsvD/diDGaYNTKwX8hW C+zA== Received: by 10.180.100.133 with SMTP id ey5mr49891744wib.4.1342037286690; Wed, 11 Jul 2012 13:08:06 -0700 (PDT) Received: from EhalepXPS (ppp079167013185.access.hol.gr. [79.167.13.185]) by mx.google.com with ESMTPS id h9sm36027314wiz.1.2012.07.11.13.08.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 13:08:05 -0700 (PDT) From: "Haleplidis Evangelos" To: =?gb2312?B?J1pvbHSoom4gTGFqb3MgS2lzJw==?= References: <3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8@ESESSCMS0361.eemea.ericsson.se> In-Reply-To: <3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8@ESESSCMS0361.eemea.ericsson.se> Date: Wed, 11 Jul 2012 23:08:00 +0300 Message-ID: <000301cd5fa0$e067fd90$a137f8b0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CD5FBA.05B53590" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1EtJY/2KP1mbYMSoaj7ClE7skrogH3D87Q Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] More comments on draft-haleplidis-forces-openflow-lib-00 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 20:07:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01CD5FBA.05B53590 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Greetings, =20 Thank you again for your comments. =20 Please see inline for responses for comments requiring answer. =20 The new version have all these comments addressed. =20 Regards, Evangelos Haleplidis. =20 From: Zolt=A8=A2n Lajos Kis [mailto:zoltan.lajos.kis@ericsson.com]=20 Sent: Thursday, June 07, 2012 4:51 PM To: Haleplidis Evangelos Cc: forces@ietf.org Subject: More comments on draft-haleplidis-forces-openflow-lib-00 =20 Hi, =20 I went through the whole draft - not too thoroughly on the XML part - = and would like to clarify / comment on a few things. I'm still working on understanding the complete data model of the = described architecture, so don't take this as an exthaustive list of issues. (Btw, is there a tool available for ForCES, which can convert the XML description to a more digestive form? ER-diagrams, or similar....) =20 Regards, Zoltan. =20 =20 =20 Generic comments: =20 1) I think the Action Set description - section 4.7 in OpenFlowSpec1.1 - = is misinterpreted. In OpenFlow there is only one set of actions defined (25 + experimenter). Those = actions are used in ApplyAction, WriteAction instructions and PacketOut messages. The 9-element listing = in the section merely defined To discuss the ordering in which actions in the ActionSet must be = executed (regardless of in what order they have been written to it). These 9 elements represents different "classes" of actions. For example, "Setting a field" refers to all the action types for manipulating header fields in the frame. Actions of the same class are not concurrent, i.e., they can be executed = in arbitrary order, without affecting the overall result of executing the ActionSet. Actions of different classes however can have effect on each other, so their execution order must be specified.=20 =20 2) QoS handling is misinterpreted. In the OpenFlow 1.1 model QoS queues = are attached to (the output side of) ports. The identifiers of these queues are port-specific; i.e. both Port = 1 and Port 2 can have a queue with an ID of 2. If the controller is to send a frame to the default (or no-)queue, it = simply uses the output action. If it wants to target a specific queue of the port, it first has to set the port-local queue ID (with set_queue action), and then use the output action. The output action will forward the frame = to the appropriate port, and the port will use the queue previously appointed by the set_queue call. (Note that beginning with OpenFlow 1.3 a new Meter entity is introduced, which can be used for QoS between tables, and before outputting to ports.) =20 3) Besides the pieces of OpenFlow metadata identified, there are = additional metadata that needs to be attached to the frame - due to implicit requirements in OpenFlow, and due to the architecture of the ForCES description. queue_id: as described above in 2), the id of the queue which is to be = used on output is set by the set_queue action. Therefore the set queue_id must be passed along with the frame = as metadata for the output action to process it. of_phy_port: The OpenFlow specification allows logical ports over = physical ports. In this case a packet_in message is supposed to tell the controller both the logical and the = physical port of the packet. Thus the physical port id must also be sent along with the packet (given a = logical port was used). =20 4) The description of how outputting a frame is handled is not clear. It would seem logical that it is done by the OFOutputActionLFB only, i.e. only that LFB's output is = connected to the ports' input - but not those Of OFFlowTableLFBs. Furthermore a special ToControllerLFB should be added, which would send = the frame to the controller. This LFB could be used by both the FlowTableLFBs and the = OutputActionLFB. Also, this LFB could address the buffering of packets sent to the controller. =20 5) OpenFlow allows the controller to construct and send frames to the datapath for processing in the OFPT_PACKET_OUT message type. I believe this functionality is missing = from the current description. =20 6) OpenFlow 1.1 added extensibility features to the datapath. One can = define custom experimenter messages, matches, instructions, actions. While not necessarily the duty of this = text, it would be nice to see how that can be incorporated into the ForCES description. I.e., how an experimenter action is mapped into an (experimenter) ForCES LFB, etc. =20 =20 Comments on the text: =20 Page 5: - at the end: it should at least mention group entries, "the controller = can add, update and delete flow and group entries" =20 Page 7: - Even though it is fairly trivial to tell them apart, I think it would = make sense to add a separator between ForCES and OpenFlow definitions. Also, I think further OpenFlow concept should be explained, and the order of elements should be changed. Suggested list of elements: Match fields, Actions, Flow Entry, = Instruction, Flow Table, Pipeline, Action Set, Groups (incl. GroupEntry and GroupTable), Ports. (I'm willing to provide definition for these terms.) [=A6=A5=A6=A7] I have made an attempt, however if you=A1=AFll find the = definitions inadequate please provide me with alternatives. Thanks. =20 Page 9: - Fig. 1., and the text below suggests that one piece of metadata (the Action Set) is available in the packet before entering Flow Table 0, while another piece (the Metadata field) is only available after leaving the table. I believe a more convenient description would be if the Metadata is = already available when entering Flow Table 0, with a default value of all zero. 1) A table not necessarily touches Metadata, so in the current method FlowTable 0 would have the special function of "create if not exists" the Metadata. 2) The OpenFlowSpec1.1 in theory allows modifying Metadata with bitmasks used - let alone matching on it. [=A6=A5=A6=A7] Both Metadata and ActionSet Metadata are now invisible to = the model since all Flow Tables reside within one OFFlowTable LFB.=20 =20 - "Write Metadata action" should be "Write Metadata instruction" =20 - "Forward to the OpenFlow controllers" should be changed to singular "controller". OF 1.1 does not define multi-controller support. It is only added in OF 1.2 =20 - "The list of actions a Flow Table may perform..." should be "The list = of instructions..." =20 Page 10: =20 - "Write a List of actions to the action set" would be more correct as = "set of actions", and should refer to the method of writing the action set (which should probably be described among the concepts of Page 7. =20 - "The list of actions the Flow Table can perform or write in the = Action Set is". Similar to generic comment 1), this is not a list of possible actions, but rather the list of the different action "classes". =20 - "Additionally a Flow Table may drop the packet as an action. The drop action is implicit based on the Flow Table's configuration.". This sentence is confusing. The configuration is only consulted in case of no match. As this listing is for the list of actions in write actions, there is no drop action. On match a flow entry can drop a flow by clearing the action set, and not specifying a goto. =20 - "An Action Set contains a maximum of one action of the following types...". Should be "...one action of each type...". (See generic comment 1) =20 - "1. Copy TTL Outwards" should be "1. Copy TTL Inwards" =20 Page 11: =20 - "The Group Table contains a set of actions": the Group Table contains = a set of Group Entries, each of which contains a set of "Action Buckets", each of which contains a set of actions. =20 Page 11-13 (Fig 2-4.): =20 - At this point the basic architectural decisions (i.e. ActionLFBs maintaining the action parameters) are not described, so the use of ActionIndex is quite confusing at this point. =20 - Also it is not clear (and remains unclear to me), that after the FlowTableLFB sent the packet for processing to an ActionLFB, when the packet returns from processing, how will the FlowTableLFB know the processing state of the packet? Particularly, how does it know which was the matching flow entry, and = which action in the action list is being executed? [=A6=A5=A6=A7] A new metadata has been added, the PacketID which must = uniquely identify a packet inside the switch. This is not implementation = specific, but rather internal info as how the packet can be identified. This = metadata can be used to track a packets progress within the Flow or Group Table = and when it returns it can continue from where it stopped.=20 Thank you for this catch. =20 Page 15: =20 - "Additionally each OFFlowTable can output a packet to a specific = port." As in generic comment 4), this should not be the case. Tables can only output to the controller (without = OutputAction involvment). [=A6=A5=A6=A7] Text has been changed (as per the figure). =20 - On Fig 5. a number of arrows are missing from the lines pointing to OFPorts. [=A6=A5=A6=A7] Fig 5 has been completely renovated. =20 Page 16: =20 - The "OpenFlow Atomic Types" table: it should be made clear that there = are more atomic types used in the OpenFlow description, but those types (e.g., IEEEMAC) are defined elsewhere - I = guess in the LFB Library. [=A6=A5=A6=A7] Yes, the types are defined in the LFB library. Added = necessary text. =20 - ActionSetType: see the generic comment on action sets [=A6=A5=A6=A7] The ActionSet model has been changed. =20 Page 20: =20 - "... the maximum number of bytes of new flow that datapath should send = ... ". "new flow" is not a correct a term here. "unmatched / invalid frame" should be better. The controller does not neccesarily ant to convert it to a flow. =20 Page 22: =20 - first paragraph: same comment as for Page 9 / Fig 1. regarding Action = Set vs. Metadata field =20 - sencond paragraph: as Dave Meyer commented already, the text should elaborat on how matching is done. I would suggest that it is described among the description of concepts, and this = paragraph refers to that. [=A6=A5=A6=A7] The text has been changed. =20 =20 Page 24: =20 - It it intentional that "buffer" is made a component of the FlowTable, = and not a separate LFB? In OpenFlow a packet is buffered when sent to the controller, regardless of which table it = came on. With packet out, the controller can instruct the switch to execute "on the fly defined" actions on the = packet and/or send it through the pipeline starting at Table 0. There is no need for keeping track of which packet was = buffered in which table. [=A6=A5=A6=A7] BufferID is a metadata and will be removed from the = FlowTable as well. As the BufferLFB would hold no information whatsoever, there is no need to have it as a separate LFB. The FlowTable will produce the = bufferID metadata and send it to the controller. =20 Page 25: =20 - OFPortLFB / Data Handling: The OpenFlow spec. allows a port to be a "logical port" defined over the physical ports. So the OFPort is not necessarily directly connected to the phyisical = medium ports. =20 =20 Page 26: =20 - OFQueueLFB: see generic comment 2) on how QoS is defined. =20 - "The Length component" : I think this is a misunderstanding. The queue does not have a length. The only length we have in the Queue context is the length of the queue properties, which = is a wire protocol feature (for the TLV structure), and so should not be reflected in the data model. =20 Page 27: =20 - "length of the property" : see above comment. =20 - "maximum 9 actions": see general comment 1" =20 - "maximum size 9 rows": see general comment 1" [=A6=A5=A6=A7] The length is removed, the ActionSetLFB has been removed. = =20 Page 28: =20 - "As none of the OFActionLFBs have no capabilities..." - there no is = not needed =20 Page 29: =20 - "Only valid in the action set of a packet-out message" should be = "action list of a packet-out message". =20 Page 33: =20 - 5.8.18.2: the Push VLAN action's argument is an Ethertype, not a VLAN header value. =20 Page 35: =20 - 5.8.25.2: "SetIPTTLTable" is probably wrong, something like " [=A6=A5=A6=A7] Why? There is a Set IPv4 TTL action.. =20 Page 36: =20 - "C:\Workspace\Forces...\" - I guess this should be something else [=A6=A5=A6=A7] Indeed! J I use the schema to validate the xml, but the = location is locally to my pc. =20 Page 37: =20 - MPLSLabelValue: 1048576 should be 1048575 =20 - IPv4ToSBits: 64 should be 63 =20 - "Ethermet frame typ Wildcard" - e missing =20 Page 38: =20 - IngressPort: certain values are invalid for the match type (those > OFPP_MAX) =20 Page 39: =20 - ArpOpcode: As of OpenFlow 1.1, this field is "overloaded" into the IP protocol field. Is it intentional that it is separately defined? [=A6=A5=A6=A7] This is the IPProtocol field (with the ARP opcode) Text = is fixed. =20 Page 48: =20 - "Buffer Reason" should be "Packet-in reason" =20 Page 50: =20 - "multiple ows" -> "multiple flows" =20 - "speciffic" -> "specific" =20 Page 52: =20 - "VLNA" -> "VLAN" =20 Page 53: =20 - "administatevely" - "administratively" =20 Page 57: =20 - "trasmittion" - "transmission" =20 Page 58: =20 - "Length of property" : same as for Page 26. This is a wire protocol = TLV feature, should be not part of the data model. =20 - ActionsetLFB dataTypeDef: see generic comment 1 ------=_NextPart_000_0004_01CD5FBA.05B53590 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Greetings,

 

Thank you again for your comments.

 

Please see inline for responses for comments requiring = answer.

 

The new version have all these comments = addressed.

 

Regards,

Evangelos Haleplidis.

 

From:= = Zolt=A8=A2n Lajos Kis [mailto:zoltan.lajos.kis@eri= csson.com]
Sent: Thursday, June 07, 2012 4:51 = PM
To: Haleplidis Evangelos
Cc: forces@ietf.org
Subject: = More comments on = draft-haleplidis-forces-openflow-lib-00

=

 

Hi,

 

I went = through the whole draft - not too thoroughly on the XML part -  and = would like to clarify / comment on a few = things.

I'm still = working on understanding the complete data model of the described = architecture, so don't take this as = an

exthaustive = list of issues. (Btw, is there a tool available for ForCES, which can = convert the XML description to a more = digestive

form? = ER-diagrams, or similar....)

 

Regards,=

Zoltan.<= /o:p>

 

 

 

Generic = comments:

 

1) I think = the Action Set description - section 4.7 in OpenFlowSpec1.1 - is = misinterpreted. In OpenFlow

there is = only one set of actions defined (25 + experimenter). Those actions are = used in ApplyAction,

WriteAction = instructions and PacketOut messages. The 9-element listing in the = section merely defined

To discuss = the ordering in which actions in the ActionSet must be executed = (regardless of in what order

they have = been written to it). These 9 elements represents different = "classes" of actions. For = example,

"Setting= a field" refers to all the action types for manipulating header = fields in the frame.

Actions of = the same class are not concurrent, i.e., they can be executed in = arbitrary order, without

affecting = the overall result of executing the ActionSet. Actions of different = classes however can have

effect on = each other, so their execution order must be specified. =

 

2) QoS = handling is misinterpreted. In the OpenFlow 1.1 model QoS queues are = attached to (the output side of)

ports. The = identifiers of these queues are port-specific; i.e. both Port 1 and Port = 2 can have a queue with an ID of 2.

If the = controller is to send a frame to the default (or no-)queue, it simply = uses the output action. If it

wants to = target a specific queue of the port, it first has to set the port-local = queue ID (with set_queue action),

and then use = the output action. The output action will forward the frame to the = appropriate port, and the port will

use the = queue previously appointed by the set_queue = call.

(Note that = beginning with OpenFlow 1.3 a new Meter entity is introduced, which can = be used for QoS between

tables, and = before outputting to ports.)

 

3) Besides = the pieces of OpenFlow metadata identified, there are additional = metadata that needs to be attached

to the frame = - due to implicit requirements in OpenFlow, and due to the architecture = of the ForCES description.

queue_id: as = described above in 2), the id of the queue which is to be used on output = is set by the set_queue

action. = Therefore the set queue_id must be passed along with the frame as = metadata for the output action

to process = it.

of_phy_port: = The OpenFlow specification allows logical ports over physical ports. In = this case a packet_in

message is = supposed to tell the controller both the logical and the physical port = of the packet. Thus the

physical = port id must also be sent along with the packet (given a logical port = was used).

 

4) The = description of how outputting a frame is handled is not clear. It would = seem logical that it is

done by the = OFOutputActionLFB only, i.e. only that LFB's output is connected to the = ports' input - but not those

Of = OFFlowTableLFBs.

Furthermore = a special ToControllerLFB should be added, which would send the frame to = the controller.

This LFB = could be used by both the FlowTableLFBs and the OutputActionLFB.  = Also, this LFB could address

the = buffering of packets sent to the = controller.

 

5) OpenFlow = allows the controller to construct and send frames to the datapath for = processing in the

OFPT_PACKET_O= UT message type. I believe this functionality is missing from the = current description.

 

6) OpenFlow = 1.1 added extensibility features to the datapath. One can define custom = experimenter messages,

matches, = instructions, actions. While not necessarily the duty of this text, it = would be nice to see how

that can be = incorporated into the ForCES description. I.e., how an experimenter = action is mapped into

an = (experimenter) ForCES LFB, etc.

 

 

Comments on = the text:

 

Page = 5:

- at the = end: it should at least mention group entries, "the controller can = add, update and delete flow and group = entries"

 

Page = 7:

- Even = though it is fairly trivial to tell them apart, I think it would make = sense to add a separator between

ForCES and = OpenFlow definitions. Also, I think further OpenFlow concept should be = explained, and the order of elements

should be = changed.

Suggested = list of elements: Match fields, Actions, Flow Entry, Instruction, Flow = Table, Pipeline, Action Set,

Groups = (incl. GroupEntry and GroupTable), = Ports.

(I'm willing = to provide definition for these = terms.)

[=A6=A5=A6=A7] I have made an attempt, however if you=A1=AFll find = the definitions inadequate please provide me with alternatives. = Thanks.

 

Page = 9:

- Fig. 1., = and the text below suggests that one piece of metadata (the Action Set) = is available in the packet before

entering = Flow Table 0, while another piece (the Metadata field) is only available = after leaving the table.

I believe a = more convenient description would be if the Metadata is already = available when entering Flow Table 0,

with a = default value of all zero.

1) A table = not necessarily touches Metadata, so in the current method FlowTable 0 = would have the special function

of = "create if not exists" the Metadata. 2) The OpenFlowSpec1.1 in = theory allows modifying Metadata with bitmasks = used

- let alone = matching on it.

[=A6=A5=A6=A7] Both Metadata and ActionSet Metadata are now invisible = to the model since all Flow Tables reside within one OFFlowTable LFB. =

 

- = "Write Metadata action" should be "Write Metadata = instruction"

 

- = "Forward to the OpenFlow controllers" should be changed to = singular "controller". OF 1.1 does not define = multi-controller

support. It = is only added in OF 1.2

 

- "The = list of actions a Flow Table may perform..." should be "The = list of instructions..."

 

Page = 10:

 

- = "Write a List of actions to the action set" would be more = correct as "set of actions", and should refer to the = method

of writing = the action set (which should probably be described among the concepts of = Page 7.

 

- "The = list of actions the Flow Table can perform  or write in the Action = Set is". Similar to generic comment 1), = this

is not a = list of possible actions, but rather the list of the different action = "classes".

 

- = "Additionally a Flow Table may drop the packet as an action. The = drop action is implicit based on the Flow = Table's

configuration= .". This sentence is confusing. The configuration is only consulted = in case of no match. As this listing

is for the = list of actions in write actions, there is no drop action. On match a = flow entry can drop a flow by

clearing the = action set, and not specifying a = goto.

 

- "An = Action Set contains a maximum of one action of the following = types...". Should be "...one action of each = type...".

(See generic = comment 1)

 

- "1. = Copy TTL Outwards" should be "1. Copy TTL = Inwards"

 

Page = 11:

 

- "The = Group Table contains a set of actions": the Group Table contains a = set of Group Entries, each of which = contains

  a set = of "Action Buckets", each of which contains a set of = actions.

 

Page 11-13 = (Fig 2-4.):

 

- At this = point the basic architectural decisions (i.e. ActionLFBs maintaining the = action parameters) are not described,

so the use = of ActionIndex is quite confusing at this = point.

 

- Also it is = not clear (and remains unclear to me), that after the FlowTableLFB sent = the packet for processing to an

ActionLFB, = when the packet returns from processing, how will the FlowTableLFB know = the processing state of the packet?

Particularly,= how does it know which was the matching flow entry, and which action in = the action list is being executed?

[=A6=A5=A6=A7] A new metadata has been added, the PacketID which must = uniquely identify a packet inside the switch. This is not implementation = specific, but rather internal info as how the packet can be identified. = This metadata can be used to track a packets progress within the Flow or = Group Table and when it returns it can continue from where it stopped. =

Thank you for this catch.

 

Page = 15:

 

- = "Additionally each OFFlowTable can output a packet to a specific = port." As in generic comment 4), this should = not

be the case. = Tables can only output to the controller (without OutputAction = involvment).

[=A6=A5=A6=A7] Text has been changed (as per the = figure).

 

- On Fig 5. = a number of arrows are missing from the lines pointing to = OFPorts.

[=A6=A5=A6=A7] Fig 5 has been completely = renovated.

 

Page = 16:

 

- The = "OpenFlow Atomic Types" table: it should be made clear that = there are more atomic types used in the = OpenFlow

description, = but those types (e.g., IEEEMAC) are defined elsewhere - I guess in the = LFB Library.

 = [=A6=A5=A6=A7] Yes, the types are defined in the LFB library. Added = necessary text.

 

- = ActionSetType: see the generic comment on action = sets

[=A6=A5=A6=A7] The ActionSet model has been = changed.

 

Page = 20:

 

- "... = the maximum number of bytes of new flow that datapath should send = ...". "new flow" is not a correct a term = here.

"unmatch= ed / invalid frame" should be better. The controller does not = neccesarily ant to convert it to a = flow.

 

Page = 22:

 

- first = paragraph: same comment as for Page 9 / Fig 1. regarding Action Set vs. = Metadata field

 

- sencond = paragraph: as Dave Meyer commented already, the text should elaborat on = how matching is done. I would suggest

that it is = described among the description of concepts, and this paragraph refers = to that.

[=A6=A5=A6=A7] The text has been = changed.

 

 

Page = 24:

 

- It it = intentional that "buffer" is made a component of the = FlowTable, and not a separate LFB? In OpenFlow a = packet

is buffered = when sent to the controller, regardless of which table it came on. With = packet out, the controller can

instruct the = switch to execute "on the fly defined" actions on the packet = and/or send it through the pipeline = starting

at Table 0. = There is no need for keeping track of which packet was buffered in which = table.

 = [=A6=A5=A6=A7] BufferID is a metadata and will be removed from the = FlowTable as well. As the BufferLFB would hold no information = whatsoever, there is no need to have it as a separate LFB. The FlowTable = will produce the bufferID metadata and send it to the = controller.

 

Page = 25:

 

- OFPortLFB = / Data Handling: The OpenFlow spec. allows a port to be a "logical = port" defined over the physical = ports.

So the = OFPort is not necessarily directly connected to the phyisical medium = ports.

 

 

Page = 26:

 

- = OFQueueLFB: see generic comment 2) on how QoS is = defined.

 

- "The = Length component" : I think this is a misunderstanding. The queue = does not have a length. The only length = we

have in the = Queue context is the length of the queue properties, which is a wire = protocol feature (for the TLV = structure),

and so = should not be reflected in the data = model.

 

Page = 27:

 

- = "length of the property" : see above = comment.

 

- = "maximum 9 actions": see general comment = 1"

 

- = "maximum size 9 rows": see general comment = 1"

[=A6=A5=A6=A7] The length is removed, the ActionSetLFB has been = removed.

 

Page = 28:

 

- "As = none of the OFActionLFBs have no capabilities..." - there no is not = needed

 

Page = 29:

 

- "Only = valid in the action set of a packet-out message" should be = "action list of a packet-out = message".

 

Page = 33:

 

- 5.8.18.2: = the Push VLAN action's argument is an Ethertype, not a VLAN header = value.

 

Page = 35:

 

- 5.8.25.2: = "SetIPTTLTable" is probably wrong, something like = "

 = [=A6=A5=A6=A7] Why? There is a Set IPv4 TTL = action..

 

Page = 36:

 

- = "C:\Workspace\Forces...\" - I guess this should be something = else

[=A6=A5=A6=A7] Indeed! J I use the schema to validate the xml, but the location is locally to = my pc.

 

Page = 37:

 

- = MPLSLabelValue: 1048576 should be = 1048575

 

- = IPv4ToSBits: 64 should be 63

 

- = "Ethermet frame typ Wildcard" - e = missing

 

Page = 38:

 

- = IngressPort: certain values are invalid for the match type (those > = OFPP_MAX)

 

Page = 39:

 

- ArpOpcode: = As of OpenFlow 1.1, this field is "overloaded" into the IP = protocol field. Is it intentional

that it is = separately defined?

[=A6=A5=A6=A7] This is the IPProtocol field (with the ARP opcode) = Text is fixed.

 

Page = 48:

 

- = "Buffer Reason" should be "Packet-in = reason"

 

Page = 50:

 

- = "multiple ows" -> "multiple = flows"

  &= nbsp;            =

- = "speciffic" -> = "specific"

 

Page = 52:

 

- = "VLNA" -> = "VLAN"

 

Page = 53:

 

- = "administatevely" - = "administratively"

 

Page = 57:

 

- = "trasmittion" - = "transmission"

 

Page = 58:

 

- = "Length of property" : same as for Page 26. This is a wire = protocol TLV feature, should be not part of the data = model.

 

- = ActionsetLFB dataTypeDef: see generic comment = 1

------=_NextPart_000_0004_01CD5FBA.05B53590-- From ehalep@gmail.com Wed Jul 11 13:09:50 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C90021F852A for ; Wed, 11 Jul 2012 13:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=1.376, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kuKSC9a6COT for ; Wed, 11 Jul 2012 13:09:49 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 67C6F21F84AF for ; Wed, 11 Jul 2012 13:09:49 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1000867wgb.13 for ; Wed, 11 Jul 2012 13:10:18 -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 :content-transfer-encoding:x-mailer:thread-index:content-language; bh=k7a/KYgR4levb8OEp7dPky+btBbGuBAwojaxio3FFg8=; b=x55yGEJyFnQyWwrrnIfxr3XWbTAjuKIkqSYXz6e9qFNGv1w106R0gX5/2ase++c/k4 Dosr3u60lgX1W+3iIcKonnZUV7tdLljIz+XEA2eUvk29ow5sIQy3OJYpPZCV5hOCjNHZ L/Ygh8Ha0/qUdoiUhcIZFuKsOoUuibqgunXWJRpOTA67j6ldsSvLxn2GyGJJ7EzZzPeI hU0IkXW3cJM0+3RAoZAvhhXTJ0DVN0ukQ8xxgWxTIi03JaZbiVjDtq00Ly+hR9c23D0s 8kI2kZ8IlySjzhOWg4nKhVFTBKgYTrcXDOh5YelKFwnIUg4mISqvBR7SoGgfLah4ABSN N/Uw== Received: by 10.180.97.33 with SMTP id dx1mr7588588wib.18.1342037417829; Wed, 11 Jul 2012 13:10:17 -0700 (PDT) Received: from EhalepXPS (ppp079167013185.access.hol.gr. [79.167.13.185]) by mx.google.com with ESMTPS id t8sm36042016wiy.3.2012.07.11.13.10.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 13:10:17 -0700 (PDT) From: "Haleplidis Evangelos" To: Date: Wed, 11 Jul 2012 23:10:13 +0300 Message-ID: <000801cd5fa1$2f3f3fa0$8dbdbee0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1fog/qWurPuD5GQuKogl1yyQFPkgAAb+Ww Content-Language: el Subject: [forces] FW: New Version Notification for draft-haleplidis-forces-openflow-lib-01.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 20:09:50 -0000 Greetings to the list, This is the second version of the OpenFlow LFB library document, = currently only for the OpenFlow 1.1 switch specification. Regards, Evangelos Haleplidis. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, July 11, 2012 11:01 PM > To: ehalep@ece.upatras.gr > Cc: cherkaoui.omar@uqam.ca; wmwang@zjgsu.edu.cn; shares@ndzh.com > Subject: New Version Notification for = draft-haleplidis-forces-openflow- > lib-01.txt >=20 >=20 > A new version of I-D, draft-haleplidis-forces-openflow-lib-01.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Filename: draft-haleplidis-forces-openflow-lib > Revision: 01 > Title: Forwarding and Control Element Separation (ForCES) > OpenFlow Model Library > Creation date: 2012-07-09 > WG ID: Individual Submission > Number of pages: 97 > URL: = http://www.ietf.org/internet-drafts/draft-haleplidis-forces-openflow-lib-= 01.txt > Status: = http://datatracker.ietf.org/doc/draft-haleplidis-forces-openflow-lib > Htmlized: = http://tools.ietf.org/html/draft-haleplidis-forces-openflow-lib-01 > Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-haleplidis-forces-openflow-lib= -01 >=20 > Abstract: > This document describes the OpenFlow switch in Logical Function > Blocks (LFBs) used in the Forwarding and Control Element Separation > (ForCES). The LFB classes are defined according to the ForCES > Forwading Element (FE) model and ForCES protocol specifications. > The > library includes the descriptions of the OpenFlow LFBs and the XML > definitions. >=20 >=20 >=20 >=20 > The IETF Secretariat From hadi@mojatatu.com Thu Jul 12 08:40:20 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B0111E80E4 for ; Thu, 12 Jul 2012 08:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFgb998oVt8t for ; Thu, 12 Jul 2012 08:40:20 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 17A6511E80BC for ; Thu, 12 Jul 2012 08:40:15 -0700 (PDT) Received: by qaea16 with SMTP id a16so1731157qae.10 for ; Thu, 12 Jul 2012 08:40:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=4yV7InuJFwcY2uKXpXPBUr5lW2hIu2XITCgYPiRax+4=; b=VKD2sxVfSGvX6i9LGZ8HIHpKsUbcAN0lcd5jGK8GihktKMhqTAeuTTl4Y0VWqRDWGH vz8Vj1EVSzHPdAXTHyaqGOfch9VTJAKlIf5wGhtPjEm9oYKxAiUr4JS/LRtaj2cJn9GA j+Cwalvxm6OXPzoVQ3BktJB0ExLBtKbpQMt2InhFHmsaQ1Mx8g2nSvzlpVAR8TruEXSW 87ZE8jwE0N6AR7sKBjrjd4TP/VIfSLK6M12ACI2jTIr3aiLtzn5adYqEUXDPvEx4UZqB 2sBsTGc6eVdAo/BhiYNsccJDP3Spt0JcabxcH4sbaErQFP7mqxQ2MN6OhKxSi558Gaer BVvg== Received: by 10.60.7.104 with SMTP id i8mr55442010oea.31.1342107649155; Thu, 12 Jul 2012 08:40:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.134.137 with HTTP; Thu, 12 Jul 2012 08:40:28 -0700 (PDT) In-Reply-To: <4FFEDDFC.9050809@mojatatu.com> References: <4FFEDDFC.9050809@mojatatu.com> From: Jamal Hadi Salim Date: Thu, 12 Jul 2012 11:40:28 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmHfPAZ3bzu7wcmOezgfx51svt0nP9PEaQab7mAuOgCN74N0a7hDm0R5IUL32YgE8IoY0wq Cc: Glen Sandness , forces@ietf.org Subject: [forces] Fwd: OpenFlow XML errata X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 15:40:21 -0000 Greetings Evangelos, We are trying to implement this draft in time for the meeting. Here are some comments. Some of them probably are implementation specific to us. We'll send you the fixed up xml separately. cheers, jamal ---------- Forwarded message ---------- From: Glen Sandness Date: Thu, Jul 12, 2012 at 10:23 AM Subject: OpenFlow XML errata To: Jamal Hadi Salim Following is a summary of all the changes required to make the latest OpenFlow xml usable with the Mojatatu ForCES SDK toolset: dataTypeDef MatchFieldType - component IPProto has a typeRef of "uchar8", which should be "uchar". dataTypeDef InstructionTypes - forward reference from dataTypeDef FlowEntry. Definition of InstructionTypes must be moved before that of FlowEntry. dataTypeDef FlowCounterType - forward reference from dataTypeDef FlowEntry. Definition of FlowCounterType must be moved before that of FlowEntry. dataTypeDef ActionType - forward reference from dataTypeDef ActionRowType. Definition of ActionType must be moved before that of FlowEntry. dataTypeDef ActionRowType - forward reference from dataTypeDef TableCounterType. Definition of ActionRowType must be moved before that of TableCounterType. dataTypeDef GroupBucketExecuteType - atomic special values list includes a special value "select", which is invalid as a C identifier due to the overlap with the glibc/syscall function of the same name. Fixed this by capitalizing the name of all special values for this dataTypeDef ("Select", "Indirect", "FastFailover"). dataTypeDef ActionBucket - forward reference from dataTypeDef GroupTableEntry. Definition of ActionBucket must be moved before that of GroupTableEntry. dataTypeDef PortFeaturesType - Special value names for atomic SpeedTypes are invalid as C identifiers because the names start with a digit. Fixed this by prefixing all the special value names with "Speed_", resulting in "Speed_10MB_HD", "Speed_10MB_FD", etc. LFBClass OFSwitch - All events in this LFBClass have no reports defined, and are therefore invalid. Temporary fix implemented by commenting out these events. LFBClass OFFlowTables - The event defined for this LFBClass has a target path which does not start from a component, but rather starts from a field in a structure residing in an array. To be valid, this event would have to include the name of the array and a wildcard for the row index at the beginning of the event target path. Same problem exists in all the eventReport paths. Temporary fix implemented by commenting out this event. LFBClass OFPort - Component 5 has a typeRef of PortState, which is undefined. This should be PortStateType. LFBClass OFRedirectIn - Declared as derivedFrom RedirectIn, which is not itself defined. Fixed by commenting out the derivedFrom line. - Strangely, companion LFBClass OFRedirectOut has no such line. Regards, Glen From hadi@mojatatu.com Sun Jul 15 09:37:37 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D15B21F85C0 for ; Sun, 15 Jul 2012 09:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk5VlPg8TGgX for ; Sun, 15 Jul 2012 09:37:36 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8025521F85B4 for ; Sun, 15 Jul 2012 09:37:36 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9070968obb.31 for ; Sun, 15 Jul 2012 09:38:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=oaG9PfY2BiN1cIXrkCpy07Y2HJp188yd+MElAe/ZTCU=; b=WCl+KVHIOaVoCTlqWH2lrJgqHC+bhIV8gD/L86g3fsyUf1KEKM9aqMgsmc812weVTl NS3IDBta1uQb7qlPR1AsnWFDtHwM+jLvgSxZJPZVpAbEs7w9kumjVKbT4wxf4QzkpPg/ 1OsJ3F09dRditSsnYOI2/9U7SyCD8hKkeul3ZLzYmtTp76JLd6mWGdSWfFENB7kWyL7M C01RzTIu9G/51XIm6EwB57mKTbldAwB2bI5zmboVCOnQTCf7BqHW5sze7zY69bmlDB17 nmCCFA7sMoU9Yc3GatpkSWp+fb7AKGmWzCwn2fwUTDYLBltk459ef0iPEcvI/kuf03LY zsoQ== Received: by 10.60.28.101 with SMTP id a5mr11255265oeh.69.1342370298543; Sun, 15 Jul 2012 09:38:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.134.137 with HTTP; Sun, 15 Jul 2012 09:37:58 -0700 (PDT) From: Jamal Hadi Salim Date: Sun, 15 Jul 2012 12:37:58 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnkrWlhgqkbNTkVDig3v1KfcMxZnllxLTieBQFTe97oQTJ2WQVtcllLb4EBI2HUyZjarDdl Cc: sdnp , sdn@irtf.org Subject: [forces] New draft: draft-hares-forces-vs-openflow X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 16:37:37 -0000 For some reason Sue's draft didnt seem to propagate on the ietf announce list: http://datatracker.ietf.org/doc/draft-hares-forces-vs-openflow/ cheers, jamal From internet-drafts@ietf.org Mon Jul 16 11:16:06 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06511E810C; Mon, 16 Jul 2012 11:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE8dM2kbLIjl; Mon, 16 Jul 2012 11:16:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A11911E8072; Mon, 16 Jul 2012 11:16:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716181605.31906.29745.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 11:16:05 -0700 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-ceha-04.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 18:16:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separation= Working Group of the IETF. Title : ForCES Intra-NE High Availability Author(s) : Kentaro Ogawa Weiming Wang Evangelos Haleplidis Jamal Hadi Salim Filename : draft-ietf-forces-ceha-04.txt Pages : 25 Date : 2012-07-16 Abstract: This document discusses CE High Availability within a ForCES NE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-ceha There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-ceha-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-forces-ceha-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hadi@mojatatu.com Thu Jul 19 11:19:14 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F62921F8679 for ; Thu, 19 Jul 2012 11:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.823 X-Spam-Level: X-Spam-Status: No, score=-102.823 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9Bz2+tZ4uL7 for ; Thu, 19 Jul 2012 11:19:13 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC0F21F8678 for ; Thu, 19 Jul 2012 11:19:13 -0700 (PDT) Received: by qcac10 with SMTP id c10so2046345qca.31 for ; Thu, 19 Jul 2012 11:20:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=rkXuveH6YqNW4QazVbPjeiG9FAcTWolj5jagailTjXU=; b=Q/JbaUkQhahBKgNXFBLORy7BMr87SFV7MnI4lWtc3cCltgZ387XLg/YhG/vhNUfmC9 h2wW/MNjpYN6KnsrbsJef7n1YS8zPOchfHmfv+PggPkVxQBbam238OqKJafp8kHheB5O btE7+RVJFx4WWZ+NiZUzjUS7c9JUIRRDW7Ie7zhhgHOMfXPtfQf3pmW/AYZ9xDVSahtr LgcAJ6i9eTrmCdeT5nKpGNkF2IQILVbGzxJ3y3bPYiY9SOJedA0RnzpJ0p9nRIQbnfk6 bcZUAGDhABPchoCN4auKwWd8eXJgjGNVGq5eTakkNjOzxT2l3slXDsfjLhVpeS9kavWb l1zg== Received: by 10.182.164.40 with SMTP id yn8mr3954477obb.40.1342722006953; Thu, 19 Jul 2012 11:20:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.134.137 with HTTP; Thu, 19 Jul 2012 11:19:46 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 19 Jul 2012 14:19:46 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmKubh2JDzE0smaSXdqCbvFr8yGb7kqHP898q0GH+iZz/yN6ccpPlWIDKRTUS7Tllbw7avU Subject: [forces] meeting moved to tuesday X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 18:19:14 -0000 Folks, The meeting has been moved from Thursday to Tuesday 1700-1830 cheers, jamal From hadi@mojatatu.com Sun Jul 29 09:43:55 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE9A21F8716 for ; Sun, 29 Jul 2012 09:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.812 X-Spam-Level: X-Spam-Status: No, score=-102.812 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIkrNkcxosee for ; Sun, 29 Jul 2012 09:43:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB2CC21F862B for ; Sun, 29 Jul 2012 09:43:49 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so8708596obb.31 for ; Sun, 29 Jul 2012 09:43:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=CMcKzECfOhAMRlVBj23VJAI8TB8VAzpmMYIPmhCpuNk=; b=lRXq1QqTx8p5C3/gbGTAOh8qpqreo7Sf9TEueasTcBfrpnu6brmq+0+HhsZbGj9neM o2Xg9x8lZC5Ul47duGGrzgwA6nVQVtG+VGYSrP8i3Rd3jweeGMO2/HI/VJZvrOaUFACL leeCV8umxmTbVxdtXBmwVSzIJNULgqgka19QNs2ZJUS2aHCNCl4dI99uZ1fj7tSQidxJ h8MbBFRMJ7d02FDa+g0MrZMMfO/Oiqur01aYlYpfR2M1hrosI/34YY+jRqoOzRW9clTR wTtApJD1LBKQvh/bbZ4UvNdWPFkRVTZvxRtPBWIZlMACuQwWcffBPHRbG3sJBSTr6qoE iqxQ== Received: by 10.60.20.233 with SMTP id q9mr10383226oee.57.1343580229458; Sun, 29 Jul 2012 09:43:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.134.137 with HTTP; Sun, 29 Jul 2012 09:43:29 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Sun, 29 Jul 2012 12:43:29 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnmLTW6qXokpJVh4gE7ACGzSYgtXLD5HYHxihDJ33rvUovNvmyVQDN6NOhxJ0ts1ctmtBZ7 Subject: [forces] Fwd: IRS mailing list created X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 16:43:55 -0000 Discussion in the Routing Area meeting this coming Thursday. cheers, jamal ---------- Forwarded message ---------- From: Thomas Nadeau Date: Sun, Jul 29, 2012 at 12:37 PM Subject: [Sdnp] IRS mailing list created To: "sdnp@lucidvision.com" A new IETF non-working group email list has been created. List address: irs-discuss@ietf.org Archive: http://www.ietf.org/mail-archive/web/irs-discuss/ To subscribe: https://www.ietf.org/mailman/listinfo/irs-discuss Purpose: This list is for the discussion of an interface to the routing system (IRS) that allows applications to rapidly and dynamically install routing state into routers, and to learn sufficient information from routers to make timely, data-based decisions about what routing state to specify. Such an interface would facilitate control and diagnosis of the routing infrastructure, as well as enabling sophisticated applications to be built on top of today's routed networks. The IRS is conceived as a programmatic, streaming interface for transferring state into and out of the Internet's routing system, recognizing that the routing system and a router's OS provide useful mechanisms that applications could harness to accomplish application-level goals. A fundamental component of the IRS is a clear data model that defines the semantics of the information that can be written and read. For additional information, please contact the list administrators. _______________________________________________ SDNP mailing list SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp From hadi@mojatatu.com Sun Jul 29 21:46:04 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BA421F85A3 for ; Sun, 29 Jul 2012 21:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.828 X-Spam-Level: X-Spam-Status: No, score=-102.828 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZYjnGynzGba for ; Sun, 29 Jul 2012 21:46:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1B6A21F8575 for ; Sun, 29 Jul 2012 21:45:56 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9591626obb.31 for ; Sun, 29 Jul 2012 21:45:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=lFdsb/pPvIjnIUsUS92nTOsGJHDbPP86iiJXRuWaIH0=; b=Lc9eAiwZGPSsHTlCrd2+dvoI5LuvuIdvfibMOXrghVkY3ogkKooTZA9kSIT9fXjCVa 4rn1dBB9ZNG3SBz/Zd8ijVGAE5kkLz/6rNs/a8A1TypgVhxxSTwJXWOmb5tOKPbqCr67 6yJ17sAs4LAS8/xPLJ/YP37b9xmi36sZs3CKTGr+WzUDDtXig0bibFfiMhVBJx/ZODB0 0nmB8ZnHbBsvDujw3tReDnP138SuXctlu7bp6xVWbBw2jStS0kZp0SuRX2rlQS22Jcdo ILQVN0nXliTK8vUwxI7DvMBhDvuS6mlK6R93x88tb9oxP0dUKf/2lXXJscKPnaiefQ9W f82Q== Received: by 10.60.7.104 with SMTP id i8mr15332424oea.31.1343623556092; Sun, 29 Jul 2012 21:45:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.134.137 with HTTP; Sun, 29 Jul 2012 21:45:35 -0700 (PDT) From: Jamal Hadi Salim Date: Mon, 30 Jul 2012 00:45:35 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmsWPprPybVoQLg0s76ulKqjpimWXdD3b5TOf6QL01wBXw+VRNXA+Gd3kU44yQ8nIo4L2Uy Subject: [forces] agenda update etc X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 04:46:05 -0000 Folks, The agenda has a small update. The OF demo is gone, replaced by two short presentations one on redirect and another on FEM LFB. Anyone willing to volunteer to take minutes or be a jabber scribe, please send me email. cheers, jamal From hadi@mojatatu.com Tue Jul 31 10:37:36 2012 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EE021F8820 for ; Tue, 31 Jul 2012 10:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.857 X-Spam-Level: X-Spam-Status: No, score=-102.857 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWiG5Ex+Xg2v for ; Tue, 31 Jul 2012 10:37:35 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C100D21F8818 for ; Tue, 31 Jul 2012 10:37:35 -0700 (PDT) Received: by yenq13 with SMTP id q13so6847695yen.31 for ; Tue, 31 Jul 2012 10:37:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=DyXY6JARxJTA/PsO5L7akvHdCWKGh4nLQ6aIu3I3dfM=; b=PrY2x6nM073hkZ7I6uslLpg2J1xKsFkAR/s3TxApsdIiqlHg71EUtkXi5lBMNAr/Zl RMBVQKvtSWo5O6uff+h9o8L9ngCw+Dc6tW2Rl78nSskg0fEGGX4x4rS3O67yA/kolCrT nB8gCRR8FeZmVlEn8wWmVZmQWlPcI/3eLIpZnvR9uECfhE4rxj8EI+qSHA23j8vGUpe8 JBnewNJQlTMIL0TLUL3e5Hqo+gvgdWY9AL7ZoPljRquJpSwhAbCCmQPeI3HCCfXxYQLg B+Cmay1FjhRd9S97fvKplVa/OFIKQZLyiaMAjve7MrIggoDQ076pLB8Dd/4UHJpVEl+g DoyA== Received: by 10.60.28.101 with SMTP id a5mr24287747oeh.69.1343756255165; Tue, 31 Jul 2012 10:37:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.134.137 with HTTP; Tue, 31 Jul 2012 10:37:14 -0700 (PDT) From: Jamal Hadi Salim Date: Tue, 31 Jul 2012 13:37:14 -0400 Message-ID: To: forces@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlPzCi+Xz3hS2+BgEsS2XazrDHOwht+1LjrZPmv6lkUSUVy6PIi3Yc2zqoakM6RhGvmEvk8 Subject: [forces] small agenda change X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:37:36 -0000 For the sake of time: The LFBlib and CEHA are collapsed as part of the WG status. https://datatracker.ietf.org/meeting/84/agenda/forces/ Still soliciting for scribes - fame guaranteed if you volunteer; send me email. cheers, jamal