Re: [forces] a few initial comments on draft-haleplidis-forces-openflow-lib-00

"Haleplidis Evangelos" <ehalep@gmail.com> Wed, 20 June 2012 14:14 UTC

Return-Path: <ehalep@gmail.com>
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 <forces@ietfa.amsl.com>; 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 <forces@ietfa.amsl.com>; 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 <forces@ietf.org>; Wed, 20 Jun 2012 07:14:52 -0700 (PDT)
Received: by werb13 with SMTP id b13so6200355wer.31 for <forces@ietf.org>; 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 <ehalep@gmail.com>
To: 'David Meyer' <dmm@1-4-5.net>, forces@ietf.org
References: <CAHiKxWgHzbhrDCb9=d_z+k5nZxutBo4VkLdrGLGm1j1h29NCTA@mail.gmail.com>
In-Reply-To: <CAHiKxWgHzbhrDCb9=d_z+k5nZxutBo4VkLdrGLGm1j1h29NCTA@mail.gmail.com>
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 <forces.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/forces>, <mailto:forces-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/forces>
List-Post: <mailto:forces@ietf.org>
List-Help: <mailto:forces-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/forces>, <mailto:forces-request@ietf.org?subject=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
> 
> -