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

Acee Lindem <acee.lindem@ericsson.com> Tue, 06 August 2013 14:31 UTC

Return-Path: <acee.lindem@ericsson.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE9B21F9A13 for <ospf@ietfa.amsl.com>; Tue, 6 Aug 2013 07:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRmpcfTuXnVJ for <ospf@ietfa.amsl.com>; Tue, 6 Aug 2013 07:31:35 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1DF21F9A34 for <ospf@ietf.org>; Tue, 6 Aug 2013 07:31:09 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-60-520108ac8292
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C8.64.13034.CA801025; Tue, 6 Aug 2013 16:31:08 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 10:31:08 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: David Lamparter <equinox@diac24.net>
Thread-Topic: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"?
Thread-Index: AQHOkqwAjkxiEC+2aEOyPevoodJ9h5mIfLUAgAABlICAAAKZgA==
Date: Tue, 6 Aug 2013 14:31:07 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4702FEA3ED@eusaamb101.ericsson.se>
References: <20130806134954.GJ95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA381@eusaamb101.ericsson.se> <20130806142149.GK95257@jupiter.n2.diac24.net>
In-Reply-To: <20130806142149.GK95257@jupiter.n2.diac24.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A70DC2BE2A64FA499014AF79E833BC0A@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPrO4aDsYggxmb9C3WNG5gtmi5d4/d gcnjy14pjyVLfjIFMEVx2aSk5mSWpRbp2yVwZcz48YCt4DN/xdeJ09kaGA/zdDFyckgImEj8 2HSREcIWk7hwbz1bFyMXh5DAUUaJf4cWsEA4yxgl5r+/wARSxSagI/H80T9mEFtEQEOi7e0K oDgHB7OAqsTjo2wgYWGBGInuzZfYIUpiJaY0/WaFsJ0kZm3eBhZnEVCRWDLnOthiXgFfiY0P OsDGCwmsZ5SYcc8axOYUsJZ4fagBrJcR6Ljvp9aA1TALiEvcejKfCeJoAYkle84zQ9iiEi8f /2OFsJUlljzZzwJRryOxYPcnNgjbWuLW6+fsELa2xLKFr5khbhCUODnzCcsERvFZSFbMQtI+ C0n7LCTts5C0L2BkXcXIUVqcWpabbmSwiREYU8ck2HR3MO55aXmIUZqDRUmcd5XemUAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjMtU3TL5w12//zdq6tu9fbLg03MlM8rsLTezOzOUnL3o bDz54ynTlwVu6ZMaZE5KzKh7s6Yg5JiUg5/bnsmzl3pJW0XsnVbstznX81d/wALJ4raZzgeW fjGNlgg8lLpzo1S5xtsi4UWS52eVZ71kUZiy3qOeobJccbLc1ni9Xcd/bl+1QTxVU4mlOCPR UIu5qDgRAGiKpmp3AgAA
Cc: "<ospf@ietf.org>" <ospf@ietf.org>
Subject: Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"?
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Aug 2013 14:31:42 -0000

On Aug 6, 2013, at 10:21 AM, David Lamparter wrote:

> On Tue, Aug 06, 2013 at 02:16:10PM +0000, Acee Lindem wrote:
>> 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.
> 
> Section 3 of the draft states:
> 	[...] Unrecognized types are ignored.
> How does that make sense then?  Did I misunderstand that sentence?

No - the only valid option for a TLV that you don't recognize is to ignore it. It makes no sense to attempt to imply some action based on bits in the TLV type. 

Acee 


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