IETF Logo Mail Archive

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

"Acee Lindem (acee)" <acee@cisco.com> Mon, 21 May 2018 17:51 UTC

Return-Path: <acee@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 0D9C112D77A for <lsr@ietfa.amsl.com>; Mon, 21 May 2018 10:51:19 -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_HIGH=-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 YBKD7z9Qi_1a for <lsr@ietfa.amsl.com>; Mon, 21 May 2018 10:51:17 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C83012D72F for <lsr@ietf.org>; Mon, 21 May 2018 10:51:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3212; q=dns/txt; s=iport; t=1526925077; x=1528134677; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OlNjXkza4bnnTOm9nW7sqONpbKsUT1nxiMh0RQSERDI=; b=Ia/B/bNNgXBvNinDiSTT5AR07tsCl7p3/O/ljHpnfrmklKgXM0us5pH7 5Qi9Rz0EyNzrESghAWtHamvQd5nslspKpkefupsgSSU22mmccGwRf4tsu pem8vzw8pMrORf4X4xBZSKczRX0s5J7eBLm0N8FDRI+C1EI8oShUQZZIq E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CrAQChBgNb/4gNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYMUL4FeKAqDa5R3gXmBD5M2gXgLhGwCGoF/ITYWAQIBAQEBAQECbCiFKAEBAQECASMROA0QAgEIDgoCAiYCAgIwFRACBA4FgyKBeQioBoIciEGCD4EJhyyCE4EOJII7LoRMASYXgmkwgiQCmEwJAo5VjH2QUAIREwGBJAEjDiOBUnAVZQGCGIIgF44Xb44JASWBCIEYAQE
X-IronPort-AV: E=Sophos;i="5.49,426,1520899200"; d="scan'208";a="117306870"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 May 2018 17:51:16 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w4LHpFD6009536 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 May 2018 17:51:16 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 21 May 2018 13:51:15 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Mon, 21 May 2018 13:51:15 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Christian Hopps <chopps@chopps.org>
CC: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
Thread-Index: AQHT8D2CKoE9smu2IUCuPNoXojwY7qQ6S18AgABPEID//92zgA==
Date: Mon, 21 May 2018 17:51:14 +0000
Message-ID: <0D2D84C7-3D2A-4B50-8E3B-10831F9D4AED@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> <5B01766A.2090901@cisco.com> <73789432-BD35-4E42-96BB-7D48D4E10E93@cisco.com> <5AAB5659-975D-4E75-9BDE-D3A05DBF1C2F@chopps.org>
In-Reply-To: <5AAB5659-975D-4E75-9BDE-D3A05DBF1C2F@chopps.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <3192FACD96DE724B8425C56E17D06B6E@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/kJ7pipUtrbvXeKPPx1JWhAydcXg>
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 17:51:19 -0000

Hi Chris, 

The registries we are adding for FAD sub-TLVs do, in fact, refer to protocol encodings. Conversely, the IGP Algorithm type refers to a specific type of IGP algorithm independent of the protocol. So they are not completely analogous. Are you suggesting that we define a registry for the FAD information type abstraction and then say the OSPF/IS-IS sub-tlv types correspond to the FAD information type registry? I think having separate registries, as we do for other TLV and sub-TLV types, is much cleaner. 

Thanks,
Acee 

On 5/21/18, 11:54 AM, "Christian Hopps" <chopps@chopps.org> wrote:

    We aren't talking generically about TLV space here. When I raised the question I certainly intended it to be limited to times, as is the case here, where we are literally duplicating registries b/c they both refer to the same thing. I didn't realize that we'd already done this with SR IGP Algorithm registry.
    
    I did also include talking about what (if anything) to do with the duplicated containing TLV, but it seems no one wants to go there, which is fine, and I happen to agree probably is going too far.
    
    Thanks,
    Chris.
    
    > On May 21, 2018, at 11:11 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
    > 
    > Hi Peter, Chris,
    > 
    > In this particular case, it may be ok as long as we just limit the code point space to the 1 octet type (i.e., 0-255 with reserved values). However, for all the reasons Peter and Les have already articulated, there will be cases where the TLV or Sub-TLV registries cannot be common. So, I have to ask myself just what are we gaining by here? The encodings are not going to be identical (for all the previously mentioned reasons) and this leaves the door open for time wasted on revisiting this issue...
    > 
    > Thanks,
    > Acee
    > 
    > On 5/20/18, 9:21 AM, "Peter Psenak (ppsenak)" <ppsenak@cisco.com> wrote:
    > 
    >    Chris,
    > 
    >    On 20/05/18 01:47 , Christian Hopps wrote:
    >> How about an option 2c
    >> 
    >>   2c: Leave the encodings the way they are, and use a common registry to define the type/value semantics.
    > 
    >    having a combined registry that defines FAD Sub-TLVs types is fine with me.
    > 
    >    thanks,
    >    Peter
    > 
    > 
    >

v2.23.0 | Report a Bug | By Email