From zoltan.lajos.kis@ericsson.com Fri Jun 1 03:31:30 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 5DE4F21F85D6 for ; Fri, 1 Jun 2012 03:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=2.468, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ovYUA-x8V2r for ; Fri, 1 Jun 2012 03:31:29 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 68BB421F85D9 for ; Fri, 1 Jun 2012 03:31:29 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-7f-4fc89a002c9c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2C.D5.11869.00A98CF4; Fri, 1 Jun 2012 12:31:28 +0200 (CEST) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.105]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 1 Jun 2012 12:31:28 +0200 From: =?iso-8859-1?Q?Zolt=E1n_Lajos_Kis?= To: Jamal Hadi Salim Date: Fri, 1 Jun 2012 12:31:27 +0200 Thread-Topic: [forces] [Sdnp] a few initial comments on draft-haleplidis-forces-openflow-lib-00 Thread-Index: Ac0/URVZLgsAd83CRFKTNoULw69APgAiErVg Message-ID: <3A92A63EBFD41F4196707AF266E1CDA550CB234E34@ESESSCMS0361.eemea.ericsson.se> References: <010f01cd3df4$6773f6a0$365be3e0$@com> <3A92A63EBFD41F4196707AF266E1CDA550CB1ABC18@ESESSCMS0361.eemea.ericsson.se> <00dd01cd3eb5$2cb75ef0$86261cd0$@com> <3A92A63EBFD41F4196707AF266E1CDA550CB234B19@ESESSCMS0361.eemea.ericsson.se> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+JvrS7DrBP+BgvfKFnceHaH1eLhm9ls Fre37mGz6L48hcWBxWPnrLvsHkuW/GTy2PpkCbvHtltrWQNYorhsUlJzMstSi/TtErgyjm9Y z1LwgLti7f0+lgbGvZxdjJwcEgImEt2HN7JA2GISF+6tZ+ti5OIQEjjFKLHgyWNmCGcOo8Tu px+YQarYBDwlvv9bxAhiiwhoSHS3rmMHKWIWaGSUWDr/AFgRi4CKxObrj9lAbGGBBImta56x QjQkSny9do0JwjaSWHDmNdhqXoFwie2tl1ggtjUzS8ybuw1sEKdAoMSClyfBBjEC3ff91Bqw ZmYBcYlbT+YzQdwtILFkz3lmCFtU4uXjf6wQ9aISd9rXM0LU60ncmDqFDcLWlli28DUzxGJB iZMzn7BMYBSbhWTsLCQts5C0zELSsoCRZRWjcG5iZk56uZFealFmcnFxfp5eceomRmCkHdzy W3UH451zIocYpTlYlMR5rbfu8RcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuHZj3DqLz56S f9h4XQ2n1mr+ijtbGeW8u/jMp3uVh21nhfD8KhJ7zBTcbrsnveRTwcI/Frol+91OBk/pMowK 6WHbrFFsd37KOgaBFwZX/3O+2VZ1yi0r3PL2pyTJVft/SRxmT1z9evJ+I73bm9n22v+Zx1LV k2upNS9jdbOxttzp1K4vj1x+KLEUZyQaajEXFScCAFQmeNaCAgAA Cc: "sdnp@lucidvision.com" , "forces@ietf.org" Subject: Re: [forces] [Sdnp] a few initial 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: Fri, 01 Jun 2012 10:31:30 -0000 =20 > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com]=20 > Sent: Thursday, May 31, 2012 7:16 PM > To: Zolt=E1n Lajos Kis > Cc: Haleplidis Evangelos; forces@ietf.org; sdnp@lucidvision.com > Subject: Re: [forces] [Sdnp] a few initial comments on=20 > draft-haleplidis-forces-openflow-lib-00 >=20 > On Thu, May 31, 2012 at 12:07 PM, Zolt=E1n Lajos Kis=20 > wrote: > > Hi, > > > > Yes, the interpretation is correct. If the apply-actions'=20 > action list contains an output or group action, a copy of the=20 > current packet (i.e., the previous actions in the action list=20 > have been applied) are sent to the port or group, as if the=20 > packet reached the end of the pipeline. The pipeline=20 > processing will continue with the original copy with the next=20 > action in the action list. > > >=20 > Is it correct to conclude that the apply-actions cannot=20 > terminate a flow pipeline? >=20 Correct, pipeline processing ends (and processing of the action set begins)= if: a) a matching entry was found, and the entry has no Goto (to the next table= ) instruction, OR b) no matching entry was found, and the table miss behavior is not to Conti= nue (to the next table) Note that in OF 1.3 the table miss behavior configuration has been replaced= with a table miss flow entry. This allows one to describe the miss behavior using the instruction semanti= cs of flow entries. Regards, Zoltan.= From zoltan.lajos.kis@ericsson.com Thu Jun 7 06:51: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 9363C21F869C for ; Thu, 7 Jun 2012 06:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=1.850, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMKoFi60T-cG for ; Thu, 7 Jun 2012 06:51:12 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2942E21F8618 for ; Thu, 7 Jun 2012 06:51:10 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-71-4fd0b1cc3577 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C9.84.28636.CC1B0DF4; Thu, 7 Jun 2012 15:51:08 +0200 (CEST) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.105]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 7 Jun 2012 15:51:08 +0200 From: =?iso-8859-1?Q?Zolt=E1n_Lajos_Kis?= To: Haleplidis Evangelos Date: Thu, 7 Jun 2012 15:51:06 +0200 Thread-Topic: More comments on draft-haleplidis-forces-openflow-lib-00 Thread-Index: Ac1EtJY/2KP1mbYMSoaj7ClE7skrog== Message-ID: <3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8@ESESSCMS0361.eemea.ericsson.se> 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_3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8ESESSCMS0361e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvre6ZjRf8DXoXmFrceHaH1eLhm9ls DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGhflfWQreX2GsWPCtn7WBccN6xi5GTg4J AROJ2Yu3MEHYYhIX7q1n62Lk4hASOMUoceHjQ0YIZwGjxJs9N9hAqtgEPCW+/1sE1i0ioC0x 9eoHsG5mAXWJR9dPsYDYLAIqEguf9YLZwgKOEqdm/WPuYuQAqneT+PtZHaJVT2LOgRVgrbwC 4RJfN81nB7EZgY74fmoN1EhxiVtP5kMdJyCxZM95ZghbVOLl43+sEPWiEnfaIZ5hFsiXaH40 DWqmoMTJmU9YJjAKz0IyahaSsllIyiDiehI3pk5hg7C1JZYtfM0MYetKzPh3iAVZfAEj+ypG 4dzEzJz0ckO91KLM5OLi/Dy94tRNjMD4Objlt+4OxlPnRA4xSnOwKInzciXt9xcSSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAyFZwafpZpV/H1GcvW353i8ZNq6N3FH+c4z9muZ77aIvutqPH 9EUW9ezZHfCN+/WxGy4SZeVdBmEz0rfVXV07PcHNaqe/3uEryqv5/ssuza1vPnI/J+ZZnIXG lM19kft9frW7xZw1vsQgp/3TxiCWWflQ6O3PXonMFT1ukyN9ZkfrKD0NF7PoVWIpzkg01GIu Kk4EADh2YuVtAgAA Cc: "forces@ietf.org" Subject: [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: Thu, 07 Jun 2012 13:51:14 -0000 --_000_3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8ESESSCMS0361e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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, whi= ch can convert the XML description to a more digestive form? ER-diagrams, or similar....) Regards, Zoltan. 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 t= he 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 "class= es" of actions. For example, "Setting a field" refers to all the action types for manipulating header fi= elds 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 differe= nt 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 simpl= y 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, wh= ich 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 arc= hitecture 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 m= etadata 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 physica= l port of the packet. Thus the physical port id must also be sent along with the packet (given a logical p= ort was used). 4) The description of how outputting a frame is handled is not clear. It wo= uld seem logical that it is done by the OFOutputActionLFB only, i.e. only that LFB's output is connecte= d 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 datap= ath for processing in the OFPT_PACKET_OUT message type. I believe this functionality is missing from = the current description. 6) OpenFlow 1.1 added extensibility features to the datapath. One can defin= e 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 experime= nter 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 mak= e sense to add a separator between ForCES and OpenFlow definitions. Also, I think further OpenFlow concept sho= uld 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.) Page 9: - Fig. 1., and the text below suggests that one piece of metadata (the Acti= on Set) is available in the packet before entering Flow Table 0, while another piece (the Metadata field) is only ava= ilable 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 FlowT= able 0 would have the special function of "create if not exists" the Metadata. 2) The OpenFlowSpec1.1 in theory al= lows modifying Metadata with bitmasks used - let alone matching on it. - "Write Metadata action" should be "Write Metadata instruction" - "Forward to the OpenFlow controllers" should be changed to singular "cont= roller". 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 con= cepts of Page 7. - "The list of actions the Flow Table can perform or write in the Action S= et is". Similar to generic comment 1), this is not a list of possible actions, but rather the list of the different act= ion "classes". - "Additionally a Flow Table may drop the packet as an action. The drop act= ion is implicit based on the Flow Table's configuration.". This sentence is confusing. The configuration is only cons= ulted in case of no match. As this listing is for the list of actions in write actions, there is no drop action. On ma= tch 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 s= et 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 maintain= ing 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 FlowTabl= eLFB sent the packet for processing to an ActionLFB, when the packet returns from processing, how will the FlowTableL= FB 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? Page 15: - "Additionally each OFFlowTable can output a packet to a specific port." A= s in generic comment 4), this should not be the case. Tables can only output to the controller (without OutputAction= involvment). - On Fig 5. a number of arrows are missing from the lines pointing to OFPor= ts. 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 gues= s in the LFB Library. - ActionSetType: see the generic comment on action sets Page 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 necce= sarily 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 elabo= rat on how matching is done. I would suggest that it is described among the description of concepts, and this paragraph = refers to that. 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 a= nd/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. Page 25: - OFPortLFB / Data Handling: The OpenFlow spec. allows a port to be a "logi= cal 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 do= es 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" Page 28: - "As none of the OFActionLFBs have no capabilities..." - there no is not n= eeded 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 hea= der value. Page 35: - 5.8.25.2: "SetIPTTLTable" is probably wrong, something like " Page 36: - "C:\Workspace\Forces...\" - I guess this should be something else 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 pro= tocol field. Is it intentional that it is separately defined? Page 48: - "Buffer Reason" should be "Packet-in reason" Page 50: - "multiple ows" -> "multiple flows" - "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 f= eature, should be not part of the data model. - ActionsetLFB dataTypeDef: see generic comment 1 --_000_3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8ESESSCMS0361e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I went through the whole draft - not too thoroughly on the XML part -&= nbsp; and would like to clarify / comment on a few things.
I'm still working on understanding the complete data model of the desc= ribed 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.
 
 
 
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). Thos= e 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 exec= uted (regardless of in what order
they have been written to it). These 9 elements represents different &= quot;classes" of actions. For example,
"Setting a field" refers to all the action types for manipul= ating header fields in the frame.
Actions of the same class are not concurrent, i.e., they can be execut= ed in arbitrary order, without
affecting the overall result of executing the ActionSet. Actions of di= fferent 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 queue= s are attached to (the output side of)
ports. The identifiers of these queues are port-specific; i.e. both Po= rt 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 fra= me 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 introduce= d, which can be used for QoS between
tables, and before outputting to ports.)
 
