From isis-wg-admin@ietf.org  Thu Apr  1 08:11:40 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10613
	for <isis-archive@lists.ietf.org>; Thu, 1 Apr 2004 08:11:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B91yG-0002E7-PK; Thu, 01 Apr 2004 08:11:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B91xU-0002CE-8L
	for isis-wg@optimus.ietf.org; Thu, 01 Apr 2004 08:10:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10463
	for <isis-wg@ietf.org>; Thu, 1 Apr 2004 08:10:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B91xT-0007i0-00
	for isis-wg@ietf.org; Thu, 01 Apr 2004 08:10:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B91wc-0007bp-00
	for isis-wg@ietf.org; Thu, 01 Apr 2004 08:09:19 -0500
Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B91vp-0007P3-00
	for isis-wg@ietf.org; Thu, 01 Apr 2004 08:08:30 -0500
Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19)
	id <HSJF8P1W>; Thu, 1 Apr 2004 14:08:06 +0100
Message-ID: <37701240971DD31193970000F6CCB9F7050420A0@duke.datcon.co.uk>
From: Jonathan Harrison <jon.harrison@dataconnection.com>
To: "'jparker@axiowave.com'" <jparker@axiowave.com>, isis-wg@ietf.org
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [Isis-wg] Comments on draft-ietf-isis-wg-mib-13.txt
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, 1 Apr 2004 14:07:44 +0100

Hi,

We've recently been examining the IS-IS MIB, draft-ietf-isis-wg-mib-13.  In
addition to a number of minor details (which will follow in a separate
mail), we have come up with a number of issues.  These are described below,
along with our initial thoughts on the suggested solutions.

If you could let me know if you think the solutions are along the right
lines, I can propose any detailed re-wording required in the MIB text.

Thanks,
Jon
-------------------------------------------
Jon Harrison
Network Protocols Group
Data Connection Ltd
Tel:	+44 20 8366 1177                 
Fax:	+44 20 8363 1039
Email:	jrh@dataconnection.com    
Web:	http://www.dataconnection.com


MIB ISSUES
==========

1) The isisIPRATable has just the system instance and destination prefix as
the index.  However, a single destination prefix may be associated with
multiple equal cost next hops, and so we should extend the MIB to make any
additional next hops accessible.  The simplest way to do this would be to
make the next hop itself part of the index.

2) Where possible, it is helpful to provide default values for MIB objects.
Could we default isisCirc3WayEnabled to 'true'?  Also, would it be possible
to provide a default for isisCircExtendedCircID?  (In fact, it would make
sense to always use isisCircIndex for the extended circuit ID, since it has
the same requirement for uniqueness.)

3) The description of isisPacketCountIIHello could be changed to "IIH PDUs
are counted at the lowest enabled level: at L1 on L1 or L1L2 circuits, and
at L2 otherwise."  This makes the object consistent with
isisPacketCountISHello and isisPacketCountESHello.

4) There are two MIB objects that count the number of mismatches of max area
addresses.  Each circuit has the isisCircMaxAreaAddrMismatches count, plus
there is the overall count in the system statistics table,
isisSysStatMaxAreaAddrMismatches.  I think we should remove one of these
superfluous objects.

5) RFC 2763 allows a hostname to be included in the local non-pseudonode
LSP.  Although this will normally be the system name, the RFC does allow the
hostname TLV to contain any string that the operator wants to use for the
router.  This suggests that the IS-IS MIB should allow this string to be
configured.  This could be done using a new object in the isisSys table,
such as isisSysHostname.  Some implementations will always want to configure
the hostname automatically, so we would need to add some comments similar to
those describing the ManualOrAutomatic behavior.


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Apr  1 15:34:28 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00650
	for <isis-archive@lists.ietf.org>; Thu, 1 Apr 2004 15:34:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B98qJ-0005xK-SR; Thu, 01 Apr 2004 15:31:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B94oQ-0000W0-BL
	for isis-wg@optimus.ietf.org; Thu, 01 Apr 2004 11:13:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14675
	for <isis-wg@ietf.org>; Thu, 1 Apr 2004 09:30:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B93Cz-00015n-00
	for isis-wg@ietf.org; Thu, 01 Apr 2004 09:30:17 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B93C8-00010m-00
	for isis-wg@ietf.org; Thu, 01 Apr 2004 09:29:24 -0500
Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B93BW-0000tb-00
	for isis-wg@ietf.org; Thu, 01 Apr 2004 09:28:46 -0500
Message-ID: <EB5FFC72F183D411B38200062957342904831E04@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Jonathan Harrison'" <jon.harrison@dataconnection.com>, isis-wg@ietf.org
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Isis-wg] RE: Comments on draft-ietf-isis-wg-mib-13.txt
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, 1 Apr 2004 09:28:08 -0500

Jon -
	Thanks for the suggestions.  Comments below.
 
> 1) The isisIPRATable ... may be associated with
> multiple equal cost next hops

I'd be happy to look at a proposal
 
> 2) Could we default isisCirc3WayEnabled to 'true'?  

Fair enough

> ... provide a default for isisCircExtendedCircID? 

Can we use a variable as a default?  I will need to 
consult with the Mib Doctors

> it would make sense to always use isisCircIndex 
> for the extended circuit ID, since it has
> the same requirement for uniqueness.)

Does anyone have an issue with that?  The isisCircIndex
is not required to match the underlying ifIndex.

RFC 3373             Three-Way Handshake for IS-IS        September 2002
   ....
   Extended Local Circuit ID
      Unique ID assigned to this circuit when it is created by this
      Intermediate system.

Katz & Saluja                Informational                      [Page 5]

vs
    isisCircIndex OBJECT-TYPE
        SYNTAX Integer32 (1..2000000000)
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "The identifier of this circuit, unique within the
             instance of the IS-IS protocol. This object follows
             the index behavior.  This is for SNMP Indexing
             purposes only and need not have any relation to
             any protocol value."
    ::= { isisCircEntry 1 }

I think that Dave Katz had a request to drop arbitrary restraints,
such as that in the SYNTAX clause above

> 3) The description of isisPacketCountIIHello could be changed 
> to "IIH PDUs are counted at the lowest enabled level: at L1 
> on L1 or L1L2 circuits, and at L2 otherwise."  This makes 
> the object consistent with isisPacketCountISHello and 
> isisPacketCountESHello.

Will do

> 4) There are two MIB objects that count the number of 
> mismatches of max area
> addresses.  Each circuit has the 
> isisCircMaxAreaAddrMismatches count, plus
> there is the overall count in the system statistics table,
> isisSysStatMaxAreaAddrMismatches.  I think we should remove 
> one of these
> superfluous objects.

I will take a look

> 5) RFC 2763 allows a hostname to be included in ... LSP
> Although this will normally be the system name, the RFC 
> does allow the hostname TLV to contain any string that 
> the operator wants to use for the router.  This suggests 
> that the IS-IS MIB should allow this string to be
> configured.  This could be done using a new object in the 
> isisSys table, such as isisSysHostname.  Some 
> implementations will always want to configure
> the hostname automatically, so we would need to add some 
> comments similar to those describing the 
> ManualOrAutomatic behavior.

I would prefer not to add another value that is close to,
but different enough from, a standard value.  Can you 
give me a reason why we would want to have the IS-IS
hostname be different from the system name?  

- jeff parker

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Apr  1 17:50:39 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05818
	for <isis-archive@lists.ietf.org>; Thu, 1 Apr 2004 17:50:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B994N-0005i1-T4; Thu, 01 Apr 2004 15:45:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B95vl-0001qz-TH
	for isis-wg@optimus.ietf.org; Thu, 01 Apr 2004 12:24:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17070
	for <isis-wg@ietf.org>; Thu, 1 Apr 2004 10:40:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B94If-00076w-00
	for isis-wg@ietf.org; Thu, 01 Apr 2004 10:40:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B94Hk-00071u-00
	for isis-wg@ietf.org; Thu, 01 Apr 2004 10:39:17 -0500
Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B94H1-0006sm-00
	for isis-wg@ietf.org; Thu, 01 Apr 2004 10:38:31 -0500
Message-ID: <EB5FFC72F183D411B38200062957342904831E07@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "ISIS-WG (E-mail)" <isis-wg@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Isis-wg] Updates to Mib
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, 1 Apr 2004 10:37:56 -0500

The IS-IS Mib editor is open for comments. 
 
There have been a few pending about the Notifications, which was a recent
addition.  Here is what I have done this morning.  

A number of compilers balk at the accessible-for-notify keyword.  I am told
that this is the correct keyword, and that the mib compilers need updating.
It is a royal pain.  

- jeff parker

--  Changes in version 14
--
--      Set DEFVAL for isisCirc3WayEnabled to true
--      Revised description for isisPacketCountIIHello
--      Removed isisSysStatMaxAreaAddrMismatches as
--          duplicating isisCircMaxAreaAddrMismatches
--      Replaced isisManAreaAddrExistState with isisManAreaAddr
--          in isisManualAddressDrops 
--      Drop isisSysLevelIndex in isisDatabaseOverload

19c26
<         LAST-UPDATED "200401191200Z" 
---
>         LAST-UPDATED "200404011200Z" 
1362a1370
>         DEFVAL { true }
1655,1656d1662
<             isisSysStatMaxAreaAddrMismatches
<                 Counter32,
1768,1779d1773
<     isisSysStatMaxAreaAddrMismatches OBJECT-TYPE
<         SYNTAX Counter32
<         UNITS "frames"
<         MAX-ACCESS read-only
<         STATUS current
<         DESCRIPTION
<             "Number of times a PDU is received with a different value
<              for MaximumAreaAddresses from that of the receiving
<              system."
<         REFERENCE "{ISIS.aoi MaximumAreaAddressesMismatches (118)}"
<     ::= { isisSystemCounterEntry 11 }
< 
1786c1780
<     ::= { isisSystemCounterEntry 12 }
---
>     ::= { isisSystemCounterEntry 11 }
1794c1788
<     ::= { isisSystemCounterEntry 13 }
---
>     ::= { isisSystemCounterEntry 12 }
2035,2036c2029,2030
<              Level 1 if the value of their Circuit Type
<              field is 1, and are counted at Level 2 otherwise."
---
>              the lowest enabled level: at L1 on L1 or L1L2 circuits, 
>              and at L2 otherwise."
3262d3255
<             isisSysLevelIndex,
3277c3270
<             isisManAreaAddrExistState
---
>             isisManAreaAddr 
3284c3277
<              isisManAreaAddrExistState describes the area that
---
>              isisManAreaAddr describes the area that
3710d3702
<             isisSysStatMaxAreaAddrMismatches,

 

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Fri Apr  2 12:01:21 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18396
	for <isis-archive@lists.ietf.org>; Fri, 2 Apr 2004 12:01:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B9Q7O-0004m3-If; Fri, 02 Apr 2004 09:58:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B9LPC-0007UH-Mm
	for isis-wg@optimus.ietf.org; Fri, 02 Apr 2004 04:56:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02028
	for <isis-wg@ietf.org>; Fri, 2 Apr 2004 04:56:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B9LP9-0004YO-00
	for isis-wg@ietf.org; Fri, 02 Apr 2004 04:56:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B9LOA-0004PW-00
	for isis-wg@ietf.org; Fri, 02 Apr 2004 04:55:03 -0500
Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B9LNj-0004HO-00
	for isis-wg@ietf.org; Fri, 02 Apr 2004 04:54:35 -0500
Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19)
	id <HSJF85A7>; Fri, 2 Apr 2004 10:54:06 +0100
Message-ID: <37701240971DD31193970000F6CCB9F7050420AE@duke.datcon.co.uk>
From: Jonathan Harrison <jon.harrison@dataconnection.com>
To: "'Jeff Parker'" <jparker@axiowave.com>, isis-wg@ietf.org
Subject: RE: [Isis-wg] RE: Comments on draft-ietf-isis-wg-mib-13.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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: Fri, 2 Apr 2004 10:53:33 +0100

Jeff,

I agree with your comments on 2), 3), 4) and 5).

On 1), I would suggest changing isisIPRATable as follows:

-- The IP Reachable Address Table

-- Each entry records information about a path to an IP reachable
-- address manually configured on this system or learned from
-- another protocol.

    isisIPRATable OBJECT-TYPE
        SYNTAX SEQUENCE OF IsisIPRAEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "The table of IP Reachable Addresses to networks,
             subnetworks or hosts either manually configured or
             learned from another protocol."
    ::= { isisIPReachAddr 1 }

    isisIPRAEntry OBJECT-TYPE
        SYNTAX IsisIPRAEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "Each entry defines a route to an IP Reachable Address to 
             a network, subnetwork or host.

             Each IP Reachable Address may have multiple entries in the
             table, one for each equal cost path to the reachable address." 
        INDEX { isisSysInstance,
                isisIPRADestType,
                isisIPRADest,
                isisIPRADestPrefixLen,
                isisIPRANextHopType,
                isisIPRANextHop }

In addition, isisIPRANextHopType and isisIPRANextHop are changed to have
MAX-ACCESS not-accessible.

Does this sound OK to you?

Thanks,
Jon


-----Original Message-----
From: Jeff Parker [mailto:jparker@axiowave.com]
Sent: 01 April 2004 15:28
To: Jonathan Harrison; isis-wg@ietf.org
Subject: [Isis-wg] RE: Comments on draft-ietf-isis-wg-mib-13.txt


