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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Mon, 21 May 2018 15: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 7335012EA81 for <lsr@ietfa.amsl.com>; Mon, 21 May 2018 08:46:41 -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 gfzJNbDAmrlU for <lsr@ietfa.amsl.com>; Mon, 21 May 2018 08:46:39 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C193B12EA59 for <lsr@ietf.org>; Mon, 21 May 2018 08:46:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14899; q=dns/txt; s=iport; t=1526917598; x=1528127198; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XxtZ9V6RhUON9p/PnvWzwLhUYoJPqTgDg6E44vd+Vzc=; b=XxeIWCfHEXiqCVuydu6fUi3GhCREq3oZjdaApdezGk6E4w36MoyHnM7A y8UAYTqVPCPNPVfAYrfd1pbrLgg9ieXUCBRLIkPx5CYmRDIh6/lFDgyQT iFAvzDSHulpb4p/FDU/l4QcUVyi8P2odNRlq1gj0/XhdYS4WzQLTXCY4h M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAAAh6QJb/5JdJa1SChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCTXZhfSgKi2+Mc4F5gQ+OP4R3gXgLJYRHAoIZITQYAQI?= =?us-ascii?q?BAQEBAQECbBwMhSgBAQEBAy1MEAIBCA4DBAEBKAcyFAkIAgQOBQiDHIEbZA+?= =?us-ascii?q?pWohBggoFiDWBVD+BDoIOUS6ESFEQhR4CkRSHOAkCjk2BP4Nth1mQUAIREwG?= =?us-ascii?q?BJAEcOIFScBWCfosQhT5vAY8bgRgBAQ?=
X-IronPort-AV: E=Sophos;i="5.49,426,1520899200"; d="scan'208,217";a="401655648"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 May 2018 15:46:37 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w4LFkb5k013799 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 May 2018 15:46:37 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 10:46:37 -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 10:46:36 -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//3Ovg
Date: Mon, 21 May 2018 15:46:36 +0000
Message-ID: <1edb59cc76f64de4b8462200061cbba4@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>
In-Reply-To: <168AA42F-82CA-4882-977C-856FCBC6E6EE@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_1edb59cc76f64de4b8462200061cbba4XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/njKApsiYH4QTuGgEjpRCJalqez8>
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 15:46:51 -0000

Chris -

From: Christian Hopps <chopps@chopps.org>
Sent: Monday, May 21, 2018 5:44 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 20, 2018, at 12:33 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote:

Chris-

I am happy to see that the scope of this discussion is narrowing. I think the scope of what your proposing is much more appropriate for discussion - but we are in still not in agreement.

This has never changed for me, so I'm glad that we are understanding each other better. :)


I agree! IGP algorithm is a great example, and I'm glad you agree that it was a
good idea. The content of the "Sub-TLVs of the FAD TLV" are in the same way
shared by both protocols. The types and the values are defined exactly the
same for both protocols. The *only* difference is the encoding of the type
(and length) value, the semantics are the same.
[Les:] There is a qualitative difference between having a common registry to identify a protocol independent attribute and having a common registry to define a protocol scoped type value.

I appreciate that in this case we are defining a new container (FAD) which will have sub-containers that are applicable to both protocols. And I agree that it seems very hard to imagine any future sub-container which would not be applicable to both protocols. And I also agree that assigning the same type value to each sub-TLV for both protocols (now and in the future) is practical - and perhaps even desirable.

Great. BTW, nice renaming to "container" here.


Nevertheless, the "type" which identifies the sub-container is a protocol scoped attribute.  The fact that we could use a common number in this case does not mean it is conceptually correct to consider the value as protocol independent.

Let's please keep the definitions in registries which have the correct scope - which in the case of TLV/sub-TLV types is per/protocol.

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.

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.

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?
I don't.

   Les

Thanks,
Chris.

  Les