Subject: Re: ForCES WG meeting minutes, IETF 63, Paris, Aug 1 2005.

From: Dong Ligang <[email-masked]>
Date: Tue, 9 Aug 2005 09:55:16 -0400

Great! Thank you

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 16 Aug 2005 10:53:20 +0800

Hi,

followed is a supposed editorial change to the protocol draft. Pls send your comments if any. 

Thanks,
Weiming
 
<ORIGINAL>
Abstract

This specification documents the Forwarding and Control Element Separation protocol.  This protocol is designed to be used between a Control Element and a Forwarding Element in a Routing Network Element.

</ORIGINAL>

<SUPPOSED CHANGE>
Abstract

This document specifies the Forwarding and Control Element Separation (ForCES) protocol. ForCES protocol is a message exchange protocol that is used for communications between a Control Element (CE) and a Forwarding Element (FE) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC3654. Besides the ForCES protocol messages, the specification also defines the framework, the mechanisms, and the Transport Mapping Layer (TML) requirements for ForCES protocol.

</SUPPOSED CHANGE>

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 16 Aug 2005 15:39:15 +0800

Hi,
This issue is as below:
<ISSUE 9>
Need to define LFBs better now that we have things like core LFBs.
Caught by Alistair Munro, to quote:

---
Definitions: LFB type is defined as a "packet processing function" but some 
LFBs, (e.g. the protocol LFBs in 3.3.2, 6.2 - these aren't really 
"fine-grain" either), do not process packets. Perhaps it should be a 
"processing function... generally operating upon packets...". Probably 
taken from the Model?
---
capturing aso we dont loose it.
</ISSUE 9>

I suggest to solve this issue by modifying the LFB definition in either the FE model and the protocol draft as below:
from:
   LFB (Logical Functional Block) Class (or type) -- A template    representing a fine-grained, logically separable and well-defined    packet processing operation in the datapath.  LFB classes are the    basic building blocks of the FE model.
to: 
   LFB (Logical Functional Block) Class (or type) -- A template    representing a fine-grained, logically separable and well-defined    packet processing operation in the datapath, or a functinal block    for protocol operation in FE. LFB classes are the basic building    blocks of the FE model.Any comments?Thanks,Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 16 Aug 2005 07:08:38 -0400

On Tue, 2005-16-08 at 15:39 +0800, Wang,Weiming wrote:
>    LFB (Logical Functional Block) Class (or type) -- A template  representing a fine-grained, logically 
> separable and well-defined    packet processing operation in the datapath.  LFB classes are the  basic 
> building blocks of the FE model.
> to: 
>    LFB (Logical Functional Block) Class (or type) -- A template  representing a fine-grained, logically 
> separable and well-defined    packet processing operation in the datapath, or a functinal block    for 
> protocol operation in FE. LFB classes are the basic building blocks of the FE model.

BTW, I am really suprised at the weak definitions of LFB; i just glanced
at model and framework docs.

Probably you want to emphasize the following:
- it resides at the FE (since we killed CE based LFBs)
- it _may_ process packets
- it is managed/controlled by the CE

i.e something along:
"LFB classes are the basic building blocks that are operated on by the
Forces protocol. The LFB is a well defined, logically separable
functional block that resides in the FE and is controlled by the CE via
forces protocol. The LFB may reside at the FEs datapath and process
packets or may be purely a control entity that is operated on by the CE"

cheers,
jamal

> Any comments?Thanks,Weiming
>  
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 16 Aug 2005 07:33:29 -0400

> at model and framework docs.

To emphasize again: the definition in the model/protocol draft is weak.
Weimings editing should fix that.  But what about the Framework? or even
the requirements RFC? Neither has any mention of LFB. Is there anything
that can be done or is it unnecessary?

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 16 Aug 2005 23:08:43 +0800

Hi,

 followed is a supposed editorial change to the protocol draft. Pls send
your comments if any.

 Thanks,
Weiming

 <ORIGINAL>
1.  Introduction

   This specification provides a draft definition of an IP-based
   protocol for Control Element control of an Forwarding Element.  The
   protocol is a TLV based protocol that include commands for transport
   of LFB information as well as TLVs for association, configuration,
   status, and events.

   This specification does not specify a transport mechanism for
   messages, but does include a discussion of the services that must be
   provided by the transport interface.

1.1  Sections of this document

   Section 2 provides a glossary of terminology used in the
   specification.

   Section 3 provides an overview of the protocol including a discussion
   on the protocol framework, descriptions of the protocol layer (PL)
   and a transport mapping layer (TML), as well as of the ForCES
   protocol mechanisms.

   While this document does not define the TML, Section 4 details the
   services that the TML must provide.

   The Forces protocol is defined to have a common header for all other
   message types.  The header is defined in Section 5.1, while the
   protocol messages are defined in Section 6.

   Section 7 describes several Protocol Scenarios and includes message
   exchange descriptions.

   Section 8 describes mechanism in the protocol to support high
   availability mechanisms including redundancy and fail over.
   Section 9 defines the security mechanisms provided by the PL and TML.

</ORIGINAL>

<SUPPOSED CHANGE>
 1.  Introduction

Forwarding and Control Element Separation (ForCES) aims to define an
architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding plane
in an ForCES Network Element (ForCES NE). RFC 3654 has defined the
ForCES requirements, and RFC 3764 has defined the ForCES framework.
While there may be multiple protocols used within the overall ForCES
architecture, the term "ForCES protocol" refers only to the protocol
used to standardize the information exchange between Control
Elements(CEs) and Forwarding Elements(FEs) only. ForCES FE model
[FE-MODEL] represents the capabilities, state and configuration of  FEs
within the context of the ForCES protocol, so that CEs can accordingly
control the FEs in a standardizded way and by means of the ForCES
protocol.

This document defines the specifications for the ForCES protocol.
Basically, the ForCES protocol works in a master-slave mode in which FEs
are slaves and CEs are masters. The ForCES protocol is a message
exchange protocol, information exchanged between FEs and CEs is always
in the form of protocol messages.  The protocol is also a TLV based
protocol that include commands for transport of LFB information as well
as TLVs for association, configuration, status, and event notifications,
etc.

Section 2 provides a glossary of terminology used in the specification.

Section 3 provides an overview of the protocol including a discussion on
the protocol framework, descriptions of the Protocol Layer (PL) and a
Transport Mapping Layer (TML), as well as of the ForCES protocol
mechanisms.

While this document does not define any specific TML, Section 4 details
the services that a TML must provide (TML requirements).

The ForCES protocol is defined to have a common header for all protocol
messages. The header is defined in Section 5.1, while the actual
protocol messages are defined in Section 6.

Section 7 describes several protocol scenarios and includes message
exchange descriptions.

Section 8 describes mechanism in the protocol to support high
availability mechanisms including redundancy and fail over.

Section 9 defines the security mechanisms provided by the PL and TML.

</SUPPOSED CHANGE>

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 16 Aug 2005 23:37:48 +0800

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
> packets or may be purely a control entity that is operated on by the
CE"

I'm fine with the definition. How about model team thought? We need to
be consistent between the protocol and the team on the definition.

Jamal, when it is solved, I will immediately modify the definition in
the protocol draft.

Thanks,
Weiming