Hello Jeff Up to know, I start coding the Node MSD as for me, Link MSD as nosense. But, I could add the corresponding TLV/Sub-TLV for decoding purpose when receiving such information. Now, regarding the value of Node MSD, I will do 2 things: 1/ fulfil the default MSD at compilation time by fixing the default MSD value with the kernel value. 2/ give the possibility to modify the MSD value with dedicated new CLI command, but by checking that the administrative value is not greater than the default MSD value provided at compilation time. Unfortunately, if the kernel is recompile with a different value or if the kernel on which FRR is running as a different value compared to the one where the compilation has been done, we manage a wrong value. It is why I add the possibility to modify it through CLI. For a more dynamic MSD assignment, we must look at the running kernel. But again, kernel header are not necessary install on the host where FRR is running. So, even if it is a technical solution, it is not sure that we could collect the MSD value. For me, the best is the possibility to collect the MSD value via the /proc or /sys file system. But, this need some modification in the linux kernel module to fulfil this value. Another possibility, is through IOCTL, but again this imply some extra coding in the MPLS Module. And, this cover only Linux Kernel. I don't know for *BSD. Regards Olivier Le 04/07/2017 à 01:50, Jeff Tantsura a écrit :
Hi Olivier,
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?
Cheers, Jeff
On Jul 3, 2017, at 06:13, olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com> wrote:
Hello,
This limit must not be avoided. But, fix looking up to whatthe 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.
Regards
Olivier
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) 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
_______________________________________________ dev mailing list dev@lists.frrouting.org 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@lists.frrouting.org <mailto:dev@lists.frrouting.org> 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.