[Lsr] Calculating OSPF external routes for non-zero FA

Alexander Okonnikov <alexander.okonnikov@gmail.com> Fri, 01 March 2019 13:15 UTC

Return-Path: <alexander.okonnikov@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5607D130E7C for <lsr@ietfa.amsl.com>; Fri, 1 Mar 2019 05:15:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 shCybt8_DSyc for <lsr@ietfa.amsl.com>; Fri, 1 Mar 2019 05:15:47 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B96E130E73 for <lsr@ietf.org>; Fri, 1 Mar 2019 05:15:47 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id d14so20328097ljl.9 for <lsr@ietf.org>; Fri, 01 Mar 2019 05:15:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=vs4XkFBWlMFSe/ni3a3WfnaevWKxo3iS/hFoIFVR3mc=; b=gZFTBYfTvCmS+y2AjlWlZsSFi+/LfskSSWH+43+NrmQXwiSmJbCGlPCxnnYK9pMsqJ 2eSNODKaaK2yKIweGGvjhk1mU6ig/d6QNVLUFnT+H2jdI9YRSU1O5Amws7P+sr5yqjZO ddMOnzJqJuaSUvMtqqej5Ak40x5Z5gzZ4gNEGZ2MIPeDebwnnZc+i2S+Oas60/K0F4fV n1joVEjYaQkykKFBaWi1LIbHX5TU9EFpW7kCMLACj9smiOE9JmoQJI3ZTyuasRPrt7JT /uHcfWtcVE3yqQ08HYxqoxjOBhoXkOH2GhhbO2C0se4WfXZJHsSzzrpjcgV7nUqG0tDG 9bvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=vs4XkFBWlMFSe/ni3a3WfnaevWKxo3iS/hFoIFVR3mc=; b=OYJ1rB7gD9hFxphwQwEi+cU5aFJ37qEvkAaAAsaRaswY9ecn7PM1ygjce/4iqm13Jq iQ096q5MMy4axPhQEJ6ZQOFycqw7BZmKA/FuJs6c/4N60hiCkEXkebA8QzE/3TDQu+Qa Ou2nFdNlSLeF5XJVgu0OUuXBz4wnDyegOFYbIAskZQsz1YQbSd+zyXCw9wgRNOzS03B0 6fVzZaaeDkt8CmoXVeIN1En9+IqBknJO1wMMiHOzSbnh6ghAzi9KHFcok6V9A63z7+I/ l5mGGBaPuM8E8VSgdTHwnhtpmZnTEDpX/MLOmy0QDwy3iV9ia7uRmP/eAcTwveTjpxeo qL8w==
X-Gm-Message-State: APjAAAXqJxUlT9Ah0CiETNnLUlMztm3/88tVqFIA1/R0KBD61BuSgTB5 sAit0eGqn4AJvpg7jZ+L6aC9opj2
X-Google-Smtp-Source: APXvYqxpeOqA6I+MQsnBrs8Uk/SvzFuUK2cCsldipogO0jpmy1Y5lpIVxcwr/HOqBPZ0RXJCs6RZPw==
X-Received: by 2002:a2e:8092:: with SMTP id i18mr2723078ljg.91.1551446144945; Fri, 01 Mar 2019 05:15:44 -0800 (PST)
Received: from secretmaker-188.ip.peterstar.net (secretmaker-188.ip.PeterStar.net. [217.195.72.188]) by smtp.gmail.com with ESMTPSA id v65sm4639654lje.77.2019.03.01.05.15.44 for <lsr@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 05:15:44 -0800 (PST)
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <8CAFA47F-8188-4045-9CB8-CD1CFEC4DF1B@gmail.com>
Date: Fri, 01 Mar 2019 16:15:43 +0300
To: lsr@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/fjZLBp-NhKVObgvPfP0SPaKODCc>
Subject: [Lsr] Calculating OSPF external routes for non-zero FA
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2019 13:15:51 -0000

Hi WG,

I don't know whether the problem below is known already, but I have not found neither update nor corresponding errata for RFC 2328. RFC 2328, section 16.4 says:

"(3) ...  Look up the routing table entries (potentially one per attached area) for the AS boundary router (ASBR) that originated the LSA. If no entries exist for router ASBR (i.e., ASBR is unreachable), do nothing with this LSA and consider the next in the list.

Else, this LSA describes an AS external path to destination N.  Examine the forwarding address specified in the AS-external-LSA.  This indicates the IP address to which packets for the destination should be forwarded. ..."

and

"... If the forwarding address is non-zero, look up the forwarding address in the routing table.[24] The matching routing table entry must specify an intra-area or inter-area path; if no such path exists, do nothing with the LSA and consider the next in the list. ..."


In case when AS-external LSA has non-zero FA, why do we need to look up the routing table entries for ASBR, that originated the LSA? It is possible that FA is available via other ASBR(s). This is valid case when there are more than one ASBRs, and all may originate AS-external LSA with the same FA and metric for some external destination, but only one (with highest RID) will originate such LSA (RFC 2328, section 12.4.4.1). Another case with Type-7 to Type-5 translation doing by ABRs in Candidate mode (RFC 3101).

Per my understanding a calculating router should initially analyse FA value and only then check availability of ASBR or FA, depending on whether FA is zero or not. Am I missing something?

Thanks.