From isis-wg-admin@ietf.org Thu Jan 2 18:06:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16595 for ; Thu, 2 Jan 2003 18:06:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NBlJ30548; Thu, 2 Jan 2003 18:11:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02NACJ30442 for ; Thu, 2 Jan 2003 18:10:12 -0500 Received: from ns2.vivacenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16522 for ; Thu, 2 Jan 2003 18:01:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B2B3.4974AA34" Message-ID: Thread-Topic: draft-ietf-isis-restart-02 question Thread-Index: AcKytAOZB5mTLSiiRD+WMneE7FBP1Q== From: "Ravindra Sunkad" To: Subject: [Isis-wg] draft-ietf-isis-restart-02 question 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 2 Jan 2003 15:04:22 -0800 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2B2B3.4974AA34 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Section 4.3.1.2 (Re-starting) paragraph 2 reads =20 "In the case of a re-starting router, none of the router's own non- pseudonode LSPs are transmitted, nor are the router's own forwarding=20 tables updated while the timer T3 is running." =20 Does this mean that own pseudonodes can be transmitted before T3 is cancelled or expires?=20 =20 If yes: o At what point can the restarting router assume that all the=20 adjacencies on a LAN circuit have been re-established?=20 =20 Thanks, Ravi ------_=_NextPart_001_01C2B2B3.4974AA34 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
Section 4.3.1.2 (Re-starting) paragraph = 2=20 reads
 
"In the case of a re-starting router, = none of the=20 router's own non-
 pseudonode LSPs are transmitted, nor are the = router's=20 own forwarding
 tables updated while the timer T3 is=20 running."
 
Does this mean that own pseudonodes can = be=20 transmitted before T3 is
cancelled or expires?
 
If yes:
    o At what = point can the restarting = router=20 assume that all the
      adjacencies = on a LAN circuit have been = re-established?=20
 