3) Besides the pieces of OpenFlow metadata identified, there are addit= ional metadata that needs to be attached
to the frame - due to implicit requirements in OpenFlow, and due to th= e 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 phys= ical ports. In this case a packet_in
message is supposed to tell the controller both the logical and the ph= ysical port of the packet. Thus the
physical port id must also be sent along with the packet (given a logi= cal 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 con= nected to the ports' input - but not those
Of OFFlowTableLFBs.
Furthermore a special ToControllerLFB should be added, which would sen= d the frame to the controller.
This LFB could be used by both the FlowTableLFBs and the OutputActionL= FB.  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_OUT 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 exp= erimenter 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 cont= roller can add, update and delete flow and group entries"
 
Page 7:
- Even though it is fairly trivial to tell them apart, I think it woul= d make sense to add a separator between
ForCES and OpenFlow definitions. Also, I think further OpenFlow concep= t should be explained, and the order of elements
should be changed.
Suggested list of elements: Match fields, Actions, Flow Entry, Instruc= tion, Flow Table, Pipeline, Action Set,
Groups (incl. GroupEntry and GroupTable), Ports.
(I'm willing to provide definition for these terms.)
 
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 onl= y available after leaving the table.
I believe a more convenient description would be if the Metadata is al= ready 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.
 
- "Write Metadata action" should be "Write Metadata ins= truction"
 
- "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 b= e "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 th= e 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 differen= t action "classes".
 
- "Additionally a Flow Table may drop the packet as an action. Th= e 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 followin= g 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 Tab= le contains a set of Group Entries, each of which contains
  a set of "Action Buckets", each of which contains a s= et of actions.
 
Page 11-13 (Fig 2-4.):
 
- At this point the basic architectural decisions (i.e. ActionLFBs mai= ntaining 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 Flo= wTableLFB sent the packet for processing to an
ActionLFB, when the packet returns from processing, how will the FlowT= ableLFB 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?
 
Page 15:
 
- "Additionally each OFFlowTable can output a packet to a specifi= c port." As in generic comment 4), this should not
be the case. Tables can only output to the controller (without OutputA= ction involvment).
 
- On Fig 5. a number of arrows are missing from the lines pointing to = OFPorts.
 
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.
 
- ActionSetType: see the generic comment on action sets
 
Page 20:
 
- "... the maximum number of bytes of new flow that datapath shou= ld 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.
 
Page 22:
 
- first paragraph: same comment as for Page 9 / Fig 1. regarding Actio= n 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 parag= raph refers to that.
 
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 buf= fered in which table.
 
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 m= edium ports.
 
Page 26:
 
- OFQueueLFB: see generic comment 2) on how QoS is defined.
 
- "The Length component" : I think this is a misunderstandin= g. 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"
 
Page 28:
 
- "As none of the OFActionLFBs have no capabilities..." - th= ere no is not needed
 
Page 29:
 
- "Only valid in the action set of a packet-out message" sho= uld 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 VLA= N header value.
 
Page 35:
 
- 5.8.25.2: "SetIPTTLTable" is probably wrong, something lik= e "
 
Page 36:
 
- "C:\Workspace\Forces...\" - I guess this should be somethi= ng else
 
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 &g= t; 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?
 
Page 48:
 
- "Buffer Reason" should be "Packet-in reason"
 
Page 50:
 
- "multiple ows" -> "multiple flows"
 
- "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
 
 --_000_3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8ESESSCMS0361e_-- From ehalep@gmail.com Fri Jun 8 15:18:21 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 A895E11E81AF for ; Fri, 8 Jun 2012 15:18:21 -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 JFRRElRh2dzH for ; Fri, 8 Jun 2012 15:18:19 -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 B66B811E80E8 for ; Fri, 8 Jun 2012 15:18:18 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so853985wib.13 for ; Fri, 08 Jun 2012 15:18:17 -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=4y9ovu6sCEMn33Ri2qmyg5jsbQj3VTWLAklzNAyCyrs=; b=QmQ8dovFhI0Zpvji0u9WgqTGBZ2LWmeaEK43NbT6pSolRY7as+3uCHn7WoMX2Ejezv 0sQ4U/8mQzkDwpU8hafwxts7sxpb8d5BitafbC/2GG5eWbMvr72CFSF0mFCbykKeWXz8 mYB8jCN1fcwSyJyVMSxJ2ZUPvC1AuNRiHuVbeFcw6yYjM9oU2hSkdcY6FBADPMhBHEKz 9b/S4Z+bIUk19I2Q5/GnnTLWzQb1J93S9a1lMtHJplV4RKqxjrWMqHGL5w3a4yyFMTKl LE29E/EmNRVMviTltuMC8PObbJ8RAFDYI+WuWly/4T9V2C3hG2+YZh48GVSBGIxf5rH7 1zAw== Received: by 10.180.91.225 with SMTP id ch1mr3689417wib.18.1339193897783; Fri, 08 Jun 2012 15:18:17 -0700 (PDT) Received: from EhalepXPS (ppp079166063204.dsl.hol.gr. [79.166.63.204]) by mx.google.com with ESMTPS id d3sm6561034wiz.9.2012.06.08.15.18.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 15:18:17 -0700 (PDT) From: "Haleplidis Evangelos" To: =?GB2312?B?J1pvbHSoom4gTGFqb3MgS2lzJw==?= References: <3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8@ESESSCMS0361.eemea.ericsson.se> In-Reply-To: <3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8@ESESSCMS0361.eemea.ericsson.se> Date: Sat, 9 Jun 2012 01:18:11 +0300 Message-ID: <009801cd45c4$987148c0$c953da40$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01CD45DD.BDBE80C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1EtJY/2KP1mbYMSoaj7ClE7skrogAtfY+g 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: Fri, 08 Jun 2012 22:18:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0099_01CD45DD.BDBE80C0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Greetings Zoltan, =20 Thank you very much for the extensive comments. I responded to your = generic comments.=20 I will answer you text comments in an separate email. =20 Please see inline. =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 [=A6=A5=A6=A7] If I understand you correctly, an ActionSet may contain = multiple set field actions (e.g. set IP address, set MAC address), but only one of a = kind (only one set IP address). Correct? And the same applies to push/pop tag action. If yes, then we will modify the text accordingly. =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 [=A6=A5=A6=A7] Regarding queues, we may need to add an additional figure = to depict queues. I don=A1=AFt think that the current definition of the queue LFB = is different from what you describe. You may have multiple instances of QueueLFBs, each with its own queue ID (which may not be unique. Only the Queue LFB=A1=AFs Instance ID is unique).=20 =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 [=A6=A5=A6=A7] Continuing from above, we do need to add the queue_ID = metadata as you describe in your comment. Regarding the of_phy_port, the OF 1.1 spec is a bit confusing: 1. What is the meaning of ingress port if you have the of_phy_port = & of_in_port metadata? Is ingress port the of_in_port?=20 2. Where is the of_phy_port generated, and how is it transmitted = (it is not shown in Figure 2 in the OF 1.1 spec). 3. The of_phy_port is only useful in the case of the frame sent to = the controller? 4. Are there any other components of the datapath described (only) = in the protocol instead of the datapath definition. Example table 4 is = datapath spec but appendix A is protocol spec. =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 [=A6=A5=A6=A7] There is currently no OFOutputActionLFB defined, but = there will be in the next draft update. The current model description has the OFFlowTable = to output the frame to the port or queue, but upon discussion it=A1=AFs = better to have an additional Action LFB. As for the ToControllerLFB and FromControllerLFB, these two LFBs have = been defined in the LFB-library document as the RedirectIn and RedirectOut = LFBs. A new figure should be added to depict them as well. If there is a need = for more components than defined in these two LFBs we can extend them. =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 [=A6=A5=A6=A7] The above comment (and figure) should cover this as well. =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 [=A6=A5=A6=A7] An experimenter action can be defined as a new = OFActionLFB. As for matches, the datatype definition for the match will need to be updated. However this is a good idea and we should add such section =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.) =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. =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? =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). =20 - On Fig 5. a number of arrows are missing from the lines pointing to OFPorts. =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. =20 - ActionSetType: see the generic comment on action sets =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. =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. =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 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" =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 " =20 Page 36: =20 - "C:\Workspace\Forces...\" - I guess this should be something else =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? =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 =20 ------=_NextPart_000_0099_01CD45DD.BDBE80C0 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Greetings Zoltan,

 

Thank you very much for the extensive comments. I responded to your = generic comments.

I will answer you text comments in an separate = email.

 

Please see inline.

 

Regards,

Evangelos Haleplidis.

 

From:= = Zolt=A8=A2n Lajos Kis [mailto:zoltan.lajos.kis@ericsson.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. =

 =

[=A6=A5=A6=A7] If I understand you correctly, an ActionSet may = contain multiple set field actions (e.g. set IP address, set MAC = address), but only one of a kind (only one set IP address). Correct? And = the same applies to push/pop tag action. If yes, then we will modify the = text accordingly.

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;          =

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.)

 

[=A6=A5=A6=A7] Regarding queues, we may need to add an additional = figure to depict queues. I don=A1=AFt think that the current definition = of the queue LFB is different from what you describe. You may have = multiple instances of QueueLFBs, each with its own queue ID (which may = not be unique. Only the Queue LFB=A1=AFs Instance ID is unique). =

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      =

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).

 =

[=A6=A5=A6=A7] Continuing from above, we do need to add the queue_ID = metadata as you describe in your = comment.

Regarding the of_phy_port, the OF 1.1 spec is a bit = confusing:

1.       = What is the meaning of ingress port if you have the of_phy_port & = of_in_port metadata? Is ingress port the of_in_port? =

2.       = Where is the of_phy_port generated, and how is it transmitted (it is = not shown in Figure 2 in the OF 1.1 = spec).

3.       = The of_phy_port is only useful in the case of the frame sent to the = controller?

4.       = Are there any other components of the datapath described (only) in = the protocol instead of the datapath definition. Example table 4 is = datapath spec but appendix A is protocol = spec.

 

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.

 

[=A6=A5=A6=A7] There is currently no OFOutputActionLFB defined, but = there will be in the next draft update. The current model description = has the OFFlowTable to output the frame to the port or queue, but upon = discussion it=A1=AFs better to have an additional Action = LFB.

As for the ToControllerLFB and FromControllerLFB, these two LFBs have = been defined in the LFB-library document as the RedirectIn and = RedirectOut LFBs. A new figure should be added to depict them as well. = If there is a need for more components than defined in these two LFBs we = can extend them.

 

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.

 

