Re: [mpls-linux-devel] Current state of dst stacking on davem implementation

[Jamal H. S. <ha...@zn...>]

On Tue, 2004-04-20 at 09:33, James R. Leu wrote:
> Sorry for being absent for the last couple of weeks, I'm in the midst of
> the busiest time of the year for me.  I'm preparing for the Network + InterOp
> tradeshow.  This year I'm working on an 'Advanced Internetworking Initiative'
> which basically means MPLS services :-)

Fun in Las Vegas; gambling, cheap food and drinks and oh, a trade 
show ;->

> We have equiptment from 10 vendors and over 20 devices.  We'll be concentrating
> on MPLS BGP VPNs (v4,v6,Multicast), VPLS, and Carrier's Carrier.  Our main
> area of 'experimenting' is in the multicast space.  We're showing carriers
> and vendors how BGP VPNs have an advantage (although only slight) over
> L2 VPNs (ala VPLS) with repect to multicast.  Hopefully the result will be
> L2 VPN vendors re-thinking their implementation.

Doesnt VPLS eventually have to converge to a MPLS cloud? 
a lot of elcheapo ASICs with VPLS capability appearing lately. Ethernet
will always be king ;->
Didnt understand the multicast part.

> Anyway enough of that, onto the questions I've missed.
> 
> On Tue, Apr 20, 2004 at 01:22:58PM +0200, Ramon Casellas wrote:
> > On Mon, 19 Apr 2004, Jamal Hadi Salim wrote:
> > 
> > > On Mon, 2004-04-19 at 02:22, Ramon Casellas wrote:
> <snip>
> > OTOH, with the new extensions for L2SC/PWE3 control in (G)MPLS we may need
> > to work more closely with the bridging people (although most things belong
> > clearly to userspace). I know that James has been working in this area,
> > but I don't know the details or whether he has been working with other
> > people.
> 
> My work, as usual, is a solo effort.  If anything I've done can be of
> use, I'd be more the happy to contribute.
> 

I think lets go to that in the next phase. Lets get in the MPLs code
first. If theres any architectural concerns that will hindre that work,
then we should certainly address them now.


> One thing to note is that the great thing about a dual instructions scheme
> (one set on the ILM and one set on the NHLFE) is that you can optimize the
> instructions for speed or flexibility.  If you want to create a PUSHN
> instruction, you can easily add it and use it instead of the NHLFE stacking
> (if that is what your particular application needs).  I still think that NHLFE
> stacking is what will be used for the common hierachical LSP case though.

I have no problems with this. The way i see it is like this: You guys
are the MPLS experts - i have opinions that i make known and if you have
strong reservations then we go with yours. 


> BTW do either of you have a good upstream connection?  If so we could
> create a p4 proxy with a high level of caching.  Then only the commits
> need to consume my limited bandwidth.  (I'm researching getting a better
> upstream, but options are limited in my suburb, which was a farms corn field
> last year at this time).

I dont. My damn ISP doesnt even give me more than 5M of space (cant move
have been there more than 10 years).

cheers,
jamal