Re: [mpls-linux-devel] More comments on Jamal's spec

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

On Mon, Feb 16, 2004 at 04:41:37PM -0500, Jamal Hadi Salim wrote:
> BTW, I am fine with whatever you guys end up picking for the
> code repository; you will have to teach me about its usage.
> p4 sounds good.
> Also James i know you are a big fan of UML - i am trying to see if it
> valubale - getting tired of hanging my laptop (though i run ext3 these
> days ;->); so if you can share your setup on a test environment i would
> appreaciate it.
> I looked at Qemu it does look very interesting; any thoughts on that?

I never tied Qemu, but your right it does look interesting.
I'll put my UML environment on a ftp server some place for your
to download.  It consists of a couple of scripts I thew together and
some rh8.0 files systems.  I'll arrange that this evening.

> On Mon, 2004-02-16 at 12:47, Ramon Casellas wrote:
> > On 16 Feb 2004, Jamal Hadi Salim wrote:
> 
> > 
> > 
> > > Ok. So we may need some extra speacilized NHLFE entries. I am not a big
> > > fan of the two step process unless you guys really insist - then we can
> > > go and convince davem.
> > 
> > 
> > Well, the problem with CR-LDP and/or RSVP is that it is a 'ping-pong' set
> > up process, and you usually need to define a 'prestate'. Another
> > possibility is to consider RSVP as using the unsollicited downstream
> > label distribution and only process the RSVP-RESV message from control
> > space (when the message comes up from your downstream router), I am not
> > sure about this though.
> > 
> 
> Could something in user space be responsible for maintaining the
> prestate? When full state is available, it gets downloaded to the
> kernel.
> 
> > > My opinion is lets have 3 new speacial NHLFEs:
> > 
> > > - something that sends the packet to a blackhole which will work for
> > > such a scenarion as above.
> > 
> > A 'disabled' NHLFE. I think that this can be useful, for example for
> > liberal retention mode.
> > 
> 
> Ok, so we could add something this:
> l2c mpls nhlfe add dev eth0 proto ipv4 nhlfeid 3 blackhole
> 
> > 
> > > - Another one will send the packet to user space via netlink. This may
> > > also be used for resolving what you have above.
> > 
> > So we can conform to the RFC (although sometimes it is just IETF jargon)
> > But the question is 'which packet?' I assume that it is the first packet
> > that according to the FIB_RES should be mapped to a NHLFEid that just does
> > not exist. Don't we risk flooding userspace? Should it be only the first
> > packet? what a bout a single netlink event (in plain english: hey, I don't
> > know what to do with this FEC, can you do something about it?)
> 
> Well, something along the same lines. Example:
> 
> l2c mpls nhlfe add dev eth0 proto ipv4 nhlfeid 4 control-redirect 
> 
> The above could be a result of intentional policy  such as preceeded by:
> 
> l2c mpls ilm add dev eth0 label 9 nhlfeid 4 
> 
> or as a result of it being the default NHLFE rule which gets consulted
> because bothing else was found, example:
> l2c mpls nhlfe add dev eth0 nhlfeid 4 default control-redirect
> 
> Thoughts?
> 
> > > - A third one is for locally destined packets. I was not sure whether
> > > this should just be a flag which says neighbor = local or not.
> > 
> > IIRC, locally destined packets means that the LSR is egress (for all
> > hierarchical levels) and pops the last packet. As one possibility, the
> > default action should be just call IP module packet reception if we just
> > popped the last label, so the packet is locally delivered or forwarded per
> > dest address.
> 
> If the last label has been popped then it would make sense to redirect
> to the stack. The one that i was worried about is it having a stack of 
> labels hiding a local host IP packet. Can we assume that the user can
> shoot themselves in the feet and we wouldnt care?
> 
> cheers,
> jamal
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

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