Re: [Isis-wg] SRLG Stuff with draft-ginsberg-isis-te-app-00

Uma Chunduri <uma.chunduri@huawei.com> Thu, 01 June 2017 00:23 UTC

Return-Path: <uma.chunduri@huawei.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7138D1293F9 for <isis-wg@ietfa.amsl.com>; Wed, 31 May 2017 17:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AF8cr7TmN6Rp for <isis-wg@ietfa.amsl.com>; Wed, 31 May 2017 17:23:36 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B781A120046 for <isis-wg@ietf.org>; Wed, 31 May 2017 17:23:35 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHR31654; Thu, 01 Jun 2017 00:23:33 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 1 Jun 2017 01:23:33 +0100
Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.56]) by SJCEML702-CHM.china.huawei.com ([169.254.4.117]) with mapi id 14.03.0235.001; Wed, 31 May 2017 17:23:30 -0700
From: Uma Chunduri <uma.chunduri@huawei.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Chris Bowers <cbowers@juniper.net>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: SRLG Stuff with draft-ginsberg-isis-te-app-00
Thread-Index: AdLaagDCKviKM/vDQIu/ZYvkdw4/TQ==
Date: Thu, 1 Jun 2017 00:23:30 +0000
Message-ID: <25B4902B1192E84696414485F5726854018BC418@SJCEML701-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.49.108]
Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F5726854018BC418SJCEML701CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.592F5E86.0030, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4e6a6a81f8c9544f4a7fc6564f9b40d4
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/jKh26O0M6xLXwcK_ltFFz--J3jA>
Subject: Re: [Isis-wg] SRLG Stuff with draft-ginsberg-isis-te-app-00
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jun 2017 00:23:38 -0000

Les,

Changed the title as this is bit side topic.

In-line [Uma]:

--
Uma C.




-          On the new TLV (TLV 238) proposed in https://tools.ietf.org/html/draft-ginsberg-isis-te-app-00

o   Not sure why SRLG need to be a separate TLV to start with as done in RFC 5307 for IPv4 and RFC 6119 for IPv6. This indeed, created lot of grief during BGP-LS time too from  both specification and implementation PoV.

If this need to be fixed these should be brought under T LVs 22, 23, 141, 222, and 223 not a 'new' separate TLV.

o   Hence, strongly disagree to clean-up this SRLG mess with yet another high level TLV

[Les:] I understand your concern. However, we have existing formats. What we have deliberately done with the extensions is to make sure we do NOT change existing formats for attribute advertisements - we only "encapsulate" with the "application bit mask".
This should allow a significant amount of existing TLV parsing code to be reused.
[Uma]: :). Code-reuse argument can be used for TLVs 22, 23, 141, 222, and 223 sub-TLVs too.

In the case of SRLG if we followed that model precisely we would have had to define two new top level TLVs - one for IPv4/unnumbered and one for IPv6. We wanted to be more frugal in consuming TLV code points
[Uma]: You arguing against what's been done in draft-ginsberg-isis-te-app i.e., creating yet another high level TLV code point. Sub-TLV format and code point space is far lesser relevance here..
                Section 4.3 Reads -

            A new TLV is defined to advertise application specific SRLGs for a
      given link.  Although similar in functionality to TLV 138 (defined by
      [RFC5307<https://tools.ietf.org/html/rfc5307>]) and TLV 139 (defined by [RFC6119<https://tools.ietf.org/html/rfc6119>] a single TLV provides
      support for IPv4, IPv6, and unnumbered identifiers for a link.


so we elected to make the new TLV format flexible enough to accommodate IPv4/IPv6, and unnumbered.
[Uma]: Why we are burning new TLV is the issue - to fix an already 'not needed' high level TLVs (138 and 139) for representing SRLGs. Issue is not the format of the sub-tlvs under it...

Your proposal is more "ambitious",
[Uma]: I see if you want to fix TLV138/139 - folding under  TLVs 22, 23, 141, 222, and 223 is more tractable way than introducing yet another high level TLV. Else use the same bit-mask/application-identifiers sub-TLVs in existing TLVs 13 & 139.


but I am not sure the benefits are significant enough. There are downsides to advertising SRLG in IS-neighbor TLVs.
AS a link may well have multiple SRLG values it could significantly bloat the TLV space used
[Uma]: Don't agree.  Would argue it other way. You would rather save space in your LSP by not having to use 6-byte system ID and other Interface address, neighbor address etc..


, forcing multiple TLVs for the same neighbor - which would defeat the purpose.
And it is harder for an implementation to determine whether a topology change is signaled by the revised IS-neighbor advertisement - so unnecessary SPFs might be triggered as a result.
[Uma]: I don't think so. A change have to be identified and trigger SPF, if the information is changed under existing TLV 138/139 (as LFA's also can potentially change).
Just by putting under TLVs 22, 23, 141, 222, and 223, won't cause any additional SPFs rather it is all at one place to see/compare and identify the change in topology.