Jon -
	Thanks for the suggestions.  Comments below.
 
> 1) The isisIPRATable ... may be associated with
> multiple equal cost next hops

I'd be happy to look at a proposal
 
> 2) Could we default isisCirc3WayEnabled to 'true'?  

Fair enough

> ... provide a default for isisCircExtendedCircID? 

Can we use a variable as a default?  I will need to 
consult with the Mib Doctors

> it would make sense to always use isisCircIndex 
> for the extended circuit ID, since it has
> the same requirement for uniqueness.)

Does anyone have an issue with that?  The isisCircIndex
is not required to match the underlying ifIndex.

RFC 3373             Three-Way Handshake for IS-IS        September 2002
   ....
   Extended Local Circuit ID
      Unique ID assigned to this circuit when it is created by this
      Intermediate system.

Katz & Saluja                Informational                      [Page 5]

vs
    isisCircIndex OBJECT-TYPE
        SYNTAX Integer32 (1..2000000000)
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "The identifier of this circuit, unique within the
             instance of the IS-IS protocol. This object follows
             the index behavior.  This is for SNMP Indexing
             purposes only and need not have any relation to
             any protocol value."
    ::= { isisCircEntry 1 }

I think that Dave Katz had a request to drop arbitrary restraints,
such as that in the SYNTAX clause above

> 3) The description of isisPacketCountIIHello could be changed 
> to "IIH PDUs are counted at the lowest enabled level: at L1 
> on L1 or L1L2 circuits, and at L2 otherwise."  This makes 
> the object consistent with isisPacketCountISHello and 
> isisPacketCountESHello.

Will do

> 4) There are two MIB objects that count the number of 
> mismatches of max area
> addresses.  Each circuit has the 
> isisCircMaxAreaAddrMismatches count, plus
> there is the overall count in the system statistics table,
> isisSysStatMaxAreaAddrMismatches.  I think we should remove 
> one of these
> superfluous objects.

I will take a look

> 5) RFC 2763 allows a hostname to be included in ... LSP
> Although this will normally be the system name, the RFC 
> does allow the hostname TLV to contain any string that 
> the operator wants to use for the router.  This suggests 
> that the IS-IS MIB should allow this string to be
> configured.  This could be done using a new object in the 
> isisSys table, such as isisSysHostname.  Some 
> implementations will always want to configure
> the hostname automatically, so we would need to add some 
> comments similar to those describing the 
> ManualOrAutomatic behavior.

I would prefer not to add another value that is close to,
but different enough from, a standard value.  Can you 
give me a reason why we would want to have the IS-IS
hostname be different from the system name?  

- jeff parker

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Fri Apr  2 12:02:37 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18486
	for <isis-archive@lists.ietf.org>; Fri, 2 Apr 2004 12:02:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B9Q7P-0004mM-OC; Fri, 02 Apr 2004 09:58:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1B9LQq-0007VW-SL
	for isis-wg@optimus.ietf.org; Fri, 02 Apr 2004 04:57:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02082
	for <isis-wg@ietf.org>; Fri, 2 Apr 2004 04:57:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1B9LQn-0004m2-00
	for isis-wg@ietf.org; Fri, 02 Apr 2004 04:57:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1B9LQ1-0004gL-00
	for isis-wg@ietf.org; Fri, 02 Apr 2004 04:56:58 -0500
Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk)
	by ietf-mx with esmtp (Exim 4.12)
	id 1B9LPW-0004XJ-00
	for isis-wg@ietf.org; Fri, 02 Apr 2004 04:56:26 -0500
Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2653.19)
	id <2A747P5G>; Fri, 2 Apr 2004 10:55:52 +0100
Message-ID: <37701240971DD31193970000F6CCB9F7050420AF@duke.datcon.co.uk>
From: Jonathan Harrison <jon.harrison@dataconnection.com>
To: "'Jeff Parker'" <jparker@axiowave.com>, isis-wg@ietf.org
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [Isis-wg] Minor comments on draft-ietf-isis-wg-mib-13.txt
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: Fri, 2 Apr 2004 10:55:43 +0100

Hi,

We've got a number of minor suggested clarifications and typo fixes to the
MIB, itemized below.  Hopefully, these won't be too controversial!

Please let me know what you think.

Thanks,
Jon
-------------------------------------------
Jon Harrison
Network Protocols Group
Data Connection Ltd
Tel:	+44 20 8366 1177                 
Fax:	+44 20 8363 1468
Email:	jrh@dataconnection.com    
Web:	http://www.dataconnection.com


SUGGESTED FIXES
===============

 - The MIB defines the type WideMetric for 24 bit values and the type
FullMetric for 32 bit values.  The syntax for FullMetric should be "SYNTAX
Unsigned32" rather than "SYNTAX Unsigned32 (0..16777215)".

 - The second sentence of the description of isisSysMaxAge should read "This
should be at least 300 seconds greater than isisSysMaxLSPGenInt."
 
 - isisSysInstance and isisSysLevelIndex are used in notifications, and so
the MIB compiler we use gives warnings because these objects have MAX-ACCESS
not-accessible.  Should these objects have MAX-ACCESS read-only (or
accessible-for-notify) instead?

 - Both isisCircPassiveCircuit and isisCircLevelCSNPInterval have an empty
REFERENCE "{}".  The reference for isisCircPassiveCircuit should be removed.
The reference for isisCircLevelCSNPInterval should be {ISIS.aoi
completeSNPInterval (8)}.

 - isisISAdjIndex - the description should read "This value is automatically
assigned by the system when the adjacency is created."

 - The references sometimes refer to level 1 objects, sometimes level 2
object (for example, l1DefaultMetric and l2DesignatedIntermediateSystem).
It would be more consistent to just refer to L1 objects, if possible.

 - The description for isisISAdjAreaAddrIndex should read "This provides a
simple way to walk the table."

 - The description of isisLSPSummaryEntry description has a typo - should be
"Each entry describes an LSP currently stored in the system."

 - In the LSP table description change "tupples" to "tuples".

 - To make the capitalization consistent, the description of isisLSPTLVType
should read "The type of this TLV".

 - The description of isisCircExtendedCircID could be clarified as follows
"The value to be used as the extended circuit ID in 3Way handshake.  This
value is only used if isisCirc3WayEnabled is true, and must be unique across
all circuits on this IS."

 - The description of the isisNotificationTable should read "Objects seen in
the most recent notification from this instance of the IS-IS protocol."

 - isisPduOriginatingBufferSize - The description should read "Holds the
size of isisSysOrigLSPBuffSize advertised by the peer in the
originatingLSPBufferSize TLV."

 - To make it (even more!) obvious that the minimum LSP generation interval
should be less than the maximum interval, modify the description of
isisSysMaxLSPGenInt as follows "The value must be greater than any value
configured for isisSysLevelMinLSPGenInt, and should be at least 300 seconds
less than isisSysMaxAge."  Similarly, add to the description of
isisSysLevelMinLSPGenInt "The value must be less than isisSysMaxLSPGenInt." 

 - isisSysTable description has a missing 's'.  Should be "The set of
instances of the Integrated IS-IS protocol existing on the system."

 - Add "This object follows the resettingTimer behavior." to the description
of the isisCircLevelCSNPInterval.

 - For consistency, isisISAdjIPAddressType and isisISAdjIPAddress should be
named isisISAdjIPAddrType and isisISAdjIPAddrAddress.

 - isisCircInitFails refers to "ISIS.aoi  initialisationFailures", which
counts specific adjacency initialization failures due to having no version
or area address in common.  The MIB should spell this out.  For example,
"The number of times initialization of an adjacency on this circuit has
failed due to the peer having either no version or no area address in common
with the local system."

 - Finally, isisCircLevelID.  I'd like to clarify whether this object is
only used for point to point circuits (as suggested by the reference to
ptPtCircuitID), or whether this field can be given a sensible value for a
LAN (since the CircuitID syntax doesn't give an option to return a zero
length OCTET STRING).

If the field does take a value on a LAN (with the disadvantage of making the
meaning of the field less clear), then the following text could be used.

"On a point to point circuit with a fully initialized adjacency to a peer
IS, the value of this object is the circuit ID negotiated during adjacency
initialization.  In all other cases, the value is the concatenation of the
local system ID and the one byte isisCircLevelIDOctet for this circuit.
This is the value that would be proposed for the circuit ID on a point to
point circuit, or for the LAN ID should this node be chosen as the LAN
Designated IS."

Or if the field is purely for use as the ptPtCircuitID, I suggest we change
the Circuit ID syntax to "OCTET STRING (SIZE(0|7))", and change the
description as follows:

"On a point to point circuit with a fully initialized adjacency to a peer
IS, the value of this object is the circuit ID negotiated during adjacency
initialization.  On a point to point circuit without such an adjacency, the
value is the concatenation of the local system ID and the one byte
isisCircLevelIDOctet for this circuit i.e. the value that would be proposed
for the circuit ID.

On other circuit types, the value returned is the zero length OCTET STRING."




_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Mon Apr  5 13:41:01 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19297
	for <isis-archive@lists.ietf.org>; Mon, 5 Apr 2004 13:41:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BAY4r-00031v-Ff; Mon, 05 Apr 2004 13:40:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BAY4N-0002pp-Lr
	for isis-wg@optimus.ietf.org; Mon, 05 Apr 2004 13:39:36 -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 NAA19000
	for <isis-wg@ietf.org>; Mon, 5 Apr 2004 13:39:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BAY4L-0002J9-00
	for isis-wg@ietf.org; Mon, 05 Apr 2004 13:39:33 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BAY0G-0001Wy-00
	for isis-wg@ietf.org; Mon, 05 Apr 2004 13:35:22 -0400
