Re: Outstanding issues with the LFB Lib document

["Wang,Weiming" <[e-mail]>]

Hi all,

It's closing to the meeting date. Just as Jamal proposed, we may need to focus on the issue on how the conceptual model is described and established. We may have more time discussing on other issues after the meeting.

Together with Ligang, Fenggen, and Chuanhuang, I propose to present a very draft slides on the conceptual model in two days to the list for discussion. Based on the discussions, we may form a slides file for the meeting. 

Note that we only have less than one week for the work.

thanks,
Weiming

----- Original Message ----- 
From: "Ligang Dong(董黎刚)" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, November 03, 2009 9:20 AM
Subject: Re: 答复: Re: Outstanding issues with the LFB Lib document


> More complemental explanation are provided here.
> 1) A document including only the most basic LFB defintion and conceptual model will not have a big size.
> 2) If the XML description of LFBs is in the different document from the conceptual model, then only the conceptal model will provide little help on the implementation of ForCES NE. 
> For example, without the definition of FE Object LFB in the FE model, we cannot successfully interoperate in July.
> regards
> Ligang
> 
> ----- Original Message ----- 
> From: "Ligang Dong(董黎刚)" <[e-mail]>
> To: <[e-mail]>
> Sent: Tuesday, November 03, 2009 8:50 AM
> Subject: Re: 答复: Re: Outstanding issues with the LFB Lib document
> 
> 
>> hi, every one,
>> 
>> If the size of LFB Lib document is our concern, then I suggest here "1+X" scheme that a little different from Evangelos'.
>> 
>> First, "1" in "1+X" means a basic LFB lib that contains conceptual models for routers, switches, etc. Actually, the conceptual model describe some basic packet/frame processing (e.g., IP forwarding, ethernet switching) in network devices. According to this conceptual model, we can decide that some LFBs will be left in this document while other LFBs will be deleted from current LFB lib document. 
>> 
>> Second, "X" in "1+X" means some LFB libs for various application, e.g., VPN, firewall.
>> 
>> regards
>> Dong, Ligang
>> 
>> 
>> 
>> 
>> ----- Original Message ----- 
>> From: "Haleplidis Evangelos" <[e-mail]>
>> To: <[e-mail]>
>> Sent: Monday, November 02, 2009 11:52 PM
>> Subject: Re: 答复: Re: Outstanding issues with the LFB Lib document
>> 
>> 
>> Greetings to the list,
>> 
>> I agree with Jamal's concern about having a big document. 
>> 
>> The actual problem lies within the xml, as we can't have it externally from
>> the document and it takes a lot of space.
>> Do you think it is valid to separate the conceptual part and the lfb lib
>> part?
>> 
>> I mean, let's have a basic lfb-lib draft with only the xml specifications
>> inside and then have another draft, using these to create the FE based on
>> the concept we choose, and allow us more space to create what we deem as
>> necessary for the basic lfb lib draft.
>> 
>> Now, on the concept, imho, we should not do something very complex or very
>> large, and with the above separation, we can have both ports LFBs as Jamal
>> has specified and do a very basic IP handling issue, including Fenggen's
>> concepts. As I see it, we can describe with generic lfbs (like generic
>> connectivity lfb) a very basic data flow:
>> 
>> portIn/interfaceIn -> Validator -> Queue -> Meter -> Classifier -> Forwarder
>> -> Queue -> portOut/interfaceOut
>> 
>> Queue, Validator and Meter LFBs can be empty LFBs that can be used as basis
>> for inheritance. Then in the Concept document we can create the queue lfb or
>> what we didn't create in the basic-lfb lib and say this is how an extension
>> of the library can be done. 
>> 
>> What do you think?
>> 
>> Regards,
>> Evangelos Haleplidis.
>> 
>>> -----Original Message-----
>>> From: Forwarding and Control Element Separation
>>> [mailto:[e-mail]] On Behalf Of Jamal Hadi Salim
>>> Sent: Friday, October 30, 2009 2:50 PM
>>> To: [e-mail]
>>> Subject: Re: 答复: Re: Outstanding issues with the LFB Lib document
>>> 
>>> I am not going to stand in the way of the authors if they decide to go
>>> with IP forwarding.
>>> My stated concern was that the document needs to be piece-meal
>>> readable and allow
>>> someone implementing to do the incremental pieces as needed. If you
>>> decide to do IPV4
>>> forwarding, then i should still be able to take the base LFBs and
>>> create an ethernet switch
>>> with additional LFB(s).
>>> Doing Ethernet switching + classifier (which is simpler) has some
>>> value in demonstrating for example that
>>> approaches such as openflow could use ForCES as a basis.
>>> 
>>> cheers,
>>> jamal
>>> 
>>> On Fri, Oct 30, 2009 at 4:50 AM,  <[e-mail]> wrote:
>>> > I think we have reach some consensus on how to build the LFB lib
>>> document, before Hiroshima we could focus only on conceptual model of
>>> the LFBs, but we still have to decide what packet handling conceptual
>>> model we should focus on, jamal thinks we should start with ethernet
>>> switch, and joel likes to address IP handling?What's other forks ideas?
>>> I have give a IPv4 forwarding processing model,is there any comments?
>>> >
>>> > Yours,Fenggen