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

"Les Ginsberg (ginsberg)" <> Fri, 18 May 2018 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76F0912DA2C for <>; Fri, 18 May 2018 08:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z0H1VEpyDjqv for <>; Fri, 18 May 2018 08:41:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 507FC12DA29 for <>; Fri, 18 May 2018 08:41:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6626; q=dns/txt; s=iport; t=1526658089; x=1527867689; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QfAufKoCZ8qyhe9wk789ZQcs/oYpT4JaxFEvF6X3wCQ=; b=GlKgkr++r/20W9TbfnGkD9ZFi6mkvf3tIK+B0EhPD6knfO0hEg3sEAkG de3Hf2wu8CO0lui1UlU387CurmLwG6GoJpbmnjB7vArXK5czD6SG839e7 D4nWFYnXnXP0ll81JKi5ejrOcR/H6c/ozjaR36DxOM8pHOgkG2pPKQMfe E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DuAABf8/5a/5FdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDYX0oCoNqiASMd4F5dRqTNhSBZAsYC4RJAhqBdyE0GAE?= =?us-ascii?q?CAQEBAQEBAmwcDIUoAQEBBAEBIRE6CwwEAgEIEQQBAQMCJgICAiULFQgIAgQ?= =?us-ascii?q?BDQUIgx2Bfw+oFoIciD6CIgWBCYV5gTOBVD+BDgGCDUoHLoMRAQGBLQERAgF?= =?us-ascii?q?EglqCVAKYTAkCjk2NBZBQAhETAYEkARw4YXFwFTuCQ4IgF4hZhT5vjmiBGAE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.49,415,1520899200"; d="scan'208";a="397493106"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 May 2018 15:41:28 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w4IFfSUp016610 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2018 15:41:28 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 18 May 2018 10:41:27 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Fri, 18 May 2018 10:41:27 -0500
From: "Les Ginsberg (ginsberg)" <>
To: "Acee Lindem (acee)" <>, Christian Hopps <>
CC: "" <>
Thread-Topic: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
Thread-Index: AQHT7rSaiHAWoyz3a0iRubot8Dm8UqQ1nILg
Date: Fri, 18 May 2018 15:41:27 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 May 2018 15:41:32 -0000

(I never saw Chris's original email either - perhaps it was sent during the period when delivery to the alias when compromised.)

I am in full agreement w Acee - it is a VERY BAD idea to try to combine protocol TLV registries.
There are many reasons for this - here are a few.

1)In IS-IS the scope of TLV type identifiers is the protocol - in OSPF it is the LSA type

2)There are (obviously) many legacy code points which will make consistency at best confusing

3)Imposing an 8 bit type on OSPF or a 16 bit type on IS-IS is simply a non-starter.  RFC 7356 defines a non-backwards compatible way of doing this for IS-IS - but does so in a way that preserves the legacy codepoints - which seems obviously necessary. And introducing a 16 bit length into IS-IS isn't sensible unless we also address the current 256 LSP number limitation (which RFC 7356 also does). Suggesting this can be usefully done in a backwards compatible way does not make sense to me.
I cannot imagine why OSPF would be motivated to move to a more restricted 8 bit type/length model.

I cannot support this suggestion.


> -----Original Message-----
> From: Lsr <> On Behalf Of Acee Lindem (acee)
> Sent: Friday, May 18, 2018 7:29 AM
> To: Christian Hopps <>
> Cc:
> Subject: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
> Hi Chris,
> Somehow, I lost the mail below and was only able to retrieve it from the
> archive. Pardon my top posting.
> While I believe that sharing code points for values, e.g., IGP Algorithm Type,
> is a good idea, I don’t necessarily think it is a good idea to merge the TLV type
> registries. It seems to me it would be a poor trade-off to impact optimal
> protocol encoding including implementation just so we can have a combined
> IANA registry. It is extremely unlikely that OSPF and IS-IS implementations
> will ever share a common TLV parsing library.
> Note that we did discuss this once before in the context of the OSPF and IS-
> IS Tunnel Encapsulation drafts. I'd appreciate hearing what other WG
> members feel with respect to this issue.
> Thanks,
> Acee
> Christian Hopps <> Thu, 17 May 2018 21:07 UTC
> 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.
> _______________________________________________
> Lsr mailing list