Received: from [208.45.133.202] (helo=excite.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BAXoA-00079o-00
	for isis-wg@ietf.org; Mon, 05 Apr 2004 13:22:50 -0400
Received: from xprdmailfe9.nwk.excite.com (xprdmailfe9.nwk.excite.com [10.50.30.38])
	by xmxpita.excite.com (Postfix) with ESMTP
	id C1AAB1861A; Mon,  5 Apr 2004 13:22:15 -0400 (EDT)
Received: by xprdmailfe9.nwk.excite.com (Postfix, from userid 110)
	id C1CDC393F; Mon,  5 Apr 2004 13:22:12 -0400 (EDT)
To: jon.harrison@dataconnection.com, jparker@axiowave.com, isis-wg@ietf.org
Subject: RE: [Isis-wg] Minor comments on draft-ietf-isis-wg-mib-13.txt
Received: from [64.47.48.10] by xprdmailfe9.nwk.excite.com via HTTP; Mon, 05 Apr 2004 13:22:12 EST
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4
Reply-To: dgoodspe@excite.com
From: "Don Goodspeed" <dgoodspe@excite.com>
MIME-Version: 1.0
X-Sender: dgoodspe@excite.com
X-Mailer: PHP
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <20040405172212.C1CDC393F@xprdmailfe9.nwk.excite.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
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: Mon,  5 Apr 2004 13:22:12 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Jon,

Had a chance to review your comments since I helped generate/
contribute to a couple of the attributes, tables, TCs, etc.
that you mentioned.  I agree with most of the text changes.
The only points I did not have an opinion on were:
 - the change of the isisSysInstance and isisSysLevelIndex
   to accessible-for-notify
 - the references to "l1" vs "l2" being more consistent
 - The rename of the isisISAdjAddress... objects to Addr...

On your last discussion point on isisCircLevelID, I think the
latter suggestion is the one to go with (purely used as the
ptPtCircuitID) but I'd like others to comment.

Cheers,
Don
=======================================
Hi,

We've got a number of minor suggested clarifications and typo fixes to the
MIB, itemized below. Hopefully, these won't be too controversial!

Please let me know what you think.

Thanks,
Jon
-------------------------------------------
Jon Harrison
Network Protocols Group
Data Connection Ltd
Tel:     +44 20 8366 1177
Fax:     +44 20 8363 1468
Email:     jrh@dataconnection.com
Web:     http://www.dataconnection.com


SUGGESTED FIXES
===============

- The MIB defines the type WideMetric for 24 bit values and the type
FullMetric for 32 bit values. The syntax for FullMetric should be "SYNTAX
Unsigned32" rather than "SYNTAX Unsigned32 (0..16777215)".

- The second sentence of the description of isisSysMaxAge should read "This
should be at least 300 seconds greater than isisSysMaxLSPGenInt."

- isisSysInstance and isisSysLevelIndex are used in notifications, and so
the MIB compiler we use gives warnings because these objects have MAX-ACCESS
not-accessible. Should these objects have MAX-ACCESS read-only (or
accessible-for-notify) instead?

- Both isisCircPassiveCircuit and isisCircLevelCSNPInterval have an empty
REFERENCE "{}". The reference for isisCircPassiveCircuit should be removed.
The reference for isisCircLevelCSNPInterval should be {ISIS.aoi
completeSNPInterval (8)}.

- isisISAdjIndex - the description should read "This value is automatically
assigned by the system when the adjacency is created."

- The references sometimes refer to level 1 objects, sometimes level 2
object (for example, l1DefaultMetric and l2DesignatedIntermediateSystem).
It would be more consistent to just refer to L1 objects, if possible.

- The description for isisISAdjAreaAddrIndex should read "This provides a
simple way to walk the table."

- The description of isisLSPSummaryEntry description has a typo - should be
"Each entry describes an LSP currently stored in the system."

- In the LSP table description change "tupples" to "tuples".

- To make the capitalization consistent, the description of isisLSPTLVType
should read "The type of this TLV".

- The description of isisCircExtendedCircID could be clarified as follows
"The value to be used as the extended circuit ID in 3Way handshake. This
value is only used if isisCirc3WayEnabled is true, and must be unique across
all circuits on this IS."

- The description of the isisNotificationTable should read "Objects seen in
the most recent notification from this instance of the IS-IS protocol."

- isisPduOriginatingBufferSize - The description should read "Holds the
size of isisSysOrigLSPBuffSize advertised by the peer in the
originatingLSPBufferSize TLV."

- To make it (even more!) obvious that the minimum LSP generation interval
should be less than the maximum interval, modify the description of
isisSysMaxLSPGenInt as follows "The value must be greater than any value
configured for isisSysLevelMinLSPGenInt, and should be at least 300 seconds
less than isisSysMaxAge." Similarly, add to the description of
isisSysLevelMinLSPGenInt "The value must be less than isisSysMaxLSPGenInt."

- isisSysTable description has a missing 's'. Should be "The set of
instances of the Integrated IS-IS protocol existing on the system."

- Add "This object follows the resettingTimer behavior." to the description
of the isisCircLevelCSNPInterval.

- For consistency, isisISAdjIPAddressType and isisISAdjIPAddress should be
named isisISAdjIPAddrType and isisISAdjIPAddrAddress.

- isisCircInitFails refers to "ISIS.aoi initialisationFailures", which
counts specific adjacency initialization failures due to having no version
or area address in common. The MIB should spell this out. For example,
"The number of times initialization of an adjacency on this circuit has
failed due to the peer having either no version or no area address in common
with the local system."

- Finally, isisCircLevelID. I'd like to clarify whether this object is
only used for point to point circuits (as suggested by the reference to
ptPtCircuitID), or whether this field can be given a sensible value for a
LAN (since the CircuitID syntax doesn't give an option to return a zero
length OCTET STRING).

If the field does take a value on a LAN (with the disadvantage of making the
meaning of the field less clear), then the following text could be used.

"On a point to point circuit with a fully initialized adjacency to a peer
IS, the value of this object is the circuit ID negotiated during adjacency
initialization. In all other cases, the value is the concatenation of the
local system ID and the one byte isisCircLevelIDOctet for this circuit.
This is the value that would be proposed for the circuit ID on a point to
point circuit, or for the LAN ID should this node be chosen as the LAN
Designated IS."

Or if the field is purely for use as the ptPtCircuitID, I suggest we change
the Circuit ID syntax to "OCTET STRING (SIZE(0|7))", and change the
description as follows:

"On a point to point circuit with a fully initialized adjacency to a peer
IS, the value of this object is the circuit ID negotiated during adjacency
initialization. On a point to point circuit without such an adjacency, the
value is the concatenation of the local system ID and the one byte
isisCircLevelIDOctet for this circuit i.e. the value that would be proposed
for the circuit ID.

On other circuit types, the value returned is the zero length OCTET STRING."




_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Mon Apr  5 17:03:43 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09570
	for <isis-archive@lists.ietf.org>; Mon, 5 Apr 2004 17:03:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BAbFF-0003QZ-Tr; Mon, 05 Apr 2004 17:03:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BAbES-0003L4-Al
	for isis-wg@optimus.ietf.org; Mon, 05 Apr 2004 17:02:12 -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 RAA09193
	for <isis-wg@ietf.org>; Mon, 5 Apr 2004 17:02:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BAbEQ-0003nB-00
	for isis-wg@ietf.org; Mon, 05 Apr 2004 17:02:10 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BAb2n-0001aa-00
	for isis-wg@ietf.org; Mon, 05 Apr 2004 16:50:10 -0400
Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BAabv-0006Vg-00
	for isis-wg@ietf.org; Mon, 05 Apr 2004 16:22:23 -0400
Message-ID: <EB5FFC72F183D411B38200062957342904831E64@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'dgoodspe@excite.com'" <dgoodspe@excite.com>,
        jon.harrison@dataconnection.com, Jeff Parker <jparker@axiowave.com>,
        isis-wg@ietf.org
Subject: [Isis-wg] Minor comments on draft-ietf-isis-wg-mib-13.txt
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
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: Mon, 5 Apr 2004 16:21:47 -0400

More private comments on the Mib: the issue of Corrupted LSP and
AuthFailures.  Relevant portions of mib are below.  

1) The isisCorruptedLSPDetected states that it is to announce the detection
of an in-mmeory corruption.  I have found it much more useful to announce
the detection of on-the wire corrupted LSPs.  

Proposal: 
	A) modify the Description to include Corrupted LSPs found on the
wire
	B) modify the object to include the isisCircIfIndex where we found
the packet.  If the LSP is really corrupted, the sysid would be suspect.  

2) For isisAuthenticationTypeFailure and isisAuthenticationFailure, we
include the packet header, level, and circ index.  Would it be useful to
include the packet type?  While this is contained in the PDU fragment, it
may help developers working on trap handlers to know the packet type.  If
so, do we want all packet types, or just to distinguish between hello
packets and the rest, as the authenetication for these packets are
configured differently.

Proposal: Add an object to both Auth Traps that will ease dispatching on
packet type.  

- jeff parker

    isisCorruptedLSPDetected NOTIFICATION-TYPE
        OBJECTS {
            isisSysInstance,
            isisSysLevelIndex,
            isisPduLspId
        }
        STATUS current
        DESCRIPTION
            "This notification is generated when we find that
             an LSP that was stored in memory has become
             corrupted.  The number of times this has been
             generated is counted by isisSysCorrLSPs.

             We forward an LSP ID.  We may have independent
             knowledge of the ID, but in some implementations
             there is a chance that the ID itself will be
             corrupted."

    ::= { isisTrapPrefix 3 }

    isisAuthenticationTypeFailure NOTIFICATION-TYPE
        OBJECTS {
            isisSysInstance,
            isisSysLevelIndex,
            isisCircIfIndex,
            isisPduFragment
        }
        STATUS current
        DESCRIPTION
            "A notification sent when we receive a PDU
             with the wrong authentication type field.
             This notification includes the header of the
             packet, which may help a network manager
             identify the source of the confusion.

             This should be an edge-triggered notification.
             We should not send a second notification about
             PDUs received from what seem to be the same source."

    ::= { isisTrapPrefix 9 }

    isisAuthenticationFailure NOTIFICATION-TYPE
        OBJECTS {
            isisSysInstance,
            isisSysLevelIndex,
            isisCircIfIndex,
            isisPduFragment
        }
        STATUS current
        DESCRIPTION
            "A notification sent when we receive a PDU
             with incorrect authentication information
             field.  This notification includes the header
             of the packet, which may help a network manager
             identify the source of the confusion.

             This should be an edge-triggered notification.
             We should not send a second notification about
             PDUs received from what seem to be the same source."

    ::= { isisTrapPrefix 10 }

- jeff parker
- axiowave networks
- As scarce as truth is, the supply has always been in excess of the demand
- Josh Billings
 

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Mon Apr  5 17:32:37 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10317
	for <isis-archive@lists.ietf.org>; Mon, 5 Apr 2004 17:32:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BAbhJ-0002JV-EZ; Mon, 05 Apr 2004 17:32:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BAbhE-0002Ie-EX
	for isis-wg@optimus.ietf.org; Mon, 05 Apr 2004 17:31:56 -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 RAA10313
	for <isis-wg@ietf.org>; Mon, 5 Apr 2004 17:31:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BAbhC-0006bm-00
	for isis-wg@ietf.org; Mon, 05 Apr 2004 17:31:54 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BAbF4-0003uQ-00
	for isis-wg@ietf.org; Mon, 05 Apr 2004 17:02:51 -0400
Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BAb4C-0001kM-00
	for isis-wg@ietf.org; Mon, 05 Apr 2004 16:51:36 -0400
Message-ID: <EB5FFC72F183D411B38200062957342904831E65@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Jonathan Harrison'" <jon.harrison@dataconnection.com>,
        Jeff Parker
	 <jparker@axiowave.com>, isis-wg@ietf.org
Subject: [Isis-wg] Minor comments on draft-ietf-isis-wg-mib-13.txt
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
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: Mon, 5 Apr 2004 16:51:02 -0400

Jonathan -

I am accepting almost all of you helpful suggestions.  
However, this gave me pause.  I would thnk that the
two reasons you spell out would apply to isisCircRejAdjs, 
while InitFails would count link problems, such as NCP
failures on PPP.  You are probably right about the reference,
but I would argue that there are more reasons to drop adjacencies
today (non-matching IP adress, disagreements on 3-way handshake,..)
and we should put your two events in CircRejAdjs.  

- jeff parker

 - isisCircInitFails refers to "ISIS.aoi initialisationFailures", which
counts specific adjacency initialization failures due to having no version
or area address in common.  The MIB should spell this out.  For example,
"The number of times initialization of an adjacency on this circuit has
failed due to the peer having either no version or no area address in common
with the local system." 

Relevant objects below

    isisCircInitFails OBJECT-TYPE
        SYNTAX Counter32
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The number of times initialization of this circuit has
             failed."
        REFERENCE "{ISIS.aoi initialisationFailures (41)}"
    ::= { isisCircuitCounterEntry 4 }

    isisCircRejAdjs OBJECT-TYPE
        SYNTAX Counter32
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The number of times an adjacency has been rejected on
             this circuit."
        REFERENCE "{ISIS.aoi rejectedAdjacencies (42)}"
    ::= { isisCircuitCounterEntry 5 }

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Mon Apr  5 18:03:34 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14216
	for <isis-archive@lists.ietf.org>; Mon, 5 Apr 2004 18:03:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BAcBK-0004zL-1l; Mon, 05 Apr 2004 18:03:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BAcAP-00046R-L4
	for isis-wg@optimus.ietf.org; Mon, 05 Apr 2004 18:02:05 -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 SAA13939
	for <isis-wg@ietf.org>; Mon, 5 Apr 2004 18:02:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BAcAM-00035C-00
	for isis-wg@ietf.org; Mon, 05 Apr 2004 18:02:02 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BAbtI-0007f2-00
	for isis-wg@ietf.org; Mon, 05 Apr 2004 17:44:26 -0400
Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BAbGb-00047W-00
	for isis-wg@ietf.org; Mon, 05 Apr 2004 17:04:25 -0400
Message-ID: <EB5FFC72F183D411B38200062957342904831E66@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Jonathan Harrison'" <jon.harrison@dataconnection.com>,
        Jeff Parker
	 <jparker@axiowave.com>, isis-wg@ietf.org
Subject: [Isis-wg] Minor comments on draft-ietf-isis-wg-mib-13.txt
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
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: Mon, 5 Apr 2004 17:03:48 -0400

Jon -
	Since we have the isisCircLevelDesIS to define the CircID for LANs,
I see no problem restricting isisCircLevelID to P2P circuits. 
	Any issues with this?

	Your mail, and relevant portions of mib follow.  
  
- jeff parker

- Finally, isisCircLevelID.  I'd like to clarify whether this object is
only used for point to point circuits (as suggested by the reference to
ptPtCircuitID), or whether this field can be given a sensible value for a
LAN (since the CircuitID syntax doesn't give an option to return a zero
length OCTET STRING).

If the field does take a value on a LAN (with the disadvantage of making the
meaning of the field less clear), then the following text could be used.

"On a point to point circuit with a fully initialized adjacency to a peer
IS, the value of this object is the circuit ID negotiated during adjacency
initialization.  In all other cases, the value is the concatenation of the
local system ID and the one byte isisCircLevelIDOctet for this circuit.
This is the value that would be proposed for the circuit ID on a point to
point circuit, or for the LAN ID should this node be chosen as the LAN
Designated IS."

Or if the field is purely for use as the ptPtCircuitID, I suggest we change
the Circuit ID syntax to "OCTET STRING (SIZE(0|7))", and change the
description as follows:

"On a point to point circuit with a fully initialized adjacency to a peer
IS, the value of this object is the circuit ID negotiated during adjacency
initialization.  On a point to point circuit without such an adjacency, the
value is the concatenation of the local system ID and the one byte
isisCircLevelIDOctet for this circuit i.e. the value that would be proposed
for the circuit ID.

On other circuit types, the value returned is the zero length OCTET STRING."

    isisCircLevelID OBJECT-TYPE
        SYNTAX CircuitID
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The ID of the circuit allocated during initialization.
             If no value has been negotiated (either because the
             adjacency is to an End System, or because initialization
             has not yet successfully completed), this object has the
             value which would be proposed for this circuit (i.e. the
             concatenation of the local system ID and the one byte
             isisCircLevelIDOctet for this circuit."
        REFERENCE "{ISIS.aoi ptPtCircuitID (51)}"
    ::= { isisCircLevelEntry 6 }

    isisCircLevelDesIS OBJECT-TYPE
        SYNTAX CircuitID
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The ID of the LAN Designated Intermediate System
             on this circuit at this level. If, for any reason,
             this system is not partaking in the relevant
             Designated Intermediate System election process,
             then the value returned is the zero length OCTET STRING."
        REFERENCE "{ISIS.aoi l2DesignatedIntermediateSystem (75)}"
    ::= { isisCircLevelEntry 7 }

    

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Apr  7 07:56:43 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15205
	for <isis-archive@lists.ietf.org>; Wed, 7 Apr 2004 07:56:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BBBez-0007N3-S7; Wed, 07 Apr 2004 07:56:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BBBeJ-0007IW-Hw
	for isis-wg@optimus.ietf.org; Wed, 07 Apr 2004 07:55:20 -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 HAA14889
	for <isis-wg@ietf.org>; Wed, 7 Apr 2004 07:55:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BBBeI-00030M-00
	for isis-wg@ietf.org; Wed, 07 Apr 2004 07:55:18 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BBAwV-0004UO-00
	for isis-wg@ietf.org; Wed, 07 Apr 2004 07:10:04 -0400
Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BB9jL-0003rH-00
	for isis-wg@ietf.org; Wed, 07 Apr 2004 05:52:23 -0400
Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19)
	id <HSJF08F5>; Wed, 7 Apr 2004 10:52:05 +0100