[=A6=A5=A6=A7] The above comment (and figure) should cover this as = well.

 

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.

 =

[=A6=A5=A6=A7] An experimenter action can be defined as a new = OFActionLFB. As for matches, the datatype definition for the match will = need to be updated. However this is a good idea and we should add such = section

 

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.)

 

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.

 

- = "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?

 

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).

 

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

 

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.

 

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

 

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.

 

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.

 

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"

 

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 = "

 

Page = 36:

 

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

 

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?

 

Page = 48:

 

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

 

Page = 50:

 

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

 

- = "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_0099_01CD45DD.BDBE80C0-- From zoltan.lajos.kis@ericsson.com Sun Jun 10 23:47:31 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 5D73021F842F for ; Sun, 10 Jun 2012 23:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.055 X-Spam-Level: **** X-Spam-Status: No, score=4.055 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHCTGOaITRCF for ; Sun, 10 Jun 2012 23:47:30 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EF0C221F8442 for ; Sun, 10 Jun 2012 23:47:28 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-03-4fd5947f56a9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A2.CB.11869.F7495DF4; Mon, 11 Jun 2012 08:47:27 +0200 (CEST) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.37]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 11 Jun 2012 08:47:26 +0200 From: =?gb2312?B?Wm9sdKiibiBMYWpvcyBLaXM=?= To: Haleplidis Evangelos Date: Mon, 11 Jun 2012 08:47:25 +0200 Thread-Topic: More comments on draft-haleplidis-forces-openflow-lib-00 Thread-Index: Ac1EtJY/2KP1mbYMSoaj7ClE7skrogAtfY+gAIrAVkA= Message-ID: <3A92A63EBFD41F4196707AF266E1CDA550CC681809@ESESSCMS0361.eemea.ericsson.se> References: <3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8@ESESSCMS0361.eemea.ericsson.se> <009801cd45c4$987148c0$c953da40$@com> In-Reply-To: <009801cd45c4$987148c0$c953da40$@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_3A92A63EBFD41F4196707AF266E1CDA550CC681809ESESSCMS0361e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+JvrW79lKv+Bm2HBCxuPLvDavHwzWw2 ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSuja/EB5oJ/LcwVqzZvZGtgfH2LqYuRk0NC wETi3+nt7BC2mMSFe+vZQGwhgVOMEmfvenQxcgHZCxglzpyZygySYBPwlvjx+DdYs4iAtsTU qx/AbGYBdYlH10+xgNgsAqoSB+4uYgWxhQVcJfq+3AKKcwDVu0n8/awO0WolsfvcZrByXoFw iZer3zND7K2XWL/nOCOIzSlgJDF37h+w8YxAt30/tQZqlbjErSfzoe4XkFiy5zwzhC0q8fLx P1aIelGJO+3rGSHq8yXuPvzNCLFLUOLkzCcsExhFZyEZNQtJ2SwkZRBxLYl5Db+hahQlpnQ/ ZIewNSWuTD4EZWtLLFv4mnkBI/sqRuHcxMyc9HIjvdSizOTi4vw8veLUTYzAaDu45bfqDsY7 50QOMUpzsCiJ81pv3eMvJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTFL8v1ixdL99Xlq24M2 mx6Wdb95vmWbhEtPrnrlTtXslAN9IdI80U/dlIQOBOzXME/6s4Rra5T4gUjBnpO9gmZFnx36 nt80cOS45bCmdMnpx2v6dU/GTXe8kpQgfHl5is7n6n9VOy7Of35OioU92tFprpts/rMO0Y6e PcczPme1mZ3knHYhW4mlOCPRUIu5qDgRAOh0hHiEAgAA 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: Mon, 11 Jun 2012 06:47:31 -0000 --_000_3A92A63EBFD41F4196707AF266E1CDA550CC681809ESESSCMS0361e_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBIYWxlcGxpZGlzIEV2 YW5nZWxvcyBbbWFpbHRvOmVoYWxlcEBnbWFpbC5jb21dDQpTZW50OiBTYXR1cmRheSwgSnVuZSAw OSwgMjAxMiAxMjoxOCBBTQ0KVG86IFpvbHSoom4gTGFqb3MgS2lzDQpDYzogZm9yY2VzQGlldGYu b3JnDQpTdWJqZWN0OiBSRTogTW9yZSBjb21tZW50cyBvbiBkcmFmdC1oYWxlcGxpZGlzLWZvcmNl cy1vcGVuZmxvdy1saWItMDANCg0KR3JlZXRpbmdzIFpvbHRhbiwNCg0KVGhhbmsgeW91IHZlcnkg bXVjaCBmb3IgdGhlIGV4dGVuc2l2ZSBjb21tZW50cy4gSSByZXNwb25kZWQgdG8geW91ciBnZW5l cmljIGNvbW1lbnRzLg0KSSB3aWxsIGFuc3dlciB5b3UgdGV4dCBjb21tZW50cyBpbiBhbiBzZXBh cmF0ZSBlbWFpbC4NCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNClJlZ2FyZHMsDQpFdmFuZ2Vsb3Mg SGFsZXBsaWRpcy4NCg0KRnJvbTogWm9sdKiibiBMYWpvcyBLaXMgW21haWx0bzp6b2x0YW4ubGFq b3Mua2lzQGVyaWNzc29uLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDA3LCAyMDEyIDQ6NTEg UE0NClRvOiBIYWxlcGxpZGlzIEV2YW5nZWxvcw0KQ2M6IGZvcmNlc0BpZXRmLm9yZw0KU3ViamVj dDogTW9yZSBjb21tZW50cyBvbiBkcmFmdC1oYWxlcGxpZGlzLWZvcmNlcy1vcGVuZmxvdy1saWIt MDANCg0KSGksDQoNCkkgd2VudCB0aHJvdWdoIHRoZSB3aG9sZSBkcmFmdCAtIG5vdCB0b28gdGhv cm91Z2hseSBvbiB0aGUgWE1MIHBhcnQgLSAgYW5kIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSAvIGNv bW1lbnQgb24gYSBmZXcgdGhpbmdzLg0KSSdtIHN0aWxsIHdvcmtpbmcgb24gdW5kZXJzdGFuZGlu ZyB0aGUgY29tcGxldGUgZGF0YSBtb2RlbCBvZiB0aGUgZGVzY3JpYmVkIGFyY2hpdGVjdHVyZSwg c28gZG9uJ3QgdGFrZSB0aGlzIGFzIGFuDQpleHRoYXVzdGl2ZSBsaXN0IG9mIGlzc3Vlcy4gKEJ0 dywgaXMgdGhlcmUgYSB0b29sIGF2YWlsYWJsZSBmb3IgRm9yQ0VTLCB3aGljaCBjYW4gY29udmVy dCB0aGUgWE1MIGRlc2NyaXB0aW9uIHRvIGEgbW9yZSBkaWdlc3RpdmUNCmZvcm0/IEVSLWRpYWdy YW1zLCBvciBzaW1pbGFyLi4uLikNCg0KUmVnYXJkcywNClpvbHRhbi4NCg0KDQoNCkdlbmVyaWMg Y29tbWVudHM6DQoNCjEpIEkgdGhpbmsgdGhlIEFjdGlvbiBTZXQgZGVzY3JpcHRpb24gLSBzZWN0 aW9uIDQuNyBpbiBPcGVuRmxvd1NwZWMxLjEgLSBpcyBtaXNpbnRlcnByZXRlZC4gSW4gT3BlbkZs b3cNCnRoZXJlIGlzIG9ubHkgb25lIHNldCBvZiBhY3Rpb25zIGRlZmluZWQgKDI1ICsgZXhwZXJp bWVudGVyKS4gVGhvc2UgYWN0aW9ucyBhcmUgdXNlZCBpbiBBcHBseUFjdGlvbiwNCldyaXRlQWN0 aW9uIGluc3RydWN0aW9ucyBhbmQgUGFja2V0T3V0IG1lc3NhZ2VzLiBUaGUgOS1lbGVtZW50IGxp c3RpbmcgaW4gdGhlIHNlY3Rpb24gbWVyZWx5IGRlZmluZWQNClRvIGRpc2N1c3MgdGhlIG9yZGVy aW5nIGluIHdoaWNoIGFjdGlvbnMgaW4gdGhlIEFjdGlvblNldCBtdXN0IGJlIGV4ZWN1dGVkIChy ZWdhcmRsZXNzIG9mIGluIHdoYXQgb3JkZXINCnRoZXkgaGF2ZSBiZWVuIHdyaXR0ZW4gdG8gaXQp LiBUaGVzZSA5IGVsZW1lbnRzIHJlcHJlc2VudHMgZGlmZmVyZW50ICJjbGFzc2VzIiBvZiBhY3Rp b25zLiBGb3IgZXhhbXBsZSwNCiJTZXR0aW5nIGEgZmllbGQiIHJlZmVycyB0byBhbGwgdGhlIGFj dGlvbiB0eXBlcyBmb3IgbWFuaXB1bGF0aW5nIGhlYWRlciBmaWVsZHMgaW4gdGhlIGZyYW1lLg0K QWN0aW9ucyBvZiB0aGUgc2FtZSBjbGFzcyBhcmUgbm90IGNvbmN1cnJlbnQsIGkuZS4sIHRoZXkg Y2FuIGJlIGV4ZWN1dGVkIGluIGFyYml0cmFyeSBvcmRlciwgd2l0aG91dA0KYWZmZWN0aW5nIHRo ZSBvdmVyYWxsIHJlc3VsdCBvZiBleGVjdXRpbmcgdGhlIEFjdGlvblNldC4gQWN0aW9ucyBvZiBk aWZmZXJlbnQgY2xhc3NlcyBob3dldmVyIGNhbiBoYXZlDQplZmZlY3Qgb24gZWFjaCBvdGhlciwg c28gdGhlaXIgZXhlY3V0aW9uIG9yZGVyIG11c3QgYmUgc3BlY2lmaWVkLg0KDQpbpqWmp10gSWYg SSB1bmRlcnN0YW5kIHlvdSBjb3JyZWN0bHksIGFuIEFjdGlvblNldCBtYXkgY29udGFpbiBtdWx0 aXBsZSBzZXQgZmllbGQgYWN0aW9ucyAoZS5nLiBzZXQgSVAgYWRkcmVzcywgc2V0IE1BQyBhZGRy ZXNzKSwgYnV0IG9ubHkgb25lIG9mIGEga2luZCAob25seSBvbmUgc2V0IElQIGFkZHJlc3MpLiBD b3JyZWN0PyBBbmQgdGhlIHNhbWUgYXBwbGllcyB0byBwdXNoL3BvcCB0YWcgYWN0aW9uLiBJZiB5 ZXMsIHRoZW4gd2Ugd2lsbCBtb2RpZnkgdGhlIHRleHQgYWNjb3JkaW5nbHkuDQoNCltaXSBZZXMs IG9uZSBvZiBlYWNoIE9GUEFUXyogdHlwZSwgYXMgaWRlbnRpZmllZCBieSB0aGUgb2ZwX2FjdGlv bl90eXBlICBlbnVtIHN0YXJ0aW5nIG9uIHAuIDMxLi4gSnVzdCBmb3IgY2xhcml0eSwgaXQgY2Fu IGNvbnRhaW4gb25lIHNldCBJUCBzcmMuIGFkZHJlc3MsIGFuZCBvbmUgc2V0IElQIGRzdC4gYWRk cmVzczsgc2ltaWxhcmx5b25lIHNldCBNQUMgc3JjIGFuZCBvbmUgc2V0IE1BQyBkc3QuIEl0IGNh biBhbHNvIGNvbnRhaW4gb25lIHBvcCBNUExTLCBvbmUgcG9wIFZMQU4sIG9uZSBwdXNoIE1QTFMg YW5kIG9uZSBwdXNoIFZMQU4uDQoNCjIpIFFvUyBoYW5kbGluZyBpcyBtaXNpbnRlcnByZXRlZC4g SW4gdGhlIE9wZW5GbG93IDEuMSBtb2RlbCBRb1MgcXVldWVzIGFyZSBhdHRhY2hlZCB0byAodGhl IG91dHB1dCBzaWRlIG9mKQ0KcG9ydHMuIFRoZSBpZGVudGlmaWVycyBvZiB0aGVzZSBxdWV1ZXMg YXJlIHBvcnQtc3BlY2lmaWM7IGkuZS4gYm90aCBQb3J0IDEgYW5kIFBvcnQgMiBjYW4gaGF2ZSBh IHF1ZXVlIHdpdGggYW4gSUQgb2YgMi4NCklmIHRoZSBjb250cm9sbGVyIGlzIHRvIHNlbmQgYSBm cmFtZSB0byB0aGUgZGVmYXVsdCAob3Igbm8tKXF1ZXVlLCBpdCBzaW1wbHkgdXNlcyB0aGUgb3V0 cHV0IGFjdGlvbi4gSWYgaXQNCndhbnRzIHRvIHRhcmdldCBhIHNwZWNpZmljIHF1ZXVlIG9mIHRo ZSBwb3J0LCBpdCBmaXJzdCBoYXMgdG8gc2V0IHRoZSBwb3J0LWxvY2FsIHF1ZXVlIElEICh3aXRo IHNldF9xdWV1ZSBhY3Rpb24pLA0KYW5kIHRoZW4gdXNlIHRoZSBvdXRwdXQgYWN0aW9uLiBUaGUg b3V0cHV0IGFjdGlvbiB3aWxsIGZvcndhcmQgdGhlIGZyYW1lIHRvIHRoZSBhcHByb3ByaWF0ZSBw b3J0LCBhbmQgdGhlIHBvcnQgd2lsbA0KdXNlIHRoZSBxdWV1ZSBwcmV2aW91c2x5IGFwcG9pbnRl ZCBieSB0aGUgc2V0X3F1ZXVlIGNhbGwuDQooTm90ZSB0aGF0IGJlZ2lubmluZyB3aXRoIE9wZW5G bG93IDEuMyBhIG5ldyBNZXRlciBlbnRpdHkgaXMgaW50cm9kdWNlZCwgd2hpY2ggY2FuIGJlIHVz ZWQgZm9yIFFvUyBiZXR3ZWVuDQp0YWJsZXMsIGFuZCBiZWZvcmUgb3V0cHV0dGluZyB0byBwb3J0 cy4pDQoNClumpaanXSBSZWdhcmRpbmcgcXVldWVzLCB3ZSBtYXkgbmVlZCB0byBhZGQgYW4gYWRk aXRpb25hbCBmaWd1cmUgdG8gZGVwaWN0IHF1ZXVlcy4gSSBkb26hr3QgdGhpbmsgdGhhdCB0aGUg Y3VycmVudCBkZWZpbml0aW9uIG9mIHRoZSBxdWV1ZSBMRkIgaXMgZGlmZmVyZW50IGZyb20gd2hh dCB5b3UgZGVzY3JpYmUuIFlvdSBtYXkgaGF2ZSBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgUXVldWVM RkJzLCBlYWNoIHdpdGggaXRzIG93biBxdWV1ZSBJRCAod2hpY2ggbWF5IG5vdCBiZSB1bmlxdWUu IE9ubHkgdGhlIFF1ZXVlIExGQqGvcyBJbnN0YW5jZSBJRCBpcyB1bmlxdWUpLg0KDQpbWl0gVG8g bWUgdGhlIGN1cnJlbnQgZGVzY3JpcHRpb24gb2Ygd2hlcmUgcXVldWVzIGFyZSBsb2NhdGVkIGlz IG5vdCBjbGVhci4gNS41KC4xKSBzdWdnZXN0cyB0aGF0IHRoZSBwYWNrZXQgZmlyc3QgZW50ZXJz IHRoZSBRdWV1ZUxGQiwgd2hpY2ggdGhlbiBwYXNzZXMgaXQgdG8gdGhlIFBvcnRMRkIuIEF0IHRo ZSBzYW1lIHRpbWUgNS44KC4xKSBzdWdnZXN0cyBPdXRwdXRBY3Rpb25MRkIgZGlyZWN0bHkgc2Vu ZHMgdGhlIHBhY2tldCB0byB0aGUgUG9ydExGQi4gRWl0aGVyIHdheSwgbXkgcG9pbnQgaXMgdGhh dCB0aGUgUXVldWVMRkIgbXVzdCBiZSBpZGVudGlmaWVkIGJ5IHRoZSB0dXBsZSBvZiB0aGUgb3V0 cHV0IHBvcnQgaWQgYW5kIHRoZSBxdWV1ZSBpZC4NCmEpIElmIFF1ZXVlTEZCcyBhcmUgImJldHdl ZW4iIE91dHB1dEFjdGlvbkxGQiBhbmQgUG9ydExGQiwgdGhlbiB0aGUgT3V0cHV0QWN0aW9uTEZC IG11c3Qgcm91dGUgdGhlIHBhY2tldCB0byB0aGUgY29ycmVjdCBRdWV1ZUxGQiBieSB0YWtpbmcg aW50byBhY2NvdW50IGJvdGggdGhlIHBvcnQgaWQgYW5kIHF1ZXVlIGlkLiBUaGVuIHRoZSBRdWV1 ZUxGQiB3aWxsIGhhdmUgYSBzaW5nbGUgb3V0cHV0IHRvIGEgc2luZ2xlIFBvcnRMRkIgaW5zdGFu Y2UsIHNvIG5vIG1vcmUgcm91dGluZyBpcyBuZWVkZWQuDQpiKSBJZiBRdWV1ZUxGQnMgYXJlICJh ZnRlciIgUG9ydExGQnMgdGhlbiB0aGUgcXVldWUgaWQgbXVzdCBiZSBwcm9wYWdhdGVkIHRvIHRo ZSBQb3J0TEZCIGluc3RhbmNlIGFzIGEgbWV0YWRhdGEsIGFuZCB0aGUgUG9ydExGQiBtdXN0IHJv dXRlIHRvIHRoZSBjb3JyZWN0IFF1ZXVlTEZCIGJhc2VkIG9uIHRoYXQuDQoNCjMpIEJlc2lkZXMg dGhlIHBpZWNlcyBvZiBPcGVuRmxvdyBtZXRhZGF0YSBpZGVudGlmaWVkLCB0aGVyZSBhcmUgYWRk aXRpb25hbCBtZXRhZGF0YSB0aGF0IG5lZWRzIHRvIGJlIGF0dGFjaGVkDQp0byB0aGUgZnJhbWUg LSBkdWUgdG8gaW1wbGljaXQgcmVxdWlyZW1lbnRzIGluIE9wZW5GbG93LCBhbmQgZHVlIHRvIHRo ZSBhcmNoaXRlY3R1cmUgb2YgdGhlIEZvckNFUyBkZXNjcmlwdGlvbi4NCnF1ZXVlX2lkOiBhcyBk ZXNjcmliZWQgYWJvdmUgaW4gMiksIHRoZSBpZCBvZiB0aGUgcXVldWUgd2hpY2ggaXMgdG8gYmUg dXNlZCBvbiBvdXRwdXQgaXMgc2V0IGJ5IHRoZSBzZXRfcXVldWUNCmFjdGlvbi4gVGhlcmVmb3Jl IHRoZSBzZXQgcXVldWVfaWQgbXVzdCBiZSBwYXNzZWQgYWxvbmcgd2l0aCB0aGUgZnJhbWUgYXMg bWV0YWRhdGEgZm9yIHRoZSBvdXRwdXQgYWN0aW9uDQp0byBwcm9jZXNzIGl0Lg0Kb2ZfcGh5X3Bv cnQ6IFRoZSBPcGVuRmxvdyBzcGVjaWZpY2F0aW9uIGFsbG93cyBsb2dpY2FsIHBvcnRzIG92ZXIg cGh5c2ljYWwgcG9ydHMuIEluIHRoaXMgY2FzZSBhIHBhY2tldF9pbg0KbWVzc2FnZSBpcyBzdXBw b3NlZCB0byB0ZWxsIHRoZSBjb250cm9sbGVyIGJvdGggdGhlIGxvZ2ljYWwgYW5kIHRoZSBwaHlz aWNhbCBwb3J0IG9mIHRoZSBwYWNrZXQuIFRodXMgdGhlDQpwaHlzaWNhbCBwb3J0IGlkIG11c3Qg YWxzbyBiZSBzZW50IGFsb25nIHdpdGggdGhlIHBhY2tldCAoZ2l2ZW4gYSBsb2dpY2FsIHBvcnQg d2FzIHVzZWQpLg0KDQpbpqWmp10gQ29udGludWluZyBmcm9tIGFib3ZlLCB3ZSBkbyBuZWVkIHRv IGFkZCB0aGUgcXVldWVfSUQgbWV0YWRhdGEgYXMgeW91IGRlc2NyaWJlIGluIHlvdXIgY29tbWVu dC4NClJlZ2FyZGluZyB0aGUgb2ZfcGh5X3BvcnQsIHRoZSBPRiAxLjEgc3BlYyBpcyBhIGJpdCBj b25mdXNpbmc6DQoNCjEuICAgICAgIFdoYXQgaXMgdGhlIG1lYW5pbmcgb2YgaW5ncmVzcyBwb3J0 IGlmIHlvdSBoYXZlIHRoZSBvZl9waHlfcG9ydCAmIG9mX2luX3BvcnQgbWV0YWRhdGE/IElzIGlu Z3Jlc3MgcG9ydCB0aGUgb2ZfaW5fcG9ydD8NCg0KMi4gICAgICAgV2hlcmUgaXMgdGhlIG9mX3Bo eV9wb3J0IGdlbmVyYXRlZCwgYW5kIGhvdyBpcyBpdCB0cmFuc21pdHRlZCAoaXQgaXMgbm90IHNo b3duIGluIEZpZ3VyZSAyIGluIHRoZSBPRiAxLjEgc3BlYykuDQoNCjMuICAgICAgIFRoZSBvZl9w aHlfcG9ydCBpcyBvbmx5IHVzZWZ1bCBpbiB0aGUgY2FzZSBvZiB0aGUgZnJhbWUgc2VudCB0byB0 aGUgY29udHJvbGxlcj8NCg0KNC4gICAgICAgQXJlIHRoZXJlIGFueSBvdGhlciBjb21wb25lbnRz IG9mIHRoZSBkYXRhcGF0aCBkZXNjcmliZWQgKG9ubHkpIGluIHRoZSBwcm90b2NvbCBpbnN0ZWFk IG9mIHRoZSBkYXRhcGF0aCBkZWZpbml0aW9uLiBFeGFtcGxlIHRhYmxlIDQgaXMgZGF0YXBhdGgg c3BlYyBidXQgYXBwZW5kaXggQSBpcyBwcm90b2NvbCBzcGVjLg0KDQpbWl0gVW5mb3J0dW5hdGVs eSB0aGUgc3BlYy4gaXMgaW5kZWVkIGNvbmZ1c2luZyByZWdhcmRpbmcgdGhpcywgYW5kIEkgc3Vw cG9zZSBpdCB3YXMgbmV2ZXIgZml4ZWQuIEkganVzdCB3YW50ZWQgdG8gcG9pbnQgb3V0IHRoYXQg aWYgeW91IHdhbnQgZnVsbCBjb25mb3JtYW5jZSB0byB0aGUgc3BlYy4sIHRoaXMgaXMgYWxzbyBz b21ldGhpbmcgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50Lg0KQW4gZXhhbXBsZSBzY2VuYXJpbyB3 b3VsZCBiZSB0aGF0IHRoZSBzd2l0Y2ggaGFzIGZvdXIgcGh5c2ljYWwgcG9ydHMgKFBvcnQxIC0g UG9ydDQpLCBhbmQgdXNpbmcgYW4gIm91dC1vZi1iYW5kIiBwcm90b2NvbCwgYSBsb2dpY2FsIExB RyBwb3J0LCBQb3J0NSBpcyBjb25maWd1cmVkLCBhZ2dyZWdhdGluZyBQb3J0MSBhbmQgUG9ydDIs LiBTbyBub3cgdGhlIGRhdGFwYXRoIHdvdWxkIG5vdCByZWNlaXZlIHBhY2tldHMgb24gUG9ydDEg b3IgUG9ydDIsIGJ1dCBpbnN0ZWFkIG9uIFBvcnQ1IG9ubHkuIEhvd2V2ZXIsIHdoZW4NCnRoaXMg cGFja2V0IGlzIHNlbnQgdG8gdGhlIGNvbnRyb2xsZXIsIGl0IHRlbGxzIHRoYXQgdGhlIGlucHV0 IHBvcnQgaXMgUG9ydDUsIGJ1dCBwaHlzaWNhbGx5IGl0IGNhbWUgb24gUG9ydDEuDQoxKSBhcyBk ZXNjcmliZWQgaWYgeW91IGhhdmUgbG9naWNhbCBwb3J0cyBkZWZpbmVkLCBpdCB0ZWxscyB0aGUg YWN0dWFsIHBoeWlzaWNhbCBwb3J0Lg0KMikgaW4gRm9yQ0VTIEkgd291bGQgZ3Vlc3MgdGhlIE9G UG9ydExGQiB3b3VsZCBnZW5lcmF0ZSBib3RoIGJ5IGRlZmF1bHQuIEJ1dCBpZiB5b3UgaGFkIGEg bmV3IExGQiBpbnNlcnRlZCBiZXR3ZWVuIHRoZSBQb3J0TEZCIGFuZCBUYWJsZUxGQiwgdGhlbiB0 aGlzIG5ldyAibG9naWNhbCBwb3J0IiBMRkIgd291bGQgdXBkYXRlIHRoZSBpbl9wb3J0IG1ldGFk YXRhLg0KMykgWWVzLCB0aGF0IGlzIHRoZSBvbmx5IHBsYWNlIHdoZXJlIHRoZSBzcGVjLiBleHBv c2VzIHRoaXMgbWV0YWRhdGEuDQo0KSAgSSBiZWxpZXZlIG5vdDsgb25seSB0aG9zZSBJIGRlc2Ny aWJlZCBpbiBteSBtYWlsLg0KDQo0KSBUaGUgZGVzY3JpcHRpb24gb2YgaG93IG91dHB1dHRpbmcg YSBmcmFtZSBpcyBoYW5kbGVkIGlzIG5vdCBjbGVhci4gSXQgd291bGQgc2VlbSBsb2dpY2FsIHRo YXQgaXQgaXMNCmRvbmUgYnkgdGhlIE9GT3V0cHV0QWN0aW9uTEZCIG9ubHksIGkuZS4gb25seSB0 aGF0IExGQidzIG91dHB1dCBpcyBjb25uZWN0ZWQgdG8gdGhlIHBvcnRzJyBpbnB1dCAtIGJ1dCBu b3QgdGhvc2UNCk9mIE9GRmxvd1RhYmxlTEZCcy4NCkZ1cnRoZXJtb3JlIGEgc3BlY2lhbCBUb0Nv bnRyb2xsZXJMRkIgc2hvdWxkIGJlIGFkZGVkLCB3aGljaCB3b3VsZCBzZW5kIHRoZSBmcmFtZSB0 byB0aGUgY29udHJvbGxlci4NClRoaXMgTEZCIGNvdWxkIGJlIHVzZWQgYnkgYm90aCB0aGUgRmxv d1RhYmxlTEZCcyBhbmQgdGhlIE91dHB1dEFjdGlvbkxGQi4gIEFsc28sIHRoaXMgTEZCIGNvdWxk IGFkZHJlc3MNCnRoZSBidWZmZXJpbmcgb2YgcGFja2V0cyBzZW50IHRvIHRoZSBjb250cm9sbGVy Lg0KDQpbpqWmp10gVGhlcmUgaXMgY3VycmVudGx5IG5vIE9GT3V0cHV0QWN0aW9uTEZCIGRlZmlu ZWQsIGJ1dCB0aGVyZSB3aWxsIGJlIGluIHRoZSBuZXh0IGRyYWZ0IHVwZGF0ZS4gVGhlIGN1cnJl bnQgbW9kZWwgZGVzY3JpcHRpb24gaGFzIHRoZSBPRkZsb3dUYWJsZSB0byBvdXRwdXQgdGhlIGZy YW1lIHRvIHRoZSBwb3J0IG9yIHF1ZXVlLCBidXQgdXBvbiBkaXNjdXNzaW9uIGl0oa9zIGJldHRl ciB0byBoYXZlIGFuIGFkZGl0aW9uYWwgQWN0aW9uIExGQi4NCkFzIGZvciB0aGUgVG9Db250cm9s bGVyTEZCIGFuZCBGcm9tQ29udHJvbGxlckxGQiwgdGhlc2UgdHdvIExGQnMgaGF2ZSBiZWVuIGRl ZmluZWQgaW4gdGhlIExGQi1saWJyYXJ5IGRvY3VtZW50IGFzIHRoZSBSZWRpcmVjdEluIGFuZCBS ZWRpcmVjdE91dCBMRkJzLiBBIG5ldyBmaWd1cmUgc2hvdWxkIGJlIGFkZGVkIHRvIGRlcGljdCB0 aGVtIGFzIHdlbGwuIElmIHRoZXJlIGlzIGEgbmVlZCBmb3IgbW9yZSBjb21wb25lbnRzIHRoYW4g ZGVmaW5lZCBpbiB0aGVzZSB0d28gTEZCcyB3ZSBjYW4gZXh0ZW5kIHRoZW0uDQoNCjUpIE9wZW5G bG93IGFsbG93cyB0aGUgY29udHJvbGxlciB0byBjb25zdHJ1Y3QgYW5kIHNlbmQgZnJhbWVzIHRv IHRoZSBkYXRhcGF0aCBmb3IgcHJvY2Vzc2luZyBpbiB0aGUNCk9GUFRfUEFDS0VUX09VVCBtZXNz YWdlIHR5cGUuIEkgYmVsaWV2ZSB0aGlzIGZ1bmN0aW9uYWxpdHkgaXMgbWlzc2luZyBmcm9tIHRo ZSBjdXJyZW50IGRlc2NyaXB0aW9uLg0KDQpbpqWmp10gVGhlIGFib3ZlIGNvbW1lbnQgKGFuZCBm aWd1cmUpIHNob3VsZCBjb3ZlciB0aGlzIGFzIHdlbGwuDQoNCjYpIE9wZW5GbG93IDEuMSBhZGRl ZCBleHRlbnNpYmlsaXR5IGZlYXR1cmVzIHRvIHRoZSBkYXRhcGF0aC4gT25lIGNhbiBkZWZpbmUg Y3VzdG9tIGV4cGVyaW1lbnRlciBtZXNzYWdlcywNCm1hdGNoZXMsIGluc3RydWN0aW9ucywgYWN0 aW9ucy4gV2hpbGUgbm90IG5lY2Vzc2FyaWx5IHRoZSBkdXR5IG9mIHRoaXMgdGV4dCwgaXQgd291 bGQgYmUgbmljZSB0byBzZWUgaG93DQp0aGF0IGNhbiBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUg Rm9yQ0VTIGRlc2NyaXB0aW9uLiBJLmUuLCBob3cgYW4gZXhwZXJpbWVudGVyIGFjdGlvbiBpcyBt YXBwZWQgaW50bw0KYW4gKGV4cGVyaW1lbnRlcikgRm9yQ0VTIExGQiwgZXRjLg0KDQpbpqWmp10g QW4gZXhwZXJpbWVudGVyIGFjdGlvbiBjYW4gYmUgZGVmaW5lZCBhcyBhIG5ldyBPRkFjdGlvbkxG Qi4gQXMgZm9yIG1hdGNoZXMsIHRoZSBkYXRhdHlwZSBkZWZpbml0aW9uIGZvciB0aGUgbWF0Y2gg d2lsbCBuZWVkIHRvIGJlIHVwZGF0ZWQuIEhvd2V2ZXIgdGhpcyBpcyBhIGdvb2QgaWRlYSBhbmQg d2Ugc2hvdWxkIGFkZCBzdWNoIHNlY3Rpb24NCg0KIC0tLS0gODwgLS0tLQ0KDQpaLg0K --_000_3A92A63EBFD41F4196707AF266E1CDA550CC681809ESESSCMS0361e_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 

