[spring] Question on RFC8660

Martin Horneffer <maho@lab.dtag.de> Fri, 31 January 2020 15:50 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 AAD31120123 for <spring@ietfa.amsl.com>; Fri, 31 Jan 2020 07:50:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level:
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=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 88BUXrNuYbUG for <spring@ietfa.amsl.com>; Fri, 31 Jan 2020 07:50:33 -0800 (PST)
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 E80BB1200FE for <spring@ietf.org>; Fri, 31 Jan 2020 07:50:32 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 920E2D9504 for <spring@ietf.org>; Fri, 31 Jan 2020 16:50:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lab.dtag.de; s=dkim; t=1580485813; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=yfwEdGZDgg+CtqbBovXgMwyllwuIYuRIU519YZ8KW0o=; b=cuJzNmX4CGbl9odJlhDeNSVoTPBclmZElwHV71f+la8nEWOdKWclmGjGdfjw/y9uMw+JoI 6H+z84JH0opIfgHaR8RY0rXppoy1bUigibg+ZrZQHM1+KL2G3O6E02R11ttpGIGAF9//kf UN/kolFwY3LA3RgW9qf/L1XB6dsFDhcLATdiPDz4myi9woMImv/hriMO4Dyl4nOdor1tNE xMDLj262AgloRIyx+8kw2PXCXXBkl7zxDUH5v6Py8dC7iZ5qJk6038zDtENleO8hWpwPc5 vfyqnVCRbTmBLu/f5fkPkTXfAHVSnk0gkqkWvyowU/LLYcuTn6dRpf+FW2LVIQ==
From: Martin Horneffer <maho@lab.dtag.de>
To: SPRING WG List <spring@ietf.org>
Message-ID: <15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de>
Date: Fri, 31 Jan 2020 16:50:13 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/-aRbu8w5MvU6fUcOAQ_vXssUdQU>
Subject: [spring] 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: Fri, 31 Jan 2020 15:50:35 -0000

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