Message-ID: <37701240971DD31193970000F6CCB9F7050420E3@duke.datcon.co.uk>
From: Jonathan Harrison <jon.harrison@dataconnection.com>
To: "'Jeff Parker'" <jparker@axiowave.com>, isis-wg@ietf.org
Subject: RE: [Isis-wg] Minor comments on draft-ietf-isis-wg-mib-13.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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: Wed, 7 Apr 2004 10:51:40 +0100

Jeff,

I agree.  It is clearer to have isisCircLevelID restricted to P2P circuits.

Jon

-----Original Message-----
From: Jeff Parker [mailto:jparker@axiowave.com]
Sent: 05 April 2004 22:04
To: Jonathan Harrison; Jeff Parker; isis-wg@ietf.org
Subject: [Isis-wg] Minor comments on draft-ietf-isis-wg-mib-13.txt


Jon -
	Since we have the isisCircLevelDesIS to define the CircID for LANs,
I see no problem restricting isisCircLevelID to P2P circuits. 
	Any issues with this?

	Your mail, and relevant portions of mib follow.  
  
- jeff parker

- Finally, isisCircLevelID.  I'd like to clarify whether this object is
only used for point to point circuits (as suggested by the reference to
ptPtCircuitID), or whether this field can be given a sensible value for a
LAN (since the CircuitID syntax doesn't give an option to return a zero
length OCTET STRING).

If the field does take a value on a LAN (with the disadvantage of making the
meaning of the field less clear), then the following text could be used.

"On a point to point circuit with a fully initialized adjacency to a peer
IS, the value of this object is the circuit ID negotiated during adjacency
initialization.  In all other cases, the value is the concatenation of the
local system ID and the one byte isisCircLevelIDOctet for this circuit.
This is the value that would be proposed for the circuit ID on a point to
point circuit, or for the LAN ID should this node be chosen as the LAN
Designated IS."

Or if the field is purely for use as the ptPtCircuitID, I suggest we change
the Circuit ID syntax to "OCTET STRING (SIZE(0|7))", and change the
description as follows:

"On a point to point circuit with a fully initialized adjacency to a peer
IS, the value of this object is the circuit ID negotiated during adjacency
initialization.  On a point to point circuit without such an adjacency, the
value is the concatenation of the local system ID and the one byte
isisCircLevelIDOctet for this circuit i.e. the value that would be proposed
for the circuit ID.

On other circuit types, the value returned is the zero length OCTET STRING."

    isisCircLevelID OBJECT-TYPE
        SYNTAX CircuitID
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The ID of the circuit allocated during initialization.
             If no value has been negotiated (either because the
             adjacency is to an End System, or because initialization
             has not yet successfully completed), this object has the
             value which would be proposed for this circuit (i.e. the
             concatenation of the local system ID and the one byte
             isisCircLevelIDOctet for this circuit."
        REFERENCE "{ISIS.aoi ptPtCircuitID (51)}"
    ::= { isisCircLevelEntry 6 }

    isisCircLevelDesIS OBJECT-TYPE
        SYNTAX CircuitID
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The ID of the LAN Designated Intermediate System
             on this circuit at this level. If, for any reason,
             this system is not partaking in the relevant
             Designated Intermediate System election process,
             then the value returned is the zero length OCTET STRING."
        REFERENCE "{ISIS.aoi l2DesignatedIntermediateSystem (75)}"
    ::= { isisCircLevelEntry 7 }

    

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Apr  7 08:45:27 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15206
	for <isis-archive@lists.ietf.org>; Wed, 7 Apr 2004 07:56:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BBBf0-0007NJ-8G; Wed, 07 Apr 2004 07:56:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BBBeI-0007IV-UM
	for isis-wg@optimus.ietf.org; Wed, 07 Apr 2004 07:55:20 -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 HAA14881
	for <isis-wg@ietf.org>; Wed, 7 Apr 2004 07:55:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BBBeH-000307-00
	for isis-wg@ietf.org; Wed, 07 Apr 2004 07:55:17 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BBAwR-0004Tc-00
	for isis-wg@ietf.org; Wed, 07 Apr 2004 07:10:00 -0400
Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BB9jA-0003qP-00
	for isis-wg@ietf.org; Wed, 07 Apr 2004 05:52:12 -0400
Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2653.19)
	id <234RY0C5>; Wed, 7 Apr 2004 10:51:34 +0100
Message-ID: <37701240971DD31193970000F6CCB9F7050420E2@duke.datcon.co.uk>
From: Jonathan Harrison <jon.harrison@dataconnection.com>
To: "'Jeff Parker'" <jparker@axiowave.com>, isis-wg@ietf.org
Subject: RE: [Isis-wg] Minor comments on draft-ietf-isis-wg-mib-13.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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: Wed, 7 Apr 2004 10:51:27 +0100

Jeff,

I agree that it does make sense to have these specific failures counted in
the isisCircRejAdjs.  We should still clarify the use of isisCircInitFails
though.

I think we should 

 - remove the reference to the "ISIS.aoi initialisationFailures"

 - change the description e.g. "The number of times that the underlying link
has failed."  (Possibly with an additional example?)

 - maybe even change the name to isisCircLinkFails.

What do you think?
Jon

-----Original Message-----
From: Jeff Parker [mailto:jparker@axiowave.com]
Sent: 05 April 2004 21:51
To: Jonathan Harrison; Jeff Parker; isis-wg@ietf.org
Subject: [Isis-wg] Minor comments on draft-ietf-isis-wg-mib-13.txt


Jonathan -

I am accepting almost all of you helpful suggestions.  
However, this gave me pause.  I would thnk that the
two reasons you spell out would apply to isisCircRejAdjs, 
while InitFails would count link problems, such as NCP
failures on PPP.  You are probably right about the reference,
but I would argue that there are more reasons to drop adjacencies
today (non-matching IP adress, disagreements on 3-way handshake,..)
and we should put your two events in CircRejAdjs.  

- jeff parker

 - isisCircInitFails refers to "ISIS.aoi initialisationFailures", which
counts specific adjacency initialization failures due to having no version
or area address in common.  The MIB should spell this out.  For example,
"The number of times initialization of an adjacency on this circuit has
failed due to the peer having either no version or no area address in common
with the local system." 

Relevant objects below

    isisCircInitFails OBJECT-TYPE
        SYNTAX Counter32
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The number of times initialization of this circuit has
             failed."
        REFERENCE "{ISIS.aoi initialisationFailures (41)}"
    ::= { isisCircuitCounterEntry 4 }

    isisCircRejAdjs OBJECT-TYPE
        SYNTAX Counter32
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The number of times an adjacency has been rejected on
             this circuit."
        REFERENCE "{ISIS.aoi rejectedAdjacencies (42)}"
    ::= { isisCircuitCounterEntry 5 }

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Apr 14 15:00:44 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14921
	for <isis-archive@lists.ietf.org>; Wed, 14 Apr 2004 15:00:43 -0400 (EDT)
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
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.8 required=5.0 tests=HTML_20_30,
	HTML_FONTCOLOR_GREEN,HTML_IMAGE_ONLY_12,HTML_MESSAGE,
	NORMAL_HTTP_TO_IP autolearn=no version=2.60
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

--=_MAILER_ATTACH_BOUNDARY1_20044154012596516649
Content-Type: text/plain; charset=us-ascii

 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

--=_MAILER_ATTACH_BOUNDARY1_20044154012596516649
Content-Type: text/html; charset=us-ascii

 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,
Suryanarayana<hr><font face="Arial" size="2">Indiatimes Email now powered by <b>APIC Advantage</b>. <a href="http://email.indiatimes.com/apic/">Help!</a> </font><br><DIV align=left><a target="_blank" href="http://imaround.indiatimes.com/IMaround/presencefr.mss?userid=appallar" ><IMG alt="My Presence" border=0 src="http://203.199.93.51/IMaround/getpresence.mss?userid=appallar" ></a><a target="_blank" href="http://email.indiatimes.com/apic/instachat.htm"><FONT face="Arial" size=2>Help</font></a></DIV><DIV align=left><FONT color=#008000 face="Lucida Sans Unicode" size=1>Click on the image to chat with me</FONT></DIV>

--=_MAILER_ATTACH_BOUNDARY1_20044154012596516649--


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Apr 14 19:13:04 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04884
	for <isis-archive@lists.ietf.org>; Wed, 14 Apr 2004 19:13:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BDtSE-0001Af-Hd; Wed, 14 Apr 2004 19:06:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BDtQ0-0000er-TS
	for isis-wg@optimus.ietf.org; Wed, 14 Apr 2004 19:03:45 -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 TAA04604
	for <isis-wg@ietf.org>; Wed, 14 Apr 2004 19:03:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BDtPx-0004B4-00
	for isis-wg@ietf.org; Wed, 14 Apr 2004 19:03:41 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BDtP2-00049F-00
	for isis-wg@ietf.org; Wed, 14 Apr 2004 19:02:45 -0400
Received: from rwcrmhc12.comcast.net ([216.148.227.85])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BDtOe-00044s-00
	for isis-wg@ietf.org; Wed, 14 Apr 2004 19:02:20 -0400
Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40])
          by comcast.net (rwcrmhc12) with SMTP
          id <20040414230145014001c4k4e>; Wed, 14 Apr 2004 23:01:46 +0000
In-Reply-To: <200404141800.XAA12664@WS0005.indiatimes.com>
References: <200404141800.XAA12664@WS0005.indiatimes.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B196CF13-8E67-11D8-BC33-000A95D1475E@tony.li>
Content-Transfer-Encoding: 7bit
Cc: <isis-wg@ietf.org>
From: Tony Li <tony.li@tony.li>
Subject: Re: [Isis-wg] (no subject)
To: "appallar" <appallar@indiatimes.com>
X-Mailer: Apple Mail (2.613)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
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: Wed, 14 Apr 2004 16:01:41 -0700
Content-Transfer-Encoding: 7bit


We tried to explain this in the authentication RFC.  If there is no body
to the LSP, then you can't really have authentication.  And without 
authentication, this gives folks a trivial way to attack you.  
Therefore, you MUST retain some portion of the body and, when 
authentication is enforced, you must ignore 0 age LSPs that have no 
body.

The system generating a 0 age LSP can either then retain the entire 
body of the LSP or remove the body and recalculate the authentication.  
Either is acceptable.

Tony



On Apr 14, 2004, at 11:31 AM, appallar wrote:

>  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, 
> Suryanarayana
> Indiatimes Email now powered by APIC Advantage. Help!
> <image.tiff>Help
> Click on the image to chat with me


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Apr 15 05:53:00 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14195
	for <isis-archive@lists.ietf.org>; Thu, 15 Apr 2004 05:53: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 1BE3SY-0001LS-6N; Thu, 15 Apr 2004 05:47:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BE3Pm-0000Wm-JL
	for isis-wg@optimus.ietf.org; Thu, 15 Apr 2004 05:44:10 -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 FAA13717
	for <isis-wg@ietf.org>; Thu, 15 Apr 2004 05:44:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BE3Pi-00074P-00
	for isis-wg@ietf.org; Thu, 15 Apr 2004 05:44:07 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BE3On-00070C-00
	for isis-wg@ietf.org; Thu, 15 Apr 2004 05:43:09 -0400
Received: from zephir.uk.clara.net ([195.8.69.53])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BE3OK-0006vt-00
	for isis-wg@ietf.org; Thu, 15 Apr 2004 05:42:40 -0400
Received: from du-069-0056.access.clara.net ([217.158.132.56] helo=Puppy)
	by zephir.uk.clara.net with smtp (Exim 4.22)
	id 1BE3OL-0005rK-8J
	for isis-wg@ietf.org; Thu, 15 Apr 2004 10:42:42 +0100
Message-ID: <007901c422cd$ff2a7870$83919ed9@Puppy>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <isis-wg@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Isis-wg] Heads up - CCAMP last call on draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt
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 10:42:36 +0100
Content-Transfer-Encoding: 7bit

Hi,

This is a heads up on the working group last call of a CCAMP informational draft that
crosses some working group boundaries. The last call ends on April 28th.
 
 http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt
captures the requirements placed on GMPLS routing protocols by the ITU-T's ASON
architecture.
 
 As the abstract puts it...
   The Generalized MPLS (GMPLS) suite of protocols has been defined to
   control different switching technologies as well as different
   applications. These include support for requesting TDM connections
   including SONET/SDH and Optical Transport Networks (OTNs).

   This document concentrates on the routing requirements on the GMPLS
   suite of protocols to support the capabilities and functionalities
   for an Automatically Switched Optical Network (ASON) as defined by
   ITU-T.
 
