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

[Ramon C. <cas...@in...>]

On 16 Feb 2004, Jamal Hadi Salim wrote:

> On Sun, 2004-02-15 at 05:36, Ramon Casellas wrote:


> Some comments:

Ok. I'll do it asap.

(nhlfeid ;) so when we prefix it there is just one underscore... agreed?
:)




>
> What would be useful in this document as well is to describe the
> interface between the kernel and user space. i.e describe the packets

Agreed. I'll take care of this.




> For how we document this typically look at:
> http://www.faqs.org/rfcs/rfc3549.html

ok.






> 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.





> 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.



> - 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?)




> - 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.



Thanks,

R.