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

[Robert Raszuk <[e-mail]>]

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]> 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]
> > https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>