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

[Martin Horneffer <[e-mail]>]

Hi Robert,

the setup I sketched does not cover double failures nor 100 % of all 
topological cases for forwarding.
And in fact, forwarding the traffic is not the main purpose. The main 
purpose it to DETECT the failure in a useful way.

For the same reason we would sure not want to add yet another 
encapsulation technology.

But, of course, if the behavior (drop or forward unlabelled) would be 
configurable, that would be perfectly ok from my point of view.

Best regards, Martin


Am 27.08.20 um 14:45 schrieb Robert Raszuk:
> Martin,
>
> > it follows an IGP default route to a central device,
>
> So putting aside that such default must point domian wide to the same 
> address (could be anycast if you are careful) once this "central 
> device" receives a packet and does a BGP full table lookup it will 
> again try to encapsulate it in MPLS towards exit.
>
> What if the path is again via a device which breaks LDP LSP or SR 
> path and the packet will again go back to central device creating a 
> very nice loop ?
>
> Sure central device could give up on MPLS all together and IP encap to 
> egress via your BGP free core - but you are not mentioning that.
>
> Bottom line if you would not have BGP free core (or Internet route 
> free core) I would say sure good idea to continue. But since you do I 
> think this is a lot of hidden traps number of networks may fall into 
> by doing it. So at least it should not be a default behaviour.
>
> Thx,
> R.
>
>
>
>
>
> On Thu, Aug 27, 2020 at 12:35 PM Martin Horneffer <[e-mail] 
> <mailto:maho@lab..dtag.de>> 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.
>
>     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?
>
>     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]
> https://www.ietf.org/mailman/listinfo/spring