From: Haleplidis Evangelos=20 [mailto:ehalep@gmail.com]
Sent: Saturday, June 09, 2012 12:18= =20 AM
To: Zolt=A8=A2n Lajos Kis
Cc:=20 forces@ietf.org
Subject: RE: More comments on=20 draft-haleplidis-forces-openflow-lib-00

Greetings=20 Zoltan,

 

Thank=20 you very much for the extensive comments. I responded to your generic=20 comments.

I=20 will answer you text comments in an separate email.

 

Please=20 see inline.

 

Regards,

Evangelos=20 Haleplidis.

 

From:Hi,

 <= /o:p>

I went throu= gh the=20 whole draft - not too thoroughly on the XML part -  and would like t= o=20 clarify / comment on a few things.

I'm still wo= rking=20 on understanding the complete data model of the described architecture, s= o=20 don't take this as an

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

form? ER-dia= grams,=20 or similar....)

 <= /o:p>

Regards,

Zoltan.=

 <= /o:p>

 <= /o:p>

 <= /o:p>

Generic=20 comments:

 <= /o:p>

1) I think t= he=20 Action Set description - section 4.7 in OpenFlowSpec1.1 - is misinterpret= ed.=20 In OpenFlow

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

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

To discuss t= he=20 ordering in which actions in the ActionSet must be executed (regardless o= f in=20 what order

they have be= en=20 written to it). These 9 elements represents different "classes" of action= s.=20 For example,

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

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

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

