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

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

Return-Path: <ginsberg@cisco.com>
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 76F0912DA2C for <lsr@ietfa.amsl.com>; Fri, 18 May 2018 08:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 z0H1VEpyDjqv for <lsr@ietfa.amsl.com>; Fri, 18 May 2018 08:41:29 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507FC12DA29 for <lsr@ietf.org>; Fri, 18 May 2018 08:41:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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 rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 May 2018 15:41:28 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-9.cisco.com (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 xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 18 May 2018 10:41:27 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1320.000; Fri, 18 May 2018 10:41:27 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, Christian Hopps <chopps@chopps.org>
CC: "lsr@ietf.org" <lsr@ietf.org>
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: <8c0d3e38bfe04b1a973f3cb4285840e8@XCH-ALN-001.cisco.com>
References: <612C3B15-9DD2-48C0-A5E5-B999D07AD1D7@cisco.com>
In-Reply-To: <612C3B15-9DD2-48C0-A5E5-B999D07AD1D7@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.73.231]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_ZsbpP9zmQqVwO02uNwgDzKyycw>
Subject: Re: [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: 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.

   Les
 

> -----Original Message-----
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Acee Lindem (acee)
> Sent: Friday, May 18, 2018 7:29 AM
> To: Christian Hopps <chopps@chopps.org>
> Cc: lsr@ietf.org
> 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 <chopps@chopps.org> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr