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

David Lamparter <equinox@diac24.net> Tue, 06 August 2013 14:41 UTC

Return-Path: <equinox@diac24.net>
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 A1A8321F992E for <ospf@ietfa.amsl.com>; Tue, 6 Aug 2013 07:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level:
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 VM8LFQRbEHyq for <ospf@ietfa.amsl.com>; Tue, 6 Aug 2013 07:41:55 -0700 (PDT)
Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A06521F9DF1 for <ospf@ietf.org>; Tue, 6 Aug 2013 07:41:51 -0700 (PDT)
Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from <equinox@diac24.net>) id 1V6iSL-0000rZ-R4; Tue, 06 Aug 2013 16:41:50 +0200
Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from <equinox@diac24.net>) id 1V6iS9-0038eb-3v; Tue, 06 Aug 2013 16:41:39 +0200
Date: Tue, 6 Aug 2013 16:41:37 +0200
From: David Lamparter <equinox@diac24.net>
To: Acee Lindem <acee.lindem@ericsson.com>
Message-ID: <20130806144136.GM95257@jupiter.n2.diac24.net>
References: <20130806134954.GJ95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA381@eusaamb101.ericsson.se> <20130806142149.GK95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA3ED@eusaamb101.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4702FEA3ED@eusaamb101.ericsson.se>
User-Agent: Mutt/1.5.21 (2010-09-15)
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:41:55 -0000

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?

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


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