[mpls-linux-devel] Jamal's kernel patch

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

Jamal,

I am still in the middle of understanding your patch. One of the things
that worries me (most probably due to my lack of understanding) is that it
seems quite intrusive w.r.t other parts of the stack. IMVHO, I often
consider strong coupling not_a_so_good_thing, and I defend duplicating
some parts of code in the sake of clarity and modularity. So some
ideas/questions:

* I appreciated your effort with the design document. I am a paranoid guy
regarding documentation (that's why I wrote down the devel guide on James'
implementation). A design document stating the required changes of core
parts for MPLS support and the reasons would be much welcome, and it would
allow further discussion (you stated in a previous mail, that this time,
as a premiere in Linux, you wanted to do things right :)) . Do you plan to
write something about that?  I know it is the most ungrateful part..

* In this sense, to truly modularize the MPLS implementation, I think it
would be appropriate to make things in such a way that the user could be
able to select "Core MPLS support" and "Full MPLS Support" (or something
like that) when configuring the kernel. Core LSRs would only be able to
forward mpls labelled packets without knowledge of L3 protocols (think of
a BGP/MPLS VPN 'P' router that is used to forward L3 and L2 frames) and
only a minimal set modifications to IPv4/IPv6 would be compiled in (in
other words, the FIB Table need only be extended in the second case). Is
this level of granularity common practice in the Linux kernel?

* It's just a simple question, take no offense :) but do you consider the
patch you sent quite "feature freeze" and "written in stone" or are you
willing to open development and allow changes *iff* common consensus
justifies it? I think this is an important point for us.


Thoughts?

R.