[frr] 2 MPLS Questions

[Amine Kherbouche]

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.


Regards,
Amine

On 23 March 2017 at 17:47, David Ahern <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20170323/576ddb95/attachment.html>