Thanks,
Ravi
=00 ------_=_NextPart_001_01C2B2B3.4974AA34-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 7 01:54:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25213 for ; Tue, 7 Jan 2003 01:54:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0770IJ17255; Tue, 7 Jan 2003 02:00:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h076wMJ17149 for ; Tue, 7 Jan 2003 01:58:22 -0500 Received: from xover.netplane.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25066 for ; Tue, 7 Jan 2003 01:47:15 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HSYQ4>; Tue, 7 Jan 2003 01:50:26 -0500 Message-ID: From: "Jonnala, Nagi" To: "'Jeff Parker'" Cc: 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" Subject: [Isis-wg] isisISAdjNeighSysID 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Jan 2003 01:52:32 -0500 Hi Jeff, I have a couple of comments. 1) Is there any reason why we allocated 7 bytes for isisISADjNeighSysID? I think 6 bytes should be okay for SysID. Right? 2) The order of isisISAdjNeighSysID and isisISAdjExtendedCircID mismatches from the isisISAdjEntry description.(Also mentioned in private mail) Thanks Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 7 02:26:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05812 for ; Tue, 7 Jan 2003 02:26:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h077ZDJ29959; Tue, 7 Jan 2003 02:35:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h077YGJ29904 for ; Tue, 7 Jan 2003 02:34:16 -0500 Received: from xover.netplane.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05757 for ; Tue, 7 Jan 2003 02:23:08 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HSYSD>; Tue, 7 Jan 2003 02:26:20 -0500 Message-ID: From: "Jonnala, Nagi" To: "'Chris Hopps'" Cc: "'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" Subject: [Isis-wg] ipv6 prefix length. 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Jan 2003 02:28:12 -0500 Chris, I'm not sure if this was dicussed before. In IPv6 Reachability TLV, The Prefix Length field consists of 6 bits. So we can store the maximum unsigned value of 63(2^6 - 1). which means we cannot have more than prefixlen of 63 in ipv6. Right? Don't we need to be able to store the maximum prefix length of 128? Please enlighten me on this issue. Thanks Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 7 03:35:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07069 for ; Tue, 7 Jan 2003 03:35:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h078fNJ02207; Tue, 7 Jan 2003 03:41:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h078bXJ01865 for ; Tue, 7 Jan 2003 03:37:33 -0500 Received: from xover.netplane.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06936 for ; Tue, 7 Jan 2003 03:26:26 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HSY4L>; Tue, 7 Jan 2003 03:29:36 -0500 Message-ID: From: "Jonnala, Nagi" To: "'Jeff Parker'" Cc: 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" Subject: [Isis-wg] isisISAdj3WayState 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Jan 2003 03:31:43 -0500 Jeff, Shouldn't isisISAdj3WayState have the as enumerations as isisISAdjState? Looks like "Up" and "Down" enums need to be reordered. -Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 7 10:29:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18212 for ; Tue, 7 Jan 2003 10:29:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FcOJ28926; Tue, 7 Jan 2003 10:38:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FZaJ28207 for ; Tue, 7 Jan 2003 10:35:36 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17956 for ; Tue, 7 Jan 2003 10:24:19 -0500 (EST) Received: from cisco.com ([64.101.135.211]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h07FR0jS000278; Tue, 7 Jan 2003 07:27:00 -0800 (PST) Subject: Re: [Isis-wg] ipv6 prefix length. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Chris Hopps'" , "'isis-wg@ietf.org'" To: "Jonnala, Nagi" From: Micah Bartell In-Reply-To: Message-Id: <8A9BBF8C-2254-11D7-829B-000A95765246@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Jan 2003 09:27:32 -0600 Content-Transfer-Encoding: 7bit I believe the Interface ID in an IPv6 address is 64 bits long, this does not get subnetted down.... /mpb On Tuesday, January 7, 2003, at 01:28 AM, Jonnala, Nagi wrote: > Chris, > > I'm not sure if this was dicussed before. > > In IPv6 Reachability TLV, The Prefix Length field consists of 6 bits. > So we can store the maximum unsigned value of 63(2^6 - 1). > > which means we cannot have more than prefixlen of 63 in ipv6. Right? > > Don't we need to be able to store the maximum prefix length of 128? > > Please enlighten me on this issue. > > Thanks > Nagi. > > _______________________________________________ > 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 Jan 7 11:10:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19352 for ; Tue, 7 Jan 2003 11:10:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GJDJ32218; Tue, 7 Jan 2003 11:19:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GG6J32147 for ; Tue, 7 Jan 2003 11:16:06 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19226 for ; Tue, 7 Jan 2003 11:04:48 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h07G7TjS006987; Tue, 7 Jan 2003 08:07:29 -0800 (PST) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp15.cisco.com [144.254.108.82]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA07867; Tue, 7 Jan 2003 16:07:57 GMT Message-Id: <4.3.2.7.2.20030107160035.0289d080@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ravindra Sunkad" From: mike shand Subject: Re: [Isis-wg] draft-ietf-isis-restart-02 question Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 07 Jan 2003 16:07:47 +0000 At 15:04 02/01/2003 -0800, Ravindra Sunkad wrote: >Hi, > >Section 4.3.1.2 (Re-starting) paragraph 2 reads > >"In the case of a re-starting router, none of the router's own non- > pseudonode LSPs are transmitted, nor are the router's own forwarding > tables updated while the timer T3 is running." > >Does this mean that own pseudonodes can be transmitted before T3 is >cancelled or expires? Yes, the point is that there is no propagation into pseudonodes between levels so all we are concerned with is whether the adjacencies have been established. > >If yes: > o At what point can the restarting router assume that all the > adjacencies on a LAN circuit have been re-established? Well, you can never know for sure! There is no particular hurry, since the old LSPs are still out there. If you KNOW that the information has changed you should probably advertise that ASAP. The point is that you shouldn't prematurely issue pseudonode LSP(s) with missing information and then quickly replace them with information which is identical to what it was before the re-start. Exactly what heuristic you use is implementation dependant. Mike > >Thanks, >Ravi _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 7 12:34:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21851 for ; Tue, 7 Jan 2003 12:34:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07HhIJ05496; Tue, 7 Jan 2003 12:43:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07HerJ05423 for ; Tue, 7 Jan 2003 12:40:53 -0500 Received: from tahoe.sj.allegronetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21676 for ; Tue, 7 Jan 2003 12:29:34 -0500 (EST) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 09:32:49 -0800 Message-ID: From: Chris Hopps To: "'Jonnala, Nagi'" Cc: "'isis-wg@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Isis-wg] RE: ipv6 prefix length. 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Jan 2003 09:32:48 -0800 It's a mistake. The earlier draft had the prefix length as a full octet. The mistake was made in the conversion to the ascii art. I'll be re-issuing with the field changed to 8 bits. Chris. -----Original Message----- From: Jonnala, Nagi [mailto:nagij@netplane.com] Sent: Monday, January 06, 2003 11:28 PM To: 'Chris Hopps' Cc: 'isis-wg@ietf.org' Subject: ipv6 prefix length. Chris, I'm not sure if this was dicussed before. In IPv6 Reachability TLV, The Prefix Length field consists of 6 bits. So we can store the maximum unsigned value of 63(2^6 - 1). which means we cannot have more than prefixlen of 63 in ipv6. Right? Don't we need to be able to store the maximum prefix length of 128? Please enlighten me on this issue. Thanks Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 7 12:55:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22445 for ; Tue, 7 Jan 2003 12:55:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07I47J06376; Tue, 7 Jan 2003 13:04:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07I1GJ06245 for ; Tue, 7 Jan 2003 13:01:16 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22277 for ; Tue, 7 Jan 2003 12:49:56 -0500 (EST) Message-ID: From: Jeff Parker To: "'Jonnala, Nagi'" Cc: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: isisISAdjNeighSysID 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Jan 2003 12:52:57 -0500 > Hi Jeff, > > I have a couple of comments. > > 1) Is there any reason why we allocated 7 bytes > for isisISADjNeighSysID? I think 6 bytes should > be okay for SysID. Right? Good point. I have changed to the type SystemID. > 2) The order of isisISAdjNeighSysID and isisISAdjExtendedCircID > mismatches from the isisISAdjEntry description.(Also mentioned > in private mail) I have reordered, and now have three variables: isisISAdjExtendedCircID Unsigned32, isisISAdjNeighSysID SystemID, isisISAdjNbrExtendedCircID Unsigned32, The first uses the previous name, but is now defined to be our extended ID, the second and third hold the system ID and Extended ID of the far side. > Thanks > Nagi. > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 7 13:02:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22696 for ; Tue, 7 Jan 2003 13:01:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07IB5J07358; Tue, 7 Jan 2003 13:11:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07I8iJ07253 for ; Tue, 7 Jan 2003 13:08:44 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22508 for ; Tue, 7 Jan 2003 12:57:24 -0500 (EST) Message-ID: From: Jeff Parker To: "'Jonnala, Nagi'" Cc: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: isisISAdj3WayState 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Jan 2003 12:59:54 -0500 > Jeff, > > Shouldn't isisISAdj3WayState have the as enumerations > as isisISAdjState? Looks like "Up" and "Down" enums > need to be reordered. > > -Nagi. This comes up every few months, so I have modified the text. isisISAdj3WayState OBJECT-TYPE SYNTAX INTEGER { up (0), initializing (1), down (2), failed (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The 3Way state of the adjacency. These are picked to match the historical on-the-write representation of the 3Way state, and are not intended to match isisISAdjState." REFERENCE "{ RFC 3373 }" ::= { isisISAdjEntry 3 } - jdp _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 7 13:06:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22787 for ; Tue, 7 Jan 2003 13:06:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07IF4J07565; Tue, 7 Jan 2003 13:15:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07ICOJ07459 for ; Tue, 7 Jan 2003 13:12:24 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22647 for ; Tue, 7 Jan 2003 13:01:04 -0500 (EST) Message-ID: From: Jeff Parker To: "'Jonnala, Nagi'" , Jeff Parker Cc: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: isisISAdj3WayState, etc. 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Jan 2003 13:03:41 -0500 There have been a number of minor changes to the MIB. While they are far less than the revisions behind the last couple of drafts, it is probably time for me to re-issue the draft. I will wait for any review comments on the current draft for a week or so: I would be happy to send the current state of the document to anyone by private mail. The checkin comments for the changes since the last release are below. - jeff parker - axiowave networks "Clarify enum for 3way state" "Align adjacency information to match order in 3way option" "Change MeshoGroup value to Uint32" "Replace tabs with spaces" "Clearup CSNP Interval" "ExistState objects should not have a default value" "Change ISIS to IS-IS" "Change changes" "Move isisSysLevelTable" "Change isisLSPId to isisLSPID" "Change isisLSPTTLV to LSPTLV" _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 7 14:05:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24671 for ; Tue, 7 Jan 2003 14:05:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JEOJ11060; Tue, 7 Jan 2003 14:14:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JDjJ11028 for ; Tue, 7 Jan 2003 14:13:45 -0500 Received: from xprdmailfe29.nwk.excite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24451 for ; Tue, 7 Jan 2003 14:02:23 -0500 (EST) Received: by xprdmailfe29.nwk.excite.com (Postfix, from userid 110) id C8B6BE5CD; Tue, 7 Jan 2003 14:05:36 -0500 (EST) To: jparker@axiowave.com, nagij@netplane.com Subject: [Isis-wg] RE: isisISAdj3WayState Received: from [63.104.212.252] by xprdmailfe29.nwk.excite.com via HTTP; Tue, 07 Jan 2003 14:05:36 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 Reply-To: dgoodspe@excite.com From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org Message-Id: <20030107190536.C8B6BE5CD@xprdmailfe29.nwk.excite.com> 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Jan 2003 14:05:36 -0500 (EST) Content-Transfer-Encoding: 7bit Jeff, Shouldn't "on-the-write" be "on-the-wire"? -don ----------------------------- "The 3Way state of the adjacency. These are picked to match the historical on-the-write representation of the 3Way state, and are not intended to match isisISAdjState." _______________________________________________ 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 Tue Jan 7 14:22:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25468 for ; Tue, 7 Jan 2003 14:22:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JV8J11881; Tue, 7 Jan 2003 14:31:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JU4J11802 for ; Tue, 7 Jan 2003 14:30:04 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25334 for ; Tue, 7 Jan 2003 14:18:41 -0500 (EST) Message-ID: From: Jeff Parker To: "'dgoodspe@excite.com'" , Jeff Parker , nagij@netplane.com Cc: isis-wg@ietf.org Subject: RE: [Isis-wg] RE: isisISAdj3WayState MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Jan 2003 14:21:27 -0500 > Jeff, > > Shouldn't "on-the-write" be "on-the-wire"? > > -don Guilty as charged. Fixed. - jdp _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 7 20:54:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08082 for ; Tue, 7 Jan 2003 20:54:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0823LJ04164; Tue, 7 Jan 2003 21:03:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0822fJ04147 for ; Tue, 7 Jan 2003 21:02:41 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08019 for ; Tue, 7 Jan 2003 20:51:10 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18W5QE-00079L-00 for isis-wg@ietf.org; Tue, 07 Jan 2003 17:54:22 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <143689391.20030107175342@psg.com> To: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Fwd: Last Call: Draft of agreement between ISOC/IETF and SO/IEC JTC1/SC6 on IS-IS protocol development to Informational 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Jan 2003 17:53:42 -0800 Content-Transfer-Encoding: 7bit Folks- Below is the IETF LC announcement for the new version of the agreement text. As I said in my message on Dec 20th, the draft incorporates comments from the WG. The wdiff against the old ver is available at http://psg.com/~zinin/ietf/draft.wdiff.txt This text will be brought for approval to the next meeting of the UK committee (Jan 21st) as a UK proposal for approval at the SC6 plenary (Feb 21st). Cheers, -- Alex This is a forwarded message From: The IESG To: Cc: Date: Tuesday, January 07, 2003, 2:22:22 PM Subject: Last Call: Draft of agreement between ISOC/IETF and SO/IEC JTC1/SC6 on IS-IS protocol development to Informational ===8<==============Original message text=============== The IESG has received a request to consider Draft of agreement between ISOC/IETF and SO/IEC JTC1/SC6 on IS-IS protocol development as a Informational. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-7. Files can be obtained via http://www.ietf.org/internet-drafts/draft-zinin-ietf-jtc1-aggr-01.txt This Internet Draft documents proposed text of an agreement between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol extensions. For a long time there has been no guidelines on how the two organizations should work together and separate their IS-IS related work scopes. This resulted in a confusion where the IETF did not put Internet-related extensions of the protocol on its standards track, and there was no authority maintaining the IS-IS namespace. The agreement between the two organizations is an attempt to resolve this situation. This Internet Draft does not propose any changes to IETF processes or priorities. It describes (among other things) how the IETF processes are applied to the IS-IS protocol extensions. The IESG is issuing this Last-Call for review by the IETF community to ensure that the community is comfortable with the description of the proposed collaboration between the two organizations. ===8<===========End of original message text=========== _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jan 8 09:00:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19985 for ; Wed, 8 Jan 2003 09:00:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08E7hJ23611; Wed, 8 Jan 2003 09:07:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08E27J22790 for ; Wed, 8 Jan 2003 09:02:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19711; Wed, 8 Jan 2003 08:50:10 -0500 (EST) Message-Id: <200301081350.IAA19711@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-16.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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 08 Jan 2003 08:50:10 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-isis-gmpls-extensions-16.txt Pages : 13 Date : 2003-1-7 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-16.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-gmpls-extensions-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-7161053.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-7161053.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jan 9 06:05:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06778 for ; Thu, 9 Jan 2003 06:05:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09BEkJ14916; Thu, 9 Jan 2003 06:14:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09BCcJ14857 for ; Thu, 9 Jan 2003 06:12:38 -0500 Received: from xover.netplane.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06690 for ; Thu, 9 Jan 2003 06:00:29 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HS7V2>; Thu, 9 Jan 2003 06:03:38 -0500 Message-ID: From: "Jonnala, Nagi" To: "'Jeff Parker'" Cc: "'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" Subject: [Isis-wg] SystemID Type definition. 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Jan 2003 06:05:17 -0500 Jeff, Current Type definition of System ID is SystemID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A system ID." SYNTAX OCTET STRING (SIZE(0..6)) May be, you would want to change the size to 6 because the WG has agreed on System-ID length earlier. -Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jan 9 07:48:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08162 for ; Thu, 9 Jan 2003 07:48:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Cw1J20511; Thu, 9 Jan 2003 07:58:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09CuAJ20433 for ; Thu, 9 Jan 2003 07:56:10 -0500 Received: from xover.netplane.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08080 for ; Thu, 9 Jan 2003 07:43:58 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HS7X8>; Thu, 9 Jan 2003 07:47:09 -0500 Message-ID: From: "Jonnala, Nagi" To: "'Jeff Parker'" Cc: "'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" Subject: [Isis-wg] isisSysMaxAreaAddresses 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Jan 2003 07:49:15 -0500 Jeff, Since the WG has already agreed upon the maximum number of area addresses(3), can we remove isisSysMaxAreaAddresses object from System Table? -Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jan 9 10:30:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14655 for ; Thu, 9 Jan 2003 10:30:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FdaJ31828; Thu, 9 Jan 2003 10:39:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FW2J30807 for ; Thu, 9 Jan 2003 10:32:02 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14219 for ; Thu, 9 Jan 2003 10:19:46 -0500 (EST) Message-ID: From: Jeff Parker To: "'Jonnala, Nagi'" Cc: "'isis-wg@ietf.org'" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: SystemID Type definition. 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Jan 2003 10:22:27 -0500 > Jeff, > > Current Type definition of System ID is > > SystemID ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A system ID." > SYNTAX OCTET STRING (SIZE(0..6)) > > May be, you would want to change the size to 6 because > the WG has agreed on System-ID length earlier. > > -Nagi. Nagi - Yup, it used to read 0..8, and I cranked it down to 6 when that discussion happened. There is one spot where we have an object of type SystemID which might be null. If there was a syntax for it, I would say OCTET STRING (SIZE(0 or 6)) but there isn't. - 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 Jan 9 10:31:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14695 for ; Thu, 9 Jan 2003 10:31:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FegJ32034; Thu, 9 Jan 2003 10:40:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09FbZJ31589 for ; Thu, 9 Jan 2003 10:37:35 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14343 for ; Thu, 9 Jan 2003 10:25:18 -0500 (EST) Message-ID: From: Jeff Parker To: "'Jonnala, Nagi'" , Jeff Parker Cc: "'isis-wg@ietf.org'" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: isisSysMaxAreaAddresses 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Jan 2003 10:28:02 -0500 > Jeff, > > Since the WG has already agreed upon the maximum number of area > addresses(3), > can we remove isisSysMaxAreaAddresses object from System Table? > > -Nagi. Nagi - Sounds good to me. Any objections? - 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 Jan 9 15:01:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24851 for ; Thu, 9 Jan 2003 15:01:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09K8cJ20951; Thu, 9 Jan 2003 15:08:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09K7JJ20695 for ; Thu, 9 Jan 2003 15:07:19 -0500 Received: from xmxpita.excite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24328 for ; Thu, 9 Jan 2003 14:54:58 -0500 (EST) Received: by xmxpita.excite.com (Postfix, from userid 110) id A4F4A3DCE; Thu, 9 Jan 2003 14:58:14 -0500 (EST) To: jparker@axiowave.com, nagij@netplane.com Subject: [Isis-wg] RE: SystemID Type definition. Received: from [63.104.212.252] by xprdmailfe8.nwk.excite.com via HTTP; Thu, 09 Jan 2003 14:58:14 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 Reply-To: dgoodspe@excite.com From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org Message-Id: <20030109195814.A4F4A3DCE@xmxpita.excite.com> 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Jan 2003 14:58:14 -0500 (EST) Content-Transfer-Encoding: 7bit Jeff, I thought I've seen the following syntax before: SYNTAX OCTET STRING (SIZE(0|6)) -don > Jeff, > > Current Type definition of System ID is > > SystemID ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A system ID." > SYNTAX OCTET STRING (SIZE(0..6)) > > May be, you would want to change the size to 6 because > the WG has agreed on System-ID length earlier. > > -Nagi. Nagi - Yup, it used to read 0..8, and I cranked it down to 6 when that discussion happened. There is one spot where we have an object of type SystemID which might be null. If there was a syntax for it, I would say OCTET STRING (SIZE(0 or 6)) but there isn't. - jeff parker _______________________________________________ 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 Thu Jan 9 16:43:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27338 for ; Thu, 9 Jan 2003 16:43:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09LpVJ28435; Thu, 9 Jan 2003 16:51:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09LoJJ28371 for ; Thu, 9 Jan 2003 16:50:19 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27259 for ; Thu, 9 Jan 2003 16:37:56 -0500 (EST) Message-ID: From: Jeff Parker To: "ISIS-WG (E-mail)" Subject: FW: [Isis-wg] RE: SystemID Type definition. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Jan 2003 16:41:11 -0500 > > Jeff, > > > > I thought I've seen the following syntax before: > > SYNTAX OCTET STRING (SIZE(0|6)) > > > > -don Thanks, Don. I will make this change. - 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 Jan 9 19:44:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02371 for ; Thu, 9 Jan 2003 19:44:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0qmJ07028; Thu, 9 Jan 2003 19:52:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0pBJ06969 for ; Thu, 9 Jan 2003 19:51:11 -0500 Received: from ns2.vivacenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02121 for ; Thu, 9 Jan 2003 19:38:17 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Another draft-ietf-isis-restart-02 question Message-ID: Thread-Topic: [Isis-wg] Another draft-ietf-isis-restart-02 question Thread-Index: AcK2ZvZyVT6tOxX4S/SrVTtGGY/ZAwB16Agw From: "Ravindra Sunkad" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0A0pBJ06970 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Jan 2003 16:41:29 -0800 Content-Transfer-Encoding: 8bit Paragraph 4 of section 4.2 in draft-ietf-isis-restart-02 reads: "As LSPs are received (by the normal operation of the update process) over any interface, the corresponding LSPID entry is removed (it is also removed if the LSP had arrived before the CSNP containing the reference). When an LSPID has been held in the list for its indicated remaining lifetime, it is removed from the list. When the list of LSPIDs becomes empty, the timer T2 is cancelled." Shouldn't the last sentence in above paragraph instead be: "When the list of LSPIDs is empty, and a complete set of CSNP(s) and a restart acknowledgement have been received over all the interfaces that have an adjacency at this level, the timer T2 is cancelled." Thanks, Ravi _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jan 9 19:46:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02449 for ; Thu, 9 Jan 2003 19:46:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0t2J07109; Thu, 9 Jan 2003 19:55:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A0rBJ07036 for ; Thu, 9 Jan 2003 19:53:11 -0500 Received: from ns2.vivacenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02225 for ; Thu, 9 Jan 2003 19:40:45 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Another draft-ietf-isis-restart-02 question Message-ID: Thread-Topic: [Isis-wg] Another draft-ietf-isis-restart-02 question Thread-Index: AcK2ZvZyVT6tOxX4S/SrVTtGGY/ZAwB16AgwAAClzpA= From: "Ravindra Sunkad" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0A0rBJ07037 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Jan 2003 16:44:01 -0800 Content-Transfer-Encoding: 8bit Oops. I meant "section 4.3" and not "section 4.2" in my previous email. > -----Original Message----- > From: Ravindra Sunkad > Sent: Thursday, January 09, 2003 4:41 PM > To: 'isis-wg@ietf.org' > Subject: RE: [Isis-wg] Another draft-ietf-isis-restart-02 question > > > Paragraph 4 of section 4.2 in draft-ietf-isis-restart-02 reads: > > "As LSPs are received (by the normal operation of the update process) > over any interface, the corresponding LSPID entry is removed (it is > also removed if the LSP had arrived before the CSNP containing the > reference). When an LSPID has been held in the list for its > indicated remaining lifetime, it is removed from the list. When the > list of LSPIDs becomes empty, the timer T2 is cancelled." > > Shouldn't the last sentence in above paragraph instead be: > > "When the list of LSPIDs is empty, and a complete set of > CSNP(s) and a restart acknowledgement have been received over > all the interfaces that have an adjacency at this level, the > timer T2 is cancelled." > > Thanks, > Ravi > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 02:09:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19272 for ; Fri, 10 Jan 2003 02:09:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A7JaJ04220; Fri, 10 Jan 2003 02:19:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A7I6J04165 for ; Fri, 10 Jan 2003 02:18:06 -0500 Received: from xover.netplane.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16423 for ; Fri, 10 Jan 2003 02:05:32 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HS9RJ>; Fri, 10 Jan 2003 02:08:44 -0500 Message-ID: From: "Jonnala, Nagi" To: "'Jeff Parker'" Cc: 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" Subject: [Isis-wg] Extended Circuit ID for Point-to-Point 3-Way Handshake. 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 02:10:49 -0500 Jeff, Don't we need to add Extended Circuit ID(a 4 byte integer), a configurable object to support the PTP 3-Way handshake mechanism? Also please note that it should be added to Circuit Table not to the Adjacency Table as you mentioned earlier. Thanks Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 05:30:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23442 for ; Fri, 10 Jan 2003 05:30:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAa9J18239; Fri, 10 Jan 2003 05:36:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAZ0J18180 for ; Fri, 10 Jan 2003 05:35:00 -0500 Received: from net4u.net4u.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23268 for ; Fri, 10 Jan 2003 05:22:18 -0500 (EST) Received: from net4u.ch (zux006-035-062.adsl.green.ch [81.6.35.62]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h0AAPUt29895; Fri, 10 Jan 2003 11:25:30 +0100 Message-ID: <3E1E9F94.7090004@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Parker CC: "ISIS-WG (E-mail)" Subject: Re: FW: [Isis-wg] RE: SystemID Type definition. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 11:25:24 +0100 Content-Transfer-Encoding: 7bit Jeff Parker wrote: > > >>>Jeff, >>> >>>I thought I've seen the following syntax before: >>>SYNTAX OCTET STRING (SIZE(0|6)) >>> >>>-don >>> > >Thanks, Don. I will make this change. > how can 0 make any sense ? That would per definition make all routers crash into each others' IDs ? Just wondering ? -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 05:37:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23661 for ; Fri, 10 Jan 2003 05:37:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAh9J19221; Fri, 10 Jan 2003 05:43:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAgFJ19167 for ; Fri, 10 Jan 2003 05:42:15 -0500 Received: from net4u.net4u.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23403 for ; Fri, 10 Jan 2003 05:29:35 -0500 (EST) Received: from net4u.ch (zux006-035-062.adsl.green.ch [81.6.35.62]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h0AAWqt31365 for ; Fri, 10 Jan 2003 11:32:52 +0100 Message-ID: <3E1EA14D.3070603@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ISIS-WG (E-mail)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] last call on draft draft-ietf-isis-admin-tags-01 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 11:32:45 +0100 Content-Transfer-Encoding: 7bit We are starting last call on draft-ietf-isis-admin-tags-01. The last call will end 1/24/03 thanks -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 05:38:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23682 for ; Fri, 10 Jan 2003 05:38:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAi2J19262; Fri, 10 Jan 2003 05:44:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAhRJ19235 for ; Fri, 10 Jan 2003 05:43:27 -0500 Received: from net4u.net4u.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23440 for ; Fri, 10 Jan 2003 05:30:47 -0500 (EST) Received: from net4u.ch (zux006-035-062.adsl.green.ch [81.6.35.62]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h0AAY4t31588 for ; Fri, 10 Jan 2003 11:34:04 +0100 Message-ID: <3E1EA196.2000602@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ISIS-WG (E-mail)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] last call on draft draft-ietf-isis-igp-p2p-over-lan-01 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 11:33:58 +0100 Content-Transfer-Encoding: 7bit We are starting last call on draft-ietf-isis-igp-p2p-over-lan-01. The last call will end 1/24/03 thanks -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 05:40:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23744 for ; Fri, 10 Jan 2003 05:40:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAk3J19355; Fri, 10 Jan 2003 05:46:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAjTJ19340 for ; Fri, 10 Jan 2003 05:45:29 -0500 Received: from net4u.net4u.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23498 for ; Fri, 10 Jan 2003 05:32:49 -0500 (EST) Received: from net4u.ch (zux006-035-062.adsl.green.ch [81.6.35.62]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h0AAa6t31897 for ; Fri, 10 Jan 2003 11:36:06 +0100 Message-ID: <3E1EA210.8080103@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ISIS-WG (E-mail)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] last call on draft draft-ietf-isis-iso-interoperable-00 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 11:36:00 +0100 Content-Transfer-Encoding: 7bit We are starting last call on draft-ietf-isis-iso-interoperable-00. The last call will end 1/24/03 thanks -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 05:41:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23801 for ; Fri, 10 Jan 2003 05:41:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAl7J19441; Fri, 10 Jan 2003 05:47:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAkMJ19382 for ; Fri, 10 Jan 2003 05:46:22 -0500 Received: from net4u.net4u.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23510 for ; Fri, 10 Jan 2003 05:33:40 -0500 (EST) Received: from net4u.ch (zux006-035-062.adsl.green.ch [81.6.35.62]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h0AAatt32010 for ; Fri, 10 Jan 2003 11:36:55 +0100 Message-ID: <3E1EA23F.2030800@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ISIS-WG (E-mail)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] last call on draft-ietf-isis-ip-interoperable-00 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 11:36:47 +0100 Content-Transfer-Encoding: 7bit We are starting last call on draft-ietf-isis-ip-interoperable-00. The last call will end 1/24/03 thanks -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 05:42:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23840 for ; Fri, 10 Jan 2003 05:42:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAm3J19527; Fri, 10 Jan 2003 05:48:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAlPJ19462 for ; Fri, 10 Jan 2003 05:47:25 -0500 Received: from net4u.net4u.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23544 for ; Fri, 10 Jan 2003 05:34:45 -0500 (EST) Received: from net4u.ch (zux006-035-062.adsl.green.ch [81.6.35.62]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h0AAc1t32158 for ; Fri, 10 Jan 2003 11:38:01 +0100 Message-ID: <3E1EA284.8090802@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ISIS-WG (E-mail)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] last call on draft-ietf-isis-restart-02 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 11:37:56 +0100 Content-Transfer-Encoding: 7bit We are starting last call on draft-ietf-isis-restart-02. The last call will end 1/24/03 thanks -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 05:45:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23919 for ; Fri, 10 Jan 2003 05:45:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAr9J19839; Fri, 10 Jan 2003 05:53:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AAqWJ19775 for ; Fri, 10 Jan 2003 05:52:32 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23722 for ; Fri, 10 Jan 2003 05:39:51 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0AAh4Fp013872; Fri, 10 Jan 2003 02:43:05 -0800 (PST) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp15.cisco.com [144.254.108.82]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA21463; Fri, 10 Jan 2003 10:43:02 GMT Message-Id: <4.3.2.7.2.20030110104249.04b38400@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ravindra Sunkad" From: mike shand Subject: RE: [Isis-wg] Another draft-ietf-isis-restart-02 question Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 10:43:00 +0000 At 16:41 09/01/2003 -0800, Ravindra Sunkad wrote: >Paragraph 4 of section 4.2 in draft-ietf-isis-restart-02 reads: > >"As LSPs are received (by the normal operation of the update process) > over any interface, the corresponding LSPID entry is removed (it is > also removed if the LSP had arrived before the CSNP containing the > reference). When an LSPID has been held in the list for its > indicated remaining lifetime, it is removed from the list. When the > list of LSPIDs becomes empty, the timer T2 is cancelled." > >Shouldn't the last sentence in above paragraph instead be: > >"When the list of LSPIDs is empty, and a complete set of CSNP(s) and a >restart acknowledgement have been received over all the interfaces that >have an adjacency at this level, the timer T2 is cancelled." Well, strictly, yes it should. But it would be better to say "When the list of LSPIDs is empty, and T1 has been cancelled for all the interfaces that have an adjacency at this level, the timer T2 is cancelled." Because we may have given up on getting an ack from some adjacencies (and hence cancelled T1 according to the pre-penultimate paragraph of clause 4.2 Mike >Thanks, >Ravi >_______________________________________________ >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 Jan 10 06:36:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25291 for ; Fri, 10 Jan 2003 06:36:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ABhZJ23933; Fri, 10 Jan 2003 06:43:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ABgFJ23820 for ; Fri, 10 Jan 2003 06:42:15 -0500 Received: from xover.netplane.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24954 for ; Fri, 10 Jan 2003 06:29:36 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HS9YZ>; Fri, 10 Jan 2003 06:32:47 -0500 Message-ID: From: "Jonnala, Nagi" To: "'Jeff Parker'" , "ISIS-WG (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] MIB: IPRA Table Comments 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 06:34:25 -0500 All, I've a couple of comments on IPRA table of mib-10. a) IPRA indices: ================ I'm just wondering why do we need isisIPRAIndex in the indices list? We can index into the table by using: Sys-Instance, Dest-Type, Dest-Address, Prefix-Len. Right? (or) Am I missing something? b) isisIPRANextHopType: ======================= Having DestType already in the table(Infact as one of the index), does isisIPRANextHopType carry any extra information? It MAY be the case, if the node is at the boarder of IPv4 and IPv6 or vice versa. Is this meant for that? or can we remove this field? c) isisIPRASNPAAddress: ======================= First of all, I'm not sure if using MAC address in IPRA table is okay. Where do we get this - from operator? or from other protocols? Please note that we already have isisIPRANextHop in the table. Shouldn't that be sufficient? Please correct me if I misinterpreted anything. Thanks Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 10:04:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29895 for ; Fri, 10 Jan 2003 10:04:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFERJ05436; Fri, 10 Jan 2003 10:14:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFBcJ05332 for ; Fri, 10 Jan 2003 10:11:38 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29682 for ; Fri, 10 Jan 2003 09:58:53 -0500 (EST) Message-ID: From: Jeff Parker To: "'prz@net4u.ch'" , Jeff Parker Cc: "ISIS-WG (E-mail)" Subject: RE: FW: [Isis-wg] RE: SystemID Type definition. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 10:01:58 -0500 > >>>I thought I've seen the following syntax before: > >>>SYNTAX OCTET STRING (SIZE(0|6)) > > > how can 0 make any sense ? That would per definition make all > routers crash into each others' IDs ? Just wondering ? > > -- tony Tony - At one time we were using SystemID in some place where a NULL was appropriate. I can no longer find such a spot, and I will remove the 0. In hindsight, I should have used some other type for that value anyway. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 10:12:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00119 for ; Fri, 10 Jan 2003 10:12:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFM6J05862; Fri, 10 Jan 2003 10:22:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFJUJ05760 for ; Fri, 10 Jan 2003 10:19:30 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29959 for ; Fri, 10 Jan 2003 10:06:46 -0500 (EST) Message-ID: From: Jeff Parker To: "ISIS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] FW: WideMetric, FullMetric Type definitions 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 10:09:55 -0500 > > Jeff, > > > > Can we change the types from Integer32 to Unsigned32? > > > > -Nagi. > > WideMetric ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Wide Metric for IS Neighbors. ISO 10589 > provides a 6 bit metric. > Traffic Engineering extensions provide 24 bit metrics." > SYNTAX Unsigned32 (0..16777215) > > FullMetric ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Full Metric for IP Routes. Traffic Engineering > extensions > provide 32 bit metrics." > SYNTAX Unsigned32 (0..16777215) > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 10:13:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00184 for ; Fri, 10 Jan 2003 10:13:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFOAJ05978; Fri, 10 Jan 2003 10:24:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFJoJ05767 for ; Fri, 10 Jan 2003 10:19:50 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29964 for ; Fri, 10 Jan 2003 10:07:05 -0500 (EST) Message-ID: From: Jeff Parker To: "'Jonnala, Nagi'" Cc: "ISIS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Extended Circuit ID for Point-to-Point 3-Way Handshake. 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 10:10:12 -0500 > Jeff, > > Don't we need to add Extended Circuit ID(a 4 byte integer), > a configurable object to support the PTP 3-Way handshake mechanism? > > Also please note that it should be added to Circuit Table > not to the Adjacency Table as you mentioned earlier. > > Thanks > Nagi. Of course: much better place for it. - jdp isisCircExtendedCircID OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "A unique value to be used as the extended circuit ID in 3Way handshake." ::= { isisCircEntry 14 } _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 10:42:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01125 for ; Fri, 10 Jan 2003 10:42:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFrWJ08310; Fri, 10 Jan 2003 10:53:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFq4J08218 for ; Fri, 10 Jan 2003 10:52:04 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00992 for ; Fri, 10 Jan 2003 10:39:18 -0500 (EST) Message-ID: From: Jeff Parker To: "'Jonnala, Nagi'" , "ISIS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: IPRA Table Comments 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 10:42:24 -0500 > I've a couple of comments on IPRA table of mib-10. > > a) IPRA indices: > ================ > > I'm just wondering why do we need isisIPRAIndex in > the indices list? > > We can index into the table by using: > > Sys-Instance, Dest-Type, Dest-Address, Prefix-Len. > > Right? (or) Am I missing something? There are many people who feel that complex indexing schemes are hard to deal with. This is intended to address that issue. I agree that there seems to be an excess of indicies here. > b) isisIPRANextHopType: > ======================= > > Having DestType already in the table(Infact as one of the index), > does isisIPRANextHopType carry any extra information? > > It MAY be the case, if the node is at the boarder of IPv4 > and IPv6 or vice versa. Is this meant for that? > > or can we remove this field? All IP addresses have been changed to tuples (type, value). I don't see any need to drop the generality here. > c) isisIPRASNPAAddress: > ======================= > > First of all, I'm not sure if using MAC address in IPRA table > is okay. Where do we get this - from operator? or from other > protocols? > > Please note that we already have isisIPRANextHop in the table. > Shouldn't that be sufficient? > > Please correct me if I misinterpreted anything. > > Thanks > Nagi. On a broadcast network, you learn the MAC address from the hello packets. I agree that it isn't very useful on P2P. While you can depend on IP's ARP table for this, I think this goes back to IS-IS's niche near the link layer in support of CLNS. Result: I don't see a pressing reason to change any of this. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 10:45:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01310 for ; Fri, 10 Jan 2003 10:45:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFu3J08528; Fri, 10 Jan 2003 10:56:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AFtPJ08473 for ; Fri, 10 Jan 2003 10:55:25 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01116 for ; Fri, 10 Jan 2003 10:42:39 -0500 (EST) Message-ID: From: Jeff Parker To: "ISIS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Additional Table 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 10:45:51 -0500 Before closing the books on Rev 11, I plan to add a new optional table to hold tuples, indexed by SystemID. Any suggestions or comments welcome. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Jan 10 17:44:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18906 for ; Fri, 10 Jan 2003 17:44:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AMsFJ03743; Fri, 10 Jan 2003 17:54:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AMpaJ03584 for ; Fri, 10 Jan 2003 17:51:36 -0500 Received: from xmxpita.excite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18659 for ; Fri, 10 Jan 2003 17:38:42 -0500 (EST) Received: by xmxpita.excite.com (Postfix, from userid 110) id C321CB6D0; Fri, 10 Jan 2003 17:41:55 -0500 (EST) To: jparker@axiowave.com, isis-wg@ietf.org Subject: RE: [Isis-wg] FW: WideMetric, FullMetric Type definitions Received: from [63.104.212.252] by xprdmailfe18.nwk.excite.com via HTTP; Fri, 10 Jan 2003 17:41:55 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 Reply-To: dgoodspe@excite.com From: "Don Goodspeed" 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: <20030110224155.C321CB6D0@xmxpita.excite.com> 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 17:41:55 -0500 (EST) Content-Transfer-Encoding: 7bit Jeff and all, In draft-ietf-isis-traffic-04.txt, section 4 contains: Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25). FullMetric's range should be (0..4261412864) then. -don > > Jeff, > > > > Can we change the types from Integer32 to Unsigned32? > > > > -Nagi. > > WideMetric ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Wide Metric for IS Neighbors. ISO 10589 > provides a 6 bit metric. > Traffic Engineering extensions provide 24 bit metrics." > SYNTAX Unsigned32 (0..16777215) > > FullMetric ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Full Metric for IP Routes. Traffic Engineering > extensions > provide 32 bit metrics." > SYNTAX Unsigned32 (0..16777215) > _______________________________________________ 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 Jan 13 15:14:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22490 for ; Mon, 13 Jan 2003 15:14:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKP3J19481; Mon, 13 Jan 2003 15:25:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKNKJ19384 for ; Mon, 13 Jan 2003 15:23:20 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22090 for ; Mon, 13 Jan 2003 15:09:03 -0500 (EST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0DKCL0E014158; Mon, 13 Jan 2003 12:12:21 -0800 (PST) Received: from ginsberg-w2k.cisco.com (sjc-vpn2-120.cisco.com [10.21.112.120]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADN18958; Mon, 13 Jan 2003 12:03:41 -0800 (PST) Message-Id: <4.3.2.7.2.20030113115959.00b567a8@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 From: Les Ginsberg Subject: Re: [Isis-wg] draft-ietf-isis-restart-02 question Cc: "Ravindra Sunkad" , In-Reply-To: <4.3.2.7.2.20030107160035.0289d080@jaws.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 12:12:20 -0800 The distinction between when to start transmitting locally generated non-pseudonode LSPs vs locally generated pseudonode LSPs is based on the fact that the information in pseudonode LSPs is strictly adjacency information and therefore not dependent on redistribution of inter-level information. However, if the state of ISs connected to a LAN differs from what existed prior to restart, there is no reliable way to determine when the restarting router has current adjacency information. (Note: If the state of ISs connected to a LAN has NOT changed then the old pseudonode LSPs are accurate and do not need to be reissued.) Therefore, it would be my preference to remove the distinction between pseudonode and non-pseudonode LSPs in the text and have the restarting router use T3 expiration/cancellation as the trigger to start transmitting all types of locally generated LSPs. Removal of the word "non-pseudonode" from the referenced text would accomplish that. Les At 04:07 PM 1/7/2003 +0000, mike shand wrote: >At 15:04 02/01/2003 -0800, Ravindra Sunkad wrote: >>Hi, >> >>Section 4.3.1.2 (Re-starting) paragraph 2 reads >> >>"In the case of a re-starting router, none of the router's own non- >> pseudonode LSPs are transmitted, nor are the router's own forwarding >> tables updated while the timer T3 is running." >> >>Does this mean that own pseudonodes can be transmitted before T3 is >>cancelled or expires? > >Yes, the point is that there is no propagation into pseudonodes between >levels so all we are concerned with is whether the adjacencies have been >established. > >> >>If yes: >> o At what point can the restarting router assume that all the >> adjacencies on a LAN circuit have been re-established? > >Well, you can never know for sure! There is no particular hurry, since the >old LSPs are still out there. If you KNOW that the information has changed >you should probably advertise that ASAP. The point is that you shouldn't >prematurely issue pseudonode LSP(s) with missing information and then >quickly replace them with information which is identical to what it was >before the re-start. > >Exactly what heuristic you use is implementation dependant. > > Mike > > > >> >>Thanks, >>Ravi > >_______________________________________________ >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 Jan 14 03:36:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19010 for ; Tue, 14 Jan 2003 03:36:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E8lfJ10639; Tue, 14 Jan 2003 03:47:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E8k6J10571 for ; Tue, 14 Jan 2003 03:46:06 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18922 for ; Tue, 14 Jan 2003 03:31:31 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0E8Yp0E014243; Tue, 14 Jan 2003 00:34:51 -0800 (PST) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp208.cisco.com [10.61.64.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA01319; Tue, 14 Jan 2003 08:34:39 GMT Message-Id: <4.3.2.7.2.20030114083129.04d19220@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Les Ginsberg From: mike shand Subject: Re: [Isis-wg] draft-ietf-isis-restart-02 question Cc: "Ravindra Sunkad" , In-Reply-To: <4.3.2.7.2.20030113115959.00b567a8@mira-sjc5-3.cisco.com> References: <4.3.2.7.2.20030107160035.0289d080@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 08:34:39 +0000 At 12:12 13/01/2003 -0800, Les Ginsberg wrote: >The distinction between when to start transmitting locally generated >non-pseudonode LSPs vs locally generated pseudonode LSPs is based on the >fact that the information in pseudonode LSPs is strictly adjacency >information and therefore not dependent on redistribution of inter-level >information. However, if the state of ISs connected to a LAN differs from >what existed prior to restart, there is no reliable way to determine when >the restarting router has current adjacency information. (Note: If the >state of ISs connected to a LAN has NOT changed then the old pseudonode >LSPs are accurate and do not need to be reissued.) Therefore, it would be >my preference to remove the distinction between pseudonode and >non-pseudonode LSPs in the text and have the restarting router use T3 >expiration/cancellation as the trigger to start transmitting all types of >locally generated LSPs. Removal of the word "non-pseudonode" from the >referenced text would accomplish that. That seems entirely reasonable to me. The subtle distinction between pseudonode and non-pseudonode is so subtle that it is both difficult and barely useful to exploit. It is less confusing, simply not to draw attention to it. Mike > Les > > >At 04:07 PM 1/7/2003 +0000, mike shand wrote: >>At 15:04 02/01/2003 -0800, Ravindra Sunkad wrote: >>>Hi, >>> >>>Section 4.3.1.2 (Re-starting) paragraph 2 reads >>> >>>"In the case of a re-starting router, none of the router's own non- >>> pseudonode LSPs are transmitted, nor are the router's own forwarding >>> tables updated while the timer T3 is running." >>> >>>Does this mean that own pseudonodes can be transmitted before T3 is >>>cancelled or expires? >> >>Yes, the point is that there is no propagation into pseudonodes between >>levels so all we are concerned with is whether the adjacencies have been >>established. >> >>> >>>If yes: >>> o At what point can the restarting router assume that all the >>> adjacencies on a LAN circuit have been re-established? >> >>Well, you can never know for sure! There is no particular hurry, since >>the old LSPs are still out there. If you KNOW that the information has >>changed you should probably advertise that ASAP. The point is that you >>shouldn't prematurely issue pseudonode LSP(s) with missing information >>and then quickly replace them with information which is identical to what >>it was before the re-start. >> >>Exactly what heuristic you use is implementation dependant. >> >> Mike >> >> >> >>> >>>Thanks, >>>Ravi >> >>_______________________________________________ >>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 Tue Jan 14 10:19:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27034 for ; Tue, 14 Jan 2003 10:19:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFTqJ03793; Tue, 14 Jan 2003 10:29:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFSVJ03728 for ; Tue, 14 Jan 2003 10:28:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26633; Tue, 14 Jan 2003 10:13:50 -0500 (EST) Message-Id: <200301141513.KAA26633@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ipv6-05.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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 10:13:50 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Routing IPv6 with IS-IS Author(s) : C. Hopps Filename : draft-ietf-isis-ipv6-05.txt Pages : 7 Date : 2003-1-13 This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes 2 new TLVs, a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-ipv6-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-ipv6-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-13142124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ipv6-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ipv6-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-13142124.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 14 19:41:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17479 for ; Tue, 14 Jan 2003 19:41:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0rsJ16495; Tue, 14 Jan 2003 19:53:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0qVJ16444 for ; Tue, 14 Jan 2003 19:52:31 -0500 Received: from ns2.vivacenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17371 for ; Tue, 14 Jan 2003 19:37:38 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BC2E.C4DFF684" Message-ID: Thread-Topic: draft-ietf-isis-restart-02: Update process question Thread-Index: AcK8Lslwis3DIN7LTVOeMF9njn1k3g== From: "Ravindra Sunkad" To: Subject: [Isis-wg] draft-ietf-isis-restart-02: Update process question 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 16:40:57 -0800 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2BC2E.C4DFF684 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section "4.3.1.2 Restarting" states two things: 1. Do not flood 'own' LSPs before they are completely rebuilt 2. Ignore LSP/SNP updates of 'own' LSPs before they are completely rebuilt =20 I have the following questions regarding the update process operation on the restarting router before it has completely rebuilt it's 'own' LSPs: =20 1. Should a restarting router send out CSNPs on a circuit 'C' that it would normally send out? If yes, must it include SNP entries for it's 'own' LSPs in these? =20 2. Do ACKs have to be sent on receipt of 'own' LSPs from a helper router on a point-to-point circuit? =20 Thanks, Ravi ------_=_NextPart_001_01C2BC2E.C4DFF684 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Section "4.3.1.2 Restarting" states two = things:
    1. Do not flood 'own' LSPs before they are = completely rebuilt
    2. Ignore LSP/SNP updates of 'own' = LSPs before=20 they are completely
       = rebuilt
 
I have the following questions = regarding the update=20 process operation on the
restarting router before it has completely = rebuilt=20 it's 'own' LSPs:
 
1. Should a restarting router send out = CSNPs on a=20 circuit 'C' that it would
   normally send out? If yes, = must it=20 include SNP entries for it's 'own' LSPs
   in = these?
 
2. Do ACKs have to be sent on receipt = of 'own' LSPs=20 from a helper router on a
   point-to-point circuit?
 
Thanks,
Ravi
=00 ------_=_NextPart_001_01C2BC2E.C4DFF684-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jan 15 04:10:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20625 for ; Wed, 15 Jan 2003 04:10:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9KlJ25434; Wed, 15 Jan 2003 04:20:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F9JFJ25329 for ; Wed, 15 Jan 2003 04:19:15 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20516 for ; Wed, 15 Jan 2003 04:04:10 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0F96sjS022532; Wed, 15 Jan 2003 01:06:55 -0800 (PST) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4333.cisco.com [10.61.80.236]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA07893; Wed, 15 Jan 2003 09:07:29 GMT Message-Id: <4.3.2.7.2.20030115084921.04a43608@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ravindra Sunkad" From: mike shand Subject: Re: [Isis-wg] draft-ietf-isis-restart-02: Update process question Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 09:07:25 +0000 At 16:40 14/01/2003 -0800, Ravindra Sunkad wrote: >Section "4.3.1.2 Restarting" states two things: > 1. Do not flood 'own' LSPs before they are completely rebuilt > 2. Ignore LSP/SNP updates of 'own' LSPs before they are completely > rebuilt > >I have the following questions regarding the update process operation on the >restarting router before it has completely rebuilt it's 'own' LSPs: > >1. Should a restarting router send out CSNPs on a circuit 'C' that it would > normally send out? If yes, must it include SNP entries for it's 'own' LSPs > in these? Yes it should send CSNPs. It doesn't really matter whether or not the own LSPs are mentioned. If they are not mentioned, the neighbors will send copies of the ones which they have. If they ARE mentioned, but have a lower sequence number than the copies the neighbors hold, the neighbors will still send them. If they are mentioned and have the SAME sequence number as those the neighbors hold, nothing will happen. If they are mentioned and have a greater sequence number (shouldn't happen) than those the neighbors hold or if some neighbor doesn't have them, then the neighbor will ask for them. In all cases the arrival of the "newer" version or the request is ignored until the LSPs are really there. I would say for preference don't mention them, since you don't "really" have them (yet). > >2. Do ACKs have to be sent on receipt of 'own' LSPs from a helper router on a > point-to-point circuit? Again, it doesn't really matter. If you acknowledge it, you will shut the neighbor up. If you don't, it will keep asking. But we should probably have it all sorted out by the next time it would ask anyway and will have already sent out our real LSP (with a sequence number of 1) which will provoke the neighbor to send the old copy again, so we can trump it with a higher sequence number. It all amounts to the same thing really. Or you could even remember the sequence number of the copy the neighbor sent you the first time (before you were ready) and use that to determine the sequence number to use for the first LSP. I would say for preference ACK them. What you must NOT do is purge them. The real guiding principle here is to do whatever comes naturally. i.e. we are NOT defining a NEW update process, but simply using the existing one in a creative way. There are always (even with the "normal" update process) lots of "optimizations" you COULD do with impunity, but the safest approach is not to attempt any special casing and just follow the normal very simple rules. Mike > >Thanks, >Ravi _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jan 15 17:22:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12215 for ; Wed, 15 Jan 2003 17:22:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMWlJ15211; Wed, 15 Jan 2003 17:32:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMVXJ15116 for ; Wed, 15 Jan 2003 17:31:33 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11984 for ; Wed, 15 Jan 2003 17:16:10 -0500 (EST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0FMJU0E017119; Wed, 15 Jan 2003 14:19:30 -0800 (PST) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-182.cisco.com [128.107.163.182]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADO70358; Wed, 15 Jan 2003 14:10:20 -0800 (PST) Message-Id: <4.3.2.7.2.20030115120901.00b49bc0@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 From: Les Ginsberg Subject: Re: [Isis-wg] draft-ietf-isis-restart-02: Update process question Cc: "Ravindra Sunkad" , In-Reply-To: <4.3.2.7.2.20030115084921.04a43608@jaws.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 14:19:25 -0800 At 09:07 AM 1/15/2003 +0000, mike shand wrote: >At 16:40 14/01/2003 -0800, Ravindra Sunkad wrote: >>Section "4.3.1.2 Restarting" states two things: >> 1. Do not flood 'own' LSPs before they are completely rebuilt >> 2. Ignore LSP/SNP updates of 'own' LSPs before they are completely >> rebuilt >> >>I have the following questions regarding the update process operation on the >>restarting router before it has completely rebuilt it's 'own' LSPs: >> >>1. Should a restarting router send out CSNPs on a circuit 'C' that it would >> normally send out? If yes, must it include SNP entries for it's 'own' >> LSPs >> in these? > >Yes it should send CSNPs. > >It doesn't really matter whether or not the own LSPs are mentioned. This statement MUST be amended to say that if your own LSPs are mentioned in CSNPs sent during restart, the info MUST be based on copies you have received from neighbors during the restart process. If own LSPs are never mentioned, this is OK as well. I say "MUST be amended" because there is one possible case where your old incarnation LSP will get purged unless the amended statement is followed. Please see below. >If they are not mentioned, the neighbors will send copies of the ones >which they have. > >If they ARE mentioned, but have a lower sequence number than the copies >the neighbors hold, the neighbors will still send them. > >If they are mentioned and have the SAME sequence number as those the >neighbors hold, nothing will happen. Not always true. If you did NOT base your SNP entry on a copy of the old incarnation LSP you received during the restart period, the checksums are likely to differ. This will result in a purge - which is VERY BAD. The likelihood of this case occurring is low, but non-zero. >If they are mentioned and have a greater sequence number (shouldn't >happen) than those the neighbors hold or if some neighbor doesn't have >them, then the neighbor will ask for them. Yes. And the neighbor will clear the SRMflag for the old copy it holds. So you may never receive your old copy. This may not be a problem - unless you are trying to match the new copies you generate after T3 by using the old incarnation copies. Unlikely I suppose. >In all cases the arrival of the "newer" version or the request is ignored >until the LSPs are really there. This seems to suggest that an implementation has no interest in the old copies of its own LSPs. While an implementation can certainly choose that path, there is value in storing these LSPs. You can reduce the number of copies/retransmissions of these LSPs that are received by storing them and including them in CSNPs sent subsequently. You can also use the sequence # as a starting point for regenerating these LSPs after T3 has stopped. Both of these things are optimizations, not requirements. >I would say for preference don't mention them, since you don't "really" >have them (yet). > I think the optimal thing is to mention them if you have a copy you have received from a neighbor. Second best is not to mention them at all. Dangerous to mention a locally generated copy. >>2. Do ACKs have to be sent on receipt of 'own' LSPs from a helper router on a >> point-to-point circuit? > >Again, it doesn't really matter. If you acknowledge it, you will shut the >neighbor up. If you don't, it will keep asking. But we should probably >have it all sorted out by the next time it would ask anyway and will have >already sent out our real LSP (with a sequence number of 1) which will >provoke the neighbor to send the old copy again, so we can trump it with a >higher sequence number. > >It all amounts to the same thing really. > >Or you could even remember the sequence number of the copy the neighbor >sent you the first time (before you were ready) and use that to determine >the sequence number to use for the first LSP. > >I would say for preference ACK them. What you must NOT do is purge them. > >The real guiding principle here is to do whatever comes naturally. i.e. we >are NOT defining a NEW update process, but simply using the existing one >in a creative way. There are always (even with the "normal" update >process) lots of "optimizations" you COULD do with impunity, but the >safest approach is not to attempt any special casing and just follow the >normal very simple rules. I agree - but an implementation has to do "something" a bit differently from normal. It could: o discard local LSPs received during restart o store local LSPs received during restart but suppress purging/regeneration Either way it must be sure that it does NOT send SNP entries based on local LSPs which it generated post restart until T3 has stopped. There are a variety of ways to do this as well, but regardless of what goes on behind the "implementation curtain" what appears on the wire in CSNPs must be constrained. > Mike > > >> >>Thanks, >>Ravi > >_______________________________________________ >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 Thu Jan 16 03:44:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04894 for ; Thu, 16 Jan 2003 03:44:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G8v7J01793; Thu, 16 Jan 2003 03:57:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G8smJ01632 for ; Thu, 16 Jan 2003 03:54:48 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04765 for ; Thu, 16 Jan 2003 03:39:15 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h0G8gZPg028308; Thu, 16 Jan 2003 00:42:36 -0800 (PST) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4238.cisco.com [10.61.80.141]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA16232; Thu, 16 Jan 2003 08:42:32 GMT Message-Id: <4.3.2.7.2.20030116083826.04bb3cf0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Les Ginsberg From: mike shand Subject: Re: [Isis-wg] draft-ietf-isis-restart-02: Update process question Cc: "Ravindra Sunkad" , In-Reply-To: <4.3.2.7.2.20030115120901.00b49bc0@mira-sjc5-3.cisco.com> References: <4.3.2.7.2.20030115084921.04a43608@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 08:42:28 +0000 At 14:19 15/01/2003 -0800, Les Ginsberg wrote: >At 09:07 AM 1/15/2003 +0000, mike shand wrote: >>At 16:40 14/01/2003 -0800, Ravindra Sunkad wrote: >>>Section "4.3.1.2 Restarting" states two things: >>> 1. Do not flood 'own' LSPs before they are completely rebuilt >>> 2. Ignore LSP/SNP updates of 'own' LSPs before they are completely >>> rebuilt >>> >>>I have the following questions regarding the update process operation on the >>>restarting router before it has completely rebuilt it's 'own' LSPs: >>> >>>1. Should a restarting router send out CSNPs on a circuit 'C' that it would >>> normally send out? If yes, must it include SNP entries for it's >>> 'own' LSPs >>> in these? >> >>Yes it should send CSNPs. >> >>It doesn't really matter whether or not the own LSPs are mentioned. > > >This statement MUST be amended to say that if your own LSPs are mentioned >in CSNPs sent during restart, the info MUST be based on copies you have >received from neighbors during the restart process. If own LSPs are never >mentioned, this is OK as well. I say "MUST be amended" because there is >one possible case where your old incarnation LSP will get purged unless >the amended statement is followed. Please see below. > >>If they are not mentioned, the neighbors will send copies of the ones >>which they have. >> >>If they ARE mentioned, but have a lower sequence number than the copies >>the neighbors hold, the neighbors will still send them. >> >>If they are mentioned and have the SAME sequence number as those the >>neighbors hold, nothing will happen. > >Not always true. If you did NOT base your SNP entry on a copy of the old >incarnation LSP you received during the restart period, the checksums are >likely to differ. This will result in a purge - which is VERY BAD. The >likelihood of this case occurring is low, but non-zero. Yes. You are absolutely right of course. >>If they are mentioned and have a greater sequence number (shouldn't >>happen) than those the neighbors hold or if some neighbor doesn't have >>them, then the neighbor will ask for them. > >Yes. And the neighbor will clear the SRMflag for the old copy it holds. So >you may never receive your old copy. This may not be a problem - unless >you are trying to match the new copies you generate after T3 by using the >old incarnation copies. Unlikely I suppose. > >>In all cases the arrival of the "newer" version or the request is ignored >>until the LSPs are really there. > >This seems to suggest that an implementation has no interest in the old >copies of its own LSPs. While an implementation can certainly choose that >path, there is value in storing these LSPs. You can reduce the number of >copies/retransmissions of these LSPs that are received by storing them and >including them in CSNPs sent subsequently. You can also use the sequence # >as a starting point for regenerating these LSPs after T3 has stopped. Both >of these things are optimizations, not requirements. > >>I would say for preference don't mention them, since you don't "really" >>have them (yet). > >I think the optimal thing is to mention them if you have a copy you have >received from a neighbor. >Second best is not to mention them at all. >Dangerous to mention a locally generated copy. I agree. Perhaps we should actually state that. i.e. do not mention a locally generated copy. >>>2. Do ACKs have to be sent on receipt of 'own' LSPs from a helper router >>>on a >>> point-to-point circuit? >> >>Again, it doesn't really matter. If you acknowledge it, you will shut the >>neighbor up. If you don't, it will keep asking. But we should probably >>have it all sorted out by the next time it would ask anyway and will have >>already sent out our real LSP (with a sequence number of 1) which will >>provoke the neighbor to send the old copy again, so we can trump it with >>a higher sequence number. >> >>It all amounts to the same thing really. >> >>Or you could even remember the sequence number of the copy the neighbor >>sent you the first time (before you were ready) and use that to determine >>the sequence number to use for the first LSP. >> >>I would say for preference ACK them. What you must NOT do is purge them. >> >>The real guiding principle here is to do whatever comes naturally. i.e. >>we are NOT defining a NEW update process, but simply using the existing >>one in a creative way. There are always (even with the "normal" update >>process) lots of "optimizations" you COULD do with impunity, but the >>safest approach is not to attempt any special casing and just follow the >>normal very simple rules. > >I agree - but an implementation has to do "something" a bit differently >from normal. It could: > > o discard local LSPs received during restart > o store local LSPs received during restart but suppress > purging/regeneration > >Either way it must be sure that it does NOT send SNP entries based on >local LSPs which it generated post restart until T3 has stopped. There are >a variety of ways to do this as well, but regardless of what goes on >behind the "implementation curtain" what appears on the wire in CSNPs must >be constrained. > >> Mike >> >> >>> >>>Thanks, >>>Ravi >> >>_______________________________________________ >>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 Thu Jan 16 05:13:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06085 for ; Thu, 16 Jan 2003 05:13:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GAQZJ08166; Thu, 16 Jan 2003 05:26:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GAPUJ08111 for ; Thu, 16 Jan 2003 05:25:30 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06008 for ; Thu, 16 Jan 2003 05:09:55 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 427A62F0175; Thu, 16 Jan 2003 02:13:17 -0800 (PST) To: mike shand Cc: Les Ginsberg , "Ravindra Sunkad" , isis-wg@ietf.org Subject: Re: [Isis-wg] draft-ietf-isis-restart-02: Update process question In-reply-to: Mail from mike shand dated Thu, 16 Jan 2003 08:42:28 GMT <4.3.2.7.2.20030116083826.04bb3cf0@jaws.cisco.com> From: Naiming Shen Message-Id: <20030116101317.427A62F0175@prattle.redback.com> 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 02:13:17 -0800 I don't see any reason to change the restarting router CSNP behaviour during the restart. i.e. to hide the local lsps as suggested in this thread. During restart, the restarting router starts its own lsps from 1 and it probably has a previous life higher seq# lsps out there, for example seq X. if the restarting router is a DIS on the lan, it's perfectly fine to announce the local lsps with seq less than X, equal to X, or higher than X. a) if it sends csnp with local lsp with seq less than X, then the neighbors will send its previous lsp with seq# X over. for the normal lsp operation, the router should increase its lsp to seq# X+1. b) if it sends out with seq X, and chksum does not match with the old copy. notice that, the restarting router can NOT send out this lsp with seq# X during the restart, it can only send CSNP to indicate that. the spec certainly does not say the neighbor should purge the existing lsp just because it sees the same seq# with diff chksum in a csnp and purge the lsp. when the restarting router receives its old lsp, even it want to purge, but it can't, since it's not allowed to send lsp out(including purged lsps). it should just up the seq# as in case (a). c) if it sends csnp with local lsp with seq larger than X, the neighbors should just send psnp to request this lsp(but can't get it). the neighbors should still keep the old lsp around until they get the higher seq# lsps from the restarting router. when the restarting router is allowed to send out the lsps, it will have the seq# lager than X. the neighbors will update their database. thus in all a, b, and c cases, sending out csnp with its local lsps do not in any way affect the restarting router or the neighbor non-stop forwarding status. then we should keep the normal DIS csnp behaviour to minimize the changes to the graceful restart. thanks. ] At 14:19 15/01/2003 -0800, Les Ginsberg wrote: ] >At 09:07 AM 1/15/2003 +0000, mike shand wrote: ] >>At 16:40 14/01/2003 -0800, Ravindra Sunkad wrote: ] >>>Section "4.3.1.2 Restarting" states two things: ] >>> 1. Do not flood 'own' LSPs before they are completely rebuilt ] >>> 2. Ignore LSP/SNP updates of 'own' LSPs before they are completely ] >>> rebuilt ] >>> ] >>>I have the following questions regarding the update process operation on the ] >>>restarting router before it has completely rebuilt it's 'own' LSPs: ] >>> ] >>>1. Should a restarting router send out CSNPs on a circuit 'C' that it wou ld ] >>> normally send out? If yes, must it include SNP entries for it's ] >>> 'own' LSPs ] >>> in these? ] >> ] >>Yes it should send CSNPs. ] >> ] >>It doesn't really matter whether or not the own LSPs are mentioned. ] > ] > ] >This statement MUST be amended to say that if your own LSPs are mentioned ] >in CSNPs sent during restart, the info MUST be based on copies you have ] >received from neighbors during the restart process. If own LSPs are never ] >mentioned, this is OK as well. I say "MUST be amended" because there is ] >one possible case where your old incarnation LSP will get purged unless ] >the amended statement is followed. Please see below. ] > ] >>If they are not mentioned, the neighbors will send copies of the ones ] >>which they have. ] >> ] >>If they ARE mentioned, but have a lower sequence number than the copies ] >>the neighbors hold, the neighbors will still send them. ] >> ] >>If they are mentioned and have the SAME sequence number as those the ] >>neighbors hold, nothing will happen. ] > ] >Not always true. If you did NOT base your SNP entry on a copy of the old ] >incarnation LSP you received during the restart period, the checksums are ] >likely to differ. This will result in a purge - which is VERY BAD. The ] >likelihood of this case occurring is low, but non-zero. ] ] Yes. You are absolutely right of course. ] ] ] ] >>If they are mentioned and have a greater sequence number (shouldn't ] >>happen) than those the neighbors hold or if some neighbor doesn't have ] >>them, then the neighbor will ask for them. ] > ] >Yes. And the neighbor will clear the SRMflag for the old copy it holds. So ] >you may never receive your old copy. This may not be a problem - unless ] >you are trying to match the new copies you generate after T3 by using the ] >old incarnation copies. Unlikely I suppose. ] > ] >>In all cases the arrival of the "newer" version or the request is ignored ] >>until the LSPs are really there. ] > ] >This seems to suggest that an implementation has no interest in the old ] >copies of its own LSPs. While an implementation can certainly choose that ] >path, there is value in storing these LSPs. You can reduce the number of ] >copies/retransmissions of these LSPs that are received by storing them and ] >including them in CSNPs sent subsequently. You can also use the sequence # ] >as a starting point for regenerating these LSPs after T3 has stopped. Both ] >of these things are optimizations, not requirements. ] > ] >>I would say for preference don't mention them, since you don't "really" ] >>have them (yet). ] > ] >I think the optimal thing is to mention them if you have a copy you have ] >received from a neighbor. ] >Second best is not to mention them at all. ] >Dangerous to mention a locally generated copy. ] ] I agree. Perhaps we should actually state that. i.e. do not mention a ] locally generated copy. ] ] ] ] >>>2. Do ACKs have to be sent on receipt of 'own' LSPs from a helper router ] >>>on a ] >>> point-to-point circuit? ] >> ] >>Again, it doesn't really matter. If you acknowledge it, you will shut the ] >>neighbor up. If you don't, it will keep asking. But we should probably ] >>have it all sorted out by the next time it would ask anyway and will have ] >>already sent out our real LSP (with a sequence number of 1) which will ] >>provoke the neighbor to send the old copy again, so we can trump it with ] >>a higher sequence number. ] >> ] >>It all amounts to the same thing really. ] >> ] >>Or you could even remember the sequence number of the copy the neighbor ] >>sent you the first time (before you were ready) and use that to determine ] >>the sequence number to use for the first LSP. ] >> ] >>I would say for preference ACK them. What you must NOT do is purge them. ] >> ] >>The real guiding principle here is to do whatever comes naturally. i.e. ] >>we are NOT defining a NEW update process, but simply using the existing ] >>one in a creative way. There are always (even with the "normal" update ] >>process) lots of "optimizations" you COULD do with impunity, but the ] >>safest approach is not to attempt any special casing and just follow the ] >>normal very simple rules. ] > ] >I agree - but an implementation has to do "something" a bit differently ] >from normal. It could: ] > ] > o discard local LSPs received during restart ] > o store local LSPs received during restart but suppress ] > purging/regeneration ] > ] >Either way it must be sure that it does NOT send SNP entries based on ] >local LSPs which it generated post restart until T3 has stopped. There are ] >a variety of ways to do this as well, but regardless of what goes on ] >behind the "implementation curtain" what appears on the wire in CSNPs must ] >be constrained. ] > ] >> Mike ] >> ] >> ] >>> ] >>>Thanks, ] >>>Ravi ] >> ] >>_______________________________________________ ] >>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 - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jan 16 05:47:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06753 for ; Thu, 16 Jan 2003 05:47:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GB19J10567; Thu, 16 Jan 2003 06:01:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GB0xJ10434 for ; Thu, 16 Jan 2003 06:00:59 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06669 for ; Thu, 16 Jan 2003 05:45:25 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0GAmiuV018854; Thu, 16 Jan 2003 02:48:44 -0800 (PST) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp15.cisco.com [144.254.108.82]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA19374; Thu, 16 Jan 2003 10:48:43 GMT Message-Id: <4.3.2.7.2.20030116103927.04da0008@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Naiming Shen From: mike shand Subject: Re: [Isis-wg] draft-ietf-isis-restart-02: Update process question Cc: Les Ginsberg , "Ravindra Sunkad" , isis-wg@ietf.org In-Reply-To: <20030116101317.427A62F0175@prattle.redback.com> References: <4.3.2.7.2.20030116083826.04bb3cf0@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 10:44:25 +0000 At 02:13 16/01/2003 -0800, Naiming Shen wrote: >b) if it sends out with seq X, and chksum does not match with the > old copy. notice that, the restarting router can NOT send out this > lsp with seq# X during the restart, it can only send CSNP to > indicate that. the spec certainly does not say the neighbor should > purge the existing lsp just because it sees the same seq# with diff > chksum in a csnp and purge the lsp. when the restarting router > receives its old lsp, even it want to purge, but it can't, since > it's not allowed to send lsp out(including purged lsps). it should > just up the seq# as in case (a). Hmm interesting question. In general I think you DO have to invoke whatever "LSP confusion" mechanism you are using (i.e. either purging, or treating the higher checksum as newer), when you see a CSNP entry which has the same sequence number but different checksum to your LSP. If you don't do this, you could join two isolated portions of the network which have different epochs of LSPs and you wouldn't detect anything was amiss. Or am I once again speaking without thinking hard enough? Mike _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jan 16 06:33:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07541 for ; Thu, 16 Jan 2003 06:33:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GBkRJ14103; Thu, 16 Jan 2003 06:46:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GBjSJ14001 for ; Thu, 16 Jan 2003 06:45:28 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07413 for ; Thu, 16 Jan 2003 06:29:53 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id C4162309A85; Thu, 16 Jan 2003 03:33:13 -0800 (PST) To: mike shand Cc: Naiming Shen , Les Ginsberg , "Ravindra Sunkad" , isis-wg@ietf.org Subject: Re: [Isis-wg] draft-ietf-isis-restart-02: Update process question In-reply-to: Mail from mike shand dated Thu, 16 Jan 2003 10:44:25 GMT <4.3.2.7.2.20030116103927.04da0008@jaws.cisco.com> From: Naiming Shen Message-Id: <20030116113313.C4162309A85@prattle.redback.com> 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 03:33:13 -0800 you can either send your copy over, or you can ask for a copy. either one will trigger a purge in the normal case as defined in "LSP confusion". but in this graceful restarting case, neither action will trigger a purge, this is actually what we want. usually during the restart, the restarting router either have a lower seq# lsp, or higher(due to received its own old lsp), it should be very rare to see an equal seq# case. thanks. ] At 02:13 16/01/2003 -0800, Naiming Shen wrote: ] >b) if it sends out with seq X, and chksum does not match with the ] > old copy. notice that, the restarting router can NOT send out this ] > lsp with seq# X during the restart, it can only send CSNP to ] > indicate that. the spec certainly does not say the neighbor should ] > purge the existing lsp just because it sees the same seq# with diff ] > chksum in a csnp and purge the lsp. when the restarting router ] > receives its old lsp, even it want to purge, but it can't, since ] > it's not allowed to send lsp out(including purged lsps). it should ] > just up the seq# as in case (a). ] ] Hmm interesting question. In general I think you DO have to invoke whatever ] "LSP confusion" mechanism you are using (i.e. either purging, or treating ] the higher checksum as newer), when you see a CSNP entry which has the same ] sequence number but different checksum to your LSP. If you don't do this, ] you could join two isolated portions of the network which have different ] epochs of LSPs and you wouldn't detect anything was amiss. ] ] Or am I once again speaking without thinking hard enough? ] ] Mike ] ] ] ] - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jan 16 07:27:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08200 for ; Thu, 16 Jan 2003 07:27:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GCeDJ17302; Thu, 16 Jan 2003 07:40:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GCdlJ17249 for ; Thu, 16 Jan 2003 07:39:47 -0500 Received: from xover.netplane.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08100 for ; Thu, 16 Jan 2003 07:24:11 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HTHSH>; Thu, 16 Jan 2003 07:27:26 -0500 Message-ID: From: "Jonnala, Nagi" To: "'chopps@allegronetworks.com'" Cc: 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" Subject: [Isis-wg] RE:draft-ietf-isis-ipv6-05.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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 07:29:34 -0500 Chris, According to the draft, adjacency formation between IPv4-only and IPv6-only routers is not clear. Do they form adjacency at all? If they don't form we might need to specify it in Section.5 - IPV6 NLPID. If we do form adjacency and we can't forward the traffic, we need to have a section similar to 4.5 of RFC1195 - "Forwarding to Incompatible Routers". Thanks Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jan 16 09:12:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11548 for ; Thu, 16 Jan 2003 09:12:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEPQJ25129; Thu, 16 Jan 2003 09:25:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEOUJ25062 for ; Thu, 16 Jan 2003 09:24:30 -0500 Received: from ghostrider.gredler.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11480 for ; Thu, 16 Jan 2003 09:08:46 -0500 (EST) Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h0GEBlo13122; Thu, 16 Jan 2003 15:11:47 +0100 From: Hannes Gredler To: "Jonnala, Nagi" Cc: "'chopps@allegronetworks.com'" , isis-wg@ietf.org Subject: Re: [Isis-wg] RE:draft-ietf-isis-ipv6-05.txt Message-ID: <20030116141147.GA13103@juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 15:11:47 +0100 On Thu, Jan 16, 2003 at 07:29:34AM -0500, Jonnala, Nagi wrote: | Chris, | | According to the draft, adjacency formation between IPv4-only | and IPv6-only routers is not clear. | | Do they form adjacency at all? If they don't form | we might need to specify it in Section.5 - IPV6 NLPID. what we have seen so far in the field is: if there is no matching subnet of the same adress family then the adjacency does not come up. i.e. IPv4-only and IPv6-only routers won't form an adjacency; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jan 16 09:58:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12997 for ; Thu, 16 Jan 2003 09:58:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFBFJ28807; Thu, 16 Jan 2003 10:11:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFAOJ28720 for ; Thu, 16 Jan 2003 10:10:24 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12857 for ; Thu, 16 Jan 2003 09:54:43 -0500 (EST) Message-ID: From: Jeff Parker To: "'Jonnala, Nagi'" Cc: "ISIS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: IPRA Table Comments 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 09:57:54 -0500 > | > a) IPRA indices: > | > ================ > | > > | > I'm just wondering why do we need isisIPRAIndex in > | > the indices list? > | > > | > We can index into the table by using: > | > > | > Sys-Instance, Dest-Type, Dest-Address, Prefix-Len. > | > | There are many people who feel that complex indexing > | schemesare hard to deal with. This is intended to > | address that issue. I agree that there > | seems to be an excess of indicies here. > > Nagi>> > > The reason I see is that "If something is not needed, why should it be > there". The presence of isisIPRAIndex made sense when "Dest-Type, > Dest-Address, Prefix-Len" were not there. Once these three > new indices are > introduced, isisIPRAIndex should have gone. > > I agree that it MAY be there, but with the expense of: > > i) Every now and then people come up with the same question. > ii)Complex indexing scheme will be deployed. > > Thanks > Nagi. Nagi - I agree that the index needs to be cleaned up. However, we will wind up with multiple routes, either due to ECMP or to routes appearing at L1 and L2. We can rename things and move them around, but if you want a simple index, it would have to be by dropping the Dest information. We will need some index to distinguish routes with the same destination. I suspect that people will want to search this table by Destination, and I will try a versio that reorders that, and puts another index later in the sequence. - 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 Jan 16 14:01:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20845 for ; Thu, 16 Jan 2003 14:01:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJDXJ15387; Thu, 16 Jan 2003 14:13:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJCoJ15346 for ; Thu, 16 Jan 2003 14:12:50 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20470 for ; Thu, 16 Jan 2003 13:57:06 -0500 (EST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0GJ0R0E000894; Thu, 16 Jan 2003 11:00:27 -0800 (PST) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-182.cisco.com [128.107.163.182]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADP23344; Thu, 16 Jan 2003 10:51:10 -0800 (PST) Message-Id: <4.3.2.7.2.20030116105307.00b30d88@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 From: Les Ginsberg Subject: Re: [Isis-wg] draft-ietf-isis-restart-02: Update process question Cc: Naiming Shen , "Ravindra Sunkad" , isis-wg@ietf.org In-Reply-To: <4.3.2.7.2.20030116103927.04da0008@jaws.cisco.com> References: <20030116101317.427A62F0175@prattle.redback.com> <4.3.2.7.2.20030116083826.04bb3cf0@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 11:00:26 -0800 At 10:44 AM 1/16/2003 +0000, mike shand wrote: >At 02:13 16/01/2003 -0800, Naiming Shen wrote: >>b) if it sends out with seq X, and chksum does not match with the >> old copy. notice that, the restarting router can NOT send out this >> lsp with seq# X during the restart, it can only send CSNP to >> indicate that. the spec certainly does not say the neighbor should >> purge the existing lsp just because it sees the same seq# with diff >> chksum in a csnp and purge the lsp. when the restarting router >> receives its old lsp, even it want to purge, but it can't, since >> it's not allowed to send lsp out(including purged lsps). it should >> just up the seq# as in case (a). > >Hmm interesting question. In general I think you DO have to invoke >whatever "LSP confusion" mechanism you are using (i.e. either purging, or >treating the higher checksum as newer), when you see a CSNP entry which >has the same sequence number but different checksum to your LSP. If you >don't do this, you could join two isolated portions of the network which >have different epochs of LSPs and you wouldn't detect anything was amiss. > >Or am I once again speaking without thinking hard enough? This is an old defect in the spec. DR 1 against ISO 10589 (circa 1992) mentioned that the rules in determining which LSP was newer should be applied the same for SNP entries as for received LSPs, but this was not explicit in the spec. Appropriate changes to the spec were specified, but due to some long ago confusion were never published in any of the TCs. These changes have been incorporated into the 2001 draft of ISO 10589 (to be published someday I hope). The relevant portion here is that the rules associated with LSP confusion (7.3.16.2) are to be applied to received SNP entries just as they would for a received LSP. So in this case if the neighbor of a restarting router received an SNP entry from the restarting router which matched its database entry in sequence # but checksums differed, then the neighbor is duty bound to purge the LSP. This, of course, is undesirable in this case. Although this is an unlikely case to occur, it is possible. Les > Mike > > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jan 20 12:59:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25551 for ; Mon, 20 Jan 2003 12:59:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KICRJ03643; Mon, 20 Jan 2003 13:12:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KIABJ03564 for ; Mon, 20 Jan 2003 13:10:11 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25402 for ; Mon, 20 Jan 2003 12:52:30 -0500 (EST) Message-ID: From: Jeff Parker To: "'Nob'" Cc: "ISIS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: IS-IS MIB related Query 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 12:55:52 -0500 > Hello Mr. Parker > i wanna know whether the isisLSPTLVTable is for only SELF-LSPs or for all the LSPs in the LSDB, I feel it is for all the LSPs in the LSDB,,,,,,,,,,, but i want this clarification as i have seen this table implemented only for SELF-LSPs in one of the commercially available IS-IS stack. Whereas they did implement isisLSPSummaryTable for all the LSPs in the LSDB. Please clarify in this regard......... TIA Nob - You are right, the table is intended to allow you to view any LSP. Not that this is not a Mandatory table. - jeff parker isisLSPTLVEntry OBJECT-TYPE SYNTAX IsisLSPTLVEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry describes an LSP current stored in the system." INDEX { isisSysInstance, isisLSPLevel, isisLSPID, isisLSPTLVIndex } ::= { isisLSPTLVTable 1 } _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jan 20 14:14:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27962 for ; Mon, 20 Jan 2003 14:14:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJTcJ08244; Mon, 20 Jan 2003 14:29:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJSUJ08210 for ; Mon, 20 Jan 2003 14:28:30 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27823 for ; Mon, 20 Jan 2003 14:10:47 -0500 (EST) Message-ID: From: Jeff Parker To: "'Joyal, Daniel R (Daniel)'" Cc: "ISIS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: OSPF MIB support for multiple OSPF processes 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 14:14:08 -0500 > Jeff, > > Given the comments below, where did you get the > requirement to explicitly support multiple IS-IS > instances in the IS-IS MIB? > > -Dan Dan - You are refering to the SysInstance index in the IS-IS MIB. Use of this was not a requirement: it came with the original version of the MIB I inherited. I would be interested to hear from any users that find this useful. While it seems to offer a solution, I don't know of any other MIB that supports this, so people will have to design an alternative anyway. It isn't too late to rip this out if it has no utility. - jeff parker > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@DIAL.PIPEX.COM] > Sent: Monday, January 20, 2003 1:16 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPF MIB support for multiple OSPF processes > > > Yes. > In SNMPv1, this can be done by having multiple 'agents' identified by > different community names or different IP addresses, each accessing a > distinct incarnation of MIB II and its subordinate branches. > In SNMPv3, there is a more sophisticated mechanism of contexts which > formalises the techniques given above. > I do not think you should ever return more than one instance of a > given object in GET or GETNEXT. > > Tom Petch > nwnetworks@dial.pipex.com > > -----Original Message----- > From: Roy Jose > To: OSPF@DISCUSS.MICROSOFT.COM > Date: 20 January 2003 16:04 > Subject: OSPF MIB support for multiple OSPF processes > > > >Hi, > > > >Rfc1850 doesn't talk about what to be done regarding the > retrieval(GET) of > >MIB values when multiple OSPF processes exist on a router. Out first > >impression is to return details about all the processes. The problem > is > >while selecting values for MIB objects like > >ospfRouterId,ospfAreaBdrRtrStatus, ospfASBdrRtrStatus etc. They may > differ > >in separate processes. The Qn is, can we really support multiple > processes > >with rfc1850? > > > >Thanks, > >Roy > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 21 05:04:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24926 for ; Tue, 21 Jan 2003 05:04:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LAITJ04259; Tue, 21 Jan 2003 05:18:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LAFNJ04142 for ; Tue, 21 Jan 2003 05:15:23 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24705 for ; Tue, 21 Jan 2003 04:57:23 -0500 (EST) Received: (qmail 32296 invoked from network); 21 Jan 2003 10:00:48 -0000 Received: from unknown (205.158.62.68) by spf1.us.outblaze.com with QMQP; 21 Jan 2003 10:00:48 -0000 Received: (qmail 6194 invoked from network); 21 Jan 2003 10:00:47 -0000 Received: from unknown (HELO ws1-10.us4.outblaze.com) (205.158.62.111) by 205-158-62-153.outblaze.com with SMTP; 21 Jan 2003 10:00:47 -0000 Received: (qmail 17963 invoked by uid 1001); 21 Jan 2003 10:00:47 -0000 Message-ID: <20030121100047.17962.qmail@iname.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [156.106.200.207] by ws1-10.us4.outblaze.com with http for philip.christian@iname.com; Tue, 21 Jan 2003 10:00:47 +0000 From: "Philip Christian" To: hannes@juniper.net, "Jonnala, Nagi" Cc: "'chopps@allegronetworks.com'" , isis-wg@ietf.org Subject: Re: [Isis-wg] RE:draft-ietf-isis-ipv6-05.txt X-Originating-Ip: 156.106.200.207 X-Originating-Server: ws1-10.us4.outblaze.com 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 10:00:47 +0000 Content-Transfer-Encoding: 7bit You might want to have a look at section 4 and 5 of http://www.ietf.org/internet-drafts/draft-ietf-isis-auto-encap-02.txt too. Auto-encap would certainly be more idiot proof if someway could be built into isis-ipv6 to prevent an IPv6 only router from forming an adjacency with an IPv4 only router, in line with what the ITU-T did in G.7712. Regards, Philip ----- Original Message ----- From: Hannes Gredler Date: Thu, 16 Jan 2003 15:11:47 +0100 To: "Jonnala, Nagi" Subject: Re: [Isis-wg] RE:draft-ietf-isis-ipv6-05.txt > On Thu, Jan 16, 2003 at 07:29:34AM -0500, Jonnala, Nagi wrote: > | Chris, > | > | According to the draft, adjacency formation between IPv4-only > | and IPv6-only routers is not clear. > | > | Do they form adjacency at all? If they don't form > | we might need to specify it in Section.5 - IPV6 NLPID. > > what we have seen so far in the field is: > if there is no matching subnet of the > same adress family then the adjacency does not come up. > i.e. IPv4-only and IPv6-only routers won't form an adjacency; > > /hannes > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Meet Singles http://corp.mail.com/lavalife _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 21 14:38:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09961 for ; Tue, 21 Jan 2003 14:38:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LJrrJ11605; Tue, 21 Jan 2003 14:53:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LJo7J11453 for ; Tue, 21 Jan 2003 14:50:07 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09715 for ; Tue, 21 Jan 2003 14:31:55 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 70800FD56D; Tue, 21 Jan 2003 11:34:37 -0800 (PST) To: Hannes Gredler Cc: "'chopps@allegronetworks.com'" , isis-wg@ietf.org Subject: Re: [Isis-wg] RE:draft-ietf-isis-ipv6-05.txt In-reply-to: Mail from Hannes Gredler dated Thu, 16 Jan 2003 15:11:47 +0100 <20030116141147.GA13103@juniper.net> From: Naiming Shen Message-Id: <20030121193437.70800FD56D@prattle.redback.com> 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 11:34:37 -0800 there is always a problem of DIS election on the LAN when multiple address families involved. or the same address family but multiple topologies exist such as in M-ISIS case. i would think it's much simpler to ALWAYS establish IS adjacency with neighbors regardless of their common NLPIDs. this way, we guarantee that there will be a single DIS elected on the LAN for isis. but locally, label each adjacency to be "usable" or "non-usable". a router can only forward traffic to a "usable" adjacency. an adjacency is "usable" if the neighbor has at least one common NLPID (or topology id). we install the IS neighbor TLV in the LSP only if there exist at least one "usable" adjacency on the LAN. the psedo-node lsp should contain all the adacencies, "usable" and "non-usable". thanks. ] On Thu, Jan 16, 2003 at 07:29:34AM -0500, Jonnala, Nagi wrote: ] | Chris, ] | ] | According to the draft, adjacency formation between IPv4-only ] | and IPv6-only routers is not clear. ] | ] | Do they form adjacency at all? If they don't form ] | we might need to specify it in Section.5 - IPV6 NLPID. ] ] what we have seen so far in the field is: ] if there is no matching subnet of the ] same adress family then the adjacency does not come up. ] i.e. IPv4-only and IPv6-only routers won't form an adjacency; ] ] /hannes ] _______________________________________________ ] 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 Wed Jan 22 14:51:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04882 for ; Wed, 22 Jan 2003 14:51:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MK6BJ15050; Wed, 22 Jan 2003 15:06:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MK4kJ14938 for ; Wed, 22 Jan 2003 15:04:46 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04666 for ; Wed, 22 Jan 2003 14:46:05 -0500 (EST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0MJnTFp021669; Wed, 22 Jan 2003 11:49:29 -0800 (PST) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-200.cisco.com [128.107.163.200]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADS42201; Wed, 22 Jan 2003 11:38:55 -0800 (PST) Message-Id: <4.3.2.7.2.20030122110715.00b83358@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: prz@net4u.ch From: Les Ginsberg Subject: Re: [Isis-wg] last call on draft-ietf-isis-restart-02 Cc: "ISIS-WG (E-mail)" In-Reply-To: <3E1EA284.8090802@net4u.ch> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3472413==_.ALT" 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 11:49:00 -0800 --=====================_3472413==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:37 AM 1/10/2003 +0100, Tony Przygienda wrote: >We are starting last call on draft-ietf-isis-restart-02. The last call >will end 1/24/03 > > > thanks > > -- tony Some issues with the draft in its current form: 1)In regard to LANs, if the restarting router was DIS (at either level) then it is necessary that it continue to be DIS at that level following restart in order to avoid unnecessary disruption in the network. This requires that the circuit ID associated with the LAN circuits on which the restarting router was/is DIS does not change across restarts. The only place the circuit ID used pre-restart can be found is in the LAN IIHs received from neighboring routers i.e. the neighbors had copied this information from IIHs sent by the re-starting router prior to the re-start event according to the rules in ISO 10589 8.4.5 (penultimate paragraph). In order to prevent this information from being overwritten with whatever circuit ID might be initially assigned by the restarting router, it is necessary for the neighbors of a restarting router to ignore the LANID in IIHs with the RR bit set. This requirement is not explicit in the draft. 2)When T3 expires the current draft says(4.3.1.2): If the timer T3 expires before all the T2 timers have expired, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized ... Once the restarting router begins issuing newly generated LSPs it should begin updating its own FIB so that it is consistent with what is being advertised. It would be better to say that the restarting router should begin normal operation of the update process, begin SPF calculations, and begin updating its own FIB. Basically we should exit restart mode with the exception that we allow T2 to continue to run (as it would in the case of a starting router) so we know how long to continue to set the OL bit. 3)When a router "starts" (NOT restarts) there may be stale LSPs in the network from its previous incarnation. This can cause temporary blackholes until the normal operation of the update process removes the stale LSPs from the network. The fundamental cause of the problem lies in the fact that IS-IS does not require LSP-DB synchronization prior to advertising a new adjacency. While modifying the protocol rules for adjacency formation would undoubtedly be an unpopular/unwise solution, the restart TLV in IIHs provides us with an opportunity to solve this problem in a less intrusive and backwards compatible way. Here's the idea: a)Use one of the unused bits in the restart TLV to request suppressing advertisement of the adjacency (SA bit) b)A restart capable router which is rebooting in a non-restart environment (e.g. unexpected reboot or other case in which it is unable to maintain forwarding plane across reboots) would set this bit in IIHs that it sends until it had achieved LSP database synchronization (or T2 expires) c)A restart capable neighbor of the restarting router which sees the "SA" bit in the IIH would delay advertising the neighbor in its own LSPs until the SA bit is cleared. It would also send a set of CSNPs each time it saw an IIH with the "SA" bit set - thus making CSNP delivery reliable in the case of a starting router (just as it now is for restart using the RR bit). Les --=====================_3472413==_.ALT Content-Type: text/html; charset="us-ascii" At 11:37 AM 1/10/2003 +0100, Tony Przygienda wrote:
We are starting last call on draft-ietf-isis-restart-02. The last call will end 1/24/03


   thanks

   -- tony

Some issues with the draft in its current form:

1)In regard to LANs, if the restarting router was DIS (at either level) then it is necessary that it continue to be DIS at that level following restart in order to avoid unnecessary disruption in the network. This requires that the circuit ID associated with the LAN circuits on which the restarting router was/is DIS does not change across restarts. The only place the circuit ID used pre-restart can be found is in the LAN IIHs received from neighboring routers i.e. the neighbors had copied this information from IIHs sent by the re-starting router prior to the re-start event according to the rules in ISO 10589 8.4.5 (penultimate paragraph). In order to prevent this information from being overwritten with whatever circuit ID might be initially assigned by the restarting router, it is necessary for the neighbors of a restarting router to ignore the LANID in IIHs with the RR bit set. This requirement is not explicit in the draft.

