Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"?

"Russ White" <> Tue, 06 August 2013 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9603121F9476 for <>; Tue, 6 Aug 2013 08:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.359
X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YoaImffOwsLn for <>; Tue, 6 Aug 2013 08:41:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 29E4C21F9B57 for <>; Tue, 6 Aug 2013 08:41:09 -0700 (PDT)
Received: from ([] helo=USCSWHITER10L1C) by with esmtpa (Exim 4.80.1) (envelope-from <>) id 1V6jNf-0001aX-AG; Tue, 06 Aug 2013 08:41:03 -0700
From: "Russ White" <>
To: "'Acee Lindem'" <>, "'David Lamparter'" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Date: Tue, 6 Aug 2013 11:41:07 -0400
Message-ID: <038101ce92bb$5e8e8060$1bab8120$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQKME5YFomzZRq60tI5aa5CJsaKHqwHi2JGCAirYwvQBpgThigJYgvJnAlFw81aXumAZkA==
Content-Language: en-us
X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner
Subject: Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Aug 2013 15:41:20 -0000

> These bits are for flooding behavior of the LSA (a generic OSPFv3
> independent of the LSA purpose or context. This is opposed to attempting
> define SPF specific behavior for TLVs that may or may not contain SPF
> information.

I think the problem here might be one of wording, rather than intent --the
way David worded his original email was, "let's put bits in to tell a
receiving router how to handle an LSA it doesn't understand." Acee's
response is, essentially, "if you don't know how to handle it, then how are
these bits going to matter? The only valid response to an LSA you don't
understand is to drop it."

I think David's idea should be rephrased to something like this: "Is it
useful to have bits that will instruct a router to process any given LSA in
a specific way, rather than leaving it up to the receiver to determine all
possible cases independently?" In other words, LSAs are transmitted with the
"intent," that the information in the LSA be used to build the SPT, and
hence to install routes in the local routing table.

But there may be instances where the originator doesn't actually want the
route included in the SPT, nor the local routing table. The key is to see if
there actually any valid cases where this is true or not. If not, then we
can safely ignore the entire idea (at least for now). If there are valid use
cases, then...

So let's look at the use cases a bit (?):

> 01 - ignore parent
> on calculating SPF, completely ignore the resulting route.  This
> is useful for MT-OSPF (if it ever happens), to be used on a MT-ID
> TLV with an MT-ID != 0.  Basically, non-MT routers can ignore all
> nonzero MT topologies this way.

I guess this might also be solved by an MT router simply ignoring any MT
information around topologies it's not locally calculating for, correct? Is
there a need for an explicit notification of what to do with information
about topologies you're not routing for?

> 10 - strong unreachable
> mark the route's destination prefix as unreachable and install a
> corresponding blackhole/... route.  This is the right thing to do
> on SADR routes when they hit a non-SADR router.  Even if we have
> the same prefix reachable on a non-SADR route with a lower metric,
> we can't ensure that it's loop-free for a particular source address.

I think this is useful, but it's more of a security thing than a routing
thing directly. I don't know if the WG would agree that this is something
that could/should be carried in OSPF, nor have I spent a lot of time
thinking about how it would actually be included in the SPT.