We would welcome any comments at this stage either on the CCAMP mailing list or direct to
the chairs:
Adrian Farrel adrian@olddog.co.uk
Kireeti Kompella kireeti@olddog.co.uk
 
Thanks,
Adrian
 

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Sun Apr 18 05:32:27 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09951
	for <isis-archive@lists.ietf.org>; Sun, 18 Apr 2004 05:32:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BF8Xw-0004lB-1Z; Sun, 18 Apr 2004 05:25:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BF8ND-0002Ll-P9
	for isis-wg@optimus.ietf.org; Sun, 18 Apr 2004 05:14:00 -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 FAA08731
	for <isis-wg@ietf.org>; Sun, 18 Apr 2004 05:13:57 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BF8NA-0007iK-G6
	for isis-wg@ietf.org; Sun, 18 Apr 2004 05:13:56 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BF8MC-0007Vw-00
	for isis-wg@ietf.org; Sun, 18 Apr 2004 05:12:57 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BF8LR-0007Dy-00
	for isis-wg@ietf.org; Sun, 18 Apr 2004 05:12:09 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 18 Apr 2004 01:22:46 +0000
Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3I9BcnH027335;
	Sun, 18 Apr 2004 02:11:38 -0700 (PDT)
Received: from ginsberg-w2k.cisco.com (sjc-vpn1-541.cisco.com [10.21.98.29])
	by mira-sjc5-a.cisco.com (MOS 3.4.5-GR)
	with ESMTP id APV19109;
	Sun, 18 Apr 2004 02:10:40 -0700 (PDT)
Message-Id: <4.3.2.7.2.20040418013956.01c1b320@mira-sjc5-3.cisco.com>
X-Sender: ginsberg@mira-sjc5-3.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Tony Li <tony.li@tony.li>
From: Les Ginsberg <ginsberg@cisco.com>
Subject: Re: [Isis-wg] (no subject)
Cc: "appallar" <appallar@indiatimes.com>, <isis-wg@ietf.org>
In-Reply-To: <B196CF13-8E67-11D8-BC33-000A95D1475E@tony.li>
References: <200404141800.XAA12664@WS0005.indiatimes.com>
 <200404141800.XAA12664@WS0005.indiatimes.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_64870649==_.ALT"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no 
	version=2.60
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: Sun, 18 Apr 2004 02:11:42 -0700

--=====================_64870649==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:01 PM 4/14/2004 -0700, Tony Li wrote:

>We tried to explain this in the authentication RFC.  If there is no body
>to the LSP, then you can't really have authentication.  And without 
>authentication, this gives folks a trivial way to attack you.
>Therefore, you MUST retain some portion of the body and, when 
>authentication is enforced, you must ignore 0 age LSPs that have no body.
>
>The system generating a 0 age LSP can either then retain the entire body 
>of the LSP or remove the body and recalculate the authentication.
>Either is acceptable.
>
>Tony
>

Although I hesitate to critique the author of the authentication RFC, the 
answer Tony has provided is actually partly at odds with both RFC 3567 and 
ISO 10589. RFC 3567 says:

"ISes(routers) that implement HMAC-MD5 authentication and initiate LSP
    purges MUST remove the body of the LSP and add the authentication
    TLV.  ISes implementing HMAC-MD5 authentication MUST NOT accept
    unauthenticated purges.  ISes MUST NOT accept purges that contain
    TLVs other than the authentication TLV."

ISO 10589  7.3.16.4 says:

"When the Remaining Lifetime on an LSP in memory becomes zero, the IS shall
a)      set all SRMflags for that LSP, and
b)      retain only the LSP header."

So both specs indicate that it is required that the body of an LSP be 
removed prior to purging and that the receiving system MUST (at least in 
the case of RFC 3567) reject purged LSPs that have anything in the body 
other than the authentication TLV.

I agree with Tony that retaining the body in a purged LSP in principle does 
no harm (other than wasting LSP DB space) but because there are 
implementations out there which adhere to the requirements in the two 
specs, it is quite possible that such an LSP will be rejected by some 
systems when received.

As for the original question, an old defect in 10589:1992 existed wherein 
Section 7.3.14.2e directed systems to purge received LSPs which had an 
incorrect checksum. This proved disruptive in practice and was corrected to 
indicate that the receiving system should ignore such an LSP (see 
corresponding section in 10589:2002). However, this correction did not 
extend to 7.3.14.2i (as it should have). The text in RFC 3719 is meant to 
clarify that all LSPs received with a checksum error, even if the invalid 
checksum is 0, should be ignored rather than purged.

As to why Note 32 (Note 36 in 10589:2002) is necessary, this is a result of:

7.3.11 which says: "The checksum shall never be modified by any other system"

AND

The quote above from 7.3.16.4 which requires the system issuing a purge to 
NOT retain the LSP body.

Taken literally, these two statements would require a system which is 
purging an LSP generated by another system to remove the body, thereby 
making the checksum invalid, and prohibit that system from recalculating 
the checksum. So unless the checksum check were suspended in the case of 
purged LSPs, it would fail on receive.

    Les



>On Apr 14, 2004, at 11:31 AM, appallar wrote:
>
>>  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, Suryanarayana
>>Indiatimes Email now powered by APIC Advantage. Help!
>><image.tiff>Help
>>Click on the image to chat with me
>
>
>_______________________________________________
>Isis-wg mailing list
>Isis-wg@ietf.org
>https://www1.ietf.org/mailman/listinfo/isis-wg

--=====================_64870649==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 04:01 PM 4/14/2004 -0700, Tony Li wrote:<br>
<br>
<blockquote type=cite cite>We tried to explain this in the authentication
RFC.&nbsp; If there is no body<br>
to the LSP, then you can't really have authentication.&nbsp; And without
authentication, this gives folks a trivial way to attack you.&nbsp; 
<br>
Therefore, you MUST retain some portion of the body and, when
authentication is enforced, you must ignore 0 age LSPs that have no
body.<br>
<br>
The system generating a 0 age LSP can either then retain the entire body
of the LSP or remove the body and recalculate the authentication.&nbsp;
<br>
Either is acceptable.<br>
<br>
Tony<br>
<br>
</blockquote><br>
Although I hesitate to critique the author of the authentication RFC, the
answer Tony has provided is actually partly at odds with both RFC 3567
and ISO 10589. RFC 3567 says:<br>
<br>
&quot;ISes(routers) that implement HMAC-MD5 authentication and initiate
LSP<br>
&nbsp;&nbsp; purges MUST remove the body of the LSP and add the
authentication<br>
&nbsp;&nbsp; TLV.&nbsp; ISes implementing HMAC-MD5 authentication MUST
NOT accept<br>
&nbsp;&nbsp; unauthenticated purges.&nbsp; ISes MUST NOT accept purges
that contain<br>
&nbsp;&nbsp; TLVs other than the authentication TLV.&quot;<br>
<br>
ISO 10589&nbsp; 7.3.16.4 says:<br>
<br>
&quot;When the Remaining Lifetime on an LSP in memory becomes zero, the
IS shall<br>
<font face="Times New Roman, Times">a)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>set
all SRMflags for that LSP, and<br>
<font face="Times New Roman, Times">b)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font>retain
only the LSP header.&quot;<br>
<br>
So both specs indicate that it is required that the body of an LSP be
removed prior to purging and that the receiving system MUST (at least in
the case of RFC 3567) reject purged LSPs that have anything in the body
other than the authentication TLV.<br>
<br>
I agree with Tony that retaining the body in a purged LSP in principle
does no harm (other than wasting LSP DB space) but because there are
implementations out there which adhere to the requirements in the two
specs, it is quite possible that such an LSP will be rejected by some
systems when received.<br>
<br>
As for the original question, an old defect in 10589:1992 existed wherein
Section 7.3.14.2e directed systems to purge received LSPs which had an
incorrect checksum. This proved disruptive in practice and was corrected
to indicate that the receiving system should ignore such an LSP (see
corresponding section in 10589:2002). However, this correction did not
extend to 7.3.14.2i (as it should have). The text in RFC 3719 is meant to
clarify that all LSPs received with a checksum error, even if the invalid
checksum is 0, should be ignored rather than purged.<br>
<br>
As to why Note 32 (Note 36 in 10589:2002) is necessary, this is a result
of:<br>
<br>
7.3.11 which says: &quot;The checksum shall never be modified by any
other system&quot;<br>
<br>
AND<br>
<br>
The quote above from 7.3.16.4 which requires the system issuing a purge
to NOT retain the LSP body.<br>
<br>
Taken literally, these two statements would require a system which is
purging an LSP generated by another system to remove the body, thereby
making the checksum invalid, and prohibit that system from recalculating
the checksum. So unless the checksum check were suspended in the case of
purged LSPs, it would fail on receive.<br>
<br>
&nbsp;&nbsp; Les<br>
<br>
<br>
<br>
<blockquote type=cite cite>On Apr 14, 2004, at 11:31 AM, appallar
wrote:<br>
<br>
<blockquote type=cite cite>&nbsp;Hello,&nbsp; 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,
&quot;Note 32&quot; 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??&nbsp; Thanks
in advance, Suryanarayana<br>
Indiatimes Email now powered by APIC Advantage. Help!<br>
&lt;image.tiff&gt;Help<br>
Click on the image to chat with me</blockquote><br>
<br>
_______________________________________________<br>
Isis-wg mailing list<br>
Isis-wg@ietf.org<br>
<a href="https://www1.ietf.org/mailman/listinfo/isis-wg" eudora="autourl">https://www1.ietf.org/mailman/listinfo/isis-wg</a><br>
</blockquote></html>

--=====================_64870649==_.ALT--


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Apr 20 14:35:01 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10723
	for <isis-archive@lists.ietf.org>; Tue, 20 Apr 2004 14:35:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BFzts-0002Ef-Fi; Tue, 20 Apr 2004 14:23:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BFznt-0000He-Sf
	for isis-wg@optimus.ietf.org; Tue, 20 Apr 2004 14:17:05 -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 OAA09740
	for <isis-wg@ietf.org>; Tue, 20 Apr 2004 14:17:03 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BFznr-0005TS-DB
	for isis-wg@ietf.org; Tue, 20 Apr 2004 14:17:03 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BFzmu-0005PU-00
	for isis-wg@ietf.org; Tue, 20 Apr 2004 14:16:05 -0400
Received: from westford-nat.juniper.net ([65.194.140.2] helo=pi-smtp.jnpr.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BFzm0-0005Fc-00
	for isis-wg@ietf.org; Tue, 20 Apr 2004 14:15:08 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <98F04BA831360C4FB5F7FC0118D91828034A2782@pi.jnpr.net>
Thread-Topic: ISIS graceful restart...
thread-index: AcQnA1f96J1RmnnAR1uCPGGPSz/0kQ==
From: "Jeelani Syed" <jsyed@juniper.net>
To: <isis-wg@ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Subject: [Isis-wg] ISIS graceful restart...
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: Tue, 20 Apr 2004 14:14:38 -0400
Content-Transfer-Encoding: quoted-printable

Hi,

From  draft-ietf-isis-restart-05.txt, section 3.3.1( Adjacency =
reacquisition during restart )
it says.

   "Once the timer T3 has expired or been cancelled, subsequent IIHs are =

    transmitted according to the normal algorithms, but including the=20
    restart TLV with both RR and RA clear."

I am wondering why restart router needs to wait untill T3 expires to =
send IIH with RA and RA cleared.
Can it be done once T1 expires? If not why?

Thanx,

-jeelani.sm

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Apr 20 15:27:50 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16062
	for <isis-archive@lists.ietf.org>; Tue, 20 Apr 2004 15:27:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BG0UT-0001ko-AF; Tue, 20 Apr 2004 15:01:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BG0Mo-0005HT-AF
	for isis-wg@optimus.ietf.org; Tue, 20 Apr 2004 14:53:10 -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 OAA12388
	for <isis-wg@ietf.org>; Tue, 20 Apr 2004 14:53:07 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BG0Ml-0000J6-DE
	for isis-wg@ietf.org; Tue, 20 Apr 2004 14:53:07 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BG0Lp-0000CN-00
	for isis-wg@ietf.org; Tue, 20 Apr 2004 14:52:09 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BG0Kq-0007nn-00
	for isis-wg@ietf.org; Tue, 20 Apr 2004 14:51:08 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 20 Apr 2004 11:01:00 +0000
Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3KIoa7t002450;
	Tue, 20 Apr 2004 11:50:37 -0700 (PDT)
Received: from ginsberg-w2k.cisco.com (printer-sj-24-2-128-107-163-58.cisco.com [128.107.163.58])
	by mira-sjc5-a.cisco.com (MOS 3.4.5-GR)
	with ESMTP id APW79990;
	Tue, 20 Apr 2004 11:49:39 -0700 (PDT)
Message-Id: <4.3.2.7.2.20040420114540.01bdf318@mira-sjc5-3.cisco.com>
X-Sender: ginsberg@mira-sjc5-3.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Jeelani Syed" <jsyed@juniper.net>
From: Les Ginsberg <ginsberg@cisco.com>
Subject: Re: [Isis-wg] ISIS graceful restart...
Cc: <isis-wg@ietf.org>
In-Reply-To: <98F04BA831360C4FB5F7FC0118D91828034A2782@pi.jnpr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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: Tue, 20 Apr 2004 11:50:35 -0700

At 02:14 PM 4/20/2004 -0400, Jeelani Syed wrote:
>Hi,
>
>From  draft-ietf-isis-restart-05.txt, section 3.3.1( Adjacency 
>reacquisition during restart )
>it says.
>
>    "Once the timer T3 has expired or been cancelled, subsequent IIHs are
>     transmitted according to the normal algorithms, but including the
>     restart TLV with both RR and RA clear."
>
>I am wondering why restart router needs to wait untill T3 expires to send 
>IIH with RA and RA cleared.
>Can it be done once T1 expires? If not why?

You are correct. This looks like a typo (one that has had a long life). The 
text should say "T1".
Thanx for spotting this.

Note that the state table in 4.2 is correct in this regard.

    Les


>Thanx,
>
>-jeelani.sm
>
>_______________________________________________
>Isis-wg mailing list
>Isis-wg@ietf.org
>https://www1.ietf.org/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Tue Apr 20 15:35:47 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16718
	for <isis-archive@lists.ietf.org>; Tue, 20 Apr 2004 15:35:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BG0uX-00040w-OV; Tue, 20 Apr 2004 15:28:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BG0Ue-000269-8e
	for isis-wg@optimus.ietf.org; Tue, 20 Apr 2004 15:01:16 -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 PAA13188
	for <isis-wg@ietf.org>; Tue, 20 Apr 2004 15:01:13 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BG0Ua-0000uy-Sl
	for isis-wg@ietf.org; Tue, 20 Apr 2004 15:01:12 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BG0TZ-0000pQ-00
	for isis-wg@ietf.org; Tue, 20 Apr 2004 15:00:10 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BG0Sf-0000ht-00
	for isis-wg@ietf.org; Tue, 20 Apr 2004 14:59:14 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-5.cisco.com with ESMTP; 20 Apr 2004 11:59:48 -0700
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3KIwc8k012618;
	Tue, 20 Apr 2004 11:58:41 -0700 (PDT)
Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4461.cisco.com [10.61.81.108])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA21328;
	Tue, 20 Apr 2004 19:58:36 +0100 (BST)