2)When T3 expires the current draft says(4.3.1.2):
 If the timer T3 expires before all the T2 timers have expired, this
   indicates that the synchronization process is taking longer than
   minimum holding time of the neighbors. The router's own LSP(s) for
   levels which have not yet completed their first SPF computation are
   then flooded with the overload bit set to indicate that the router's
   LSPDB is not yet synchronized ...
Once the restarting router begins issuing newly generated LSPs it should begin updating its own FIB so that it is consistent with what is being advertised. It would be better to say that the restarting router should begin normal operation of the update process, begin SPF calculations, and begin updating its own FIB. Basically we should exit restart mode with the exception that we allow T2 to continue to run (as it would in the case of a starting router) so we know how long to continue to set the OL bit.


3)When a router "starts" (NOT restarts) there may be stale LSPs in the network from its previous incarnation. This can cause temporary blackholes until the normal operation of the update process removes the stale LSPs from the network. The fundamental cause of the problem lies in the fact that IS-IS does not require LSP-DB synchronization prior to advertising a new adjacency. While modifying the protocol rules for adjacency formation would undoubtedly be an unpopular/unwise solution, the restart TLV in IIHs provides us with an opportunity to solve this problem in a less intrusive and backwards compatible way. Here's the idea:

a)Use one of the unused bits in the restart TLV to request suppressing advertisement of the adjacency (SA bit)
b)A restart capable router which is rebooting in a non-restart environment (e.g. unexpected reboot or other case in which it is unable to maintain forwarding plane across reboots) would set this bit in IIHs that it sends until it had achieved LSP database synchronization (or T2 expires)
c)A restart capable neighbor of the restarting router which sees the "SA" bit in the IIH would delay advertising the neighbor in its own LSPs until the SA bit is cleared. It would also send a set of CSNPs each time it saw an IIH with the "SA" bit set - thus making CSNP delivery reliable in the case of a starting router (just as it now is for restart using the RR bit).

   Les

