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

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

On Fri, 2004-02-13 at 17:22, Ramon Casellas wrote:
> 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:

There are certain things that you cant avoid.
Example you will have ifdefs in the v6 and v4 for FTN support.
The less ifdefs the better.
I think once you start attaching IPSEC to MPLS, same thing will happen.

There are things which are v4 and v6 specific that are totaly
abstracted out but dependent on those protocols - example neighbor
binding. But this is really clean right now.  look at the
mpls_prot_driver code.
I think this code is as decoupled as you can go but i may have missed
your point.

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

I am capable of writing good doc with proper motivation. I dont have it
right now but you could do that ;->
If you want you can take over the spec doc.
I will try to clarify things when i can.

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

Are you refering to being able to compile out FTN support?
I think this is doable; you just need to introduce a config
probably one for each of v4 or 6.

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

Consensus is key between us at least. caveat: What i would like though
is to avoid having to stress Dave when theres no clear win in some
change to be made. I would like to make it easy for him to accept 
things - so lets discuss changes first like the dst changes then have
some good reasons before we talk to him.

cheers,
jamal