Message-Id: <4.3.2.7.2.20040420195526.02212da8@jaws.cisco.com>
X-Sender: mshand@jaws.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Jeelani Syed" <jsyed@juniper.net>
From: mike shand <mshand@cisco.com>
Subject: Re: [Isis-wg] ISIS graceful restart...
Cc: <isis-wg@ietf.org>
In-Reply-To: <98F04BA831360C4FB5F7FC0118D91828034A2782@pi.jnpr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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: Tue, 20 Apr 2004 19:58:27 +0100

At 14:14 20/04/2004 -0400, Jeelani Syed wrote:
>Hi,
>
>From  draft-ietf-isis-restart-05.txt, section 3.3.1( Adjacency 
>reacquisition during restart )
>it says.
>
>    "Once the timer T3 has expired or been cancelled, subsequent IIHs are
>     transmitted according to the normal algorithms, but including the
>     restart TLV with both RR and RA clear."
>
>I am wondering why restart router needs to wait untill T3 expires to send 
>IIH with RA and RA cleared.
>Can it be done once T1 expires? If not why?


T3 has expired OR BEEN CANCELLED

You don't need to wait until T3 expires.

         Mike



>Thanx,
>
>-jeelani.sm
>
>_______________________________________________
>Isis-wg mailing list
>Isis-wg@ietf.org
>https://www1.ietf.org/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Apr 21 02:58:40 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29138
	for <isis-archive@lists.ietf.org>; Wed, 21 Apr 2004 02:58:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BGBYX-00036Q-P8; Wed, 21 Apr 2004 02:50:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BGBSL-0007oK-GG
	for isis-wg@optimus.ietf.org; Wed, 21 Apr 2004 02:43:37 -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 CAA27999
	for <isis-wg@ietf.org>; Wed, 21 Apr 2004 02:43:34 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BGBSH-0007Lg-Fe
	for isis-wg@ietf.org; Wed, 21 Apr 2004 02:43:33 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BGBRI-0007F6-00
	for isis-wg@ietf.org; Wed, 21 Apr 2004 02:42:32 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BGBQf-00075t-00
	for isis-wg@ietf.org; Wed, 21 Apr 2004 02:41:53 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
  by sj-iport-5.cisco.com with ESMTP; 20 Apr 2004 23:41:24 -0700
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3L6fKqi000261;
	Tue, 20 Apr 2004 23:41:21 -0700 (PDT)
Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4461.cisco.com [10.61.81.108])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA14398;
	Wed, 21 Apr 2004 07:41:18 +0100 (BST)
Message-Id: <4.3.2.7.2.20040420215551.0234fc78@jaws.cisco.com>
X-Sender: mshand@jaws.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Jeelani Syed" <jsyed@juniper.net>, ginsberg@cisco.com
From: mike shand <mshand@cisco.com>
Subject: Re: [Isis-wg] ISIS graceful restart...
Cc: <isis-wg@ietf.org>, chopps@procket.com, dward@cisco.com
In-Reply-To: <4.3.2.7.2.20040420195526.02212da8@jaws.cisco.com>
References: <98F04BA831360C4FB5F7FC0118D91828034A2782@pi.jnpr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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: Wed, 21 Apr 2004 07:41:17 +0100

My apologies Jeelandi, I thought you were simply questioning whether you 
had to wait for timer expiry, as opposed to cancelling. But you are right, 
this should be when T1 is cancelled. This is actually a remnant of the 
original design where we didn't want to refresh the adjacency until we were 
sure that the restart recovery was complete. But that changed a while ago, 
and somehow this piece of text was not changed accordingly, but, as Les 
pointed out, the state table was.

We should fix this.

         Mike


At 19:58 20/04/2004 +0100, mike shand wrote:
>At 14:14 20/04/2004 -0400, Jeelani Syed wrote:
>>Hi,
>From  draft-ietf-isis-restart-05.txt, section 3.3.1( Adjacency
>>reacquisition during restart )
>>it says.
>>
>>    "Once the timer T3 has expired or been cancelled, subsequent IIHs are
>>     transmitted according to the normal algorithms, but including the
>>     restart TLV with both RR and RA clear."
>>
>>I am wondering why restart router needs to wait untill T3 expires to send 
>>IIH with RA and RA cleared.
>>Can it be done once T1 expires? If not why?
>
>
>T3 has expired OR BEEN CANCELLED
>
>You don't need to wait until T3 expires.
>
>         Mike
>
>
>
>>Thanx,
>>
>>-jeelani.sm
>>
>>_______________________________________________
>>Isis-wg mailing list
>>Isis-wg@ietf.org
>>https://www1.ietf.org/mailman/listinfo/isis-wg
>
>
>_______________________________________________
>Isis-wg mailing list
>Isis-wg@ietf.org
>https://www1.ietf.org/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Apr 21 10:52:37 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26004
	for <isis-archive@lists.ietf.org>; Wed, 21 Apr 2004 10:52:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BGIyE-0004iv-4L; Wed, 21 Apr 2004 10:45:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BGIjd-0007pA-Vl
	for isis-wg@optimus.ietf.org; Wed, 21 Apr 2004 10:29:58 -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 KAA24571
	for <isis-wg@ietf.org>; Wed, 21 Apr 2004 10:29:54 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BGIjb-0000ID-ML
	for isis-wg@ietf.org; Wed, 21 Apr 2004 10:29:55 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BGIif-00009R-00
	for isis-wg@ietf.org; Wed, 21 Apr 2004 10:28:58 -0400
Received: from westford-nat.juniper.net ([65.194.140.2] helo=pi-smtp.jnpr.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BGIi0-0007fg-00
	for isis-wg@ietf.org; Wed, 21 Apr 2004 10:28:16 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isis-wg] ISIS graceful restart...
Message-ID: <98F04BA831360C4FB5F7FC0118D91828034A2785@pi.jnpr.net>
Thread-Topic: [Isis-wg] ISIS graceful restart...
thread-index: AcQna8J2bi0g4CjQSjShE+oXMCouVwAQBoog
From: "Jeelani Syed" <jsyed@juniper.net>
To: "mike shand" <mshand@cisco.com>, <ginsberg@cisco.com>
Cc: <isis-wg@ietf.org>, <chopps@procket.com>, <dward@cisco.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
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: Wed, 21 Apr 2004 10:27:45 -0400
Content-Transfer-Encoding: quoted-printable

Mike & Les,

Thanks for your response...i have one more question...
Are the local LSPs of the restart router going to use the sequence no.
they left off before restarting or they start from zero?

Thanx,

-jeelani.sm

-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent: Wednesday, April 21, 2004 2:41 AM
To: Jeelani Syed; ginsberg@cisco.com
Cc: isis-wg@ietf.org; chopps@procket.com; dward@cisco.com
Subject: Re: [Isis-wg] ISIS graceful restart...


My apologies Jeelandi, I thought you were simply questioning whether you

had to wait for timer expiry, as opposed to cancelling. But you are
right,=20
this should be when T1 is cancelled. This is actually a remnant of the=20
original design where we didn't want to refresh the adjacency until we
were=20
sure that the restart recovery was complete. But that changed a while
ago,=20
and somehow this piece of text was not changed accordingly, but, as Les=20
pointed out, the state table was.

We should fix this.

         Mike


At 19:58 20/04/2004 +0100, mike shand wrote:
>At 14:14 20/04/2004 -0400, Jeelani Syed wrote:
>>Hi,
>From  draft-ietf-isis-restart-05.txt, section 3.3.1( Adjacency
>>reacquisition during restart )
>>it says.
>>
>>    "Once the timer T3 has expired or been cancelled, subsequent IIHs
are
>>     transmitted according to the normal algorithms, but including the
>>     restart TLV with both RR and RA clear."
>>
>>I am wondering why restart router needs to wait untill T3 expires to
send=20
>>IIH with RA and RA cleared.
>>Can it be done once T1 expires? If not why?
>
>
>T3 has expired OR BEEN CANCELLED
>
>You don't need to wait until T3 expires.
>
>         Mike
>
>
>
>>Thanx,
>>
>>-jeelani.sm
>>
>>_______________________________________________
>>Isis-wg mailing list
>>Isis-wg@ietf.org
>>https://www1.ietf.org/mailman/listinfo/isis-wg
>
>
>_______________________________________________
>Isis-wg mailing list
>Isis-wg@ietf.org
>https://www1.ietf.org/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Apr 21 12:13:18 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29724
	for <isis-archive@lists.ietf.org>; Wed, 21 Apr 2004 12:13:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BGJzj-00035d-RP; Wed, 21 Apr 2004 11:50:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BGJas-0002al-F9
	for isis-wg@optimus.ietf.org; Wed, 21 Apr 2004 11:24:58 -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 LAA27249
	for <isis-wg@ietf.org>; Wed, 21 Apr 2004 11:24:55 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BGJar-0001O4-HB
	for isis-wg@ietf.org; Wed, 21 Apr 2004 11:24:57 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BGJZw-0001F2-00
	for isis-wg@ietf.org; Wed, 21 Apr 2004 11:24:00 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BGJZK-0000x3-00
	for isis-wg@ietf.org; Wed, 21 Apr 2004 11:23:22 -0400
Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3LFMMHi023307;
	Wed, 21 Apr 2004 08:22:29 -0700 (PDT)
Received: from ginsberg-w2k.cisco.com (sjc-vpn1-626.cisco.com [10.21.98.114])
	by mira-sjc5-a.cisco.com (MOS 3.4.5-GR)
	with ESMTP id APX55640;
	Wed, 21 Apr 2004 08:21:26 -0700 (PDT)
Message-Id: <4.3.2.7.2.20040421081341.01b967b8@mira-sjc5-3.cisco.com>
X-Sender: ginsberg@mira-sjc5-3.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Jeelani Syed" <jsyed@juniper.net>
From: Les Ginsberg <ginsberg@cisco.com>
Subject: RE: [Isis-wg] ISIS graceful restart...
Cc: "mike shand" <mshand@cisco.com>, <isis-wg@ietf.org>, <chopps@procket.com>,
        <dward@cisco.com>
In-Reply-To: <98F04BA831360C4FB5F7FC0118D91828034A2785@pi.jnpr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
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: Wed, 21 Apr 2004 08:22:32 -0700

At 10:27 AM 4/21/2004 -0400, Jeelani Syed wrote:
>Mike & Les,
>
>Thanks for your response...i have one more question...
>Are the local LSPs of the restart router going to use the sequence no.
>they left off before restarting or they start from zero?

As the restarting router has no memory of what sequence numbers were in use 
prior to restart, it begins by reinitializing the sequence #s of its own 
LSPs. However, as explained in Section 3.4.1.1

"In the case of a restarting router, none of the router's own LSPs
    are transmitted, nor are the router's own forwarding tables updated
    while the timer T3 is running."

During this time LSPDB synchronization is occurring. The restarting router 
will acquire copies of its own LSPs (pre-restart) from its neighbors. 
Normal operation of the update process will cause the restarting router to 
update the sequence numbers in its own LSPs based on the copies received. 
Once flooding of own LSPs is resumed (T3 expired or cancelled) this ensures 
that the own LSPs will use either the same sequence # as pre-restart or a 
newer sequence #.

    Les