effect on ea= ch=20 other, so their execution order must be specified.=20

 <= /SPAN>

[=A6=A5=A6=A7]=20 If I understand you correctly, an ActionSet may contain multiple set fiel= d=20 actions (e.g. set IP address, set MAC address), but only one of a kind (o= nly=20 one set IP address). Correct? And the same applies to push/pop tag action= . If=20 yes, then we will modify the text accordingly. 

 

[Z] Yes, one of each OFP= AT_*=20 type, as identified by=20 the ofp_action_type  enum starti= ng on=20 p. 31.. Just for clarity, it can contain one set IP src. address, and one= set=20 IP dst. address; similarlyone set MAC src and one set MAC dst. It can als= o=20 contain one pop MPLS, one pop VLAN, one pu= sh MPLS=20 and one push VLAN.

           &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =      =20

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

ports. The identifi= ers of=20 these queues are port-specific; i.e. both Port 1 and Port 2 can have a qu= eue=20 with an ID of 2.

If the contr= oller=20 is to send a frame to the default (or no-)queue, it simply uses the outpu= t=20 action. If it

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

and then use= the=20 output action. The output action will forward the frame to the appropriat= e=20 port, and the port will

use the queu= e=20 previously appointed by the set_queue call.

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

tables, and = before=20 outputting to ports.)<= /SPAN>

 

