<html>
<head>
</head>
<body>
<div style="color: black;">
<div style="color: black;">
<p style="margin: 0 0 1em 0; color: black;">It'll pass whatever label is
passed on registration.  I can send an example...</p>
<p style="margin: 0 0 1em 0; color: black;">Lou</p>
</div>
<div style="color: black;">
<p
style="color: black; font-size: 10pt; font-family: Arial, sans-serif; margin: 10pt 0;">On
March 27, 2017 4:32:04 PM Marc Sune <marc@voltanet.io> wrote:</p>
<blockquote type="cite" class="gmail_quote"
style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;">
<div dir="ltr">Hi all,<div><br></div><div>Kind of an aside question about
MPLS implementation in FRR;</div><div class="gmail_extra"><br><div
class="gmail_quote">On Mon, Mar 20, 2017 at 5:38 PM, Thomas Morin <span
dir="ltr"><<a href="mailto:thomas.morin@orange.com"
target="_blank">thomas.morin@orange.com</a>></span>
wrote:<br><blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div
class="m_-8542252114825369793m_2978769784644366954moz-cite-prefix">Hi
everyone,<br>
      <br>
      2017-03-18, Vincent Jardin:<br>
    </div><span>
    <blockquote type="cite">
      
      <div style="color:black">
        <div style="color:black">
          <p style="margin:0 0 1em 0;color:black">+Thomas to be on
            track.</p>
        </div>
      </div>
    </blockquote>
    <br></span>
    Vincent, you'll tell if what is below helped or not :)<span><br>
    <br>
    <blockquote type="cite">
      <div style="color:black">
        <div style="color:black">
        </div>
        <div style="color:black">
          <p
style="color:black;font-size:10pt;font-family:Arial,sans-serif;margin:10pt 0">
            Le 18 mars 2017 06:19:47 Vivek Venkatraman
            <a
class="m_-8542252114825369793m_2978769784644366954moz-txt-link-rfc2396E"
href="mailto:vivek@cumulusnetworks.com"
target="_blank"><vivek@cumulusnetworks.com></a> a écrit :</p>
          <blockquote type="cite" class="gmail_quote"
style="margin:0 0 0 0.75ex;border-left:1px solid #808080;padding-left:0.75ex">
            <div dir="ltr">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.
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br></span>
    (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).</div></blockquote><div><br></div><div>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?</div><div><br></div><div>thanks</div><div>Marc</div><div> </div><blockquote
class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
bgcolor="#FFFFFF" text="#000000"><span><br>
    <br>
    <blockquote type="cite">
      <div style="color:black">
        <div style="color:black">
          <blockquote type="cite" class="gmail_quote"
style="margin:0 0 0 0.75ex;border-left:1px solid #808080;padding-left:0.75ex">
            <div dir="ltr">
              <div><br>
              </div>
              <div>This behavior should already be supported.</div>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes, I can confirm that forwarding via a neighbor on an interface
    based on the incoming MPLS label is supported.<br>
    This is what we use in bagpipe IP VPN 'linux' driver [1].<span><br>
    <br>
    <blockquote type="cite">
      <div style="color:black">
        <div style="color:black">
          <blockquote type="cite" class="gmail_quote"
style="margin:0 0 0 0.75ex;border-left:1px solid #808080;padding-left:0.75ex">
            <div dir="ltr">
              <div><br>
              </div>
              <div>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.</div>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br></span>
    I think it is a requirement to have something efficient to trigger a
    lookup in any {routing table, vrf interface, netns}.<br>
    <br>
    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 ?<br>
    <br>
    -Thomas<br>
    <br>
    [1]
<a class="m_-8542252114825369793m_2978769784644366954moz-txt-link-freetext"
href="http://git.openstack.org/cgit/openstack/networking-bagpipe/tree/networking_bagpipe/bagpipe_bgp/vpn/ipvpn/mpls_linux_dataplane.py#n194"
target="_blank">http://git.openstack.org/cgit/<wbr>openstack/networking-bagpipe/t<wbr>ree/networking_bagpipe/bagpipe<wbr>_bgp/vpn/ipvpn/mpls_linux_<wbr>dataplane.py#n194</a><div><div
class="m_-8542252114825369793h5"><br>
    <br>
    <br>
    <br>
    <blockquote type="cite">
      <div style="color:black">
        <div style="color:black">
          <blockquote type="cite" class="gmail_quote"