>Thanx,
>
>-jeelani.sm
>
>-----Original Message-----
>From: mike shand [mailto:mshand@cisco.com]
>Sent: Wednesday, April 21, 2004 2:41 AM
>To: Jeelani Syed; ginsberg@cisco.com
>Cc: isis-wg@ietf.org; chopps@procket.com; dward@cisco.com
>Subject: Re: [Isis-wg] ISIS graceful restart...
>
>
>My apologies Jeelandi, I thought you were simply questioning whether you
>
>had to wait for timer expiry, as opposed to cancelling. But you are
>right,
>this should be when T1 is cancelled. This is actually a remnant of the
>original design where we didn't want to refresh the adjacency until we
>were
>sure that the restart recovery was complete. But that changed a while
>ago,
>and somehow this piece of text was not changed accordingly, but, as Les
>pointed out, the state table was.
>
>We should fix this.
>
>          Mike
>
>
>At 19:58 20/04/2004 +0100, mike shand wrote:
> >At 14:14 20/04/2004 -0400, Jeelani Syed wrote:
> >>Hi,
> >From  draft-ietf-isis-restart-05.txt, section 3.3.1( Adjacency
> >>reacquisition during restart )
> >>it says.
> >>
> >>    "Once the timer T3 has expired or been cancelled, subsequent IIHs
>are
> >>     transmitted according to the normal algorithms, but including the
> >>     restart TLV with both RR and RA clear."
> >>
> >>I am wondering why restart router needs to wait untill T3 expires to
>send
> >>IIH with RA and RA cleared.
> >>Can it be done once T1 expires? If not why?
> >
> >
> >T3 has expired OR BEEN CANCELLED
> >
> >You don't need to wait until T3 expires.
> >
> >         Mike
> >
> >
> >
> >>Thanx,
> >>
> >>-jeelani.sm
> >>
> >>_______________________________________________
> >>Isis-wg mailing list
> >>Isis-wg@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/isis-wg
> >
> >
> >_______________________________________________
> >Isis-wg mailing list
> >Isis-wg@ietf.org
> >https://www1.ietf.org/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Apr 21 12:13:31 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29742
	for <isis-archive@lists.ietf.org>; Wed, 21 Apr 2004 12:13:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BGJzl-00035y-JK; Wed, 21 Apr 2004 11:50:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BGJel-0003oI-EN
	for isis-wg@optimus.ietf.org; Wed, 21 Apr 2004 11:28:59 -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 LAA27393
	for <isis-wg@ietf.org>; Wed, 21 Apr 2004 11:28:56 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BGJek-00021w-6k
	for isis-wg@ietf.org; Wed, 21 Apr 2004 11:28:58 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BGJdv-0001sd-00
	for isis-wg@ietf.org; Wed, 21 Apr 2004 11:28:08 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BGJdM-0001hi-00
	for isis-wg@ietf.org; Wed, 21 Apr 2004 11:27:32 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 21 Apr 2004 07:38:46 +0000
Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LFQx7t019584;
	Wed, 21 Apr 2004 08:27:00 -0700 (PDT)
Received: from ginsberg-w2k.cisco.com (sjc-vpn1-626.cisco.com [10.21.98.114])
	by mira-sjc5-a.cisco.com (MOS 3.4.5-GR)
	with ESMTP id APX56072;
	Wed, 21 Apr 2004 08:26:03 -0700 (PDT)
Message-Id: <4.3.2.7.2.20040421082315.01b967b8@mira-sjc5-3.cisco.com>
X-Sender: ginsberg@mira-sjc5-3.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: mike shand <mshand@cisco.com>
From: Les Ginsberg <ginsberg@cisco.com>
Subject: Re: [Isis-wg] ISIS graceful restart...
Cc: "Jeelani Syed" <jsyed@juniper.net>, <isis-wg@ietf.org>, chopps@procket.com,
        dward@cisco.com
In-Reply-To: <4.3.2.7.2.20040420215551.0234fc78@jaws.cisco.com>
References: <4.3.2.7.2.20040420195526.02212da8@jaws.cisco.com>
 <98F04BA831360C4FB5F7FC0118D91828034A2782@pi.jnpr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
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: Wed, 21 Apr 2004 08:26:58 -0700

At 07:41 AM 4/21/2004 +0100, mike shand wrote:
>My apologies Jeelandi, I thought you were simply questioning whether you 
>had to wait for timer expiry, as opposed to cancelling. But you are right, 
>this should be when T1 is cancelled. This is actually a remnant of the 
>original design where we didn't want to refresh the adjacency until we 
>were sure that the restart recovery was complete. But that changed a while 
>ago, and somehow this piece of text was not changed accordingly, but, as 
>Les pointed out, the state table was.
>
>We should fix this.
>
>         Mike


Here is the change proposed by Mike and myself to address this issue:

Section 3.3.1 "Adjacency reacquisition during restart", page 10, para 2:

Current text:

"Once the timer T3 has expired or been cancelled, subsequent IIHs are..."

Revised text:

"Once the timer T1 has been cancelled, subsequent IIHs are ..."

Explanation:

The difference is more than a typo. At one point in time (long, long ago) 
the reference to T3 was probably appropriate. And since T3 never gets 
restarted, it either expires or is cancelled. T1 however, can run a locally 
configurable number of times (as explained later in the same section) and 
it is only on the cancellation of the timer that resumption of normal IIHs 
should be sent.

If this revision is acceptable, Alex has agreed to try to get this into the 
doc before the RFC is published.

    Les



>At 19:58 20/04/2004 +0100, mike shand wrote:
>>At 14:14 20/04/2004 -0400, Jeelani Syed wrote:
>>>Hi,
>From  draft-ietf-isis-restart-05.txt, section 3.3.1( Adjacency
>>>reacquisition during restart )
>>>it says.
>>>
>>>    "Once the timer T3 has expired or been cancelled, subsequent IIHs are
>>>     transmitted according to the normal algorithms, but including the
>>>     restart TLV with both RR and RA clear."
>>>
>>>I am wondering why restart router needs to wait untill T3 expires to 
>>>send IIH with RA and RA cleared.
>>>Can it be done once T1 expires? If not why?
>>
>>
>>T3 has expired OR BEEN CANCELLED
>>
>>You don't need to wait until T3 expires.
>>
>>         Mike
>>
>>
>>
>>>Thanx,
>>>
>>>-jeelani.sm
>>>
>>>_______________________________________________
>>>Isis-wg mailing list
>>>Isis-wg@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/isis-wg
>>
>>
>>_______________________________________________
>>Isis-wg mailing list
>>Isis-wg@ietf.org
>>https://www1.ietf.org/mailman/listinfo/isis-wg
>


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Apr 21 12:14:52 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29829
	for <isis-archive@lists.ietf.org>; Wed, 21 Apr 2004 12:14:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BGJzo-00036v-EJ; Wed, 21 Apr 2004 11:50:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BGJln-0006Qs-K2
	for isis-wg@optimus.ietf.org; Wed, 21 Apr 2004 11:36:15 -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 LAA27650
	for <isis-wg@ietf.org>; Wed, 21 Apr 2004 11:36:12 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BGJlm-00039r-Iz
	for isis-wg@ietf.org; Wed, 21 Apr 2004 11:36:14 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BGJkm-0002yt-00
	for isis-wg@ietf.org; Wed, 21 Apr 2004 11:35:13 -0400
Received: from westford-nat.juniper.net ([65.194.140.2] helo=pi-smtp.jnpr.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BGJk4-0002mG-00
	for isis-wg@ietf.org; Wed, 21 Apr 2004 11:34:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Isis-wg] ISIS graceful restart...
Message-ID: <98F04BA831360C4FB5F7FC0118D91828034A2786@pi.jnpr.net>
Thread-Topic: [Isis-wg] ISIS graceful restart...
thread-index: AcQntJcIfLJ1EylnS8yYPokC0ri+lgAAMW9w
From: "Jeelani Syed" <jsyed@juniper.net>
To: "Les Ginsberg" <ginsberg@cisco.com>
Cc: "mike shand" <mshand@cisco.com>, <isis-wg@ietf.org>, <chopps@procket.com>,
        <dward@cisco.com>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
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: Wed, 21 Apr 2004 11:33:58 -0400
Content-Transfer-Encoding: quoted-printable

Hi Les,

That is what i thought, restart router could use the pre-start seq #
from ignored local
lsp received from neighbours if the gracefull restart is successfull(T3
cancelled). Do=20
you think it is worth mentioning it in draft or it is implicit?

Thanx,

-jeelani.sm

-----Original Message-----
From: Les Ginsberg [mailto:ginsberg@cisco.com]
Sent: Wednesday, April 21, 2004 11:23 AM
To: Jeelani Syed
Cc: mike shand; isis-wg@ietf.org; chopps@procket.com; dward@cisco.com
Subject: RE: [Isis-wg] ISIS graceful restart...


At 10:27 AM 4/21/2004 -0400, Jeelani Syed wrote:
>Mike & Les,
>
>Thanks for your response...i have one more question...
>Are the local LSPs of the restart router going to use the sequence no.
>they left off before restarting or they start from zero?

As the restarting router has no memory of what sequence numbers were in
use=20
prior to restart, it begins by reinitializing the sequence #s of its own

LSPs. However, as explained in Section 3.4.1.1

"In the case of a restarting router, none of the router's own LSPs
    are transmitted, nor are the router's own forwarding tables updated
    while the timer T3 is running."

During this time LSPDB synchronization is occurring. The restarting
router=20
will acquire copies of its own LSPs (pre-restart) from its neighbors.=20
Normal operation of the update process will cause the restarting router
to=20
update the sequence numbers in its own LSPs based on the copies
received.=20
Once flooding of own LSPs is resumed (T3 expired or cancelled) this
ensures=20
that the own LSPs will use either the same sequence # as pre-restart or
a=20
newer sequence #.

    Les


>Thanx,
>
>-jeelani.sm
>
>-----Original Message-----
>From: mike shand [mailto:mshand@cisco.com]
>Sent: Wednesday, April 21, 2004 2:41 AM
>To: Jeelani Syed; ginsberg@cisco.com
>Cc: isis-wg@ietf.org; chopps@procket.com; dward@cisco.com
>Subject: Re: [Isis-wg] ISIS graceful restart...
>
>
>My apologies Jeelandi, I thought you were simply questioning whether
you
>
>had to wait for timer expiry, as opposed to cancelling. But you are
>right,
>this should be when T1 is cancelled. This is actually a remnant of the
>original design where we didn't want to refresh the adjacency until we
>were
>sure that the restart recovery was complete. But that changed a while
>ago,
>and somehow this piece of text was not changed accordingly, but, as Les
>pointed out, the state table was.
>
>We should fix this.
>
>          Mike
>
>
>At 19:58 20/04/2004 +0100, mike shand wrote:
> >At 14:14 20/04/2004 -0400, Jeelani Syed wrote:
> >>Hi,
> >From  draft-ietf-isis-restart-05.txt, section 3.3.1( Adjacency
> >>reacquisition during restart )
> >>it says.
> >>
> >>    "Once the timer T3 has expired or been cancelled, subsequent
IIHs
>are
> >>     transmitted according to the normal algorithms, but including
the
> >>     restart TLV with both RR and RA clear."
> >>
> >>I am wondering why restart router needs to wait untill T3 expires to
>send
> >>IIH with RA and RA cleared.
> >>Can it be done once T1 expires? If not why?
> >
> >
> >T3 has expired OR BEEN CANCELLED
> >
> >You don't need to wait until T3 expires.
> >
> >         Mike
> >
> >
> >
> >>Thanx,
> >>
> >>-jeelani.sm
> >>
> >>_______________________________________________
> >>Isis-wg mailing list
> >>Isis-wg@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/isis-wg
> >
> >
> >_______________________________________________
> >Isis-wg mailing list
> >Isis-wg@ietf.org
> >https://www1.ietf.org/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Wed Apr 21 12:17:06 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00027
	for <isis-archive@lists.ietf.org>; Wed, 21 Apr 2004 12:17:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BGJzv-0003Df-OT; Wed, 21 Apr 2004 11:50:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BGJxN-0002HA-IS
	for isis-wg@optimus.ietf.org; Wed, 21 Apr 2004 11:48:13 -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 LAA28271
	for <isis-wg@ietf.org>; Wed, 21 Apr 2004 11:48:10 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BGJxM-0005Gy-AD
	for isis-wg@ietf.org; Wed, 21 Apr 2004 11:48:12 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BGJwK-00055h-00
	for isis-wg@ietf.org; Wed, 21 Apr 2004 11:47:09 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BGJvj-0004ve-00
	for isis-wg@ietf.org; Wed, 21 Apr 2004 11:46:31 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 21 Apr 2004 07:57:45 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LFjw7t027013;
	Wed, 21 Apr 2004 08:45:58 -0700 (PDT)
Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp284.cisco.com [10.61.65.28])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA05325;
	Wed, 21 Apr 2004 16:45:56 +0100 (BST)
Message-Id: <4.3.2.7.2.20040421164426.029cc520@jaws.cisco.com>
X-Sender: mshand@jaws.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Jeelani Syed" <jsyed@juniper.net>
From: mike shand <mshand@cisco.com>
Subject: RE: [Isis-wg] ISIS graceful restart...
Cc: "Les Ginsberg" <ginsberg@cisco.com>, <isis-wg@ietf.org>
In-Reply-To: <98F04BA831360C4FB5F7FC0118D91828034A2786@pi.jnpr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
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: Wed, 21 Apr 2004 16:46:08 +0100

