[dev] [frr] 2 MPLS Questions

Lou Berger lberger at labn.net
Mon Apr 3 20:36:29 EDT 2017


It'll pass whatever label is passed on registration.  I can send an example...

Lou


On March 27, 2017 4:32:04 PM Marc Sune <marc at voltanet.io> wrote:

> Hi all,
>
> Kind of an aside question about MPLS implementation in FRR;
>
> On Mon, Mar 20, 2017 at 5:38 PM, Thomas Morin <thomas.morin at orange.com>
> wrote:
>
>> Hi everyone,
>>
>> 2017-03-18, Vincent Jardin:
>>
>> +Thomas to be on track.
>>
>>
>> Vincent, you'll tell if what is below helped or not :)
>>
>> Le 18 mars 2017 06:19:47 Vivek Venkatraman <vivek at cumulusnetworks.com>
>> <vivek at cumulusnetworks.com> a écrit :
>>
>>> This is correct. By definition, if a router is the penultimate hop, it
>>> means the actual egress is downstream and has signaled (advertised) an
>>> implicit-null label to this router. The router doing the PHP knows the next
>>> hop to forward to (the egress) without doing any additional lookup.
>>>
>>
>> (Note that with BGP/MPLS VPNs this is the typical behavior, but it is not
>> a mandatory behavior: the egress router may have advertise a real label
>> (i.e. not implicit null) in which case the penultimate router will swap the
>> topmost label of the stack, not seeing/touching the vpn label. This is also
>> a behavior that relates to the use of MPLS for transit, but with
>> MPLS-over-GRE or MPLS-over-UDP, MPLS can be used with IP transit, in which
>> case this behavior is not used).
>>
>
> In regular MPLS processing (no SR), does FRR currently support advertising
> any label other than implicit NULL for MPLS traffic termination(itself)?
> And for L2VPNs?
>
> thanks
> Marc
>
>
>>
>>
>>
>>> This behavior should already be supported.
>>>
>>
>> Yes, I can confirm that forwarding via a neighbor on an interface based on
>> the incoming MPLS label is supported.
>> This is what we use in bagpipe IP VPN 'linux' driver [1].
>>
>>
>>> What is not supported (if I remember right) is the ability on the egress
>>> to terminate a label and perform a (route) lookup.  That is needed to
>>> really be able to support any L2/L3 VPN service properly.
>>>
>>
>> I think it is a requirement to have something efficient to trigger a
>> lookup in any {routing table, vrf interface, netns}.
>>
>> I hadn't tried (because no need). I thought we might achieve something
>> like that by forwarding the packet on 'lo', or on a vrf interface, or on a
>> veth device: wouldn't this kind of next hop specification trigger a
>> re-enter of the packet in the IP stack after the pop operation ?
>>
>> -Thomas
>>
>> [1] http://git.openstack.org/cgit/openstack/networking-bagpipe/t
>> ree/networking_bagpipe/bagpipe_bgp/vpn/ipvpn/mpls_linux_dataplane.py#n194
>>
>>
>>
>>
>>
>>> On Thu, Mar 16, 2017 at 10:45 AM, Jeff Tantsura <jefftant at gmail.com>
>>> wrote:
>>>
>>>> Donald,
>>>>
>>>> Wrt PHP, this is incorrect, PHP node MUST not perform IP lookup, or in
>>>> fact any lookup after POP. In most cases (labeled services, L2/L3 VPN)
>>>> there's another label(s) in the stack, looking it up would be fatal.
>>>>
>>>> Regards,
>>>> Jeff
>>>>
>>>> > On Mar 15, 2017, at 08:05, Donald Sharp <sharpd at cumulusnetworks.com>
>>>> wrote:
>>>> >
>>>> > David/Roopa -
>>>> >
>>>> > Olivier asked me about these two issues yesterday in the FRR Technical
>>>> > Meeting.  I just wanted to make sure I didn't loose track of these
>>>> > questions that he had:
>>>> >
>>>> > 1) More than 2 labels in the kernel at a time, when will this be
>>>> > allowed in the kernel?
>>>> >
>>>> >   -> David is currently working on this issue.  When he is done it
>>>> > will be upstreamed.  So soonish(tm).
>>>> >
>>>> > 2) PenUltimate Hop Popping:
>>>> >
>>>> > I know this issue is not trivial to solve. In fact, once the POP
>>>> > instruction perform, the packet must re-enter in the IP packet
>>>> > processing to determine what action must apply. A possible solution
>>>> > would be to process this packet as a new incoming IP packet when
>>>> > output interface is the loopback disregarding the IP address value.
>>>> > But, this issue is less urgent than the first one. Our OSPF Segment
>>>> > Routing implementation could announce if the router works in
>>>> > PenUltimate Hop Poping mode or not. So, for the moment, the option is
>>>> > force to yes.
>>>> >
>>>> > thanks!
>>>> >
>>>> > donald
>>>> >
>>>> > _______________________________________________
>>>> > frr mailing list
>>>> > 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
>>>>
>>>
>>> _______________________________________________
>>> frr mailing list
>>> 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
>>
>>
>
>
>
> ----------
> _______________________________________________
> frr mailing list
> frr at lists.nox.tf
> https://lists.nox.tf/listinfo/frr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20170403/526e5fbf/attachment.html>


More information about the dev mailing list