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

Martin Horneffer <maho@lab.dtag.de> Thu, 27 August 2020 10:35 UTC

Return-Path: <maho@lab.dtag.de>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2B43A0B3C for <spring@ietfa.amsl.com>; Thu, 27 Aug 2020 03:35:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=lab.dtag.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRSwHj52W4xx for <spring@ietfa.amsl.com>; Thu, 27 Aug 2020 03:34:59 -0700 (PDT)
Received: from OldBailey.lab.dtag.de (OldBailey.lab.DTAG.DE [194.25.1.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2F03A0AB2 for <spring@ietf.org>; Thu, 27 Aug 2020 03:34:58 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id E7418C12DD for <spring@ietf.org>; Thu, 27 Aug 2020 12:34:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lab.dtag.de; s=dkim; t=1598524481; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=tjjyU15Lh0wO45M6o9aFhUmjfg4GCNlzCL6qXAGd5M4=; b=nLGbEJqdUvHddkW+8omOeHhAJfVRkfImsTPnDQzRByKfcM+eGEhdQRlY0F6kDaNImC0n7F t//sInuBuxpIgd7LIJ0AKqP6CHuBapVpIoSoJJ7jVr3DZaTKWNqdVVmV58eYTAIysjxEV5 jHbxDrkzZJSxOsbq1k5jrVuHCNXKlwwmx3tkN+H1gRbuA9vGZF97DWAc+z5Y6DFnWJ3/cL p2YTNS/0vmy0WCM4rrFiJLWd59cTxS1kEhQ1M+/K7C2zyknc7xZPnP595LYguaZqetw4IS /pmtLllNwor0HPWmGvBSuHp7kcp+RsDP3LQxbyE6/TygTtUywgt7O/EaUwY5EQ==
To: spring@ietf.org
References: <15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de>
From: Martin Horneffer <maho@lab.dtag.de>
Message-ID: <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de>
Date: Thu, 27 Aug 2020 12:34:33 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Last-TLS-Session-Version: TLSv1.3
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/vhqwgtf0gJvj378jMz9BudRVHL8>
Subject: [spring] to drop or to forward unlabelled (Re: Question on RFC8660)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2020 10:35:03 -0000

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
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring