[dev] Increase the number of MPLS tags in zebra
jefftant at gmail.com
Mon Jul 3 19:50:17 EDT 2017
I’m the author of MSD drafts, let me know if I can help.
Drafts are stable and will go to WGLC after Prague (IETF99),
My thinking - to keep it simple, only Base MSD has been defined and pre-allocated by IANA, all other types will be defined in another documents.
In most cases, MSD is limited by the underlying HW, obviously SW has to support larger stack too.
I have discussed an API that could be used to derive MSD value (could be more than 1 by using new MSD type) by querying it with BCM and Barefoot, both agreed on the need to do so.
As I said before - there’s no free lunch in fast path universe, there’s a price to pay in latency, reduced throughput, number of additional features, etc
Sane limits are healthy and protect a system from abuse.
From implementation prospective - extensions to OSPF/ISIS/BGP-LS are needed to signal MSD, while on x86 platform link MSD doesn’t make much sense, please do implement it for the completeness.
HW MSD, when available thru an API call should become the node/link MSD, otherwise should be configured under “routing protocol/interface” stanza.
Have you looked into entropy labels yet?
> On Jul 3, 2017, at 06:13, olivier.dugeon at orange.com wrote:
> This limit must not be avoided. But, fix looking up to what the kernel support.
> In addition, for Segment Routing, there is a new draft (draft-ietf-ospf-segment-routing-msd-05.txt) that could be used to advertise the Maximum Stack Depth. It is on my TODO list for OSPF Segment Routing support in FRR.
> Le 03/07/2017 à 14:37, Алексей Болдырев a écrit :
>> By the way, kernel 4.12 is already available: (https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.12.tar.xz <https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.12.tar.xz>)
>> In this kernel, according to the developers, the number of MPLS tags on the stack is 30.
>> Therefore, I suggest that this limit in Zebra should be avoided.
>> https://github.com/FRRouting/frr/issues/776 <https://github.com/FRRouting/frr/issues/776>
>> dev mailing list
>> dev at lists.frrouting.org <mailto:dev at lists.frrouting.org>
>> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> dev mailing list
> dev at lists.frrouting.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev