[frr] 2 MPLS Questions

Jeff Tantsura jefftant at gmail.com
Tue Mar 21 06:01:13 EDT 2017


Thanks Thomas, 

Before we write code, let’s agree on architecture, there are always tradeoffs, pros/cons analysis on such an important topic would be in place

Could someone please update me wrt SRv6 (SRH) - what’s supported/what’s planned?

Thanks!

Cheers,
Jeff


> On Mar 21, 2017, at 02:47, Thomas Morin <thomas.morin at orange.com> wrote:
> 
> Hi Jeff,
> 
> 2017-03-20, Jeff Tantsura:
>> 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? :) 
> 
> Well, I was not implying that the above would be efficient, and I would actually have the same concern as you have.
> But to be honest I also lack hard facts to back this concern: e.g. I don't know whether going through a vrf interface is a small or high cost.
> 
> Best,
> 
> -Thomas
> 
> 
> 
> 
>>> 
>>>>> 
>>>>> 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/20170321/960987da/attachment.html>


More information about the dev mailing list