Re: question on draft-lfblb-draft.txt?

Jia Fenggen <[email protected]>
Newsgroups gmane.ietf.forces
Message-ID <[email protected]> 
Yes,I agree with on that.
Still another question about port LFB,in convention router,packet 
processing on interface always be divided into to stages:ingress and egress 
processing,ingress handles things like L2 decap,Forwarding table lookup and 
then send the packets to fabric which will deliver it to egress side for 
queuing and scheduling for sending out to media.This two stage may reside 
in an interface processing card in modern routers.My question is the Port 
LFB 
reside and fuctions in such model.As model pictures:
           +----------+     +-----------+       
      ---->| Ingress  |---->|classifier |--------------+  
           |          |     |chip       |              | 
           +----------+     +-----------+              | 
                                                       v 
                           +-------------------------------------------+ 
             +--------+    |   Network Processor                       | 
        <----| Egress |    |   +------+    +------+   +-------+        | 
             +--------+    |   |Meter |    |Marker|   |Dropper|        | 
                   ^       |   +------+    +------+   +-------+        | 
                   |       |                                           | 
        +----------+-------+                                           | 
        |          |                                                   | 
        |    +---------+       +---------+   +------+    +---------+   | 
        |    |Forwarder|<------|Scheduler|<--|Queue |    |Counter  |   | 
        |    +---------+       +---------+   +------+    +---------+   | 
        |--------------------------------------------------------------+ 
what's relationship between Ingress\Egress in the above draw and the Port 
LFB?Should we give an example LFB topology which use the Port LFB,in part 
to satify the ForCES Requriment and in another aspect make the reader known 
more of the model? 
Yours,Fenggen
>From: "Joel M. Halpern" <[email protected]>
>To: "Jia Fenggen" <[email protected]>
>Subject: Re: question on draft-lfblb-draft.txt?
>Date: Thu, 21 Sep 2006 23:47:57 -0400
>
>Yes, that is what I am saying.  It is not perfect, but I think it is 
>good enough.
>
>(Note that information such as the number of VLANs permitted on the 
>ethernet would be encoded as an attribute in the general ethernet 
>LFB, rather than insisting that the FE instantiate an LFB for every 
>possible sub-Port.  This is reasonable since the supported kinds of 
>sub-ports are known when designing the base LFB class.)
>
>Yours,
>Joel M. Halpern
>
>At 11:29 PM 9/21/2006, you wrote:
>>If i understands you well,can it be said that in LFB base library 
>>we define the standard representation of port LFB,like Ethernet 
>>port LFB or anytype else,and the specified FE create a series of 
>>port LFB instances and encode them in LFB topology,when CE query 
>>the FE LFB topology,it can get to know the number of ports reside 
>>in FE and it's state and other properities.
>>Yours,Fenggen
>>
>>
>>>From: "Joel M. Halpern" <[email protected]>
>>>Reply-To: "Joel M. Halpern" <[email protected]>
>>>To: [email protected]
>>>Subject: Re: question on draft-lfblb-draft.txt?
>>>Date: Thu, 21 Sep 2006 23:19:28 -0400
>>>
>>>Given that "external port" doesn't always mean the same thing, 
>>>depending upon why one is asking the question, I don't think we 
>>>can fold a descriptor into the FE Object.
>>>
>>>So, for now, I think the best we can do is to have the CE look at 
>>>the pre-existing LFB topology.  And for some level of the meaning 
>>>of port / interface, the FE needs to create the corresponding LFBs 
>>>for itself.  Probably with their state set to "administratively 
>>>disabled."  But this seems to be an implementation issue, not a 
>>>standardization issue.  (Even with conventional routers there is 
>>>sometimes an issue of knowing what interfaces can be enabled.)
>>>
>>>Yours,
>>>Joel
>>>
>>>At 10:35 PM 9/21/2006, Jia Fenggen wrote:
>>>>Thank u for the answer.But i think just change the model draft is 
>>>>probably not enough because in ForCES Requirment document Port is 
>>>>used to reference to the external interface of the FE.
>>>>another question about Port LFB:
>>>>In port LFB I think we could on one aspect define the properties 
>>>>which relate to its function in the data flow,like receving 
>>>>packet from media ,on another aspect,we can define configurable 
>>>>properties like IP address,and we should abstract the common 
>>>>properities and define them in the Generic Connectivity LFB,and 
>>>>for specified media port,we could define the proper inherited 
>>>>LFB,am I right?
>>>>still,In current model,we have no way to get how many external 
>>>>ports on an FE,should it be defined in FE Object LFB or just let 
>>>>CE defer it from the port LFB instance it detected by LFB 
>>>>topology query,could u give me some light on this,thanks!
>>>>Yours,Fenggen
>>>>
>>>>
>>>>>From: "Joel M. Halpern" <[email protected]>
>>>>>To: "Jia Fenggen" <[email protected]>
>>>>>Subject: Re: question on draft-lfblb-draft.txt?
>>>>>Date: Thu, 21 Sep 2006 10:30:44 -0400
>>>>>
>>>>>The generic connectivity LFB in the library draft serves the 
>>>>>same purpose as the Port LFB described in the Model draft.  I 
>>>>>changed the name because the term "port" is so over-used in our 
>>>>>work.  I should probably change the terminology in the model 
>>>>>draft as well.
>>>>>
>>>>>Yours,
>>>>>Joel M. Halpern
>>>>>
>>>>>At 01:25 AM 9/21/2006, you wrote:
>>>>>>hi,joel:
>>>>>>   I am now working on abstracting some LFBs and hope to get 
>>>>>>your help,I also think it's very necessary for us to create a 
>>>>>>base LFB library,but i suspect that not so many persons are XML 
>>>>>>experts,so should we allow discussion in plain text.I have a 
>>>>>>question about port LFB in Model doc,
>>>>>>"The FE model can be used to define a Port LFB class and its 
>>>>>>technology-specific subclasses to map the physical port of the 
>>>>>>device to the LFB model with both static and configurable 
>>>>>>attributes.  The static attributes model the type of port, link 
>>>>>>speed, etc.  The configurable attributes model the addressing, 
>>>>>>administrative status, etc." in draft-lfblb-draft.txt you have 
>>>>>>defined a LFB named "Generic Connectivity LFB" and says "It 
>>>>>>only captures those properties which relate to its function in 
>>>>>>the data flow.  (So, for example, it does not provide for the 
>>>>>>IP address associated with this interface, or even an 
>>>>>>indication as to whether there is such an address.)" could you 
>>>>>>explain to me what's difference between the Port LFB and 
>>>>>>Generic Connectivity LFB?
>>>>>>Yours,Fenggen
>>>>>>
>>>>>>_________________________________________________________________
>>>>>>璐逛杞 MSN Explorer:   http://explorer.msn.com/lccn
>>>>
>>>>_________________________________________________________________
>>>>涓虹杩琛浜ゆ锛璇蜂娇 MSN Messenger:
>>>>http://messenger.msn.com/cn
>>
>>_________________________________________________________________
>>浜ㄤ涓澶х靛欢绯荤 MSN Hotmail  
>>http://www.hotmail.com
>>
>

_________________________________________________________________
涓虹杩琛浜ゆ锛璇蜂娇 MSN Messenger:  http://messenger.msn.com/cn
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.