[frr] 2 MPLS Questions

olivier.dugeon at orange.com olivier.dugeon at orange.com
Thu Mar 23 13:59:14 EDT 2017


Jeff,

We don't yet conduct performance impact because we are considering it as negligible.

Indeed, a label is 4 bytes. 16 labels = 64 bytes, so equivalent to a IP + TCP header,  or an IPv6 header, so comparable to what's the Kernel do when it uses Ipv4 into IPv6 GRE tunnel or VxLan encapsulation or equivalent encapsulation. And 16 labels is the maximum necessary to express 100,00% of routes disregarding the network topologies we tested.

In addition, this encapsulation is done at the Edge. Then, only PoP of top of stack is performed by subsequent router independently of the size of label stack.

IMHO, the impact is on the total size of the packet. The overhead introduced by the stack of labels will reduce the goodput of the connexion, but not much more than other kind of encapsulation.

Regards

Olivier


Le 23/03/2017 à 18:32, Jeff Tantsura a écrit :
> 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 <mailto:olivier.dugeon at orange.com>> <olivier.dugeon at orange.com <mailto: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
>>>> >> >>>>
>>>> >> >
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Amine
>>>> >
>>>> >
>>>> >
>>>> > ----------
>>>> > _______________________________________________
>>>> > frr mailing list
>>>> > frr at lists.nox.tf <mailto:frr at lists.nox.tf>
>>>> > https://lists.nox.tf/listinfo/frr
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> frr mailing list
>>> frr at lists.nox.tf
>>> 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.
>


_________________________________________________________________________________________________________________________

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/db64dfdd/attachment.html>


More information about the dev mailing list