[=A6=A5=A6=A7]=20 Regarding queues, we may need to add an additional figure to depict queue= s. I=20 don=A1=AFt think that the current definition of the queue LFB is differen= t from=20 what you describe. You may have multiple instances of QueueLFBs, each wit= h its=20 own queue ID (which may not be unique. Only the Queue LFB=A1=AFs Instance= ID is=20 unique).  

 

[Z] To me the current descrip= tion of=20 where queues are located is not clear. 5.5(.1) suggests that the pac= ket=20 first enters the QueueLFB, which then passes it to the PortLFB. At the sa= me=20 time 5.8(.1) suggests OutputActionLFB directly sends the=20 packet to the PortLFB. Either way,= my=20 point is that the QueueLFB must be identified by the tuple of the ou= tput=20 port id and the queue id.

a) If QueueLFBs are "between"=20 OutputActionLFB and PortLFB, then the OutputActionLFB must route the pack= et to=20 the correct QueueLFB by taking into account both the port id and queue id= .=20 Then the QueueLFB will have a single output to a single PortLFB instance,= so=20 no more routing is needed.

b) If QueueLFBs are "after" PortLF= Bs then=20 the queue id must be propagated to the PortLFB instance as a metadata, an= d the=20 PortLFB must route to the correct QueueLFB based on=20 that.

         =             &nb= sp;            =             &nb= sp;    =20

3) Besides t= he=20 pieces of OpenFlow metadata identified, there are additional metadata tha= t=20 needs to be attached

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

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

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

to process=20 it.

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

message is s= upposed=20 to tell the controller both the logical and the physical port of the pack= et.=20 Thus the

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

 <= /SPAN>

[=A6=A5=A6=A7]=20 Continuing from above, we do need to add the queue_ID metadata as you des= cribe=20 in your comment.

Regarding=20 the of_phy_port, the OF 1.1 spec is a bit=20 confusing:

1.      = ;=20 What=20 is the meaning of ingress port if you have the of_phy_port & of_in_po= rt=20 metadata? Is ingress port the of_in_port?

2.      = ;=20 Where=20 is the of_phy_port generated, and how is it transmitted (it is not shown = in=20 Figure 2 in the OF 1.1 spec).

3.      = ;=20 The=20 of_phy_port is only useful in the case of the frame sent to the=20 controller?

4.      = ;=20 Are=20 there any other components of the datapath described (only) in the protoc= ol=20 instead of the datapath definition. Example table 4 is datapath spec but= =20 appendix A is protocol spec.

 

[Z]=20 Unfortunately the spec. is indeed confusing regarding this, and I suppose= it=20 was never fixed. I just wanted to point out that if you want full conform= ance=20 to the spec., this is also something to be taken into=20 account.

An=20 example scenario would be that the switch has four physical ports (Port1 = -=20 Port4), and using an "out-of-band" protocol, a logical LAG port, Port5&nb= sp;is=20 configured, aggregating Port1 and Port2,. So now the datapath would not=20 receive packets on Port1 or Port2, but instead on Port5 only. However,=20 when

this=20 packet is sent to the controller, it tells that the input port is Port5, = but=20 physically it came on Port1.

1)=20 as described if you have logical ports defined, it tells the actual phyis= ical=20 port.

2)=20 in ForCES I would guess the OFPortLFB would generate both by default. But= if=20 you had a new LFB inserted between the PortLFB and TableLFB, then this ne= w=20 "logical port" LFB would update the in_port=20 metadata.

3) Yes, that is the only place=20 where the spec. exposes this=20 metadata.

4)  I believe not; only those= I=20 described in my mail. 

 

4) The descr= iption=20 of how outputting a frame is handled is not clear. It would see= m=20 logical that it is

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

Of=20 OFFlowTableLFBs.

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

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

the bufferin= g of=20 packets sent to the controller.<= /SPAN>

 

[=A6=A5=A6=A7]=20 There is currently no OFOutputActionLFB defined, but there will be in the= next=20 draft update. The current model description has the OFFlowTable to output= the=20 frame to the port or queue, but upon discussion it=A1=AFs better to have = an=20 additional Action LFB.

As=20 for the ToControllerLFB and FromControllerLFB, these two LFBs have been=20 defined in the LFB-library document as the RedirectIn and RedirectOut LFB= s. A=20 new figure should be added to depict them as well. If there is a need for= more=20 components than defined in these two LFBs we can extend=20 them.

 <= /o:p>

5) OpenFlow = allows=20 the controller to construct and send frames to the datapath for processin= g in=20 the

OFPT_PACKET_= OUT=20 message type. I believe this functionality is missing from the current=20 description.

 

[=A6=A5=A6=A7]=20 The above comment (and figure) should cover this as=20 well.

 <= /o:p>

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

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

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

an (experime= nter)=20 ForCES LFB, etc.

 <= /SPAN>

[=A6=A5=A6=A7]=20 An experimenter action can be defined as a new OFActionLFB. As for matche= s,=20 the datatype definition for the match will need to be updated. However th= is is=20 a good idea and we should add such section

 <= /o:p>

 ---- 8<=20 ----

&nb= sp;

Z.

