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

"Russ White" <> Tue, 06 August 2013 14:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6E8E21F8EE6 for <>; Tue, 6 Aug 2013 07:24:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.337
X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iOkH4kpekHtV for <>; Tue, 6 Aug 2013 07:24:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3A73921F8F2E for <>; Tue, 6 Aug 2013 07:24:46 -0700 (PDT)
Received: from ([] helo=USCSWHITER10L1C) by with esmtpa (Exim 4.80.1) (envelope-from <>) id 1V6iBo-00059d-JF; Tue, 06 Aug 2013 07:24:44 -0700
From: "Russ White" <>
To: "'David Lamparter'" <>, <>
References: <>
In-Reply-To: <>
Date: Tue, 6 Aug 2013 10:24:48 -0400
Message-ID: <02c801ce92b0$b56f4230$204dc690$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQKME5YFomzZRq60tI5aa5CJsaKHq5gNOgtw
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 14:24:55 -0000

> looking at the Extended LSA draft from the various use cases, I believe it
> would be advantageous to repurpose the topmost two bits of the TLV type
> to indicate what should happen if the TLV is not supported by a router.
> thinking of 3-4 possible handlings:
> (these all only apply to parent TLVs or LSAs that specify a route in some
> e.g. currently Inter/Intra/AS-Ext-Prefix LSAs.  Though the first two make
> sense in a generic way.)
> 00 - ignore TLV
>   this can be used for all "hint" TLVs, stuff like maybe communicating
>   the origin ASN for external routes or whatever you can dream up.
> 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.
> 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.

These seem useful to me...

> 11 - weak unreachable (?)
>   treat the route as "unreachable", adding it to the SPF result as such,
>   if there is no shorter path to the same prefix so far.  This is
>   probably the least useful type, I can only come up with something like
>   "route that requires special encapsulation (tunnel?)" - no idea on the
>   reality here.

This is really just max metric --I'm not certain we need another mechanism
to achieve the same thing.