Subject: Re: Question on scope

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 2 May 2005 08:50:06 -0400

Hi Jose,
Apologies that noone had responded to you so far.

On Fri, 2005-29-04 at 10:13 +0200, Jose Rey wrote:

> I went through the charter and over some of the drafts and I don't know yet 
> if I get it right.  I understand that the aim is to separate control and transport, 
> that much is clear.  Additionally, some QoS functionality is implemented in the forwarding 
> entities.  But, is it also planned to include more advanced functionalities 
> like transcoding, metering, intelligent packet dropping (e.g., only P frames) in those FEs?? 
> Related to that: the 
> charter talks about per-packet processing but does this processing stop at layer 4 ?

The end goal is to provide generic enough functionality in the protocol
and the modeling "language" such that you should be able to model and
then configure any forwarding path element in existence in variety of
future and existing FEs.

Although some basic LFBs that are mentioned in the charter will be
described - they merely exist to validate that the protocol and the
modelling "language".  As an example, at the moment i am using the LFB
model to describe IPSEC FEs and configuring them using Forces (it is not
listed in the charter but the model and protocol are sufficient for it).

Hopefully this answers your questions. If theres any objection to my
response to you from other people you should hear from them.

cheers,
jamal

---

From: Jose Rey <[email-masked]>
Date: Mon, 2 May 2005 16:51:05 +0200

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. 
> 

With routing, yes, I meant basically L3 routing. 

> > 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
> - 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?

It does to me (although my knowledge of the drafts is limited :)

Cheers,

José

---

From: Jose Rey <[email-masked]>
Date: Fri, 6 May 2005 21:12:23 +0200

Hi,

> 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.
> 
OK

> > 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?

What I mean is traditional concept of e2e: that the IP header is not modified except for normal router operations (ttl touching and checksum) .  

(I think your comment below implicitly answers with "yes" to this)

> 
> >  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.
> 
OK

> >  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.
> 
Good.

Cheers,

José

..............................................................................
Confidentiality Notice
The information contained in this Email, and any attachments, is intended for the named recipients only. It may contain confidential and/or legally privileged information. If you are not the intended recipient, you must not copy, store, distribute or take any action in reliance on it. Any views expressed do not necessarily reflect the views of the company.

If you receive this Email by mistake, please advise the sender by using the reply facility in your Email software and then delete it.
.............................................................................