[frr] 2 MPLS Questions

Jeff Tantsura jefftant at gmail.com
Thu Mar 23 13:32:43 EDT 2017


Haha :)

On a serious note - what are the implications of increasing labels stack (latency/throughput/etc)?
Where is the sweet spot?

Cheers,
Jeff


> On Mar 23, 2017, at 10:28, <olivier.dugeon at orange.com> <olivier.dugeon at orange.com> wrote:
> 
> grep '#define MAX_NEW_LABELS' internal.h | awk -e '{print $3}'
> 
> But I'm not sure it answers your question ;-)
> Olivier
> 
> Le 23/03/2017 à 18:21, Jeff Tantsura a écrit :
>> while on topic, can I please get an API to query data plane for MSD supported?
>> Use case: draft-ietf-isis-segment-routing-msd/ draft-ietf-ospf-segment-routing-msd/ draft-tantsura-idr-bgp-ls-segment-routing-msd
>> 
>> Many thanks!
>> 
>> Cheers,
>> Jeff
>> 
>> 
>>> On Mar 23, 2017, at 10:07, Vincent Jardin <vincent.jardin at 6wind.com <mailto:vincent.jardin at 6wind.com>> wrote:
>>> 
>>> +Jeff
>>> 
>>> 
>>> Le 23 mars 2017 5:59:21 PM Amine Kherbouche <amine.kherbouche at 6wind.com <mailto:amine.kherbouche at 6wind.com>> a écrit :
>>> 
>>> > Hi David,
>>> >
>>> > I think that 8 stacked labels are more than enough, I cannot imagine a core
>>> > network with 8 stacked MPLS-VPNs.
>>> > Let's see the others if they share my opinions.
>>> 
>>> 
>>> I think too that 8 is a good upper limit.
>>> 
>>> 
>>> >
>>> >
>>> > Regards,
>>> > Amine
>>> >
>>> > On 23 March 2017 at 17:47, David Ahern <dsa at cumulusnetworks.com <mailto:dsa at cumulusnetworks.com>> wrote:
>>> >
>>> >> I have the MPLS code changes to bump the number of labels. What did we
>>> >> want to use for the max? 12? 16?
>>> >>
>>> >> This limit is really only capping what we take from userspace. Kernel
>>> >> side memory allocations are done based on the actual number of labels in
>>> >> the route.
>>> >>
>>> >>
>>> >> On 3/16/17 10:49 AM, Olivier Dugeon wrote:
>>> >> > Hi David,
>>> >> >
>>> >> > Well, frankly speaking, I don't see where is the problem regarding the
>>> >> > performance.
>>> >> >
>>> >> > IMHO, the patch add an extra size of the array i.e. from 8 bytes (2
>>> >> > labels) to 64 bytes (16 labels) which is completely negligible compared
>>> >> > to the size of a IP packet, and of same magnitude order as a VxLan
>>> >> > encapsulation and twice less as an IPv6 header.
>>> >> >
>>> >> > In addition, only the edge router as to push the label stack. Then,
>>> >> > subsequent router just look at the top label. So, no more no less that a
>>> >> > packet with only 2 labels in the stack.
>>> >> >
>>> >> > I think that dealing with a dynamic MPLS STACK DEPTH i.e. dynamic memory
>>> >> > allocation of space regarding the number of labels are push in from of
>>> >> > the IP packet will certainly add more overhead and more CPU cycles
>>> >> > rather than just manage a fix amount of byte in an array.
>>> >> >
>>> >> > Finally, the default value for the MPLS_LABEL_STACK could be equal to 2
>>> >> > and let peoples want to deal with Segment Routing recompile the kernel
>>> >> > with a larger value.
>>> >> >
>>> >> > From my side, your patch will not only increase the label stack, it also
>>> >> > re-arrange the MPLS structure in order to solve the problem of corrupted
>>> >> > third label. And, this is the more important things.
>>> >> >
>>> >> > In any case, let me know what I can do to help you.
>>> >> >
>>> >> > Regards
>>> >> >
>>> >> > Olivier
>>> >> >
>>> >> >
>>> >> > Le 16/03/2017 à 16:10, David Ahern a écrit :
>>> >> >> I made the kernel patch to help you move along with your MPLS work.
>>> >> >>
>>> >> >> In the kernel thread discussing the increase in number of labels Eric
>>> >> >> Biederman mentions performance concerns about just increasing the size
>>> >> >> of the array; he wanted a much more complicated change and I have not
>>> >> >> gotten around to it.
>>> >> >>
>>> >> >>
>>> >> >> On 3/16/17 3:31 AM, Olivier Dugeon wrote:
>>> >> >>> Hi all,
>>> >> >>>
>>> >> >>> The problem is not between the kernel and iproute2. The problem comes
>>> >> >>> when stacking more than 2 labels: the LSB byte of the third label is
>>> >> >>> replaced by 0x03 value i.e. the implicit Null Label value. See attached
>>> >> >>> thread.
>>> >> >>>
>>> >> >>> Following this, David propose a new patch that we integrated and tested
>>> >> >>> successfully (See second and third attached mail).
>>> >> >>>
>>> >> >>> But, after that, I got no news and never seen this patch merge into the
>>> >> >>> Linux Kernel release. So, we just ask when this patch could be merge
>>> >> >>> into the Linux Kernel.
>>> >> >>>
>>> >> >>> For the second problem about PHP, it is also described in the first
>>> >> >>> attached thread. But, agree, that this issue is more tricking to solve.
>>> >> >>>
>>> >> >>> Regards,
>>> >> >>>
>>> >> >>> Olivier
>>> >> >>>
>>> >> >>>
>>> >> >>> Le 15/03/2017 à 16:59, David Ahern a écrit :
>>> >> >>>> On 3/15/17 9:57 AM, Amine Kherbouche wrote:
>>> >> >>>>>     > 1) More than 2 labels in the kernel at a time, when will this
>>> >> be
>>> >> >>>>>     > allowed in the kernel?
>>> >> >>>>>     >
>>> >> >>>>>
>>> >> >>>>> I don't understand why iproute2 and kernel are not sync when it
>>> >> comes to
>>> >> >>>>> the max stacked labels, iproute2 should export kernel headers.
>>> >> >>>>>
>>> >> >>>> https://marc.info/?l=linux-netdev&m=146913202123729&w=2 <https://marc.info/?l=linux-netdev&m=146913202123729&w=2>
>>> >> >>>>
>>> >> >
>>> >>
>>> >
>>> >
>>> >
>>> > -- 
>>> > Amine
>>> >
>>> >
>>> >
>>> > ----------
>>> > _______________________________________________
>>> > frr mailing list
>>> > frr at lists.nox.tf <mailto:frr at lists.nox.tf>
>>> > https://lists.nox.tf/listinfo/frr <https://lists.nox.tf/listinfo/frr>
>> 
>> 
>> 
>> _______________________________________________
>> frr mailing list
>> frr at lists.nox.tf <mailto:frr at lists.nox.tf>
>> https://lists.nox.tf/listinfo/frr <https://lists.nox.tf/listinfo/frr>
> 
> _________________________________________________________________________________________________________________________
> 
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20170323/9c92d9b2/attachment.html>


More information about the dev mailing list