Subject: Re: Question on scope

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 3 May 2005 08:29:17 -0400

Joes,

On Tue, 2005-03-05 at 10:07 +0200, Jose Rey wrote:

> As I understand, basically you got a 'processing graph' which eventually (after applying 
> the 'logic') gives you a 'processing path' and then you need the L3 route anyway, no?  
> 
>
> I guess that for the "LFB arrangement" you don't use L3 routing but you do for the 
> inter-NE connections.

Depends if the NE is doing L3. If it is, the rule of thumb imposed is "
thous shalt not decrement ttl more than once". So a packet coming in on
a port on FE1 to be L3 forwarded on a port on FE2 shall have its ttl
only decremented once.
As an example of "LFB arrangement", if you take the model draft example
from figure 10:

     +-----------------------------------------------------+ 
      |  +---------+   +------------+   +---------+         | 
    input|         |   |            |   |         | output  | 
   ---+->| Ingress |-->|Header      |-->|IPv4     |---------+--->+ 
      |  | port    |   |Decompressor|   |Forwarder| FE      |    | 
      |  +---------+   +------------+   +---------+ #1      |    | 
      +-----------------------------------------------------+    V 
                                                                 | 
           +-----------------------<-----------------------------+ 
           |     
           |    +----------------------------------------+ 
           V    |  +------------+   +----------+         | 
           | input |            |   |          | output  | 
           +->--+->|Header      |-->| Egress   |---------+--> 
                |  |Compressor  |   | port     | FE      | 
                |  +------------+   +----------+ #2      | 
                +----------------------------------------+ 
    
Another graph may have FE1: --input--> Ingressport -->
IPV4 forwarder --backplane--> FE2:egress port --out-->

And therefore totaly missing out the Header compression/decompression 
blocks in the graph. In such a case the L3 lookup is done in the ingress
on FE1 and the nexhop is on the egress on FE2s some port. This is
assuming the FEs are capable of this.

> > - i should say formally describe their parametrization - 
> > using the LFB "language" as defined by the model; if you can 
> > do that then the protocol can configure them. Does that make sense?
> 
> Something more:
> 
>  a) I hope this whole thing is end-to-end (!), no? 

Well, the scope is NE-level. I am not sure what you mean by end-2-end?

>  b) S. 4.7.2 is the base for defining complex packet header masks that 
> enable conditional processing?

The inputs and outputs are needed for describing graphs. i.e they are
logical more than for packet processing. The packet processing is done
within the blocks. When you define your LFB you define the inputs using
various criteria as mentioned in the draft.

>  c) how fast would this be? Are we talking core network routers here? 
> Or is it planned for access network' bitrate magnitude?  I mean if usually 
> processing Options takes packets out of the fast path, what would be the 
> penalty in terms of delay,e.g., for a FE? (I realise it may be too soon 
> to make a statement on this, but maybe you already have some results?? 
> Hope these questions are not 'uncomfortable' :)
> 

Every vendor building a distributed box has something like Forces
thats proprietary.  This effort is to standardize such approaches.
As far as speed is concerned, I dont suspect this will be any different
than something Juniper or CISCO or nortel etc does thats proprietary.
The goal is to be able to process as fast as possible - its part of the
requirements. If you see anything working against that goal, let us
know. So in other words, forces should be usable at both core and access
devices.

cheers,
jamal

---

From: Jose Rey <[email-masked]>
Date: Tue, 3 May 2005 10:07:26 +0200

Hi Jamal, 

> 
> Joes,
> 
> On Mon, 2005-02-05 at 16:07 +0200, Jose Rey wrote:
> 
> > Thanks for you answers.  Actually Joel answered. I paste 
> the offline traffic below.
> > 
> > Summarising the thread below, it seems that you target at 
> making the 
> > task of policy-routing much easier and as far as possible 
> automated (challenging!).
> 
> It depends on what you mean by policy routing. If it is what 
> Jpel describes in his email as "arranging the LFB instance 
> graph and classifier tables" then yes. If by routing you mean 
> L3, then thats a small subset of the larger picture.
> Forces also is constrained within the scope of an NE. 

As I understand, basically you got a 'processing graph' which eventually (after applying the 'logic') gives you a 'processing path' and then you need the L3 route anyway, no?  

I guess that for the "LFB arrangement" you don't use L3 routing but you do for the inter-NE connections.

> 
> > This controlled entities (FEs) would include things as 
> interesting as 
> > transcoders,  packet droppers and so on, thus not limited 
> to L4 functionality.
> 
> Indeed. 
> Essentially, intelligence on the CE decides what LFB building 
> blocks to use and then instantiates them interconnected via a graph.
> The graph edges may be constrained by the limits of what the 
> LFB block can connect to (as discovered during capability 
> exchange). So if the blocks constitute of L2 processing, G711 
> RTP vocoding, IPSEC etc, shouldnt matter. What matters is you 
> can formally describe these blocks

Something more:

 a) I hope this whole thing is end-to-end (!), no? 
 b) S. 4.7.2 is the base for defining complex packet header masks that enable conditional processing?
 c) how fast would this be? Are we talking core network routers here? Or is it planned for access network' bitrate magnitude?  I mean if usually processing Options takes packets out of the fast path, what would be the penalty in terms of delay,e.g., for a FE? (I realise it may be too soon to make a statement on this, but maybe you already have some results?? Hope these questions are not 'uncomfortable' :)

Cheers,

José