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

[Martin Horneffer <[e-mail]>]

Hi PSF,

limiting the "forward unlabelled" behavior to packets with the 
bottom-of-stack bit set is an interesting idea. I haven't though about 
that yet. In my case that would definitely help and be perfectly ok.

Best regards, Martin


Am 28.08.20 um 05:31 schrieb [e-mail]:
>
>
> Hi Martin,
>
>
> For the matched LFIB entry with unlabeled outgoing forwarding 
> information, I agree your opinion that public traffic need to be 
> forwarded.
>
> I think the above LFIB entry can easiely drop VPN traffic according to 
> no bottom flag of incomming LDP/SR label.
>
>
> Regards,
>
> PSF
>
>
>
> 原始邮件
> *发件人：*MartinHorneffer <[e-mail]>
> *收件人：*[e-mail] <[e-mail]>;
> *日 期 ：*2020年08月27日 18:35
> *主 题 ：**[spring] to drop or to forward unlabelled (Re: Question on 
> RFC8660)*
> 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
>
>
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring