netdev - Re: MPLS for Linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20111122.164909.156852889818363753.davem@davemloft.net>
Date:	Tue, 22 Nov 2011 16:49:09 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	igorm@....rs
Cc:	netdev@...r.kernel.org
Subject: Re: MPLS for Linux kernel

From: Igor Maravić <igorm@....rs>
Date: Tue, 22 Nov 2011 22:41:44 +0100

> I would like to know what is necesary for MPLS implementation to have,
> and to do, so it would be accepted in upstream kernel?

A long and laborious back and forth review process, taking into consideration
not just the technical details of the patches themselves, but the top level
and overall design.

That's what it will take.

Taking someone else's work, fixing all the bugs and cleaning them up is
far from sufficient for a feature of this nature.  There is natural
overlap all over and we have to make sure the implementation bits are
going into the right places.

One issue of constant contention is that people want to add all of their
favorite packet filtering and packet mangling into their protocol handling
code, with all kinds of custom controls and configuration mechanisms.

WE HATE THIS.

We have the packet scheduler classifiers and packet actions for a reason,
and we want them to used instead of ignored.

We are going through the same thing in the review process for the openvswitch
code, which brings up another design question for MPLS, which is whether MPLS
can be better implemented in terms of openvswitch.

You're in the unfortunate position of submitting a feature that has a
lot of overlap with many other subsystems, existing code, and features
being submitted at the same time.  We want as much reuse as possible,
and we want it all designed right before it gets integrated.

I frankly don't care very much about MPLS personally, it's such a
fringe facility.  So if people just argue themselves into oblivion and
no forward progress is made, just like last time an MPLS submission
was attempted, that's also fine with me :-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html