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

Peter Psenak <> Tue, 06 August 2013 18:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44A7711E80FC for <>; Tue, 6 Aug 2013 11:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.486
X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bd8viGHzj3KO for <>; Tue, 6 Aug 2013 11:45:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D910621F997D for <>; Tue, 6 Aug 2013 11:45:15 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from ( []) by (8.13.8+Sun/8.13.8) with ESMTP id r76IjDtb017589 for <>; Tue, 6 Aug 2013 20:45:13 +0200 (CEST)
Received: from [] ( []) by (8.13.8+Sun/8.13.8) with ESMTP id r76Ij9qo022817; Tue, 6 Aug 2013 20:45:10 +0200 (CEST)
Message-ID: <>
Date: Tue, 06 Aug 2013 20:45:09 +0200
From: Peter Psenak <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: David Lamparter <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 18:45:22 -0000


00 - ignoring unrecognized TVLs is a standard thing to do

01 - non-MT routers would ignore all TLVs related to MT-ID other then 0 
anyway, there is nothing special you need to do. If the non-MT capable 
router tries to do anything with TLV which is bound to a non-0 MT, or 
interpret any data that relates to non-0 MT, its a bug on that router.

10 - you can achieve this by advertising the SADR capability in the RI 
LSA and do it for any prefix coming from the non-SADR router, no per TLV 
granularity is required.

11 - looks like a router STUB advertisement

BTW, we should set the U-bit on all Extended LSAs and I believe Acee has 
agreed on that already.


On 8/6/13 15:49 , David Lamparter wrote:
> Hi ospf WG,
> 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.  I'm thinking of 3-4 possible handlings:
> (these all only apply to parent TLVs or LSAs that specify a route in
> some way, 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.
> 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.
> Note that this is supposed to work in conjunction with other ways of
> communicating per-router capabilities, e.g. Router Information LSAs.
> A router may well need to take a different action when, on calculating,
> it notices that it passed by a router without support for feature XYZ.
> Since that applies to routers that *do* implement a particular
> extension, the exact behaviour for this needs to be specified in that
> extension.
> Comments?
> -David
> _______________________________________________
> OSPF mailing list