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

Christian Hopps <chopps@chopps.org> Mon, 21 May 2018 12:44 UTC

Return-Path: <chopps@chopps.org>
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 C74141270A0 for <lsr@ietfa.amsl.com>; Mon, 21 May 2018 05:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
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 ORLDphnIXRNe for <lsr@ietfa.amsl.com>; Mon, 21 May 2018 05:44:17 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 78481127077 for <lsr@ietf.org>; Mon, 21 May 2018 05:44:17 -0700 (PDT)
Received: from stubbs.lan (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A598360B2F; Mon, 21 May 2018 12:44:16 +0000 (UTC)
From: Christian Hopps <chopps@chopps.org>
Message-Id: <168AA42F-82CA-4882-977C-856FCBC6E6EE@chopps.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_F9482D5C-27DE-4537-9E47-BE546C56DF8C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Mon, 21 May 2018 08:44:15 -0400
In-Reply-To: <14aca4c3177e44dabb66995e3187029a@XCH-ALN-001.cisco.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
To: "Les Ginsberg (ginsberg)" <ginsberg@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>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Pre8rKlKqKHXTZdscBI1YPzdVM8>
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 12:44:20 -0000

On May 20, 2018, at 12:33 PM, Les Ginsberg (ginsberg) <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.

Thanks,
Chris.

>   Les