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

Acee Lindem <acee.lindem@ericsson.com> Tue, 06 August 2013 14:49 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 3C94C21F84CD for <ospf@ietfa.amsl.com>; Tue, 6 Aug 2013 07:49:40 -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 XanpUiGYUlqA for <ospf@ietfa.amsl.com>; Tue, 6 Aug 2013 07:49:33 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D563021F9E7C for <ospf@ietf.org>; Tue, 6 Aug 2013 07:49:19 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-b3-52010ceec2f7
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3D.B5.13034.EEC01025; Tue, 6 Aug 2013 16:49:18 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 10:49:18 -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+2aEOyPevoodJ9h5mIfLUAgAABlICAAAKZgIAAAu+AgAACJAA=
Date: Tue, 6 Aug 2013 14:49:17 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4702FEA4D2@eusaamb101.ericsson.se>
References: <20130806134954.GJ95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA381@eusaamb101.ericsson.se> <20130806142149.GK95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA3ED@eusaamb101.ericsson.se> <20130806144136.GM95257@jupiter.n2.diac24.net>
In-Reply-To: <20130806144136.GM95257@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: <7EB52A2C32EF7641B79A51F5597C2246@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXRPlO47HsYgg12H9S3WNG5gtmi5d4/d gcnjy14pjyVLfjIFMEVx2aSk5mSWpRbp2yVwZfw52cpU8Eui4sf81ywNjC+Euxg5OSQETCQa Tr5lgrDFJC7cW8/WxcjFISRwlFHi28elzBDOMkaJaa+es4BUsQnoSDx/9I8ZxBYR0JBoe7sC qJuDg1lAVeLxUTaQsLBAjET35kvsECWxElOafrNC2H4SU6ccAFvGIqAicb5/GlgNr4CvxPP9 l6B2LWGS2L/uANh8TgFriVvXpoM1MAJd9/3UGjCbWUBc4taT+VBXC0gs2XOeGcIWlXj5+B8r hK0sseTJfhaIeh2JBbs/sUHY1hKtu9+yQ9jaEssWvmaGOEJQ4uTMJywTGMVnIVkxC0n7LCTt s5C0z0LSvoCRdRUjR2lxalluupHBJkZgVB2TYNPdwbjnpeUhRmkOFiVx3lV6ZwKFBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MHpyvtq+k7n1+/ZKmfnzav4YPuZM+8Sz/fVKNcnbjf/E9fdc iElf1cx5LDXHUP7UL/Mn525+XxMbevCr6nMli/fdC275SnScZCz1yW+8fHbX9vaFIQaXNp7V f/Ox5KDWbd+Yj6GssmwLfP/Vpt5uO37IbVZq07H8bd2NKSKaMund53Z9fV79mUWJpTgj0VCL uag4EQBuIMjQeAIAAA==
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:49:40 -0000

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

> On Tue, Aug 06, 2013 at 02:31:07PM +0000, Acee Lindem wrote:
>> 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.
> 
> Hm.  We have the same thing with U/S1/S2 bits in LSA function codes.
> Other protocols have a "critical" bit indicating ignore/error behaviour.
> I've tried to adapt that for a routing use case - I guess I'm not seeing
> the problem?  Do you have a few minutes to explain in more depth?

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

> 
> (I guess it needs a little more thinking in particular regarding
> multiple TLVs with different unsupported disposition, probably just an
> ordering and "choose worst".  I've also implied without saying that all
> LSAs are flooded unmodified, i.e. U=1.)

No - this draft will NOT include modifying LSAs. This is a slippery slope and one best not even considered. 

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.
>>