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

Acee Lindem <> Tue, 06 August 2013 14:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E19A21F9C37 for <>; Tue, 6 Aug 2013 07:16:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sq8gYT0o5E8N for <>; Tue, 6 Aug 2013 07:16:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D5DC921F9A4B for <>; Tue, 6 Aug 2013 07:16:12 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-c4-5201052c70e7
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8F.63.13034.C2501025; Tue, 6 Aug 2013 16:16:12 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 10:16:11 -0400
From: Acee Lindem <>
To: David Lamparter <>
Thread-Topic: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"?
Thread-Index: AQHOkqwAjkxiEC+2aEOyPevoodJ9h5mIfLUA
Date: Tue, 6 Aug 2013 14:16:10 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXSPn64OK2OQQc9tBYs1jRuYLVru3WN3 YPL4slfKY8mSn0wBTFFcNimpOZllqUX6dglcGfu3NrAW3BOpmLyqhbWBcbtAFyMnh4SAicTJ 3uOsELaYxIV769m6GLk4hASOMkosW3mPEcJZxihx+el6JpAqNgEdieeP/jGD2CICGhJtb1cA xTk4mAVUJR4fZQMJCwvESHRvvsQOURIrMaXpNyuEbSTR/GYaWCuLgIrEtzmrwGp4BXwlJh7u YwSxhQSsJLZN+AAW5xSwlmjvbgLrZQQ67vupNWAnMAuIS9x6Mp8J4mgBiSV7zjND2KISLx// g3pGWWLJk/0sEPU6Egt2f2KDsK0ljr1Ywgxha0ssW/iaGeIGQYmTM5+wTGAUn4VkxSwk7bOQ tM9C0j4LSfsCRtZVjBylxalluelGBpsYgTF1TIJNdwfjnpeWhxilOViUxHlX6Z0JFBJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cDYuUbQ3I+l8WuGyp0VP79Wiq7Yzdre8PhMZ4/nQ27/6xoX gty3ZeWzPvgmH5Q2/Uf4DcO6yr+rRcIfJD/sFSn4lLx1Q4ez7hyWN+vKXBempZcE5h1SKtT2 YLHWPPk0M8Uv1ldeKHT5x3dxnmISBeJe0zW8NO2KBPNvfhFd1RnBkJJ5hHt/oRJLcUaioRZz UXEiAIQ5bBx3AgAA
Cc: "<>" <>
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:16:18 -0000

Hi David,
I don't think this is a good idea at all. An implementation can only deal with the TLVs it understands so the ignore options don't make sense. 
If the other actions are necessary, we'd be better served with a more definitive use case and encoding than reusing TLV bits. 

On Aug 6, 2013, at 9:49 AM, 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