Subject: [forces] LFB lib 05 version comments #2

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 7 Aug 2011 12:29:24 -0400

Section #2
I know this section comes from a lot of previous text before
the main RFCs came out.
Can someone scan it quickly and see if we can mention RFC5810/1/2
to provide a more modern context?

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Mon, 8 Aug 2011 21:40:30 +0300

Greetings Jamal,

Thanks a lot for the comments.

>From a brief scan I had on the documents, we should change the text to this:

   This document follows the terminology defined by the ForCES
   protocol in [RFC5810]and by the ForCES model in [RFC5812].
   The definitions below are repeated for clarity.

since a lot of the definitions do not appear in the early RFCs.

Also we can (and probably should) add the following definitions (which are
used in the lfb-lib document):

   FE Model:  The FE model is designed to model the logical processing
      functions of an FE.  The FE model proposed in this document
      includes three components; the LFB modeling of individual Logical
      Functional Block (LFB model), the logical interconnection between
      LFBs (LFB topology), and the FE-level attributes, including FE
      capabilities.  The FE model provides the basis to define the
      information elements exchanged between the CE and the FE in the
      ForCES protocol [RFC5810].

   Data Path:  A conceptual path taken by packets within the forwarding
      plane inside an FE.  Note that more than one data path can exist
      within an FE.

Also in the model rfc there is the following definition. While we don't use
the terminology of LFB Class Library I think that it is good to have it here
as that is what we're doing.

   LFB Class Library:  The LFB class library is a set of LFB classes
      that has been identified as the most common functions found in
      most FEs and hence should be defined first by the ForCES Working
      Group.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jamal Hadi Salim
> Sent: Sunday, August 07, 2011 7:29 PM
> To: [email-masked]
> Cc: Chuanhuang Li; Joel M. Halpern
> Subject: [forces] LFB lib 05 version comments #2
> 
> Section #2
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 8 Aug 2011 14:45:10 -0400

Greetings Evangelos,

Comments embedded.

>      plane inside an FE.  Note that more than one data path can exist

All the above looks good.

>      most FEs and hence should be defined first by the ForCES Working

I think maybe add an extra sentence in this section:
"The LFB Class Library is defined by this document."

Thanks for the fast turn-around.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 16 Aug 2011 09:43:32 +0800

Hi all, 

Pls check the modification of the whole section 2 according to this and other emails on the definitions as below. 

thanks,
Weiming

-------------------
2. Definitions
 
This document follows the terminology defined by the ForCES protocol in [RFC5810] and by the ForCES FE model in [RFC5812]. The definitions below are repeated for clarity.
 
Control Element (CE) - A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs on how to process packets.  CEs handle functionality such as the execution of control and signaling protocols.
 
Forwarding Element (FE) - A logical entity that implements the ForCES protocol.  FEs use the underlying hardware to provide per-packet processing and handling as directed/controlled by one or more CEs via the ForCES protocol.
 
ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs.  To entities outside an NE, the NE represents a single point of management.  Similarly, an NE usually hides its internal organization from external entities.
 
LFB (Logical Function Block) - The basic building block that is operated on by the ForCES protocol.  The LFB is a well defined, logically separable functional block that resides in an FE and is controlled by the CE via ForCES protocol.  The LFB may reside at the FE's datapath and process packets or may be purely an FE control or configuration entity that is operated on by the CE. Note that the LFB is a functionally accurate abstraction of the FE's processing capabilities, but not a hardware-accurate representation of the FE implementation.
 
FE Model - The FE model is designed to model the logical processing functions of an FE, which is defined by The ForCES FE model document [RFC 5812]. The FE model proposed in this document includes three components; the LFB modeling of individual Logical Functional Block (LFB model), the logical interconnection between LFBs (LFB topology), and the FE-level attributes, including FE capabilities. The FE model provides the basis to define the information elements exchanged between the CE and the FE in the ForCES protocol [RFC5810].
 
FE Topology - A representation of how the multiple FEs within a single NE are interconnected.  Sometimes this is called inter-FE topology, to be distinguished from intra-FE topology (i.e., LFB topology).
 
LFB Class and LFB Instance - LFBs are categorized by LFB Classes.      An LFB Instance represents an LFB Class (or Type) existence.      There may be multiple instances of the same LFB Class (or Type) in an FE.  An LFB Class is represented by an LFB Class ID, and an LFB Instance is represented by an LFB Instance ID.  As a result, an LFB Class ID associated with an LFB Instance ID uniquely specifies an LFB existence.
 
LFB Metadata - Metadata is used to communicate per-packet state from one LFB to another, but is not sent across the network.  The FE model defines how such metadata is identified, produced and consumed by the LFBs.  It defines the functionality but not how metadata is encoded within an implementation.
 
LFB Component - Operational parameters of the LFBs that must be visible to the CEs are conceptualized in the FE model as the LFB components.  The LFB components include, for example, flags, single parameter arguments, complex arguments, and tables that the CE can read and/or write via the ForCES protocol (see below).
 
LFB Topology - Representation of how the LFB instances are      logically interconnected and placed along the datapath within one FE.  Sometimes it is also called intra-FE topology, to be
distinguished from inter-FE topology.
 
Data Path - A conceptual path taken by packets within the forwarding plane inside an FE. Note that more than one data path can exist within an FE.
 
ForCES Protocol - While there may be multiple protocols used      within the overall ForCES architecture, the term "ForCES protocol" and "protocol" refer to the Fp reference points in the ForCES Framework in [RFC3746].  This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or to communication between FE and CE managers.  Basically, the ForCES protocol works in a master-slave mode in which FEs are slaves and CEs are masters. 
 
LFB Port – A port refers to an LFB input port or output port. See Section 3.2 of RFC 5812 [5812] for more detailed definitions.
 
Physical Port – A port refers to a physical media input port or output port of an FE. A physical port is usually assigned with a physical port ID, abbreviated with a PHYPortID. This document mainly deals with physical ports with Ethernet media.
 
Logical Port – A conceptually virtual port at data link layer (L2) or network layer (L3). A logical port is usually assigned with a logical port ID, abbreviated with a LogicalPortID. The logical ports can be further categorized with a L2 logical port or a L3 logical port. An L2 logical port can be assigned with a L2 logical port ID, abbreviated with a L2PortID. An L3 logical port can be assigned with a L3 logical port ID, abbreviated with a L3PortID. MAC layer VLAN ports belongs to L2 logical ports as well as logical ports. 
 
LFB Class Library - The LFB class library is a set of LFB classes that has been identified as the most common functions found in most FEs and hence should be defined first by the ForCES Working Group. The LFB Class Library is defined by this document.
-------------------

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>
Subject: Re: [forces] LFB lib 05 version comments #2

Greetings Evangelos,

Comments embedded.

cheers,
jamal