--_000_3A92A63EBFD41F4196707AF266E1CDA550CC681809ESESSCMS0361e_-- From hadi@mojatatu.com Mon Jun 11 04:21:35 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 1E84A21F8597 for ; Mon, 11 Jun 2012 04:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.818 X-Spam-Level: X-Spam-Status: No, score=-100.818 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 oEbIOUII8WKC for ; Mon, 11 Jun 2012 04:21:34 -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 763F321F850B for ; Mon, 11 Jun 2012 04:21:34 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so9332206obb.31 for ; Mon, 11 Jun 2012 04:21:34 -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:content-transfer-encoding:x-gm-message-state; bh=6UXM+/3uS3jur1nWl8JwXovBVQI8D3NzvmZNMe/okQU=; b=SBJcbJDCm4UI1yR3nwAsczEbHwZEXOHl1RyRBEq8lao86AS0XBL+9Ym3L08bzXgXR4 IWgDVtrFpI837rttVZn8Q/Rgzp4SWmmjl8HqOs0WzzDjgwOFeDvKkuDy4tLqOLN7gdGJ hB5eCeL0msTIMHLm3TR56SZCp6hhprJbKfE7gbiSgxPJATEuBYObrbNcXVm/UIIVo0A7 z3TJHTPYSDGuywX0Z6rOtUV9UTRv4Q+QqC7GbWNqNlhsPSg5yqDqTbFhzsiH+LhdB/rq ytYrqqXYsEDx711XB8uPQF1SWroDX0XB0HPFv4go/kClFS2Dzazsx+Ac20qB1iLigzH+ BeSw== Received: by 10.60.29.137 with SMTP id k9mr16280762oeh.23.1339413693917; Mon, 11 Jun 2012 04:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.164.68 with HTTP; Mon, 11 Jun 2012 04:21:13 -0700 (PDT) In-Reply-To: <3A92A63EBFD41F4196707AF266E1CDA550CC681809@ESESSCMS0361.eemea.ericsson.se> References: <3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8@ESESSCMS0361.eemea.ericsson.se> <009801cd45c4$987148c0$c953da40$@com> <3A92A63EBFD41F4196707AF266E1CDA550CC681809@ESESSCMS0361.eemea.ericsson.se> From: Jamal Hadi Salim Date: Mon, 11 Jun 2012 07:21:13 -0400 Message-ID: To: =?ISO-8859-1?Q?Zolt=E1n_Lajos_Kis?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkTE+ejc0TVjOU6C7atW0TMUjFcZ1WeRrnbUTRTZntgZsOiJw/r2kpppIYjGYsFjIpISZd9 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: Mon, 11 Jun 2012 11:21:35 -0000 On Mon, Jun 11, 2012 at 2:47 AM, Zolt=E1n Lajos Kis wrote: > a) If QueueLFBs are "between" OutputActionLFB and PortLFB, then the > OutputActionLFB must route the packet to the correct QueueLFB by taking i= nto > account both the port id and queue id. Then the QueueLFB will have a sing= le > output to a single PortLFB instance, so no more routing is needed. > > b) If QueueLFBs are "after" PortLFBs then the queue id must be propagated= to > the PortLFB instance as a metadata, and the PortLFB must route to the > correct QueueLFB based on that. > Sounds to me like OF spec seems to be making claim for #b, no? i.e the set queue id could be done anywhere in the middle way before the output port is hit. Which may translate to either: a) there are exactly X queues per port (in 802.1q type h/ware X typically= =3D8) so no need to worry about which port it is going to (setting a queue is essentially equivalent to selecting a COS value) b) There exist global queues, so it doesnt matter which port they end up on= , the queue id being set by set_queue action is selecting the global queue. In both cases, the port id is unneeded - no? > [Z] Unfortunately the spec. is indeed confusing regarding this, and I > suppose it was never fixed. I just wanted to point out that if you want f= ull > conformance to the spec., this is also something to be taken into account= . Did you mean implementations do it that way (and the OF spec is not representative)? > An example scenario would be that the switch has four physical ports (Por= t1 > - Port4), and using an "out-of-band" protocol, a logical LAG port, Port5= =A0is > configured, aggregating Port1 and Port2,. So now the datapath would not > receive packets on Port1 or Port2, but instead on Port5 only. However, wh= en > this packet is sent to the controller, it tells that the input port is > Port5, but physically it came on Port1. I suspect where you have more virtual ports in between only the last one is reported to the controller (or other intermidiate LFBs)? > 1) as described if you have logical ports defined, it tells the actual > phyisical port. So ingress_port is called of_phy port when redirecting to the CE? Why two metadatum to represent the same thing? cheers, jamal From zoltan.lajos.kis@ericsson.com Mon Jun 11 10:43:03 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 BB25221F8565 for ; Mon, 11 Jun 2012 10:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=5.002, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1QubkYp4gRx for ; Mon, 11 Jun 2012 10:43:03 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 54C8921F85C6 for ; Mon, 11 Jun 2012 10:43:01 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-86-4fd62e2448b2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 59.84.28636.42E26DF4; Mon, 11 Jun 2012 19:43:00 +0200 (CEST) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.37]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Mon, 11 Jun 2012 19:43:00 +0200 From: =?iso-8859-1?Q?Zolt=E1n_Lajos_Kis?= To: Jamal Hadi Salim Date: Mon, 11 Jun 2012 19:42:59 +0200 Thread-Topic: [forces] More comments on draft-haleplidis-forces-openflow-lib-00 Thread-Index: Ac1HxFvwXNccyY5gQ2mTHMEPhdFyxwAMuPEt Message-ID: <3A92A63EBFD41F4196707AF266E1CDA550CC90A792@ESESSCMS0361.eemea.ericsson.se> References: <3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8@ESESSCMS0361.eemea.ericsson.se> <009801cd45c4$987148c0$c953da40$@com> <3A92A63EBFD41F4196707AF266E1CDA550CC681809@ESESSCMS0361.eemea.ericsson.se>, 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvra6K3jV/g++LVC1uPLvDavHwzWw2 i9tb97A5MHvsnHWX3WPJkp9MHtturWUNYI7isklJzcksSy3St0vgyjgy+QFrQaN0xdqWv+wN jEtEuxg5OSQETCS6r59lgrDFJC7cW88GYgsJnGKUeHWVvYuRC8hewCjx/9gVRpAEm4CnxPd/ i8BsEQENie7WdewgNrNAkETP40OsXYwcHCwCqhLNU0tBwsICARLPzvQwg4RFBAIlJn7lgug0 kjj96RRYJ69AuMS16R0sEKsmMUkcWX8ULMEJVL/t5BVWEJsR6Lbvp9YwQawSl7j1ZD7UzQIS S/acZ4awRSVePv4HVS8qcad9PSNEvZ7EjalT2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLS MgtJyywkLQsYWVYxCucmZuaklxvqpRZlJhcX5+fpFaduYgRG08Etv3V3MJ46J3KIUZqDRUmc lytpv7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxqyLavem5fDc2JRj2eRrnPmSzXb/gpu8 MzfN6fC9OilP/Yrme+6vSszx1cKV1yfdrV6kLMDfd9CDd2lbwN79H6dOcMxafSC82eKsn0ad wKFjqwPTg67ccg7+9KRLec79MzkhyqcWHFqtdUTvRbj+/KsSS9WnMMZ3lXzepCStrHlKNrhx e3zQQiWW4oxEQy3mouJEALpS0eZ0AgAA 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: Mon, 11 Jun 2012 17:43:03 -0000 > >> a) If QueueLFBs are "between" OutputActionLFB and PortLFB, then the >> OutputActionLFB must route the packet to the correct QueueLFB by taking = into >> account both the port id and queue id. Then the QueueLFB will have a sin= gle >> output to a single PortLFB instance, so no more routing is needed. >> >> b) If QueueLFBs are "after" PortLFBs then the queue id must be propagate= d to >> the PortLFB instance as a metadata, and the PortLFB must route to the >> correct QueueLFB based on that. > > >Sounds to me like OF spec seems to be making claim for #b, no? [Z2] Yes, b is the "OpenFlow way of queuing". >i.e the set queue id could be done anywhere in the middle way before the >output port is hit. Which may translate to either: >a) there are exactly X queues per port (in 802.1q type h/ware X typically= =3D8) >so no need to worry about which port it is going to (setting a queue >is essentially >equivalent to selecting a COS value) [Z2] Yes, something like that. But the intention was to remove those semant= ics from the queues. E.g. it would be perfectly valid that Queue1 on Port1 is a max-rate= -queue, while Queue1 on Port2 is a min-rate queue. >b) There exist global queues, so it doesnt matter which port they end up o= n, the >queue id being set by set_queue action is selecting the global queue. [Z2] No, if queues are "global", they must be identified by the port_id, qu= eue_id pair. > >In both cases, the port id is unneeded - no? [Z2] Port id is needed, but if an OutputActionLFB sends frames to the PortL= FB, the port id does not need to be added as a metedata. > >> [Z] Unfortunately the spec. is indeed confusing regarding this, and I >> suppose it was never fixed. I just wanted to point out that if you want = full >> conformance to the spec., this is also something to be taken into accoun= t. > >Did you mean implementations do it that way (and the OF spec is not >representative)? [Z2] I meant the opposite. The specification defines of_phy_port for the us= e case below, but I am not aware of any implementation that makes use of this logi= cal port concept. > >> An example scenario would be that the switch has four physical ports (Po= rt1 >> - Port4), and using an "out-of-band" protocol, a logical LAG port, Port5= is >> configured, aggregating Port1 and Port2,. So now the datapath would not >> receive packets on Port1 or Port2, but instead on Port5 only. However, w= hen >> this packet is sent to the controller, it tells that the input port is >> Port5, but physically it came on Port1. > >I suspect where you have more virtual ports in between only the last >one is reported to the controller (or other intermidiate LFBs)? [Z2] Correct. > >> 1) as described if you have logical ports defined, it tells the actual >> phyisical port. > >So ingress_port is called of_phy port when redirecting to the CE? >Why two metadatum to represent the same thing? [Z2] In_phy_port represents the physical port. In_port represents the logic= al port if one was defined; otherwise it equals to in_phy_port. Up until OpenFlow 1.2 the OFPT_PACKET_IN message had a fixed structure, so = it had to carry both identifiers, even though in most cases the two are equal. In = OpenFlow 1.3 this is replaced by a TLV structure, so in_phy_port is only sent to the con= troller if it differs from in_port. Regards, Zoltan.= From hadi@mojatatu.com Tue Jun 12 04:42:33 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 00D2421F84AF for ; Tue, 12 Jun 2012 04:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.748 X-Spam-Level: X-Spam-Status: No, score=-101.748 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 vWW50IILYzKc for ; Tue, 12 Jun 2012 04:42:32 -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 3F1BD21F8497 for ; Tue, 12 Jun 2012 04:42:32 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so11305020obb.31 for ; Tue, 12 Jun 2012 04:42:31 -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:content-transfer-encoding:x-gm-message-state; bh=ZTYJ5IZov5QDs3+9LpwMRFBY27aJ5rgIo9BeDL5NIwI=; b=ITVMLEiQmXLzECjTB6FJ5M1IKZLSjV2MSr+QzY3QQ9oGEX2Q4PBIgdNqXjap7yAheT K+vlMlH197W5xJTEBfj04YohxNpTueVfxxDD1GzZKyQb6MSkHUCoG3+l07vKASBAfEyY 2BRlUBNqSsYCsFjqqEaIG+AuYzgoCzprbmSd9l97RA/82i6enhTy0iwwvj+SQRYMa6AB d1CISWqT0tkMfGX5V9Q0UAzYZc6vUBeug7t548MQcHGrFK6bODg/YGBJYHFQ/VL1eORN sSTl4kkdnCP0/3nlkk5vABMaIAyoQhaZWJWAV72w6H7H02eYDdN7d6Rz2zVHuRcpJCNB xvmQ== Received: by 10.182.207.39 with SMTP id lt7mr20484314obc.67.1339501351620; Tue, 12 Jun 2012 04:42:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.7.134 with HTTP; Tue, 12 Jun 2012 04:42:10 -0700 (PDT) In-Reply-To: <3A92A63EBFD41F4196707AF266E1CDA550CC90A792@ESESSCMS0361.eemea.ericsson.se> References: <3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8@ESESSCMS0361.eemea.ericsson.se> <009801cd45c4$987148c0$c953da40$@com> <3A92A63EBFD41F4196707AF266E1CDA550CC681809@ESESSCMS0361.eemea.ericsson.se> <3A92A63EBFD41F4196707AF266E1CDA550CC90A792@ESESSCMS0361.eemea.ericsson.se> From: Jamal Hadi Salim Date: Tue, 12 Jun 2012 07:42:10 -0400 Message-ID: To: =?ISO-8859-1?Q?Zolt=E1n_Lajos_Kis?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk5O5CrkyOoqG+5dZDlQsFVh7aqY4IyerV5G5nysYVMtush7c2F0SU1NClTV9+kukfz4Pck 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: Tue, 12 Jun 2012 11:42:33 -0000 On Mon, Jun 11, 2012 at 1:42 PM, Zolt=E1n Lajos Kis wrote: >> > > [Z2] Yes, something like that. But the intention was to remove those sema= ntics from the > queues. E.g. it would be perfectly valid that Queue1 on Port1 is a max-ra= te-queue, > while Queue1 on Port2 is a min-rate queue. I wonder if you can have ports with differrent number of queues defined (eg 4 on port1 vs 8 on port2) >>b) There exist global queues, so it doesnt matter which port they end up = on, the >>queue id being set by set_queue action is selecting the global queue. > > [Z2] No, if queues are "global", they must be identified by the port_id, = queue_id pair. > I dont see why. Global in this sense means shared by all ports, the queue id should be sufficient information. The other scenario is easily identified by the LFB instance topology definition. >>So ingress_port is called of_phy port when redirecting to the CE? >>Why two metadatum to represent the same thing? > > [Z2] In_phy_port represents the physical port. In_port represents the log= ical port if > one was defined; otherwise it equals to in_phy_port. > > Up until OpenFlow 1.2 the OFPT_PACKET_IN message had a fixed structure, s= o it had > to carry both identifiers, even though in most cases the two are equal. I= n OpenFlow 1.3 > this is replaced by a TLV structure, so in_phy_port is only sent to the c= ontroller if it > differs from in_port. > I meant the metadata labelled as "ingress_port" in 1.1 spec. Is that in_phy_port or in_port? Maybe you mean it is gone in 1.3? cheers, jamal From zoltan.lajos.kis@ericsson.com Tue Jun 12 04:48:41 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 8FAE021F85C6 for ; Tue, 12 Jun 2012 04:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=2.501, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5pRynbmKbyA for ; Tue, 12 Jun 2012 04:48:41 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 84AA921F858D for ; Tue, 12 Jun 2012 04:48:40 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-1d-4fd72c9720bd Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 46.31.11869.79C27DF4; Tue, 12 Jun 2012 13:48:39 +0200 (CEST) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.37]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 12 Jun 2012 13:48:39 +0200 From: =?iso-8859-1?Q?Zolt=E1n_Lajos_Kis?= To: Jamal Hadi Salim Date: Tue, 12 Jun 2012 13:48:37 +0200 Thread-Topic: [forces] More comments on draft-haleplidis-forces-openflow-lib-00 Thread-Index: Ac1IkHQQ3r73cP12SkaEieoM5CJe7wAACR2w Message-ID: <3A92A63EBFD41F4196707AF266E1CDA550CC681EC9@ESESSCMS0361.eemea.ericsson.se> References: <3A92A63EBFD41F4196707AF266E1CDA550CB2D3DD8@ESESSCMS0361.eemea.ericsson.se> <009801cd45c4$987148c0$c953da40$@com> <3A92A63EBFD41F4196707AF266E1CDA550CC681809@ESESSCMS0361.eemea.ericsson.se> <3A92A63EBFD41F4196707AF266E1CDA550CC90A792@ESESSCMS0361.eemea.ericsson.se> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvre50nev+Bvv2iVnceHaH1eLhm9ls Fre37mFzYPbYOesuu8eSJT+ZPLbdWssawBzFZZOSmpNZllqkb5fAlTHvy1r2grciFT27vzM1 MJ4V6GLk5JAQMJFYfeQ7I4QtJnHh3nq2LkYuDiGBU4wS3c2HmEASQgILGCU2TYgGsdkEPCW+ /1sE1iAioCHR3bqOHcRmFgiS6Hl8iLWLkYODRUBVYnZnHEhYWCBA4tmZHmaQsIhAoMTEr1wQ nUYS3/9vZgGxeQXCJc72HmCBWLuSWWJf9zyw8ZxA9bc29jOD2IxAt30/tYYJYpW4xK0n85kg bhaQWLLnPDOELSrx8vE/Voh6UYk77esZIer1JG5MncIGYWtLLFv4mhlisaDEyZlPWCYwis1C MnYWkpZZSFpmIWlZwMiyilE4NzEzJ73cSC+1KDO5uDg/T684dRMjMJoObvmtuoPxzjmRQ4zS HCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDctmbe4mel8cYih5tjuHnj9r3U e7xhfoGR69dfEXsl3Jnf8oitUHvGtW7tsylFlRbNCxvD/r40Zy8sP/L22G6ru+fEJzSHHZvS li56Nobpv9uNlqg42cLLm7rObtqcvnoZk3VO75fgByFnUxxztL7VcbnorWTkj1iku1ko7LeP zJljl4TLLLOUWIozEg21mIuKEwH1cdDVdAIAAA== 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: Tue, 12 Jun 2012 11:48:41 -0000 =20 > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com]=20 > Sent: Tuesday, June 12, 2012 1:42 PM > To: Zolt=E1n Lajos Kis > Cc: Haleplidis Evangelos; forces@ietf.org > Subject: Re: [forces] More comments on=20 > draft-haleplidis-forces-openflow-lib-00 >=20 > On Mon, Jun 11, 2012 at 1:42 PM, Zolt=E1n Lajos Kis=20 > wrote: > >> >=20 >=20 > > > > [Z2] Yes, something like that. But the intention was to=20 > remove those=20 > > semantics from the queues. E.g. it would be perfectly valid that=20 > > Queue1 on Port1 is a max-rate-queue, while Queue1 on Port2=20 > is a min-rate queue. >=20 > I wonder if you can have ports with differrent number of=20 > queues defined (eg 4 on port1 vs 8 on port2) [Z3] Yes, the specification allows this scenario. >=20 > >>b) There exist global queues, so it doesnt matter which=20 > port they end=20 > >>up on, the queue id being set by set_queue action is=20 > selecting the global queue. > > > > [Z2] No, if queues are "global", they must be identified by=20 > the port_id, queue_id pair. > > >=20 > I dont see why. Global in this sense means shared by all=20 > ports, the queue id should be sufficient information. The=20 > other scenario is easily identified by the LFB instance=20 > topology definition. [Z3] That kind of global queues (i.e., shared by ports) are not conforming to the OpenFlow queues. The traffic of one port/queue Should not affect how the traffic of another port/queue is handled >=20 >=20 > >>So ingress_port is called of_phy port when redirecting to the CE? > >>Why two metadatum to represent the same thing? > > > > [Z2] In_phy_port represents the physical port. In_port=20 > represents the=20 > > logical port if one was defined; otherwise it equals to in_phy_port. > > > > Up until OpenFlow 1.2 the OFPT_PACKET_IN message had a fixed=20 > > structure, so it had to carry both identifiers, even though in most=20 > > cases the two are equal. In OpenFlow 1.3 this is replaced by a TLV=20 > > structure, so in_phy_port is only sent to the controller if=20 > it differs from in_port. > > >=20 > I meant the metadata labelled as "ingress_port" in 1.1 spec.=20 > Is that in_phy_port or in_port? Maybe you mean it is gone in 1.3? >=20 [Z3] Basically every mention of ingress port refers to in_port. The in_phy_= port is only exposed in packet in messages. I just meant that up until 1.2 the packet_in message had to contain both in= _port And in_phy_port, even if they had the same value. In 1.3 in_phy_port is onl= y to be sent if it is different from in_port. Z.= From ehalep@gmail.com Wed Jun 20 07:14:54 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 E18B221F8759 for ; Wed, 20 Jun 2012 07:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2TTC4pd2jfP for ; Wed, 20 Jun 2012 07:14:53 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF44021F86D1 for ; Wed, 20 Jun 2012 07:14:52 -0700 (PDT) Received: by werb13 with SMTP id b13so6200355wer.31 for ; Wed, 20 Jun 2012 07:14:51 -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:x-mailer :thread-index:content-language; bh=XELtKnmtpaLsPGJrKjv+EmvRS18gZ3m9DZ2ef9zEBl0=; b=EJctsJhwaV5kvtfstbsHQa6ODhWxv32PFooor/3Y9CQLIxBPenGtsIMQeSuI8r8xbs q0VL+EtdgArwW8Grju89y6BBmBj38ym5WdvMpTfsvFnukijQOSxVll4Ho8fTZB1hLbYJ +uPm8AjNSzjm8rRV3sGaXwKZPbBu7sgQ+y2eKVJN/wPc+cTAm9WAgMzMptsyePZlTwyL ki463pAP/8qQ9DUtmy7ka469wBSxA79SHf+F58JQAB5BfNSKvoHnTyb05/2RHsXrvw/L toUfZBIrx+kn0l5Pna7ulCvsBCiA8cUtcdNlQq5ydhWnXzw9f/AwDW07bK9jAlb+5Js4 tMag== Received: by 10.180.102.136 with SMTP id fo8mr6360897wib.19.1340201691855; Wed, 20 Jun 2012 07:14:51 -0700 (PDT) Received: from EhalepXPS (ppp079166011173.dsl.hol.gr. [79.166.11.173]) by mx.google.com with ESMTPS id d3sm74631258wiz.9.2012.06.20.07.14.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jun 2012 07:14:51 -0700 (PDT) From: "Haleplidis Evangelos" To: "'David Meyer'" , References: In-Reply-To: Date: Wed, 20 Jun 2012 17:14:45 +0300 Message-ID: <00b501cd4eef$0c6d6aa0$25483fe0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac06nxM0hIc/S7aHTbGmAq/Rp2ZmxQR6G1nQ Content-Language: el Cc: sdnp@lucidvision.com Subject: Re: [forces] a few initial 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, 20 Jun 2012 14:14:54 -0000 Greetings, All your internal comments will be addressed in the second draft which we hope to submit soon. Thank you very much. Some responses from your internal questions: 5.1.4. Events Three events have been specified regarding the ports. The first event will be triggered when a new port is added to the switch, the second when a port has been removed from the switch and the third when a port has been modified dmm> and what does ForCES do with these? [EH] OpenFlow defines a port status message when a port has been changed. These are three events to reflect that. ---------- The LFB is expected to receive all types of Ethernet packets through a group input named Input Port, either from a OFPortLFB or a OFFlowTableLFB, along with metadata. The metadata will contain only dmm> do you mean OpenFlow "group" here? If so, why does the LFB dmm> receive packets this way, that is, why are groups involved here? [EH] No, this is related to the ForCES model (RFC 5812). An output group, is used to model the case where a flow of similar packets with an identical set of permitted metadata needs to be split into multiple paths. An output group consists of a number of outputs, called the output instances of the group, where all output instances share the same frame (packet) and metadata emission definitions. Each output instance can connect to a different downstream LFB, just as if they were separate singleton outputs. Same applies to input group. ----------- 5.2.4. Events One event have been defined regarding the Flow Table. The event will be triggered when a flow is deleted from the Flow Table whether due to the idle timeout, or to the hard timeout or a flow was deleted by the controller. dmm> how about flow added? [EH] I did not find such an event in the OF1.1 spec, and I don't think that it would be a good idea to include one. Imho, the best way for the flow added is when you add a Flow Entry to get a response that your request was successful. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > Behalf Of David Meyer > Sent: Friday, May 25, 2012 8:48 PM > To: forces@ietf.org > Cc: sdnp@lucidvision.com > Subject: [forces] a few initial comments on draft-haleplidis-forces- > openflow-lib-00 > > Great start folks. A few inital comments. General > comments here then search for dmm> in-line in the attached... > > Meta-comment: The document is perhaps overly perscriptive > with respect to how different functionality is *implemented*. > See for example the description of Apply Actions in section > 5.2.1, which is described in terms of which data structures > implement the functionality. You can see this again in the > description of FlowEntries in section 5.2.2. Other high level > comments: > > > (i). 1.3 would be a better spec to target. I > understand that 1.3 might not have been around > when you started this work but it seems that 1.3 > will be the post 1.0 stable version (eventually). > > (ii). The modeling is in some places a little > inaccurate (see my comments in-line), and perhaps > a bit more complicated than necessary. > > (iii). The figures (e.g., Figure 2) are complicated and > could use text explaining packet flow (and what > the labels are) > > (iv). When talking about matching, it would be good to > show explicitly how OXM match behavior is > emulated. See the discussion of OFFlowTableLFB in > section 5.2.1. > > (v). The discussion of groups in section 5.{2,3}.1 seems > to indicate that packets can come back to the OF > "pipeline" from a group; is that the intent (see > my coments in-line on this). > > > > Again, thnx for doing this work. > > --dmm > > -