Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660)

[Martin Horneffer <[e-mail]>]

Hi Gyan,

we had this kind of issue since the rise of LDP and the invention of the 
BGP free core. In a larger network, every now and then.

Some years later the notions of setting up targeted LDP sessions solved 
some part of the issue.
Some more years later, IGP-LDP synchronization indeed solved a big part 
of the issue in a more elegant way.
Yet they don't cover all possible failure cases.

Best regards, Martin


Am 30.08.20 um 16:21 schrieb Gyan Mishra:
>
> Hi Martin
>
> That is a very common scenario that occurs where one path where LDP 
> neighbor has lost its label binding for FEC destinations.
>
> Most providers don’t label all prefixes and only label interesting 
> traffic meaning FEC destination which is the egress endpoint loopback 
> iBGP peers for an LSP.
>
> So their is an ACL that is used for label allocation, label 
> advertisement and label accept policy to created the label binding LIB 
> and and Label forwarding table LFIB.
>
> So the LSP is built from ingress PE to egress PE and the label mapping 
> along the path occurs downstream unsolicited in the opposite direction 
> of the LSP via label mapping message from the egress PE that the LSP 
> is being built to - to the ingress PE from the downstream node to the 
> upstream node.
>
> Most operators have a BGP free and PIM free core and usually don’t 
> dual stack the core and the concept of softwire mesh framework RFC 
> 5565 so 6to4 softwire would be v6 edge over a v4 core or v4 edge over 
> a v6 core.
>
> So with the BGP free core all PE are BGP route reflector clients and 
> have a peer to RRs that sit in the P core.
>
> The P core is BGP free so only runs an IGP ISIS PE OSPF.  This point 
> is critical and that is that since the core is BGP free it can not 
> perform L3 forwarding so all packets must be L2.5 label switched via 
> topmost label either LDP or RSVP or SR-TE.
>
> So now that we have established the core construct let’s dig into the 
> problem with the label mapping being broken on a node along a path.
>
> So with LDPv4 or LDPv6 or SR-MPLS we have a concept called “ldp-IGP” 
> synchronization.  SR-MPLS uses IGP sync for SR sid labels as well 
> since SR is reusing the MPLS data plane.
>
> So on all MPLS core enabled interfaces on both PE and P LDP sync is 
> enabled.
>
> So the goal of ldp-IGP sync is to prevent black hole of packets on 
> MPLS interfaces cause by MPLS LDP failure and so how it works is the 
> IGP prefix that needs to build a label binding for FEC destination for 
> label swapping to occurs in the core so the IGP must not come up and 
> forward traffic along the path until MPLS is up or traffic will be 
> “black holed” and dropped.  So how this is accomplished is the IGP 
> sets the prefix metric to maximum 65535 for ospf and ISIS wide metric 
> does the same so the path now cannot be utilized until ldp comes up 
> and the label binding message is received via downstream unsolicited 
> to create outgoing label for the LFIB entry.  Once LDP is up and the 
> LFIB entry outing label is populated the IGP prefix is “unset” so now 
> is set to its normal IGP metric and traffic can now flow over the path.
>
> For LDP troubleshooting first you have to see if discovery link LDP is 
> up on the interface and then have to check if both Ldp adjacencent 
> nodes have a route in rib for each other’s LDP router id for the ldp 
> neighbor to come UP and label mapping message to be sent.  As you 
> mentioned if their is summarization for FEC which results in a loop 
> the binding does not get built for the FEC resulting in unlabeled FECs 
> in the LFIB.
>
> Hope that explanation helps.
>
>
> Kind Regards
>
> Gyan
>
> On Sat, Aug 29, 2020 at 8:37 PM Tarek Saad <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Martin,
>
>
>
>     See inline for some comments.
>
>
>
>     On 8/27/20, 6:35 AM, "spring on behalf of Martin Horneffer"
>     <[e-mail] <mailto:[e-mail]> on
>     behalf of [e-mail] <mailto:[e-mail]>> wrote:
>
>
>
>         Hello everyone,
>
>
>
>         may I come back the the question below? Or rather let me
>     update it a little:
>
>
>
>         In case an SR-MPLS path is broken, should a node rather drop
>     the packet,
>
>         or forward it?
>
>
>
>         This can happen whenever the IGP points to a certain next hop,
>     but that
>
>         neither supplies a valid SID, nor allows LDP-stitching for
>     whatever
>
>         reason. For PUSH as well as for CONTINUE.
>
>
>
>         We have been using MPLS transport and a BGP free core since
>     about two
>
>         decades now, using LDP. In the analog case, LDP creates
>     "unlabelled"
>
>         entries in the LFIB, does the equivalent of a POP operation
>     and forwards
>
>         the packet to the next-hop as chosen by the IGP.
>
>
>
>         This behavior obviously breaks any traffic that relies on a
>     service
>
>         label, but it can protect some traffic.
>
>         In our case a huge percentage of all traffic still is public
>     IPv4. This
>
>         needs MPLS only for a transport label, be it LDP or SR-MPLS.
>     If this
>
>         traffic gets forwarded unlabelled, it follows an IGP default
>     route to a
>
>         central device, where it is 1) redirected to the correct
>     destination and
>
>         2) counted in a way that operators can quickly see whether and
>     where
>
>         this kind of failure occurs at some point in the network.
>
>
>
>     [TS]: The SR Path may be composed of multiple SIDs (i.e. label
>     stack) -- where the top SID destination is not the SR Path
>     endpoint.. I sense from "gets forwarded unlabelled " as you will
>     discard the full label stack (?) and forward the packet unlabeled
>     to the central device? Or are you encapsulating the remaining MPLS
>     packet over IP and IP routing packet to the central device to be
>     inspected? In either case, I expect somehow the packet to be
>     ultimately delivered to the original SR Path endpoint/egress?
>
>
>
>         After more operational experience and several internal
>     discussions we
>
>         agreed that we want packets to be forwarded unlabelled rather
>     than
>
>         dropped. Anyone to share, or oppose this position?
>
>     [TS]: again, I'm not clear on when you say "forward unlabelled" -
>     do you mean packets will follow the top SID's the IP IGP route? Or
>     are you peaking into the destination IP (public IPv4) of packet
>     encapsulated in MPLS to determine how to forward it?
>
>
>
>     Regards,
>
>     Tarek
>
>
>
>         Best regards, Martin
>
>
>
>
>
>         Am 31.01.20 um 16:50 schrieb Martin Horneffer:
>
>         > Hello everyone,
>
>         >
>
>         > again it seems the interesting questions only show up when
>     applying
>
>         > something to the live network...
>
>         >
>
>         > We ran into something that poses a question related to
>     RFC8660: What
>
>         > is the exact meaning of section 2.10.1, "Forwarding for PUSH
>     and
>
>         > CONTINUE of Global SIDs", when the chosen neighbor doesn't
>     provide a
>
>         > valid MPLS path?
>
>         >
>
>         > The relevant sections reads:
>
>         >
>
>         >       -  Else, if there are other usable next hops, use them
>     to forward
>
>         >          the incoming packet.  The method by which the
>     router "R0"
>
>         >          decides on the possibility of using other next hops
>     is beyond
>
>         >          the scope of this document.  For example, the MCC
>     on "R0" may
>
>         >          chose the send an IPv4 packet without pushing any
>     label to
>
>         >          another next hop.
>
>         >
>
>         > Does the part "send an IPv4 packet without pushing any
>     label" apply to
>
>         > PUSH and CONTINUE, or just to PUSH?
>
>         > Does R0 have to validate that neighbor N can correctly
>     process to
>
>         > packet? Or can it forward the packet regardless?
>
>         >
>
>         > The reason for asking is that we are now seeing issues
>     similar to ones
>
>         > we had when starting with LDP based MPLS about two decades ago:
>
>         > traffic being black holed even though a path to the destination
>
>         > exists, because the MPLS path is interrupted somewhere in
>     the middle.
>
>         >
>
>         > With LDP we know the case of LFIBentries called
>     "unlabelled". While
>
>         > this does break connectivity for many kinds of service, e.g.
>     those
>
>         > relying on an additional service labels, it still works for
>     plain
>
>         > IP(v4) traffic. In our cases, this works perfectly fine for all
>
>         > internal routing and control traffic. And even for IPv4
>     traffic that
>
>         > gets collected by a central router that injects a default route.
>
>         >
>
>         > However, depending on the exact interpretation of the above
>     paragraph,
>
>         > an implementor might feel obliged to chose the next paragraph:
>
>         >
>
>         >       -  Otherwise, drop the packet.
>
>         >
>
>         > Which is, at least in our case, very unfortunate...
>
>         >
>
>         > Any advice or opinion appreciated!
>
>         >
>
>         >
>
>         > Best regards, Martin
>
>         >
>
>         >
>
>         >
>
>         >
>
>         > _______________________________________________
>
>         > spring mailing list
>
>         > [e-mail] <mailto:[e-mail]>
>
>         > https://www.ietf.org/mailman/listinfo/spring
>
>
>
>         _______________________________________________
>
>         spring mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/spring
>
>     _______________________________________________
>
>     spring mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/spring
>
> -- 
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
>
>