[Isis-wg] Comments on draft-lu-isis-transaction-tlv-00
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 20 March 2012 05:18 UTC
Return-Path: <ginsberg@cisco.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 9F41C21F88ED for <isis-wg@ietfa.amsl.com>; Mon, 19 Mar 2012 22:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.799
X-Spam-Level:
X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+jSwNfFzkOx for <isis-wg@ietfa.amsl.com>; Mon, 19 Mar 2012 22:18:33 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8DE21F88EA for <isis-wg@ietf.org>; Mon, 19 Mar 2012 22:18:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=4387; q=dns/txt; s=iport; t=1332220713; x=1333430313; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=PNvPUxF03jeXdLj7AKJFKKr03XHarxgrKFoB2RHQ4vM=; b=OhXF2LX0Klgrd8qPaHuR/BvOd1x/3JQm8DPg52JnOfiCDspuHFpH6J8Q fxc4yhXDlLGw2YDR+7TgpJvToNzhkviG5eqFTYmikSMJl7J41vnMRxoe/ 2l6UNL4KHYsrqEd8teUL4G2mzMQos6A8HcCvLnQ27CiVZekYqZk7wfhdf 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAC0SaE+rRDoI/2dsb2JhbABBtliBB4ILAQQSAR0KMgoDEgEqBhgHVwEEARoTB4dnAQufRJcsj35jBIhWllwBhGuBaIMG
X-IronPort-AV: E=Sophos;i="4.73,616,1325462400"; d="scan'208";a="36833263"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 20 Mar 2012 05:18:33 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2K5IX7G024359; Tue, 20 Mar 2012 05:18:33 GMT
Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 22:18:33 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Mar 2012 22:18:25 -0700
Message-ID: <AE36820147909644AD2A7CA014B1FB521101DD7C@xmb-sjc-222.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on draft-lu-isis-transaction-tlv-00
Thread-Index: Ac0GWOCB3FpuLXGZSv6bnTJl0jkh0g==
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Wenhu.Lu@ericsson.com, Albert.Tian@ericsson.com
X-OriginalArrivalTime: 20 Mar 2012 05:18:33.0058 (UTC) FILETIME=[E4E2F420:01CD0658]
Cc: isis-wg@ietf.org
Subject: [Isis-wg] Comments on draft-lu-isis-transaction-tlv-00
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 20 Mar 2012 05:18:34 -0000
Wenhu/Albert - I acknowledge that the problem which this draft is trying to address exists - at least in theory - but I am concerned as to whether the solution offered will actually result in significant benefits. Here's why. ISO 10589 highly recommends that once a particular advertisement is assigned to a given LSP that it not be gratuitously moved to an LSP with a different number. (See Section 7.3.4.4) This means that the example you provide in Section 1.3 of the draft is something that should be avoided - and can be avoided in most (but admittedly not all) cases. This fact alone lessens the value of your proposal. ISO 10589 also recommends that if a particular advertisement is moved to an LSP with different # that the two affected LSPs be flooded "as an atomic action". In the context of fast convergence behavior, implementations have taken advantage of ISO 10589 Note 35 so that when multiple LSPs need to be flooded "atomically" the default delay between transmission of LSPs on the same circuit is not required for modest burst sizes. Implementations also support delayed triggering of the Decision Process in a way which provides for quick response time - but delays long enough for multiple LSP updates to be processed if they are sent as per the guidelines above. What this draft tries to address is the cases where multiple LSP updates are required to provide all the updates for a particular event. It provides a way for the receiving ISs to know when they have received the full set of updates. In doing so, the above guidelines from 10589 should still be followed since it is still important to receive the full set of updates as quickly as possible so that the Decision Process is not unnecessarily delayed. While from an "academic" standpoint your proposal adds some determinism into the Update Process machinery for the multiple LSP case, it isn't clear to me from a practical standpoint that we would achieve significantly better behavior than is achievable today simply by following the guidelines/behaviors I listed above. Have you done any prototyping which demonstrates that an implementation which carefully follows the ISO 10589 guidelines in regards to flooding - and also uses a judicious method of triggering the Decision Process - is significantly improved by the use of the "transaction TLV"? In order to generate enthusiasm for this proposal I think that needs to be demonstrated with a real implementation. Otherwise we are adding complexity and consuming some LSP space without real gain. Some other issues that I think need to be more fully addressed: I rather suspect that once the Transaction TLV is introduced into a particular LSP it will be difficult to remove it. Any removal needs to be delayed long enough to insure that the full transaction has been flooded everywhere - and as removal of the transaction TLV would result in a new LSP update which is gratuitous the only way the transaction TLV could be removed "efficiently" is if there is a subsequent update which is confined to the single LSP. Also, in order for the introduction of the transaction TLV into a given LSP to not be the cause of moving other information out of that LSP into an LSP with different number you will need to reserve space for the transaction TLV in each LSP whether it is actually included in the LSP or not. So your proposal really amounts to carving out space for the transaction TLV in each LSP. This decreases the available LSP space (in a modest way) which might be a concern in scale environments. As LSPs can be purged (under certain conditions) by other systems, how you avoid "transaction confusion" in this case needs to be addressed. Minor Issues: The choice of the acronym "TID" is unfortunate as this can easily be confused with topology ids as used in RFC 5120 and http://datatracker.ietf.org/doc/draft-ietf-isis-mi/ The remark in 3.2.8 about "LSP maximum age (21 minutes usually)" isn't accurate. It is true that ISO 10589 defined Maxage as 1200 seconds (20 minutes) and ZeroAgeLifetime as 60 seconds, but modern implementations allow Maxage to be configurable and it is common to see values of 65000 (18 hours) used in deployments. In the references (Section 9.2) you really should be referencing the 2002 version of IOS 10589. Les
- [Isis-wg] Comments on draft-lu-isis-transaction-t… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Comments on draft-lu-isis-transacti… Wenhu Lu