[frr] 2 MPLS Questions

Vivek Venkatraman vivek at cumulusnetworks.com
Sat Mar 18 13:50:07 EDT 2017


Yes, the pop and forward to next hop satisfies many of the common cases.
However, the pop+lookup in VRF would be needed to reach the PE itself, when
the PE is aggregating customer routes which are across next hops etc., plus
the cases you mention. I'd like the kernel to incorporate support for it,
but agree that the lack of it doesn't significantly limit usability.

On Sat, Mar 18, 2017 at 3:27 AM, Jeff Tantsura <jefftant at gmail.com> wrote:

> That's only needed with label per VRF mode, and if I recall correctly in
> currently supported/discussed label per prefix mode where POP is followed
> by IP lookup in VRF context. IMHO - would be really bad (why repeat bad
> early IOS choices?)
> The most optimal case for FRR would be label per NH allocation, where
> label lookup should yield fully resolved adj, withno need for additional
> lookup.
> It would also support the case with >1 NH's in a VRF (multihoming).
>
> There are some corner cases, like EIBGP LB + BGP FRR, however we are
> rather far away from that point in life...
>
> Regards,
> Jeff
>
> > On Mar 18, 2017, at 00:27, Roopa Prabhu <roopa at cumulusnetworks.com>
> wrote:
> >
> >> On 3/17/17, 10:19 PM, Vivek Venkatraman wrote:
> >> 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.
> >>
> >> This behavior should already be supported.
> >>
> >> 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.
> >
> > yes, correct. terminating a label and performing a route lookup is not
> supported
> > today.
> >
> >
> >>
> >>> 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
> >>>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20170318/928a68d1/attachment.html>


More information about the dev mailing list