Subject: Comments on draft-blake-forces-attrib-00.txt

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 28 Jul 2004 19:25:14 -0700

Hi Steve, Zsolt,
 
I read draft-blake-forces-attrib-00.txt, and I think it raises some
valid issues.
 
Couple of comments....
 
Regarding the issue of "Bundled Configuration of LFBs", this is part of
the protocol requirements 
and will be address by the ForCES protocol. I don't think a Dispatcher
LFB is needed in the model specifically 
for this, but I may be missing something. 
 
Regarding the issue of "Inter-LFB Control", I wonder why it is needed to
expose this in the FE Model ?
Isn't this something that would be taken care of by the FE
implementation and doesn't need the CE to
control or configure it ? 
 
Thanks for raising these issues,
 
regards
Hormuzd

---

From: Zsolt Haraszti <[email-masked]>
Date: Thu, 29 Jul 2004 10:12:00 -0400

Hi Hormuzd,

On Wed, 2004-07-28 at 22:25, Khosravi, Hormuzd M wrote:
> Regarding the issue of "Bundled Configuration of LFBs", this is part
> of the protocol requirements

Message bundling is a "mid-point" solution to address the
generic configuration bundling problem.  It is sufficient
for most cases.  It is mid-point in two senses:
1.  It only addresses bundling in terms of ForCES protocol
    messages, but not in terms of driver calls.  Above the
    ForCES layer on the CE and below the ForCES layer on the
    FE (after you demultiplexed the payload into multiple,
    per-LFB requests) you need to handle the requests separately,
    calling the respective driver API functions one-by-one.
    That may be OK for some cases, and may be a prohibitively
    expensive (high overhead) for others.
2.  Bundling at the ForCES protocol eliminates some protocol
    redundancy, but it cannot eliminate any payload data
    redundancy.  The latter only occurs if identical data
    is being sent to multiple LFB instances.
    Consider the example in Section 2.1.  ForCES bundling
    would support the solution described in the 3rd paragraph,
    i.e., it would allow one ForCES message be sent to the FE,
    simultaneously updating both the NH LFB used for network
    ingress filtering and the NH LFB used for egress selection.
    But, remember that the two LFBs require identical table content.
    So, although you would see one message, inside the message
    you would have duplicated information (one set of NH
    data for one LFB and another (identical) for the other.
I am not saying in any way the bundling is bad.  It is needed
and it is sufficient for many cases.  There are, however,
some cases where it is not sufficient, for which the model should
provide a more adequate solution.

>
> Regarding the issue of "Inter-LFB Control", I wonder why it is needed
> to expose this in the FE Model ?

Consider the example in Section 2.2 where an ARP LFB
needs to update table(s) in the Address Resolution (AR) LFB.
Suppose you have multiple instances of both LFBs in the
same FE.  So then which ARP LFB is updating the table(s)
of which (AR) LFB?  The model should be able to express such
dependencies to the CE.

/zsolt

--
Zsolt Haraszti                Phone:  +1 919-765-0027/2017
Modular Networks              Mobile:      +1 919-522-2337
                              Email:  [email-masked]

---

From: Alex Audu <[email-masked]>
Date: Thu, 29 Jul 2004 14:51:08 -0500

It seems like we need a definite line of demarcation that decouples FE
silicon internals from
everything else outside it. How about some sort of  API for FE silicon?

Regards,
Alex.

"Khosravi, Hormuzd M" wrote:

>  Hi Steve, Zsolt,I read draft-blake-forces-attrib-00.txt, and I think
> it raises some valid issues.Couple of comments....Regarding the issue
> of "Bundled Configuration of LFBs", this is part of the protocol
> requirements and will be address by the ForCES protocol. I don't think
> a Dispatcher LFB is needed in the model specifically for this, but I
> may be missing something. Regarding the issue of "Inter-LFB Control",
> I wonder why it is needed to expose this in the FE Model ?Isn't this
> something that would be taken care of by the FE implementation and
> doesn't need the CE tocontrol or configure it ?Thanks for raising
> these issues,regardsHormuzd