[frr] 2 MPLS Questions

Jeff Tantsura jefftant at gmail.com
Mon Mar 20 15:26:45 EDT 2017


Hey Thomas,

please see inline

Cheers,
Jeff


> On Mar 20, 2017, at 09:38, 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> <mailto: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).
[jeff] to better phrase - no router, beside the one allocating service labels could lookup/touch them, this is true for PHP or any other case. In PHP case, after most outer label has been looked up and a fully resolved adj provided, the rest of the label stack MUST not be looked up (payload)
In SR case, after Adj-SID has been POPed, the packed must be sent out of the interface associated with the Adj, with no any additional processing
> 
>>> 
>>> 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 ?
[jeff] would’t this be a tad inefficient? :) 
> 
> -Thomas
> 
> [1] http://git.openstack.org/cgit/openstack/networking-bagpipe/tree/networking_bagpipe/bagpipe_bgp/vpn/ipvpn/mpls_linux_dataplane.py#n194 <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 <https://lists.nox.tf/listinfo/frr>
> 

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


More information about the dev mailing list