Message-ID: <87bnk7bjby.fsf@x220.int.ebiederm.org>
Date:	Thu, 05 Mar 2015 08:38:25 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Vivek Venkatraman <vivek@...ulusnetworks.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	roopa <roopa@...ulusnetworks.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	santiago@...reenet.org, Simon Horman <horms@...ge.net.au>
Subject: Re: [PATCH net-next 3/7] mpls: Add a sysctl to control the size of the mpls label table

ebiederm@...ssion.com (Eric W. Biederman) writes:

> Vivek Venkatraman <vivek@...ulusnetworks.com> writes:
>
>> On Tue, Mar 3, 2015 at 5:11 PM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>>>
>>> This sysctl gives two benefits.  By defaulting the table size to 0
>>> mpls even when compiled in and enabled defaults to not forwarding
>>> any packets.  This prevents unpleasant surprises for users.
>>>
>>> The other benefit is that as mpls labels are allocated locally a dense
>>> table a small dense label table may be used which saves memory and
>>> is extremely simple and efficient to implement.
>>>
>>
>> The label space is often partitioned into multiple sets in MPLS and
>> used for different purposes - for example, LSP labels, VPN labels,
>> Segment labels. This in turn means that the table may no longer be
>> dense. A sysctl allowing min and max label that spans the sets of
>> labels may be useful. Or should the ILM be made a hash table?
>
> Good question.
>
> These kinds of labels are a local label management problem.
>
> Given how nice it is to have a reasonably dense label space I am not
> keen to abandon the notion of having a dense label space, as it makes
> the code simple and fast for forwarding mpls packets.
>
> That said my code is a starting point.  If you have a real world use
> case and you can show a better way to deal with it.  Go for it.
> Now is definitely time to evolve the API.

A couple more thoughts.  

The rtnetlink interface and my implementation carries a type field so it
is possible to mark which routing protocol uses an mpls route.

The global routing table is already over 500,000 routes so the 1 million
forward equivalanece classes of mpls with a single label may be
exhausted in the not too distant future so a dense label space may be a
necessity.

In a similar vein.  When I look at top of rack switches and their
hardware forwarding capacity it looks like they are in the ballpark
of 32K MPLS routes.

All of which says to me that the MPLS label space is limited and it
should be managed as a precious resource.  (A good example of why I
might want to rethink my mpls ingress path).

So while I can see arguments for one use of labels getting one quota of
labels and another use of labels getting another quota when I look at
the space there are not that many labels and I don't see how or why it
would make sense to manage the labels explicitly with ranges.

At some point for MPLS multicast traffic and MPLS source specific
addresses if we choose to support those we will need a hash table
as those addresses are assigned by others, though in that case
we will be limited in our egress set of labels we can use.

So I think MPLS interfaces need to encourage thrifty label use,
which in my mind almost certainly means not manually allocated
label use.

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

Powered by blists - more mailing lists