[Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs

Christian Hopps <chopps@chopps.org> Thu, 17 May 2018 21:07 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB133127735 for <lsr@ietfa.amsl.com>; Thu, 17 May 2018 14:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjXYKkaUX6bg for <lsr@ietfa.amsl.com>; Thu, 17 May 2018 14:07:25 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7C88612D961 for <lsr@ietf.org>; Thu, 17 May 2018 14:07:25 -0700 (PDT)
Received: from [192.168.2.5] (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id C9C3F63320 for <lsr@ietf.org>; Thu, 17 May 2018 21:07:24 +0000 (UTC)
From: Christian Hopps <chopps@chopps.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_56629C29-C338-4D06-89DE-7C59943BB695"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Message-Id: <12ED3E81-56EF-4C92-B707-B739D06F36FB@chopps.org>
Date: Thu, 17 May 2018 17:07:23 -0400
To: lsr@ietf.org
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ebjZPIVDSfw9SAyca7ApVrd5-Do>
Subject: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 May 2018 21:07:28 -0000

So in looking at the IANA requests inside the newly merged flex algorithm draft I noticed that the document is creating 2 separate Flex Algorithm Definition sub-tlvs Registries for IS-IS and OSPF with the initial content described in sections:

6.1.  ISIS Flexible Algorithm Exclude Admin Group Sub-TLV
6.2.  ISIS Flexible Algorithm Include-Any Admin Group Sub-TLV
6.3.  ISIS Flexible Algorithm Include-All Admin Group Sub-TLV

7.1.  OSPF Flexible Algorithm Exclude Admin Group Sub-TLV
7.2.  OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV
7.3.  OSPF Flexible Algorithm Include-All Admin Group Sub-TLV

They are basically the same thing (indeed the later OSPF sections refer back to the IS-IS sections), except for one detail AFAICT, the size of the type and length fields.

I think we may have some options here to make this a bit more elegant.

 1. Share the same sub-TLV structure
   a. using the OSPF sub-tlv structure (16 bit type and 16 bit len) for both protocols
   b. using the IS-IS sub-tlv structure (8 bit type and 8 bit len) for both protocols

 2. Use different structure with the same type field size of the
   a. more constrained IS-IS 8 bit size
   b. less constrained OSPF 16 bit size

 3. Define and use some generic method to define shared TLVs like this where the only actual difference is the size of the type and length fields.


1, Creates a clean and simple standard, 1 TLV definition and 1 sub-TLV registry.

1a, has the property that the length value in IS-IS can't normally exceed an 8 bit value; however, sub-TLV length values are already constrained beyond the field size as sub-TLVs may appear anywhere in the TLV.

1b, restricts both protocols to 256 types, and perhaps more importantly restricts the sub-TLV length to 257 octets. This is handled all the time in IS-IS using repeated TLVs, but not so much (ever?) in OSPF.


2. Allows us to at least create a single IANA registry for the sub-tlv types so we aren't duplicating them and their definitions for each protocol.


3. Is interesting but probably requires some work outside of this document.


This document is serving as our guinea pig for how to merge work so I think it's worth spending some effort on these types of details.

Thanks,
Chris.