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

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

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?

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