--=====================_3472413==_.ALT-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 28 05:50:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20607 for ; Tue, 28 Jan 2003 05:50:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SB73J09212; Tue, 28 Jan 2003 06:07:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SB54J09036 for ; Tue, 28 Jan 2003 06:05:04 -0500 Received: from spyserver (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20538 for ; Tue, 28 Jan 2003 05:43:33 -0500 (EST) Received: from localhost ([127.0.0.1] helo=spyserver.spymac.com) by spyserver with esmtp (Exim 3.35 #1 (Debian)) id 18dTG6-0004Ii-00 for ; Tue, 28 Jan 2003 03:46:26 -0700 Content-Disposition: inline Content-Transfer-Encoding: binary Mime-Version: 1.0 From: Saravana Kumar To: isis-wg@ietf.org Reply-To: sarav_k@spymac.com Content-Type: text/plain X-Mailer: AtMail Corp 3.4 - http://webbasedemail.com/ X-Uidl: 1043750786165197780 X-Origin: 203.197.168.168 Message-Id: Content-Transfer-Encoding: binary Subject: [Isis-wg] advertising P2P neighbors address in LSPs and IPv6 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 03:46:26 -0700 Content-Transfer-Encoding: binary Hi, Once an adjacency is extablished over a P2P link, we advertise the neighbors IP address in our LSP's as internal reachability info. Is it mandatory and if so, is there any specific reason for doing so ? Because currently in IPv6 it is not possible to advertise the P2P's neighbors address in the LSP's, since the neighbor sends us only the link-local addresses for the circuit in its hello PDU's. Thanks, sarav _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 28 06:09:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20928 for ; Tue, 28 Jan 2003 06:09:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SBT4J10691; Tue, 28 Jan 2003 06:29:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SBSjJ10664 for ; Tue, 28 Jan 2003 06:28:45 -0500 Received: from xover.netplane.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20879 for ; Tue, 28 Jan 2003 06:07:20 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HTZ0S>; Tue, 28 Jan 2003 06:10:51 -0500 Message-ID: From: "Manral, Vishwas" To: "'sarav_k@spymac.com'" , isis-wg@ietf.org Subject: RE: [Isis-wg] advertising P2P neighbors address in LSPs and IPv6 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 06:12:44 -0500 Hi Sarav, If you advertize reachability information in your LSP, it is used by the SPF process in the routers. If you do not advertize it(delay advertizing it) the other routers will not take the path to the destination thru you, but take an alternate path(if one exists). It would not create any routing loops. Thanks, Vishwas -----Original Message----- From: Saravana Kumar [mailto:sarav_k@spymac.com] Sent: Tuesday, January 28, 2003 4:16 PM To: isis-wg@ietf.org Subject: [Isis-wg] advertising P2P neighbors address in LSPs and IPv6 Hi, Once an adjacency is extablished over a P2P link, we advertise the neighbors IP address in our LSP's as internal reachability info. Is it mandatory and if so, is there any specific reason for doing so ? Because currently in IPv6 it is not possible to advertise the P2P's neighbors address in the LSP's, since the neighbor sends us only the link-local addresses for the circuit in its hello PDU's. Thanks, sarav _______________________________________________ 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 Jan 28 06:29:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21374 for ; Tue, 28 Jan 2003 06:29:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SBm9J12452; Tue, 28 Jan 2003 06:48:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SBlNJ12401 for ; Tue, 28 Jan 2003 06:47:24 -0500 Received: from ghostrider.gredler.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21318 for ; Tue, 28 Jan 2003 06:25:52 -0500 (EST) Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h0SBTK409973; Tue, 28 Jan 2003 12:29:20 +0100 From: Hannes Gredler To: Saravana Kumar Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] advertising P2P neighbors address in LSPs and IPv6 Message-ID: <20030128112920.GA9938@juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 12:29:20 +0100 On Tue, Jan 28, 2003 at 03:46:26AM -0700, Saravana Kumar wrote: | Hi, | | Once an adjacency is extablished over a P2P link, we advertise the neighbors IP | address in our LSP's as internal reachability info. Is it mandatory and if so, is | there any specific reason for doing so ? its not mandatory, the major implementations do not advertise it and i would be curious if it was somebody with an OSPF background who did implement this ? /hannes | Because currently in IPv6 it is not possible to advertise the P2P's neighbors | address in the LSP's, since the neighbor sends us only the link-local addresses | for the circuit in its hello PDU's. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jan 28 09:26:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26537 for ; Tue, 28 Jan 2003 09:26:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SEjEJ23437; Tue, 28 Jan 2003 09:45:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SEhtJ23383 for ; Tue, 28 Jan 2003 09:43:55 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26435 for ; Tue, 28 Jan 2003 09:22:24 -0500 (EST) Message-ID: From: Jeff Parker To: "ISIS-WG (E-mail)" Cc: "'jonathan.sadler@tellabs.com'" Subject: FW: [Isis-wg] RE: OSPF MIB support for multiple OSPF processes MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 09:25:51 -0500 All - One user of the SysIndex in the MIB. Jonathan - Did you need similar functionality for some other mib - perhaps the interface mib? How did you deal with other mibs? - jeff parker > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > Sent: Tuesday, January 28, 2003 5:06 AM > To: Jeff Parker > Subject: Re: [Isis-wg] RE: OSPF MIB support for multiple OSPF > processes > > > Jeff - > > I do have use for this in SONET/SDH environments -- > specifically this index > allows for support of multiple logical IS-IS instances on one physical > platform. This is needed for: > - more than one Area per physical platform > - separation of IS-IS routing for the DCN from separate IS-IS > routing for other layer networks (i.e. GMPLS) > > Jeff Parker wrote: > > > > > > Jeff, > > > > > > Given the comments below, where did you get the > > > requirement to explicitly support multiple IS-IS > > > instances in the IS-IS MIB? > > > > > > -Dan > > > > Dan - > > You are refering to the SysInstance index in > > the IS-IS MIB. Use of this was not a requirement: > > it came with the original version of the MIB I inherited. > > > > I would be interested to hear from any users > > that find this useful. While it seems to offer > > a solution, I don't know of any other MIB that supports > > this, so people will have to design an alternative > > anyway. > > > > It isn't too late to rip this out if it has > > no utility. > > > > - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jan 29 00:46:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17304 for ; Wed, 29 Jan 2003 00:46:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T5xfJ18308; Wed, 29 Jan 2003 00:59:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T5vYJ18257 for ; Wed, 29 Jan 2003 00:57:34 -0500 Received: from spyserver (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17166 for ; Wed, 29 Jan 2003 00:35:46 -0500 (EST) Received: from localhost ([127.0.0.1] helo=spyserver.spymac.com) by spyserver with esmtp (Exim 3.35 #1 (Debian)) id 18dkvg-0007c3-00; Tue, 28 Jan 2003 22:38:32 -0700 Content-Disposition: inline Content-Transfer-Encoding: binary Mime-Version: 1.0 From: Saravana Kumar To: Saravana Kumar , isis-wg@ietf.org, Hannes Gredler Subject: Re: [Isis-wg] advertising P2P neighbors address in LSPs and IPv6 Reply-To: sarav_k@spymac.com Content-Type: text/plain X-Mailer: AtMail Corp 3.4 - http://webbasedemail.com/ X-Uidl: 104375352009 X-Origin: 203.197.168.168 Message-Id: Content-Transfer-Encoding: binary 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 22:38:32 -0700 Content-Transfer-Encoding: binary On Tue, 28 Jan 2003 12:29 , Hannes Gredler sent: >On Tue, Jan 28, 2003 at 03:46:26AM -0700, Saravana Kumar wrote: >| Hi, >| >| Once an adjacency is extablished over a P2P link, we advertise the neighbors IP >| address in our LSP's as internal reachability info. Is it mandatory and if so, is >| there any specific reason for doing so ? > >its not mandatory, the major implementations do not advertise it >and i would be curious if it was somebody with an OSPF background >who did implement this ? >/hannes > >| Because currently in IPv6 it is not possible to advertise the P2P's neighbors >| address in the LSP's, since the neighbor sends us only the link-local addresses >| for the circuit in its hello PDU's. > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jan 29 00:48:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17337 for ; Wed, 29 Jan 2003 00:48:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T675J18722; Wed, 29 Jan 2003 01:07:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T66fJ18568 for ; Wed, 29 Jan 2003 01:06:41 -0500 Received: from spyserver (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17247 for ; Wed, 29 Jan 2003 00:44:53 -0500 (EST) Received: from localhost ([127.0.0.1] helo=spyserver.spymac.com) by spyserver with esmtp (Exim 3.35 #1 (Debian)) id 18dl4a-00024J-00; Tue, 28 Jan 2003 22:47:44 -0700 Content-Disposition: inline Content-Transfer-Encoding: binary Mime-Version: 1.0 From: Saravana Kumar To: Saravana Kumar , isis-wg@ietf.org, Hannes Gredler Subject: Re: [Isis-wg] advertising P2P neighbors address in LSPs and IPv6 Reply-To: sarav_k@spymac.com Content-Type: text/plain X-Mailer: AtMail Corp 3.4 - http://webbasedemail.com/ X-Uidl: 1043753415049 X-Origin: 203.197.168.168 Cc: jparker@axiowave.com Message-Id: Content-Transfer-Encoding: binary 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 22:47:44 -0700 Content-Transfer-Encoding: binary sorry about the last empty post.. Well, if its not mandatory to advertise the neighbors IP address in the LSPs, then perhaps this infomation should be added to the ip-interoperability draft, for future references. Thanks, Sarav On Tue, 28 Jan 2003 12:29 , Hannes Gredler sent: >On Tue, Jan 28, 2003 at 03:46:26AM -0700, Saravana Kumar wrote: >| Hi, >| >| Once an adjacency is extablished over a P2P link, we advertise the neighbors IP >| address in our LSP's as internal reachability info. Is it mandatory and if so, is >| there any specific reason for doing so ? > >its not mandatory, the major implementations do not advertise it >and i would be curious if it was somebody with an OSPF background >who did implement this ? > >/hannes > >| Because currently in IPv6 it is not possible to advertise the P2P's neighbors >| address in the LSP's, since the neighbor sends us only the link-local addresses >| for the circuit in its hello PDU's. > > >_______________________________________________ >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 Jan 29 03:55:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13706 for ; Wed, 29 Jan 2003 03:55:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T9ErJ08513; Wed, 29 Jan 2003 04:14:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0T9DIJ08464 for ; Wed, 29 Jan 2003 04:13:19 -0500 Received: from mx4.tellabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13595 for ; Wed, 29 Jan 2003 03:51:25 -0500 (EST) Received: from mailw02.hq.tellabs.com (mailw02.lisle.tellabs.com [172.23.207.12]) by mx4.tellabs.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ABW65135; Wed, 29 Jan 2003 02:54:57 -0600 (CST) Received: from tellabs.com ([192.168.225.16]) by mailw02.hq.tellabs.com with ESMTP (8.9.3 (PHNE_24419)/8.7.1) id CAA24857; Wed, 29 Jan 2003 02:54:56 -0600 (CST) Message-ID: <3E3796D1.86F8483E@tellabs.com> From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker CC: "ISIS-WG (E-mail)" Subject: Re: FW: [Isis-wg] RE: OSPF MIB support for multiple OSPF processes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mirapoint-Sig: mx4.tellabs.com 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Jan 2003 02:54:41 -0600 Content-Transfer-Encoding: 7bit Jeff - Acutally, we used a common ifIndex space so no issue existed with respect to the interface mib. And since we were not dealing with multiple instances of IP forwarding, we didn't have any problems with the IP MIBs. Of course, if someone would like to add multi-instance support in the interface or IP Forwarding-related MIBs, we would actively support it :^) Jonathan Sadler Jeff Parker wrote: > All - > One user of the SysIndex in the MIB. > > Jonathan - > Did you need similar functionality for some other > mib - perhaps the interface mib? How did you deal with > other mibs? > > - jeff parker > > > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > > Sent: Tuesday, January 28, 2003 5:06 AM > > To: Jeff Parker > > Subject: Re: [Isis-wg] RE: OSPF MIB support for multiple OSPF > > processes > > > > > > Jeff - > > > > I do have use for this in SONET/SDH environments -- > > specifically this index > > allows for support of multiple logical IS-IS instances on one physical > > platform. This is needed for: > > - more than one Area per physical platform > > - separation of IS-IS routing for the DCN from separate IS-IS > > routing for other layer networks (i.e. GMPLS) > > > > Jeff Parker wrote: > > > > > > > > > Jeff, > > > > > > > > Given the comments below, where did you get the > > > > requirement to explicitly support multiple IS-IS > > > > instances in the IS-IS MIB? > > > > > > > > -Dan > > > > > > Dan - > > > You are refering to the SysInstance index in > > > the IS-IS MIB. Use of this was not a requirement: > > > it came with the original version of the MIB I inherited. > > > > > > I would be interested to hear from any users > > > that find this useful. While it seems to offer > > > a solution, I don't know of any other MIB that supports > > > this, so people will have to design an alternative > > > anyway. > > > > > > It isn't too late to rip this out if it has > > > no utility. > > > > > > - jeff parker > ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jan 29 10:45:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22231 for ; Wed, 29 Jan 2003 10:45:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TG2uJ02736; Wed, 29 Jan 2003 11:02:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TG07J02560 for ; Wed, 29 Jan 2003 11:00:07 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22084 for ; Wed, 29 Jan 2003 10:38:05 -0500 (EST) Message-ID: From: Jeff Parker To: "'jonathan.sadler@tellabs.com'" , Jeff Parker Cc: "ISIS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Need to SysInstance in MIBs 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Jan 2003 10:41:21 -0500 Jonathan - Interesting. To press you on this, you did not need to invent some solution for some other MIB - perhaps another routing MIB? Perhaps there is a real need. - jeff parker > Jeff - > > Acutally, we used a common ifIndex space so no issue > existed with respect to the interface mib. And since > we were not dealing with multiple instances of IP > forwarding, we didn't have any problems with the IP MIBs. > > Jonathan Sadler > > Jeff Parker wrote: > > > Jonathan - > > Did you need similar functionality for some other > > mib - perhaps the interface mib? How did you deal with > > other mibs? > > > > - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jan 29 14:19:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26968 for ; Wed, 29 Jan 2003 14:19:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TJcoJ17188; Wed, 29 Jan 2003 14:38:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TJZKJ16405 for ; Wed, 29 Jan 2003 14:35:20 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26679 for ; Wed, 29 Jan 2003 14:13:14 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0TJH3US022741; Wed, 29 Jan 2003 14:17:03 -0500 (EST) Received: from jlearman-w2k01.cisco.com (dhcp-64-102-222-215.cisco.com [64.102.222.215]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABH34577; Wed, 29 Jan 2003 14:16:12 -0500 (EST) Message-Id: <4.3.2.7.2.20030129090301.0458af60@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: sarav_k@spymac.com From: Jeff Learman Subject: Re: [Isis-wg] advertising P2P neighbors address in LSPs and IPv6 Cc: Saravana Kumar , isis-wg@ietf.org, Hannes Gredler , jparker@axiowave.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Jan 2003 13:18:51 -0500 I'm not sure I understand what's being said here. 1195 defines what 128 TLVs can contain and what it means, but it does not state that a router must include IP addresses of IS neighbors. Since this information is redundant, it makes sense that it isn't required. Why would this be an interoperability issue? What might a router legally do that would depend on whether another router in the area included the redundant information or not? There's no harm in documenting it, but I don't see how it would be an interoperability issue. This is more of a conformance issue -- and I don't see anyone clamoring for conformance testing ;) Regards, Jeff At 12:47 AM 1/29/2003, Saravana Kumar wrote: >sorry about the last empty post.. > >Well, if its not mandatory to advertise the neighbors IP address in the LSPs, >then perhaps this infomation should be added to the ip-interoperability draft, >for future references. > >Thanks, >Sarav > >On Tue, 28 Jan 2003 12:29 , Hannes Gredler sent: > >>On Tue, Jan 28, 2003 at 03:46:26AM -0700, Saravana Kumar wrote: >>| Hi, >>| >>| Once an adjacency is extablished over a P2P link, we advertise the neighbors >IP >>| address in our LSP's as internal reachability info. Is it mandatory and if >so, is >>| there any specific reason for doing so ? >> >>its not mandatory, the major implementations do not advertise it >>and i would be curious if it was somebody with an OSPF background >>who did implement this ? >> >>/hannes >> >>| Because currently in IPv6 it is not possible to advertise the P2P's neighbors >>| address in the LSP's, since the neighbor sends us only the link-local >addresses >>| for the circuit in its hello PDU's. >> >> >>_______________________________________________ >>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 Jan 29 14:24:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27087 for ; Wed, 29 Jan 2003 14:24:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TJe6J17323; Wed, 29 Jan 2003 14:40:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TJdqJ17255 for ; Wed, 29 Jan 2003 14:39:52 -0500 Received: from titanium.ekay.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26805 for ; Wed, 29 Jan 2003 14:17:47 -0500 (EST) Received: from 0 ([127.0.0.1] helo=titanium.ekay.org) by titanium.ekay.org with esmtp (Exim 3.35 #1 (Debian)) id 18dxn5-0004Lp-00; Wed, 29 Jan 2003 11:22:31 -0800 Message-ID: <873cnbu5fs.wl@titanium.ekay.org> From: Noguchi Kay To: Naiming Shen Cc: Hannes Gredler , "'chopps@allegronetworks.com'" , isis-wg@ietf.org Subject: Re: [Isis-wg] RE:draft-ietf-isis-ipv6-05.txt In-Reply-To: <20030121193437.70800FD56D@prattle.redback.com> References: X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Jan 2003 11:22:31 -0800 Hi Naiming and all, I wrote a draft which tackles this problem. http://www.ietf.org/internet-drafts/draft-noguchi-isis-protocol-topology.txt This draft introduces "Protocols Supported Sub-TLV" in Extended IS Reachability TLV to keep the neighboring router's NLPID information and create protocol specific SPF tree for each network layer protocol using that information. In this way, IPv4 router, IPv6 router and IPv4/IPv6 dual router can co-exist in a single routing domain. Any comments? Thank you, kay At Tue, 21 Jan 2003 11:34:37 -0800, Naiming Shen wrote: > > > there is always a problem of DIS election on the LAN when multiple > address families involved. or the same address family but multiple > topologies exist such as in M-ISIS case. > > i would think it's much simpler to ALWAYS establish IS adjacency > with neighbors regardless of their common NLPIDs. this way, we > guarantee that there will be a single DIS elected on the LAN for > isis. but locally, label each adjacency to be "usable" or "non-usable". > a router can only forward traffic to a "usable" adjacency. an > adjacency is "usable" if the neighbor has at least one common NLPID > (or topology id). we install the IS neighbor TLV in the LSP only if > there exist at least one "usable" adjacency on the LAN. the psedo-node > lsp should contain all the adacencies, "usable" and "non-usable". > > thanks. > > ] On Thu, Jan 16, 2003 at 07:29:34AM -0500, Jonnala, Nagi wrote: > ] | Chris, > ] | > ] | According to the draft, adjacency formation between IPv4-only > ] | and IPv6-only routers is not clear. > ] | > ] | Do they form adjacency at all? If they don't form > ] | we might need to specify it in Section.5 - IPV6 NLPID. > ] > ] what we have seen so far in the field is: > ] if there is no matching subnet of the > ] same adress family then the adjacency does not come up. > ] i.e. IPv4-only and IPv6-only routers won't form an adjacency; > ] > ] /hannes > ] _______________________________________________ > ] 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 > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jan 29 15:49:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29503 for ; Wed, 29 Jan 2003 15:49:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TL5UJ22402; Wed, 29 Jan 2003 16:05:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TKxAJ22132 for ; Wed, 29 Jan 2003 15:59:10 -0500 Received: from nomad.tcb.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29121; Wed, 29 Jan 2003 15:37:02 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id 309D055F62; Wed, 29 Jan 2003 13:40:34 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 2FFD33E83; Wed, 29 Jan 2003 13:40:34 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mailing List , idr@merit.edu, isis-wg@ietf.org, routing-discussion@ietf.org From: Danny McPherson Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20030129204034.309D055F62@nomad.tcb.net> Subject: [Isis-wg] GR/NSF Terminology 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Jan 2003 13:40:29 -0700 [Folks, notice the cross-post... Perhaps routing-discussion@ietf.org should be the only one to receive replies, please try to respect this]. I think it'd be a good thing for all of the GR/NSF protocol extensions to employ a common set of terminology, instead of each using your own. I believe the OSPF *WG* document currently does the best job with defining terms, etc.., although I'm not sure it's sufficient or accommodates everything. I'd be willing to work on a "generic document" if need be, or would be happy if the current protocol-specific documents (i.e., BGP, IS-IS, OSPF, LDP, RSVP (dead?), VPN stuff, other?) would make some attempt to use the same terms. Any comments? -danny > This is the start of a Working Group last call for > draft-ietf-ospf-hitless-restart-05.txt, OSPF Hitless Restart. > All comments must be sent to the OSPF list by Friday, > February 8th, 2003. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-05.txt > > My previous list posting on this WG last call was lost or > filtering. My apologies if this is a duplicate. > > Thanks, > Acee & Rohit > -- > Acee _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jan 30 01:10:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09836 for ; Thu, 30 Jan 2003 01:10:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U4V6J19031; Wed, 29 Jan 2003 23:31:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U4TaJ18949 for ; Wed, 29 Jan 2003 23:29:36 -0500 Received: from titanium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07771 for ; Wed, 29 Jan 2003 23:07:20 -0500 (EST) Received: from 0 ([127.0.0.1] helo=titanium.ekay.org) by titanium with esmtp (Exim 3.35 #1 (Debian)) id 18e64D-0007vL-00; Wed, 29 Jan 2003 20:12:45 -0800 Message-ID: <87of5zs2bn.wl@titanium.ekay.org> From: Noguchi Kay To: "Jonnala, Nagi" Cc: Naiming Shen , Hannes Gredler , "'chopps@allegronetworks.com'" , isis-wg@ietf.org Subject: Re: [Isis-wg] RE:draft-ietf-isis-ipv6-05.txt In-Reply-To: <873cnbu5fs.wl@titanium.ekay.org> References: <20030121193437.70800FD56D@prattle.redback.com> <873cnbu5fs.wl@titanium.ekay.org> X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Jan 2003 20:12:44 -0800 Hi Nagi and all, Sorry for the typo. Correct URL is as below. http://ietf.org/internet-drafts/draft-noguchi-isis-protocol-topology-00.txt > http://www.ietf.org/internet-drafts/draft-noguchi-isis-protocol-topology.txt Thank you, kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jan 30 01:21:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10114 for ; Thu, 30 Jan 2003 01:21:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TMvhJ30832; Wed, 29 Jan 2003 17:57:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TMt6J30755 for ; Wed, 29 Jan 2003 17:55:06 -0500 Received: from xmxpita.excite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02409 for ; Wed, 29 Jan 2003 17:32:57 -0500 (EST) Received: by xmxpita.excite.com (Postfix, from userid 110) id B04ACB6FF; Wed, 29 Jan 2003 17:36:23 -0500 (EST) To: jlearman@cisco.com, sarav_k@spymac.com Subject: Re: [Isis-wg] advertising P2P neighbors address in LSPs and IPv6 Received: from [63.104.212.252] by xprdmailfe20.nwk.excite.com via HTTP; Wed, 29 Jan 2003 17:36:23 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 Reply-To: dgoodspe@excite.com From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: sarav_k@spymac.com, isis-wg@ietf.org, hannes@juniper.net, jparker@axiowave.com Message-Id: <20030129223623.B04ACB6FF@xmxpita.excite.com> 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Jan 2003 17:36:23 -0500 (EST) Content-Transfer-Encoding: 7bit I can think of one case where one "could" want to install the /32 routes from the other end of the interface in our own LSP. This case is where you want all traffic directed to that interface to ingress over the interface. In OSPF, this is "Option 1" as discussed in RFC2328 for point-to-point link representation in a Router LSA. Take the case of routers A, B, and C, connected in a triangular configuration. Typically traffic from C to B would flow over the direct link between the two boxes. In the case of /32's advertised by the remote router, traffic to the IP address of the A-B interface on router B would not flow directly from C to B, but would rather flow on the shortest path to A, then ingress on the A-B link to B. At least, I think that's why someone would want to do this....-don --- On Wed 01/29, Jeff Learman < jlearman@cisco.com > wrote: From: Jeff Learman [mailto: jlearman@cisco.com] To: sarav_k@spymac.com Cc: sarav_k@spymac.com, isis-wg@ietf.org, hannes@juniper.net, jparker@axiowave.com Date: Wed, 29 Jan 2003 13:18:51 -0500 Subject: Re: [Isis-wg] advertising P2P neighbors address in LSPs and IPv6 I'm not sure I understand what's being said here. 1195 defines what 128 TLVs can contain and what it means, but it does not state that a router must include IP addresses of IS neighbors. Since this information is redundant, it makes sense that it isn't required. Why would this be an interoperability issue? What might a router legally do that would depend on whether another router in the area included the redundant information or not? There's no harm in documenting it, but I don't see how it would be an interoperability issue. This is more of a conformance issue -- and I don't see anyone clamoring for conformance testing ;) Regards, Jeff At 12:47 AM 1/29/2003, Saravana Kumar wrote: >sorry about the last empty post.. > >Well, if its not mandatory to advertise the neighbors IP address in the LSPs, >then perhaps this infomation should be added to the ip-interoperability draft, >for future references. > >Thanks, >Sarav > >On Tue, 28 Jan 2003 12:29 , Hannes Gredler sent: > >>On Tue, Jan 28, 2003 at 03:46:26AM -0700, Saravana Kumar wrote: >>| Hi, >>| >>| Once an adjacency is extablished over a P2P link, we advertise the neighbors >IP >>| address in our LSP's as internal reachability info. Is it mandatory and if >so, is >>| there any specific reason for doing so ? >> >>its not mandatory, the major implementations do not advertise it >>and i would be curious if it was somebody with an OSPF background >>who did implement this ? >> >>/hannes >> >>| Because currently in IPv6 it is not possible to advertise the P2P's neighbors >>| address in the LSP's, since the neighbor sends us only the link-local >addresses >>| for the circuit in its hello PDU's. >> >> >>_______________________________________________ >>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 _______________________________________________ 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 Thu Jan 30 02:17:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21195 for ; Thu, 30 Jan 2003 02:17:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U7akJ08889; Thu, 30 Jan 2003 02:36:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U7YTJ08825 for ; Thu, 30 Jan 2003 02:34:29 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21095 for ; Thu, 30 Jan 2003 02:12:09 -0500 (EST) Received: from alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id h0U7FTq11843; Thu, 30 Jan 2003 08:15:29 +0100 (MET) Message-ID: <3E38D10F.E1E7AF1D@alcatel.be> From: Koen Vermeulen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Noguchi Kay , Isis-wg Subject: Re: [Isis-wg] RE:draft-ietf-isis-ipv6-05.txt References: <873cnbu5fs.wl@titanium.ekay.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Jan 2003 08:15:28 +0100 Content-Transfer-Encoding: 7bit Hello Noguchi, I clicked on the link you specified, but it seems this one isn't correct (anymore). Is there another way I can get this draft? Thanks, Koen Noguchi Kay wrote: > Hi Naiming and all, > > I wrote a draft which tackles this problem. > > http://www.ietf.org/internet-drafts/draft-noguchi-isis-protocol-topology.txt > > This draft introduces "Protocols Supported Sub-TLV" in Extended IS Reachability > TLV to keep the neighboring router's NLPID information and create protocol > specific SPF tree for each network layer protocol using that information. > > In this way, IPv4 router, IPv6 router and IPv4/IPv6 dual router can co-exist > in a single routing domain. > > Any comments? > > Thank you, > > kay > > At Tue, 21 Jan 2003 11:34:37 -0800, > Naiming Shen wrote: > > > > > > there is always a problem of DIS election on the LAN when multiple > > address families involved. or the same address family but multiple > > topologies exist such as in M-ISIS case. > > > > i would think it's much simpler to ALWAYS establish IS adjacency > > with neighbors regardless of their common NLPIDs. this way, we > > guarantee that there will be a single DIS elected on the LAN for > > isis. but locally, label each adjacency to be "usable" or "non-usable". > > a router can only forward traffic to a "usable" adjacency. an > > adjacency is "usable" if the neighbor has at least one common NLPID > > (or topology id). we install the IS neighbor TLV in the LSP only if > > there exist at least one "usable" adjacency on the LAN. the psedo-node > > lsp should contain all the adacencies, "usable" and "non-usable". > > > > thanks. > > > > ] On Thu, Jan 16, 2003 at 07:29:34AM -0500, Jonnala, Nagi wrote: > > ] | Chris, > > ] | > > ] | According to the draft, adjacency formation between IPv4-only > > ] | and IPv6-only routers is not clear. > > ] | > > ] | Do they form adjacency at all? If they don't form > > ] | we might need to specify it in Section.5 - IPV6 NLPID. > > ] > > ] what we have seen so far in the field is: > > ] if there is no matching subnet of the > > ] same adress family then the adjacency does not come up. > > ] i.e. IPv4-only and IPv6-only routers won't form an adjacency; > > ] > > ] /hannes > > ] _______________________________________________ > > ] 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 > > > _______________________________________________ > 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 Thu Jan 30 06:56:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24814 for ; Thu, 30 Jan 2003 06:56:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UCFdJ26246; Thu, 30 Jan 2003 07:15:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UCCkJ26103 for ; Thu, 30 Jan 2003 07:12:46 -0500 Received: from fsnt.future.futsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24718 for ; Thu, 30 Jan 2003 06:50:18 -0500 (EST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 30 Jan 2003 17:28:48 +0530 Received: from selvarajr (selvarajr.future.futsoft.com [10.6.4.12]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h0UBoJ5g012782; Thu, 30 Jan 2003 17:20:19 +0530 Reply-To: From: "SelvarajR" To: "'Manral, Vishwas'" , , Subject: RE: [Isis-wg] advertising P2P neighbors address in LSPs and IPv6 Message-Id: <001101c2c856$279ae340$0c04060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Jan 2003 17:23:06 +0530 Content-Transfer-Encoding: 7bit Hi, I've also observed some implementations advertising P2P Neighbors IP address in their LSP. Also, if the neighbors P2P link goes down the same implementation updates the IP table that the network is reachable via the P2P link, that is currently Down. The route info stays their till the adjacency comes Down !! Now the route is updated as ISIS route. Before this updation it was as directly connected route. Ofcourse, it might be a bug with that implementation. But I wonder how does it is useful to advertise P2P neighbors IP address. Does it is not wrong in the scope of ISIS ? Selva. | -----Original Message----- | From: isis-wg-admin@ietf.org | [mailto:isis-wg-admin@ietf.org]On Behalf Of | Manral, Vishwas | Sent: Tuesday, 28 January 2003 4:43 PM | To: 'sarav_k@spymac.com'; isis-wg@ietf.org | Subject: RE: [Isis-wg] advertising P2P neighbors address in LSPs and | IPv6 | | | Hi Sarav, | | If you advertize reachability information in your LSP, it is | used by the SPF | process in the routers. If you do not advertize it(delay | advertizing it) the | other routers will not take the path to the destination thru | you, but take | an alternate path(if one exists). | | It would not create any routing loops. | | Thanks, | Vishwas | | -----Original Message----- | From: Saravana Kumar [mailto:sarav_k@spymac.com] | Sent: Tuesday, January 28, 2003 4:16 PM | To: isis-wg@ietf.org | Subject: [Isis-wg] advertising P2P neighbors address in LSPs and IPv6 | | | Hi, | | Once an adjacency is extablished over a P2P link, we | advertise the neighbors | IP | address in our LSP's as internal reachability info. Is it | mandatory and if | so, is | there any specific reason for doing so ? | | Because currently in IPv6 it is not possible to advertise the P2P's | neighbors | address in the LSP's, since the neighbor sends us only the link-local | addresses | for the circuit in its hello PDU's. | | Thanks, | sarav | | _______________________________________________ | 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 | *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jan 30 14:16:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07728 for ; Thu, 30 Jan 2003 14:16:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UJFMJ23000; Thu, 30 Jan 2003 14:15:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UJBJJ22869 for ; Thu, 30 Jan 2003 14:11:19 -0500 Received: from titanium.ekay.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07365 for ; Thu, 30 Jan 2003 14:07:40 -0500 (EST) Received: from 0 ([127.0.0.1] helo=titanium.ekay.org) by titanium.ekay.org with esmtp (Exim 3.35 #1 (Debian)) id 18eK5n-0000CO-00 for ; Thu, 30 Jan 2003 11:11:19 -0800 Message-ID: <8765s68nc9.wl@titanium.ekay.org> From: Noguchi Kay To: isis-wg@ietf.org X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Subject: [Isis-wg] 56th IETF 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: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Jan 2003 11:11:18 -0800 Hi all, This is Kay. 56th IETF agenda items are listed in the IETF web site but thers is no slot for IS-IS working group. http://ietf.org/meetings/agenda_56.html And there are lots of internet-drafts out there so let's have a session at 56th IETF. What do you think, all, especially draft authers? At least for me, I want to have a slot for my new draft, Protocol Topology Support for IS-IS. http://ietf.org/internet-drafts/draft-noguchi-isis-protocol-topology-00.txt Thank you, kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg