Re: [mpls-linux-general] Better to use nfmark vs tc_index?

[James R. L. <jl...@mi...>]

Comments at the bottom:

On Thu, Nov 29, 2001 at 11:53:01PM +0100, Steven Van den Berghe wrote:
> Hi Olivier, Jim,
> 
> On Thu, 2001-11-29 at 17:32, Olivier Dugeon wrote:
> > Hi Jim,
> > 
> <did some cutting here>
> 
> > > Now to the matter of tc_index.  It seems that nfmark can be used by a
> > > scheduling classifier, but it looks like the classifier for tc_index is
> > > better.  So it might be that nfmark (or a MPLS mark) is used to influence
> > > LSP and EXP descisions (note that DSCP will still be option) and that
> > > tc_index is used to influence scheduling.
> > 
> > 
> > Actually for the TC part, we use mpls_index. My latest patch (not 
> > publish yet) use mpls_index when it has been configured in the 
> > kernel_config and directly the label in the other case. We can recopy 
> > this index into the tc_index. The TC mpls classifier has been written 
> > for this purpose. The original way we want code is to use u32 
> > classifier. But there is two pb.
> > 
> > 1/ the label is not accessible by u32 classifier. They only start at the 
> > ip header not the shim header.
> > 
> > 2/ Why classify again the packet (CPU power ....) if it has already been 
> > classified with iptable or another process ? The shim header (formely 
> > the label and/or the EXP fields of the shim header) can be used as a 
> > filter mark.
> > 
> agree, there is no use in doing the same job twice. I think for TC, the
> bottom line is that we want to be flexible on the type of classifier to
> use (especially in the ingress): tc_index, fw_mark,...

It seems you and Olivier have something against the Linux IPv4 stack, you
guys want to bypass it in any way possible :-)

I'm going to hop up on my soap box a give you my opinion about this, mind
you this is just opinion and further education about iptabels and TC may
change my mind, but:

MPLS is not meant to take the place of IP routing, it is mean to augment and
work with IP routing to do path selection upfront, and not per packet.
The same is true with traffic engineering or differentiated services, they
mean nothing without traditional IPv4 routing. So to say "we want to bypass
IP routing" is not a statment that is true to the definitions of MPLS or
TE or DiffServ.  We need to figure out what is the correct way to take
what IP routing tells us, augment it, and then find the correct place to
apply it.  Granted I'm definitly not an TE or DiffServ expert, but I have
leared the underlying mechanics of a number of MPLS implementation
(commercial).  I tend to think that marking route entries and using MPLS tunnel
interface are the only mechanisms you need to direct traffic into the
MPLS stack.  We do need additional info per packet, provided via iptables,
but iptables cannot replace the IPv4 stack.

Anyway, I'll get off my soap box now.

Jim
-- 
James R. Leu
jl...@mi...