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

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

re-hi,

FYI:
http://www.enst.fr/~casellas/mpls-linux-2.6/spec/spec.pdf
http://www.enst.fr/~casellas/mpls-linux-2.6/spec/index.html

Work in progress. Things to fix.

Regards,
Ramon


w.r.t Downstream on demand:

I *do* think it's valuable and we *must* support it (e.g RSVP-TE). If I
cannot use RSVP-TE to setup LSPs in Linux I'm going back right now to
James implementation ;-)

RCAS: I think we are confusing label distribution modes with
implementation details. RSVP-TE uses downstream on demand as a label
distribution mode, and it could be implemented as a two step process where
a dummy NHLFE is created during the RSVP_PATH message so the ILM may point
to it and then replaced by the right one upon reception of the RSVP_RESV.
What we do not support is sending orphan packets to userspace, and that
when an entry is added in the ILM or FTN there must be an exisiting
NHLFEid. I'm not saying that we need to match the exact words of the RFC,
but we can (and must) support downstream on demand.




On 14 Feb 2004, Jamal Hadi Salim wrote:

> As i said before this is NOT my implementation. I tried to document and
> sanitize what it does - mostly so we can  have a useful discussion. My

right, sorry. It's DaveM's implementation.



> him, if theres a > 20% improvement we have more strength);-> I wanna see
> MPLS in 2.6 soon and i think this is the fastest way to get there.

Well, me too :) but I'd rather see it in 2.6 when it's ready. Most
probably you're right and it is....



> For example for something like the ILM, where lookup is based on a 12
> bit label, then i would think making it anything more than a hash and
(...)
> make it 256 buckets and suddenly you are looking at 16 worst case.

Where do you get this numbers ? :)
I thought the label was 20 bits, and
with 256 buckets (2**8) you have 2**12 = 4096 worst case.
even with 1024 buckets you get 1024 worst case.

am I missing something? Are these values acceptable? In that case 4ill
shut up :)





> So evaluate for each table what needs to be done then make a call.

You are right. A choice should be made with performance numbers around.




R.