From: ebiederm@xmission.com (Eric W. Biederman)
To: Magnus Bergroth <bergroth@nordu.net>
Cc: Roopa Prabhu <roopa@cumulusnetworks.com>,
netdev@vger.kernel.org, Robert Shearman <rshearma@brocade.com>
Subject: Re: iproute2 mpls max labels
Date: Fri, 22 Jul 2016 14:24:08 -0500 [thread overview]
Message-ID: <878twtv5lz.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <579139C2.1050804@nordu.net> (Magnus Bergroth's message of "Thu, 21 Jul 2016 23:08:18 +0200")
Magnus Bergroth <bergroth@nordu.net> writes:
>> Eric W. Biederman <mailto:ebiederm@xmission.com>
>> a) I just looked and the kernel netlink protocol does not have a limit.
>> The kernel does have a limit but the netlink protocol does not so
>> there is no point in exporting a limit in a uapi header, it will
>> just be out of date and wrong.
>>
>> b) I can see in principle bumping up the kernels MAX_LABELS past two
>> although I haven't heard those requests, or understand the use cases.
>> I don't recall seeing any ducumentation on cases where it is
>> desirable to push a lot of labels at once. (Do hardware
>> implementations support pushing a lot of labels at once?)
>>
>> Bumping past 8 seems quite a lot. That starts feeling like people
>> trying to break other peoples mpls stacks. That is asking for more
>> packet space for labels than ipv6 uses for addresses and ipv6 is way
>> oversized. The commonly agreed wisdom is the world only needs 40 to
>> 48 bits to route on to reach the entire world.
> I think that 8 would be more than enough for most use cases, even 6 or 4
> would be sufficient. I'm looking at doing MPLS source routing based on a
> label-stack. Each router in the network will get a set of static routes
> that pop the label and sends it out to the next router based on the
> label that gets poped. I have no problem compiling a special build with
> the MAX_LABELS set to my need. I just noticed that changing only the
> MAX_LABELS wasn't enough to get more than 8 labels to work with iproute2
> after changing the kernel "MAX_NEW_LABELS 2" in
> include/net/mpls_iptunnel.h and net/mpls/internal.h to a higher
> number.
At a practical level in general it doesn't make sense to support special
builds. The code rarely get tested and so bit rots. In a situation
like this it makes sense to dig in and solve the problem as generally as
you can as long as it doesn't cause problems for anything else.
Eric
next prev parent reply other threads:[~2016-07-22 19:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-16 18:24 iproute2 mpls max labels Magnus Bergroth
2016-07-21 18:53 ` Roopa Prabhu
2016-07-21 19:43 ` Magnus Bergroth
2016-07-23 23:04 ` Roopa Prabhu
2016-07-21 20:00 ` Eric W. Biederman
2016-07-21 21:08 ` Magnus Bergroth
2016-07-22 19:24 ` Eric W. Biederman [this message]
2016-07-22 6:16 ` Roopa Prabhu
2016-07-22 19:20 ` Eric W. Biederman
2016-07-23 23:03 ` Roopa Prabhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878twtv5lz.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=bergroth@nordu.net \
--cc=netdev@vger.kernel.org \
--cc=roopa@cumulusnetworks.com \
--cc=rshearma@brocade.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.