At 11:33 21/04/2004 -0400, Jeelani Syed wrote:
>Hi Les,
>
>That is what i thought, restart router could use the pre-start seq #
>from ignored local
>lsp received from neighbours if the gracefull restart is successfull(T3
>cancelled). Do
>you think it is worth mentioning it in draft or it is implicit?

I think it is implicit, since (as Les has said) it is normal operation of 
the update process, which is not changed by this draft.

         Mike



>Thanx,
>
>-jeelani.sm
>
>-----Original Message-----
>From: Les Ginsberg [mailto:ginsberg@cisco.com]
>Sent: Wednesday, April 21, 2004 11:23 AM
>To: Jeelani Syed
>Cc: mike shand; isis-wg@ietf.org; chopps@procket.com; dward@cisco.com
>Subject: RE: [Isis-wg] ISIS graceful restart...
>
>
>At 10:27 AM 4/21/2004 -0400, Jeelani Syed wrote:
> >Mike & Les,
> >
> >Thanks for your response...i have one more question...
> >Are the local LSPs of the restart router going to use the sequence no.
> >they left off before restarting or they start from zero?
>
>As the restarting router has no memory of what sequence numbers were in
>use
>prior to restart, it begins by reinitializing the sequence #s of its own
>
>LSPs. However, as explained in Section 3.4.1.1
>
>"In the case of a restarting router, none of the router's own LSPs
>     are transmitted, nor are the router's own forwarding tables updated
>     while the timer T3 is running."
>
>During this time LSPDB synchronization is occurring. The restarting
>router
>will acquire copies of its own LSPs (pre-restart) from its neighbors.
>Normal operation of the update process will cause the restarting router
>to
>update the sequence numbers in its own LSPs based on the copies
>received.
>Once flooding of own LSPs is resumed (T3 expired or cancelled) this
>ensures
>that the own LSPs will use either the same sequence # as pre-restart or
>a
>newer sequence #.
>
>     Les
>
>
> >Thanx,
> >
> >-jeelani.sm
> >
> >-----Original Message-----
> >From: mike shand [mailto:mshand@cisco.com]
> >Sent: Wednesday, April 21, 2004 2:41 AM
> >To: Jeelani Syed; ginsberg@cisco.com
> >Cc: isis-wg@ietf.org; chopps@procket.com; dward@cisco.com
> >Subject: Re: [Isis-wg] ISIS graceful restart...
> >
> >
> >My apologies Jeelandi, I thought you were simply questioning whether
>you
> >
> >had to wait for timer expiry, as opposed to cancelling. But you are
> >right,
> >this should be when T1 is cancelled. This is actually a remnant of the
> >original design where we didn't want to refresh the adjacency until we
> >were
> >sure that the restart recovery was complete. But that changed a while
> >ago,
> >and somehow this piece of text was not changed accordingly, but, as Les
> >pointed out, the state table was.
> >
> >We should fix this.
> >
> >          Mike
> >
> >
> >At 19:58 20/04/2004 +0100, mike shand wrote:
> > >At 14:14 20/04/2004 -0400, Jeelani Syed wrote:
> > >>Hi,
> > >From  draft-ietf-isis-restart-05.txt, section 3.3.1( Adjacency
> > >>reacquisition during restart )
> > >>it says.
> > >>
> > >>    "Once the timer T3 has expired or been cancelled, subsequent
>IIHs
> >are
> > >>     transmitted according to the normal algorithms, but including
>the
> > >>     restart TLV with both RR and RA clear."
> > >>
> > >>I am wondering why restart router needs to wait untill T3 expires to
> >send
> > >>IIH with RA and RA cleared.
> > >>Can it be done once T1 expires? If not why?
> > >
> > >
> > >T3 has expired OR BEEN CANCELLED
> > >
> > >You don't need to wait until T3 expires.
> > >
> > >         Mike
> > >
> > >
> > >
> > >>Thanx,
> > >>
> > >>-jeelani.sm
> > >>
> > >>_______________________________________________
> > >>Isis-wg mailing list
> > >>Isis-wg@ietf.org
> > >>https://www1.ietf.org/mailman/listinfo/isis-wg
> > >
> > >
> > >_______________________________________________
> > >Isis-wg mailing list
> > >Isis-wg@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Sat Apr 24 21:16:29 2004
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16870
	for <isis-archive@lists.ietf.org>; Sat, 24 Apr 2004 21:16:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BHYCc-0000Ov-0m; Sat, 24 Apr 2004 21:13:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BHYBC-0008Ed-Qa
	for isis-wg@optimus.ietf.org; Sat, 24 Apr 2004 21:11:34 -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 VAA16680
	for <isis-wg@ietf.org>; Sat, 24 Apr 2004 21:11:32 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BHYBA-0004Aq-8A
	for isis-wg@ietf.org; Sat, 24 Apr 2004 21:11:32 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BHYAC-0003wV-00
	for isis-wg@ietf.org; Sat, 24 Apr 2004 21:10:33 -0400
Received: from firestar.cisco.com ([171.68.227.75] helo=fire.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BHY9r-0003ho-00
	for isis-wg@ietf.org; Sat, 24 Apr 2004 21:10:11 -0400
Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.98.126])
	by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i3P19gi28174
	for <isis-wg@ietf.org>; Sat, 24 Apr 2004 18:09:42 -0700 (PDT)
From: Shankar Vemulapalli <svemulap@cisco.com>
To: isis-wg@ietf.org
Message-ID: <Pine.GSO.4.58.0404241720400.20829@sj-cse-138.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [Isis-wg] IS-IS MT draft
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: Sat, 24 Apr 2004 18:09:42 -0700 (PDT)

Hi Folks -

Looking through isis-mt draft posted @:
http://www.ietf.org/proceedings/03jul/I-D/draft-ietf-isis-wg-multi-topology-06.txt
[I believe it is under AD review - I could be wrong]

Here are some observations:
a)
In section 7:
The overload, partition and attached bits in LSP header only reflect the
status of the default topology.
vs
In Section 9:
The LSP overload bit and pseudo-node LSPs are used by all topologies during
computation.

is contradicting.

b)
In Section 11.3:
 TLV number of this TLV is 235.  It is aligned with extended IS
                                            should be IP   ^^^^^
 reachability TLV type 135 beside an additional two bytes in front.


c)
In Section 11.3: [same section]
  No attempt is made in this draft to let the M-ISIS IPv6 topology to
  understand the "normal" IPv6 prefix with TLV type 236. A network
  SHOULD only run IS-IS either with IPv6 using type 236 or with M-ISIS
  IPv6 using type 237.

should probably in Section 11.4: Multi-Topology Reachable IPv6 Prefixes TLV

Thanks,


/Shankar

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Apr 29 13:44:46 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15970
	for <isis-archive@lists.ietf.org>; Thu, 29 Apr 2004 13:44:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BJFFh-00071l-Bk; Thu, 29 Apr 2004 13:23:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BJEum-0002ao-Rk
	for isis-wg@optimus.ietf.org; Thu, 29 Apr 2004 13:01:36 -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 NAA13900
	for <isis-wg@ietf.org>; Thu, 29 Apr 2004 13:01:33 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BJEuh-0001GT-N1
	for isis-wg@ietf.org; Thu, 29 Apr 2004 13:01:31 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BJEtl-0000zY-00
	for isis-wg@ietf.org; Thu, 29 Apr 2004 13:00:33 -0400
Received: from prattle.redback.com ([155.53.12.9])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BJEtI-0000iv-00
	for isis-wg@ietf.org; Thu, 29 Apr 2004 13:00:04 -0400
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP
	id 0C30817984A; Thu, 29 Apr 2004 10:00:07 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1])
 by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 13964-06; Thu, 29 Apr 2004 10:00:06 -0700 (PDT)
Received: from redback.com (malt.redback.com [155.53.12.41])
	by prattle.redback.com (Postfix) with ESMTP
	id AAF40179843; Thu, 29 Apr 2004 10:00:06 -0700 (PDT)
Received: from malt (localhost [127.0.0.1])
	by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id KAA19263;
	Thu, 29 Apr 2004 10:00:06 -0700 (PDT)
Message-Id: <200404291700.KAA19263@redback.com>
To: Shankar Vemulapalli <svemulap@cisco.com>
Cc: isis-wg@ietf.org
Subject: Re: [Isis-wg] IS-IS MT draft 
In-reply-to: Mail from Shankar Vemulapalli <svemulap@cisco.com> 
 dated Sat, 24 Apr 2004 18:09:42 PDT
 <Pine.GSO.4.58.0404241720400.20829@sj-cse-138.cisco.com> 
From: Naiming Shen <naiming@redback.com>
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
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, 29 Apr 2004 10:00:05 -0700


Shankar,

thanks for the comment, will update in the next version.

 ] Hi Folks -
 ] 
 ] Looking through isis-mt draft posted @:
 ] http://www.ietf.org/proceedings/03jul/I-D/draft-ietf-isis-wg-multi-topology-
06.txt
 ] [I believe it is under AD review - I could be wrong]
 ] 
 ] Here are some observations:
 ] a)
 ] In section 7:
 ] The overload, partition and attached bits in LSP header only reflect the
 ] status of the default topology.
 ] vs
 ] In Section 9:
 ] The LSP overload bit and pseudo-node LSPs are used by all topologies during
 ] computation.
 ] 
 ] is contradicting.
 ] 
 ] b)
 ] In Section 11.3:
 ]  TLV number of this TLV is 235.  It is aligned with extended IS
 ]                                             should be IP   ^^^^^
 ]  reachability TLV type 135 beside an additional two bytes in front.
 ] 
 ] 
 ] c)
 ] In Section 11.3: [same section]
 ]   No attempt is made in this draft to let the M-ISIS IPv6 topology to
 ]   understand the "normal" IPv6 prefix with TLV type 236. A network
 ]   SHOULD only run IS-IS either with IPv6 using type 236 or with M-ISIS
 ]   IPv6 using type 237.
 ] 
 ] should probably in Section 11.4: Multi-Topology Reachable IPv6 Prefixes TLV
 ] 
 ] Thanks,
 ] 
 ] 
 ] /Shankar
 ] 
 ] _______________________________________________
 ] Isis-wg mailing list
 ] Isis-wg@ietf.org
 ] https://www1.ietf.org/mailman/listinfo/isis-wg

- Naiming

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg


From isis-wg-admin@ietf.org  Thu Apr 29 13:47:46 2004
Received: from optimus.ietf.org (iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16272
	for <isis-archive@lists.ietf.org>; Thu, 29 Apr 2004 13:47:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BJFFo-00073Q-37; Thu, 29 Apr 2004 13:23:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BJF3H-0003sF-SI
	for isis-wg@optimus.ietf.org; Thu, 29 Apr 2004 13:10:23 -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 NAA14227
	for <isis-wg@ietf.org>; Thu, 29 Apr 2004 13:10:19 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BJF3C-0003eU-J7
	for isis-wg@ietf.org; Thu, 29 Apr 2004 13:10:18 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BJF2D-0003Ny-00
	for isis-wg@ietf.org; Thu, 29 Apr 2004 13:09:18 -0400
Received: from prattle.redback.com ([155.53.12.9])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BJF1C-00032e-00
	for isis-wg@ietf.org; Thu, 29 Apr 2004 13:08:14 -0400
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP id A7A389839E7
	for <isis-wg@ietf.org>; Thu, 29 Apr 2004 10:08:17 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1])
 by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 15340-09 for <isis-wg@ietf.org>; Thu, 29 Apr 2004 10:08:17 -0700 (PDT)
Received: from redback.com (malt.redback.com [155.53.12.41])
	by prattle.redback.com (Postfix) with ESMTP id 3C3C59839E5
	for <isis-wg@ietf.org>; Thu, 29 Apr 2004 10:08:17 -0700 (PDT)
Received: from malt (localhost [127.0.0.1])
	by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id KAA19381
	for <isis-wg@ietf.org>; Thu, 29 Apr 2004 10:08:17 -0700 (PDT)
Message-Id: <200404291708.KAA19381@redback.com>
To: isis-wg@ietf.org
From: Naiming Shen <naiming@redback.com>
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Isis-wg] Internet-Drafts@ietf.org: I-D ACTION:draft-shen-isis-interarea-route-attr-00.txt
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, 29 Apr 2004 10:08:16 -0700


Just submitted this Inter-Area Route Attribute extension draft.
We are interested in any comments on this.

thanks.
- Naiming

------- Forwarded Message

To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-shen-isis-interarea-route-attr-00.txt
Date: Wed, 28 Apr 2004 15:29:09 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Inter-Area IP Route Attribute in IS-IS
	Author(s)	: N. Shen, et al.
	Filename	: draft-shen-isis-interarea-route-attr-00.txt
	Pages		: 6
	Date		: 2004-4-28
	
This document describes an extension to the IS-IS protocol to allow
   some routing attributes to be associated with advertised inter-area
   prefixes. The extension allows routers to learn this routing
   information without the knowledge of the link-state topology in
   another IS-IS level. The initial applications for this extension
   are inter-area IP MPLS fast reroute for node protection and
   inter-area TE LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shen-isis-interarea-route-attr-00.txt


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg