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

"Les Ginsberg (ginsberg)" <> Thu, 01 June 2017 01:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 522A3129ADD for <>; Wed, 31 May 2017 18:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0e-CtdSnRXgo for <>; Wed, 31 May 2017 18:25:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 447F8129498 for <>; Wed, 31 May 2017 18:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=27519; q=dns/txt; s=iport; t=1496280344; x=1497489944; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/ES8h0wFphehaSQ+KZ6IW77DQ0lZOV7yBDqMpZSjj4Y=; b=JjjQJx+GzKRzCx6+DFt+BYC5jvasRuUh8XyCKRzQK4CFa0ltpzLhwxBF 1MfDqz2op/IxVAjuTuYN19qIJ943dQ1DBoU+t2RG+F9y1iAIMmz1em8kG YFTaDZIiLVQM430O4w7fdyw/CeBrYvOgitCvuxRh7xEL22tEttSNlFswy E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.39,277,1493683200"; d="scan'208,217";a="249985615"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jun 2017 01:25:42 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v511Pg3e002431 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2017 01:25:42 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 May 2017 20:25:42 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 31 May 2017 20:25:42 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Uma Chunduri <>, Chris Bowers <>, "" <>
Thread-Topic: SRLG Stuff with draft-ginsberg-isis-te-app-00
Thread-Index: AdLaagDCKviKM/vDQIu/ZYvkdw4/TQACgcuA
Date: Thu, 1 Jun 2017 01:25:42 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_8e1056ec1de34c3abea5f9a9d9502e25XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Isis-wg] SRLG Stuff with draft-ginsberg-isis-te-app-00
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Jun 2017 01:25:47 -0000

Uma -

I appreciate your passion - I am just not convinced there is a clear winner here. There are advantages to either approach.
Let's listen for other opinions.

A few more comments inline.

From: Uma Chunduri []
Sent: Wednesday, May 31, 2017 5:23 PM
To: Les Ginsberg (ginsberg); Chris Bowers;
Subject: RE: SRLG Stuff with draft-ginsberg-isis-te-app-00


Changed the title as this is bit side topic.

In-line [Uma]:

Uma C.

-          On the new TLV (TLV 238) proposed in

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.

[Les2:] Not sure what you are saying. We DO reuse the existing link attribute sub-TLVs. Let's at least recognize when we are in agreement. :)

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<>]) and TLV 139 (defined by [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.

[Les2:] The conclusion that TLVs 138/139 were never needed isn't indisputable.
I will agree that if more foresight had been applied when writing RFC 5307 the IPv6 case could have been anticipated and TLV 139 would never have been needed - but concluding that advertising SRLG outside of TLV 22 etc. context is completely wrong is a much bigger leap. I do think there are advantages to doing that. You have concluded that TLV138 (and by inference TLV139) was a mistake - but I think opinion may be divided on that.

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.

[Les2:] A smart implementation can act optimally - I am only saying that it requires drilling deeper into the content which was updated - and not all implementations may have implemented that logic.