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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Mon, 21 May 2018 16:46 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 AEA6012E89F for <lsr@ietfa.amsl.com>; Mon, 21 May 2018 09:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 e0zhhtqpnjrq for <lsr@ietfa.amsl.com>; Mon, 21 May 2018 09:46:56 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FDF129C70 for <lsr@ietf.org>; Mon, 21 May 2018 09:46:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24158; q=dns/txt; s=iport; t=1526921216; x=1528130816; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eZs3ajWXtH0kdOCDt/pg3U0prBObaaHSP/N3K9H7vCI=; b=mn1DvoYE0pByYdIfHMnu5MK/G9gEe67eYD0TAv6negJt+Ma/NZ1t4Xda xkST7+fh3KDCsPTqFzBuSezG5+VIgsRFmltFylHzbmPRzvpqVumaPIPy5 u1/CvcAqLQpyzQkfUlTnfurz3hUL6OFPFsptZEsmE3OBrzxax1yoP88MX c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAABT9wJb/4QNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNdmF9KAqDa4gEjHOBeYEPkzaBeAslhEcCGoF/ITQYAQI?= =?us-ascii?q?BAQEBAQECbBwMhSgBAQEBAyMKTBACAQYCDgMEAQEoAwICAjAUCQgCBA4FCIM?= =?us-ascii?q?cgRtkD4wym0OCHIhBggoFiDWBVD+BDoJfLoRTAQFEEIJKglQCkRSHOAkCjk2?= =?us-ascii?q?NBZBQAhETAYEkARw4gVJwFYJ+ixCFPm8BjXyBH4EYAQE?=
X-IronPort-AV: E=Sophos;i="5.49,426,1520899200"; d="scan'208,217";a="117239754"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 May 2018 16:46:55 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w4LGksaH025748 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 May 2018 16:46:55 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 21 May 2018 11:46:54 -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; Mon, 21 May 2018 11:46:53 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Christian Hopps <chopps@chopps.org>
CC: "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
Thread-Index: AQHT7rSaiHAWoyz3a0iRubot8Dm8UqQ1nILggAHAzoD//9yh8IAA0/2AgADBBXCAAapPgP//3OvggABd6ID//6834A==
Date: Mon, 21 May 2018 16:46:53 +0000
Message-ID: <0aea42173b704a29a8bf79773e361354@XCH-ALN-001.cisco.com>
References: <612C3B15-9DD2-48C0-A5E5-B999D07AD1D7@cisco.com> <8c0d3e38bfe04b1a973f3cb4285840e8@XCH-ALN-001.cisco.com> <F02D7E3F-15D4-4C8C-89DE-D6F69AA71323@chopps.org> <7686e04b209b4520b5a2f25e96da310d@XCH-ALN-001.cisco.com> <3E609B6F-7AAB-442A-85E4-BBE2BBD4AA70@chopps.org> <14aca4c3177e44dabb66995e3187029a@XCH-ALN-001.cisco.com> <168AA42F-82CA-4882-977C-856FCBC6E6EE@chopps.org> <1edb59cc76f64de4b8462200061cbba4@XCH-ALN-001.cisco.com> <22B658C1-AB82-42EE-AAC5-0320BA73510A@chopps.org>
In-Reply-To: <22B658C1-AB82-42EE-AAC5-0320BA73510A@chopps.org>
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: multipart/alternative; boundary="_000_0aea42173b704a29a8bf79773e361354XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/1XQm2x1lEykB7s9meiKZ5GGx_zI>
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: Mon, 21 May 2018 16:46:59 -0000

Chris –

I think you are making this thread far more confusing than necessary.
Protocol code points include:

Top level TLV types
Sub-TLV types
Sub-sub-TLV types
Etc.

Obviously a sub-TLV is “contained” in a TLV
And a “sub-sub-TLV” is contained within a sub-TLV

This does not alter the fact that all of these type identifiers are protocol specific and are managed in protocol specific registries. There are many existing examples of this.

The values managed in the “IGP Algorithm” registry are not used as a “type” identifier at any level in the protocol. They are the values advertised within the “container” – whether that container is a TLV or a sub-TLV or…

If we cannot agree on this then we will never agree on anything.

“types” at any level are protocol specific and should be managed on protocol specific registries.

   Les



From: Christian Hopps <chopps@chopps.org>
Sent: Monday, May 21, 2018 9:15 AM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Cc: Acee Lindem (acee) <acee@cisco.com>om>; lsr@ietf.org
Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs


On May 21, 2018, at 11:46 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote:

I fail to see any difference from the IGP algorithm case, which you agreed with.


  SR Algorithm container:
    - distributed as a TLV inside Router Information Opaque LSA
    - distributed as a sub-TLV inside Router Capability TLV

  IGP Algorithm: The container content which is defined using a common registry.

[Les:] The SR Algorithm “container identifier” is NOT managed by the IGP Algorithm Registry. It is only the algorithm identifiers– which are advertised inside the protocol specific containers – which are managed by the shared registry.

Here, however, you are proposing to manage the identifier for the container (not its contents) in a shared registry. That I object to.

Unfortunately, you are incorrect here, I never made that proposal. I presented various options we might choose to share commonality, none of them had to do with sharing top-level code-points, all of them had to do strictly with the content of the FAD [sub-]TLV which is being entirely defined by the document in question.

 TLV/sub-TLV codepoints are a protocol property. That is why they are managed in protocol specific registries.
You are now proposing to take “some” protocol specific identifiers and manage them in a protocol independent registry. This is wrong.

I'm talking about the content of the FAD [sub-]TLV only, just like IGP Algorithm registry is defining the content for the SR Algorithm [sub-]TLV, they are completely analogous.



You think it makes sense to go to https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml to find all the IS-IS TLV/sub-TLV codepoints EXCEPT for a few which you want to put into a shared IS-IS/OSPF registry?

This is silly, perhaps not intended but it's very close to a straw man. I know I wrote in an early mail explicitly that my intent had nothing to do with back over anything, so no.

Thanks,
Chris.


I don’t.

   Les

Thanks,
Chris.

  Les