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

"Acee Lindem (acee)" <> Fri, 18 May 2018 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A34A12DA70 for <>; Fri, 18 May 2018 08:45:33 -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 WFuxdxorodoF for <>; Fri, 18 May 2018 08:45:32 -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 C712312DA6C for <>; Fri, 18 May 2018 08:45:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5998; q=dns/txt; s=iport; t=1526658331; x=1527867931; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FckU+ZNkbGkbI+q7vuStApFfgOUGq79BHn/06giOr64=; b=BVEYKsBH6BV9J15o62LreXloQBUckpdbQ8KqcO5V1KMF96aqJ+6YhCVD F3ZToQqF9XOSOMS1DoMiqFlMc6DQhhVmUHiraOpD0ehvGQa+0bao1b9Id XzbDWfEk+BaBcy0xXcD00D8KWgenCJ1sqHsbjitn4FcITLqCDUzaM9UY7 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaBgDF9P5a/40NJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMUL4EtMSgKg2qUe4F5dRqTNoF4C4RsAhqBdyE2FgECAQE?= =?us-ascii?q?BAQEBAmwohSgBAQEDASMRRQULAgEIDgoCAiYCAgIwFRACBA4FHoMFgXkIqCq?= =?us-ascii?q?CHIRYg2aCJ4EJhyyCE4EOASOCNAcuhD8UAQEegwAwgiQCmEwJAo5VjH2QUAI?= =?us-ascii?q?REwGBJAEjDCWBUnAVZQGCGIIgF44Xb41JgR+BGAEB?=
X-IronPort-AV: E=Sophos;i="5.49,415,1520899200"; d="scan'208";a="395480433"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 May 2018 15:45:30 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w4IFjUjX002571 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2018 15:45:30 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 18 May 2018 11:45:29 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Fri, 18 May 2018 11:45:29 -0400
From: "Acee Lindem (acee)" <>
To: Christian Hopps <>
CC: "" <>
Thread-Topic: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
Thread-Index: AQHT7rSaiHAWoyz3a0iRubot8Dm8UqQ13UAAgAAG44A=
Date: Fri, 18 May 2018 15:45:29 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
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:45:34 -0000

> On May 18, 2018, at 11:20 AM, Christian Hopps <> wrote:
> To clarify, I think the win here is with clear and concise specifications, and avoiding double definitions of what is supposed to be the same thing -- not shared TLV parsing code. :)

I think this can be accomplished without a single IANA registry. It is all a matter of how the draft is written. 

> There's actually nothing sub-optimal encoding-wise with option 2a or 2b. The drawback with option 2 is we have 2 different TLV structures, the registry can be shared though.

I don’t think 2b is an option since it increases the IS-IS type/length size. 2a would be viable but by the time you documented all the constraints and what OSPF should do if they weren’t followed, you’d have negated any benefit. 

If the WG really wants protocol convergence, everyone should move to OSPFv3 since it has all the advantages of both protocols. ;^) 


> Thanks,
> Chris.
>> On May 18, 2018, at 10:29 AM, Acee Lindem (acee) <> wrote:
>> 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.