[frr] 2 MPLS Questions

[Thomas Morin]

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> 
> 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).

>>
>> 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/tree/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 
>> <mailto: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 <mailto: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 <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>
>>
>>
>> _______________________________________________
>> frr mailing list
>> frr at lists.nox.tf <mailto:frr%40lists.nox.tf>
>> https://lists.nox.tf/listinfo/frr


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