IETF Logo Mail Archive

[Isis-wg] (no subject)

"appallar" <appallar@indiatimes.com> Wed, 14 April 2004 19:20 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17171 for <isis-wg-archive@odin.ietf.org>; Wed, 14 Apr 2004 15:20:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpoT-0004jc-7O for isis-wg-archive@odin.ietf.org; Wed, 14 Apr 2004 15:12:46 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EJCj0O018200 for isis-wg-archive@odin.ietf.org; Wed, 14 Apr 2004 15:12:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpeF-0003ZH-Cx for isis-wg-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 15:02:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15134 for <isis-wg-web-archive@ietf.org>; Wed, 14 Apr 2004 15:02:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDpeC-0000cY-00 for isis-wg-web-archive@ietf.org; Wed, 14 Apr 2004 15:02:08 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDpdI-0000X5-00 for isis-wg-web-archive@ietf.org; Wed, 14 Apr 2004 15:01:13 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDpcM-0000RA-00 for isis-wg-web-archive@ietf.org; Wed, 14 Apr 2004 15:00:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpWS-0006rN-MI; Wed, 14 Apr 2004 14:54:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpGz-0004Mr-MT for isis-wg@optimus.ietf.org; Wed, 14 Apr 2004 14:38:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13808 for <isis-wg@ietf.org>; Wed, 14 Apr 2004 14:38:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDpGw-0006tJ-00 for isis-wg@ietf.org; Wed, 14 Apr 2004 14:38:06 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDpG6-0006rs-00 for isis-wg@ietf.org; Wed, 14 Apr 2004 14:37:14 -0400
Received: from [203.199.93.15] (helo=WS0005.indiatimes.com) by ietf-mx with esmtp (Exim 4.12) id 1BDpFU-0006nq-00 for isis-wg@ietf.org; Wed, 14 Apr 2004 14:36:36 -0400
Received: from 192.168.57.15 (a2 [192.168.57.22]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id XAA12664 for <isis-wg@ietf.org>; Wed, 14 Apr 2004 23:30:36 +0530
From: appallar <appallar@indiatimes.com>
Message-Id: <200404141800.XAA12664@WS0005.indiatimes.com>
To: isis-wg@ietf.org
Reply-To: appallar <appallar@indiatimes.com>
X-URL: http://indiatimes.com
Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_20044154012596516649"
MIME-Version: 1.0
Subject: [Isis-wg] (no subject)
Sender: isis-wg-admin@ietf.org
Errors-To: isis-wg-admin@ietf.org
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/isis-wg/>
Date: Thu, 15 Apr 2004 00:01:02 +0530
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_GREEN,HTML_MESSAGE,NORMAL_HTTP_TO_IP autolearn=no version=2.60

 Hello,

 When an LSP ages out, should the checksum recalculated and modified, or left unmodified?
as per ISO 10589, check sum should not be modified. In section 7.3.16.4, "Note 32" says a check of the checksum succeeds even though the data portion is not present.

How about the authentication part? do an implementation keep authentication while aging LSPs?
and if authentication information is present, how does checksum succeeds?

as per RFC 3719, if the checksum errors found, the LSPs are dropped, so do all implementations check Remaining life time before check sum??

Thanks in advance,
SuryanarayanaIndiatimes Email now powered by APIC Advantage. Help! 
HelpClick on the image to chat with me

v2.46.0 | Report a Bug | By Email | System Status