style="margin:0 0 0 0.75ex;border-left:1px solid #808080;padding-left:0.75ex">
            <div dir="ltr">
            </div>
            <div class="gmail_extra"><br>
              <div class="gmail_quote">On Thu, Mar 16, 2017 at 10:45 AM,
                Jeff Tantsura <span dir="ltr">
                  <<a href="mailto:jefftant@gmail.com"
target="_blank">jefftant@gmail.com</a>></span>
                wrote:<br>
                <blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  Donald,<br>
                  <br>
                  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.<br>
                  <br>
                  Regards,<br>
                  Jeff<br>
                  <br>
                  > On Mar 15, 2017, at 08:05, Donald Sharp <<a
href="mailto:sharpd@cumulusnetworks.com"
target="_blank">sharpd@cumulusnetworks.com</a>>
                  wrote:<br>
                  ><br>
                  > David/Roopa -<br>
                  ><br>
                  > Olivier asked me about these two issues yesterday
                  in the FRR Technical<br>
                  > Meeting.  I just wanted to make sure I didn't
                  loose track of these<br>
                  > questions that he had:<br>
                  ><br>
                  > 1) More than 2 labels in the kernel at a time,
                  when will this be<br>
                  > allowed in the kernel?<br>
                  ><br>
                  >   -> David is currently working on this
                  issue.  When he is done it<br>
                  > will be upstreamed.  So soonish(tm).<br>
                  ><br>
                  > 2) PenUltimate Hop Popping:<br>
                  ><br>
                  > I know this issue is not trivial to solve. In
                  fact, once the POP<br>
                  > instruction perform, the packet must re-enter in
                  the IP packet<br>
                  > processing to determine what action must apply. A
                  possible solution<br>
                  > would be to process this packet as a new incoming
                  IP packet when<br>
                  > output interface is the loopback disregarding the
                  IP address value.<br>
                  > But, this issue is less urgent than the first
                  one. Our OSPF Segment<br>
                  > Routing implementation could announce if the
                  router works in<br>
                  > PenUltimate Hop Poping mode or not. So, for the
                  moment, the option is<br>
                  > force to yes.<br>
                  ><br>
                  > thanks!<br>
                  ><br>
                  > donald<br>
                  ><br>
                  > ______________________________<wbr>_________________<br>
                  > frr mailing list<br>
                  > <a href="mailto:frr@lists.nox.tf"
target="_blank">frr@lists.nox.tf</a><br>
                  > <a href="https://lists.nox.tf/listinfo/frr"
rel="noreferrer" target="_blank">https://lists.nox.tf/listinfo/<wbr>frr</a><br>
                  <br>
                  ______________________________<wbr>_________________<br>
                  frr mailing list<br>
                  <a href="mailto:frr@lists.nox.tf"
target="_blank">frr@lists.nox.tf</a><br>
                  <a href="https://lists.nox.tf/listinfo/frr"
rel="noreferrer" target="_blank">https://lists.nox.tf/listinfo/<wbr>frr</a><br>
                </blockquote>
              </div>
              <br>
            </div>
            ______________________________<wbr>_________________<br>
            frr mailing list<br>
            <a
class="m_-8542252114825369793m_2978769784644366954aqm-autolink m_-8542252114825369793m_2978769784644366954aqm-autowrap"
href="mailto:frr%40lists.nox.tf" target="_blank">frr@lists.nox.tf</a><br>
            <a
class="m_-8542252114825369793m_2978769784644366954aqm-autolink m_-8542252114825369793m_2978769784644366954aqm-autowrap"
href="https://lists.nox.tf/listinfo/frr"
target="_blank">https://lists.nox.tf/listinfo/<wbr>frr</a><br>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
  </div></div></div>

<br>______________________________<wbr>_________________<br>
frr mailing list<br>
<a href="mailto:frr@lists.nox.tf" target="_blank">frr@lists.nox.tf</a><br>
<a href="https://lists.nox.tf/listinfo/frr" rel="noreferrer"
target="_blank">https://lists.nox.tf/listinfo/<wbr>frr</a><br>
<br></blockquote></div><br></div></div>

_______________________________________________<br>
frr mailing list<br>
<a class="aqm-autolink aqm-autowrap"
href="mailto:frr%40lists.nox.tf">frr@lists.nox.tf</a><br>
<a class="aqm-autolink aqm-autowrap"
href="https://lists.nox.tf/listinfo/frr">https://lists.nox.tf/listinfo/frr</a><br>
</blockquote>
</div>
</div>
</body>
</html>