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

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

I want to make sure I've got your opinion correct:

On an ingress LER your think iptables -> nfmark is sufficient.
On a transit LSR and egress LER tc_index is needed (to augment dsmask and
scheduling).

In addition you would like the option of using iptables to do all
marking/classifing AND bypass normal routing lookups, but it may be possible
to use the existing mechanisms (aux_proto on a FIB entry or a MPLS tunnel
interface) to achive the same functionality, but not necessarily the same
level of efficiency.

Jim

On Thu, Nov 29, 2001 at 08:50:56AM +0100, Steven Van den Berghe wrote:
> On Thu, 2001-11-29 at 05:20, James R. Leu wrote:
> > After looking at iptable a bit more I see that it can set a nfmark via
> > the MARK rule.  Should I use this as oppsed to tc_index to influence the
> > LSP and EXP? (note that DSCP will still be an options)
> Would be a clean choice (note: you'll still need part of Olivier's patch
> to implement a FEC like behavior per iptables result). 
> > 
> > I think I now understand what Olivier did, he created something similar
> > to MARK but for MPLS.  If we are going to continue to use that I would
> > like to change it alittle.  Instead of storing the mpls_index, I think it
> > should build a dst and store it with the rule.  This dst will direct the
> > skb to mpls_output() and will have the outgoung label info attached.
> > When it gets to mpls_output() MPLS processing will occur like normal.
> > The dst will be slapped on to any packet that matches the rule.
> Iptables has hooks in several places along the forwarding path: before,
> in or after the "routing". Is there no possibility that dev will be
> overwritten by the ip-code? I still feel, we should be able to bypass
> routing completely (i'm searching what can be done to handle
> fragmentation etc.)
> > 
> > Do you think that by using nfmark we can accomplish the same thing?
> > We would have to relay upon another mean of getting data to mpls_output()
> > like a MPLS tunnel interface or a entry in the FIB that has been marked
> > for MPLS.  Once it gets to mpls_output() the nfmark could be used to influence
> > the LSP or EXP.
> > 
> first guess (warning: statistically proven it's mostly wrong): possible
> approach.
> 
> > Ofcourse maybe it's just safer to have both options availble :-)
> > 
> > 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.
> > 
> tc_index is indeed no "must". There are other solutions possible to get
> the same effect, especially in the ingress (in the core, we don't want
> to use iptables for anything). The only thing from the original diffserv
> for ip the sch_dsmark  + tc_index combination offers you is:
> 
>  1 you can read the (ip) dscp and put it in tc_index (enqueue operation)
>  2 you can classify based on tc_index
>  3 you can modify the value of tc_index during the traffic control
>  4 you can re-write the dscp based on tc_index in the ip-header when
> exiting sch_dsmark (dequeue operation) 
> 
> 1 and 2 can be done using iptables and fw_mark classifier
> 3 and 4 need more study. At first sight, i'd say we can do this either
> in ingress policing or add it to iptables (configuration would be
> something like: if offered load <1Mbps set fwmark 2, if offered load
> <2Mbps set fwmark 1, else set fwmark 0).
> 
> just a personal opinion: i would keep the sch_dsmark approach in LSR and
> egress, but for ingress (where the more complex TC functions should be
> performed, to achieve scaleability), forgetting about sch_dsmark and
> tc_index would be just fine.
> 
> 
>  Does that make any sense?  It's late.  I'm going to sleep and think about
> > it some more.
> >
> why, i've just woken up :)
>  
> 
> cheers,
> Steven
> -- 
> --
> Steven Van den Berghe
> ste...@in...
> Workgroup Broadband Communication Networks
> Department Information Technology
> Ghent University - Belgium
> Phone:  +32 (0)9 267 35 86 | Fax  :  +32 (0)9 267 35 99
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> DiffServ over MPLS for Linux: http://dsmpls.atlantis.rug.ac.be
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> A computer is like an Old Testament god, with a lot of
> rules and no mercy. - Joseph Campbell
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> 
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general

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