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

David Lamparter <equinox@diac24.net> Tue, 06 August 2013 13:50 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 3A4B521F9EED for <ospf@ietfa.amsl.com>; Tue, 6 Aug 2013 06:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level:
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, 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 UNavuWFYg4mO for <ospf@ietfa.amsl.com>; Tue, 6 Aug 2013 06:50:09 -0700 (PDT)
Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C25521F9CAC for <ospf@ietf.org>; Tue, 6 Aug 2013 06:50:09 -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 1V6heK-0004m7-DZ for ospf@ietf.org; Tue, 06 Aug 2013 15:50:08 +0200
Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from <equinox@diac24.net>) id 1V6he7-0035cm-Gs for ospf@ietf.org; Tue, 06 Aug 2013 15:49:57 +0200
Date: Tue, 06 Aug 2013 15:49:55 +0200
From: David Lamparter <equinox@diac24.net>
To: ospf@ietf.org
Message-ID: <20130806134954.GJ95257@jupiter.n2.diac24.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [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 13:50:10 -0000

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