Re: [Isis-wg] Addressing Routers in IS-IS Packets

From isis-wg-bounces@ietf.org Thu Nov 4 09:42:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25600 for ; Thu, 4 Nov 2004 09:42:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPieW-0004n1-Nx; Thu, 04 Nov 2004 09:31:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPfsY-0004n9-Dn for isis-wg@megatron.ietf.org; Thu, 04 Nov 2004 06:34:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10679 for ; Thu, 4 Nov 2004 06:34:07 -0500 (EST) Received: from [212.25.127.226] (helo=wombat.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPg80-0001N6-0P for isis-wg@ietf.org; Thu, 04 Nov 2004 06:50:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Nov 2004 13:31:18 +0200 Message-ID: <6FAB860EC6AE3C4EB327204DEC33A528E54181@wombat.seabridge.co.il> Thread-Topic: Addressing Routers in IS-IS Packets Thread-Index: AcTCP1izZ6zB1/ymTCecI1JeTn6/Qg== From: "Nurit Sprecher" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 X-Mailman-Approved-At: Thu, 04 Nov 2004 09:31:51 -0500 Cc: Nurit Sprecher Subject: [Isis-wg] Addressing Routers in IS-IS Packets X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0318853441==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============0318853441== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C261.CD5359A7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C261.CD5359A7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a question on the OSI-style addresses of IP routers, and I'll appreciate a response. =20 RFC 1195 suggests two ways in which NSAP addresses may be obtained for use with the IS-IS protocol. When using the algorithmically generating a valid OSI style address from existing IP address, RFC 1195 suggests that the System ID is based on the System's IP address. The hex value "02 00" is used prepended to the IP address of the router. =20 However I could see that Cisco claims that most ISPs do it in another way. Each of the four bytes of the IP address is prepended by zeros if necessary. Then, the resulting 12 decimal digits are re-divided into three groups of 4 decimal digits, each group occupying 2 bytes. =20 =20 Since the mapping needs to be defined coherently network wide, I would like to know which of the methods is the common and used one, and maybe other methods are in use. =20 Thanks in advance, Nurit. =20 =20 =20 =20 ------_=_NextPart_001_01C4C261.CD5359A7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I have a question on the OSI-style addresses of IP = routers, and I'll appreciate a response.

RFC 1195 suggests two ways =
in which NSAP addresses may be obtained for use with the IS-IS =
protocol.

When using the =
algorithmically generating a valid OSI style address from existing IP =
address, RFC 1195 suggests that the System ID is based on the =
System’s IP address. The hex value "02 00" is used =
prepended to the IP address of the =
router.

However I could see that =
Cisco claims that most ISPs do it in another way. Each of the four bytes =
of the IP address is prepended by zeros if necessary. Then, the =
resulting 12 decimal digits are re-divided into three groups of 4 =
decimal digits, each group occupying 2 bytes.  =

Since the mapping needs to =
be defined coherently network wide, I would like to know which of the =
methods is the common and used one, and maybe other methods are in =
use.

Thanks in =
advance,

Nurit.

------_=_NextPart_001_01C4C261.CD5359A7-- --===============0318853441== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============0318853441==-- From isis-wg-bounces@ietf.org Thu Nov 4 12:28:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13651 for ; Thu, 4 Nov 2004 12:28:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkzX-0005BN-Qe; Thu, 04 Nov 2004 12:01:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkhR-00023H-DK for isis-wg@megatron.ietf.org; Thu, 04 Nov 2004 11:43:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08249 for ; Thu, 4 Nov 2004 11:42:58 -0500 (EST) Received: from [64.47.51.130] (helo=exchange.timetra.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPkwm-0000K0-Pe for isis-wg@ietf.org; Thu, 04 Nov 2004 11:59:06 -0500 Received: from vpndg ([128.251.10.1] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Nov 2004 08:42:11 -0800 From: "Don Goodspeed" To: "Nurit Sprecher" , Subject: RE: [Isis-wg] Addressing Routers in IS-IS Packets Date: Thu, 4 Nov 2004 08:41:54 -0800 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <6FAB860EC6AE3C4EB327204DEC33A528E54181@wombat.seabridge.co.il> X-OriginalArrivalTime: 04 Nov 2004 16:42:11.0405 (UTC) FILETIME=[3B493FD0:01C4C28D] X-Spam-Score: 0.2 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Don.Goodspeed@alcatel.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0485228545==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============0485228545== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01C4C24A.22D88480" This is a multi-part message in MIME format. ------=_NextPart_000_0085_01C4C24A.22D88480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nurit, The latter implementation is the one I've seen most frequently from various vendor's implementations. -don -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Nurit Sprecher Sent: Thursday, November 04, 2004 3:31 AM To: isis-wg@ietf.org Cc: Nurit Sprecher Subject: [Isis-wg] Addressing Routers in IS-IS Packets Hi, I have a question on the OSI-style addresses of IP routers, and I'll appreciate a response. RFC 1195 suggests two ways in which NSAP addresses may be obtained for use with the IS-IS protocol.When using the algorithmically generating a valid OSI style address from existing IP address, RFC 1195 suggests that the System ID is based on the System's IP address. The hex value "02 00" is used prepended to the IP address of the router. However I could see that Cisco claims that most ISPs do it in another way. Each of the four bytes of the IP address is prepended by zeros if necessary. Then, the resulting 12 decimal digits are re-divided into three groups of 4 decimal digits, each group occupying 2 bytes. Since the mapping needs to be defined coherently network wide, I would like to know which of the methods is the common and used one, and maybe other methods are in use. Thanks in advance,Nurit. ------=_NextPart_000_0085_01C4C24A.22D88480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nurit,

The=20 latter implementation is the one I've seen most frequently from various=20 vendor's

implementations.

-don

-----Original Message-----
From: = isis-wg-bounces@ietf.org=20 [mailto:isis-wg-bounces@ietf.org]On Behalf Of Nurit=20 Sprecher
Sent: Thursday, November 04, 2004 3:31 = AM
To:=20 isis-wg@ietf.org
Cc: Nurit Sprecher
Subject: = [Isis-wg]=20 Addressing Routers in IS-IS Packets

Hi,

I have a question on the = OSI-style=20 addresses of IP routers, and I'll appreciate a=20 response.

RFC 1195 =
suggests two ways in which NSAP addresses may be obtained for use with =
the IS-IS protocol.

When using the algorithmically generating a valid OSI style =
address from existing IP address, RFC 1195 suggests that the System ID =
is based on the System’s IP address. The hex value "02 00" is used =
prepended to the IP address of the =
router.

However I =
could see that Cisco claims that most ISPs do it in another way. Each of =
the four bytes of the IP address is prepended by zeros if necessary. =
Then, the resulting 12 decimal digits are re-divided into three groups =
of 4 decimal digits, each group occupying 2 bytes.  =

Since the =
mapping needs to be defined coherently network wide, I would like to =
know which of the methods is the common and used one, and maybe other =
methods are in use.

Thanks in =
advance,

Nurit.

------=_NextPart_000_0085_01C4C24A.22D88480-- --===============0485228545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============0485228545==-- From isis-wg-bounces@ietf.org Fri Nov 5 09:27:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15752 for ; Fri, 5 Nov 2004 09:27:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ4uX-0005jf-8D; Fri, 05 Nov 2004 09:17:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlSF-0005sa-9J for isis-wg@megatron.ietf.org; Thu, 04 Nov 2004 12:31:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14156 for ; Thu, 4 Nov 2004 12:31:20 -0500 (EST) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlhe-0001ro-5D for isis-wg@ietf.org; Thu, 04 Nov 2004 12:47:28 -0500 Received: from 140.233.20.181 [140.233.20.181] by anthrax.middlebury.edu with XWall v3.30 ; Thu, 4 Nov 2004 12:30:33 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 04 Nov 2004 12:30:17 -0500 Subject: Re: [Isis-wg] Addressing Routers in IS-IS Packets From: Jeff Parker To: Nurit Sprecher , Message-ID: In-Reply-To: <6FAB860EC6AE3C4EB327204DEC33A528E54181@wombat.seabridge.co.il> Mime-version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab X-Mailman-Approved-At: Fri, 05 Nov 2004 09:17:51 -0500 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1230957488==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1230957488== Content-type: multipart/alternative; boundary="B_3182416232_181335" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3182416232_181335 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Nurit - The short answer is that it doesn=B9t matter. If these addresses, IS-IS System IDs, were visible outside an ISP, it would matter. But as long as the values are unique within the domain, whic= h is typically interior to an ISP, it doesn=B9t matter how they are allocated. - jeff parker On 11/4/04 6:31 AM, "Nurit Sprecher" wrote: > Hi, > =20 > I have a question on the OSI-style addresses of IP routers, and I'll > appreciate a response. > =20 > RFC 1195 suggests two ways in which NSAP addresses may be obtained for us= e > with the IS-IS protocol. > When using the algorithmically generating a valid OSI style address from > existing IP address, RFC 1195 suggests that the System ID is based on the > System=B9s IP address. The hex value "02 00" is used prepended to the IP ad= dress > of the router. > =20 > However I could see that Cisco claims that most ISPs do it in another way= . > Each of the four bytes of the IP address is prepended by zeros if necessa= ry. > Then, the resulting 12 decimal digits are re-divided into three groups of= 4 > decimal digits, each group occupying 2 bytes. > =20 > Since the mapping needs to be defined coherently network wide, I would li= ke to > know which of the methods is the common and used one, and maybe other met= hods > are in use. > =20 > Thanks in advance, > Nurit. > =20 > =20 > =20 > =20 >=20 >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg --B_3182416232_181335 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Isis-wg] Addressing Routers in IS-IS Packets Nurit= -
The short answer is that it doesn’t matter. &= nbsp;
If these addresses, IS-IS System IDs, were visible = outside an ISP, it would matter. But as long as the values are unique = within the domain, which is typically interior to an ISP, it doesn’t m= atter how they are allocated.

- jeff parker

On 11/4/04 6:31 AM, "Nurit Sprecher" <nurit.sprecher@Seabridge= Networks.com> wrote:

Hi,

I have a question on the OSI-style addresses of IP routers, and I'll apprec= iate a response.

RFC 1195 suggests two ways in which NSAP addresses may be obtained for use = with the IS-IS protocol.
When using the algorithmically generating a valid OSI style address from ex= isting IP address, RFC 1195 suggests that the System ID is based on the Syst= em’s IP address. The hex value "02 00" is used prepended to = the IP address of the router.

However I could see that Cisco claims that most ISPs do it in another way. = Each of the four bytes of the IP address is prepended by zeros if necessary.= Then, the resulting 12 decimal digits are re-divided into three groups of 4= decimal digits, each group occupying 2 bytes.

Since the mapping needs to be defined coherently network wide, I would like= to know which of the methods is the common and used one, and maybe other me= thods are in use.

Thanks in advance,
Nurit.

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

--B_3182416232_181335-- --===============1230957488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1230957488==-- From isis-wg-bounces@ietf.org Tue Nov 9 09:11:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29593 for ; Tue, 9 Nov 2004 09:11:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWcN-0002Ne-P9; Tue, 09 Nov 2004 09:05:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CREQB-0004tf-95 for isis-wg@megatron.ietf.org; Mon, 08 Nov 2004 13:39:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10936 for ; Mon, 8 Nov 2004 13:39:15 -0500 (EST) Received: from [212.25.127.226] (helo=wombat.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CREQZ-0001An-5a for isis-wg@ietf.org; Mon, 08 Nov 2004 13:39:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Isis-wg] Addressing Routers in IS-IS Packets Date: Mon, 8 Nov 2004 20:36:21 +0200 Message-ID: <6FAB860EC6AE3C4EB327204DEC33A528E54196@wombat.seabridge.co.il> Thread-Topic: [Isis-wg] Addressing Routers in IS-IS Packets Thread-Index: AcTCk7WM3xZSNRmkQQuCH50H3NP8uQDLSuqQ From: "Nurit Sprecher" To: "Jeff Parker" X-Spam-Score: 0.6 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b X-Mailman-Approved-At: Tue, 09 Nov 2004 09:05:05 -0500 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1986629947==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1986629947== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C5C1.D7A1DBB0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C5C1.D7A1DBB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Jeff for your response. Your answer is correct as long as the OSI style address is administratively configured. In such a case it is the ISP's responsibility to guarantee the uniqueness. But if iit is required from the network element to map between IP address and the OSI style address it is matter. This should be done in a consistent way by all network elements. =20 Nurit. =20 _____ =20 From: Jeff Parker [mailto:jparker@world.std.com]=20 Sent: Thursday, November 04, 2004 7:30 PM To: Nurit Sprecher; isis-wg@ietf.org Subject: Re: [Isis-wg] Addressing Routers in IS-IS Packets =20 Nurit - The short answer is that it doesn't matter. =20 If these addresses, IS-IS System IDs, were visible outside an ISP, it would matter. But as long as the values are unique within the domain, which is typically interior to an ISP, it doesn't matter how they are allocated. =20 - jeff parker On 11/4/04 6:31 AM, "Nurit Sprecher" wrote: Hi, =20 I have a question on the OSI-style addresses of IP routers, and I'll appreciate a response. =20 RFC 1195 suggests two ways in which NSAP addresses may be obtained for use with the IS-IS protocol. When using the algorithmically generating a valid OSI style address from existing IP address, RFC 1195 suggests that the System ID is based on the System's IP address. The hex value "02 00" is used prepended to the IP address of the router. =20 However I could see that Cisco claims that most ISPs do it in another way. Each of the four bytes of the IP address is prepended by zeros if necessary. Then, the resulting 12 decimal digits are re-divided into three groups of 4 decimal digits, each group occupying 2 bytes. =20 =20 Since the mapping needs to be defined coherently network wide, I would like to know which of the methods is the common and used one, and maybe other methods are in use. =20 Thanks in advance, Nurit. =20 =20 =20 =20 _____ =20 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg =20 ------_=_NextPart_001_01C4C5C1.D7A1DBB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Isis-wg] Addressing Routers in IS-IS Packets

Thanks Jeff for your = response.

Your answer is correct as long as = the OSI style address is administratively configured. In such a case it is the = ISP's responsibility to guarantee the uniqueness. But if iit is required from = the network element to map between IP address and the OSI style address it = is matter. This should be done in a consistent way by all network = elements.

Nurit.

From: Jeff = Parker [mailto:jparker@world.std.com]
Sent: Thursday, November = 04, 2004 7:30 PM
To: Nurit Sprecher; isis-wg@ietf.org
Subject: Re: [Isis-wg] = Addressing Routers in IS-IS Packets

Nurit -
The short answer is that it doesn’t = matter.
If these addresses, IS-IS System IDs, were = visible outside an ISP, it would matter. But as long as the values are = unique within the domain, which is typically interior to an ISP, it = doesn’t matter how they are allocated.

- jeff parker

On 11/4/04 6:31 AM, "Nurit = Sprecher" <nurit.sprecher@SeabridgeNetworks.com> = wrote:

Hi,

I have a question on the OSI-style addresses of IP routers, and I'll = appreciate a response.

RFC 1195 suggests two ways in which NSAP addresses may be obtained for = use with the IS-IS protocol.
When using the algorithmically generating a valid OSI style address from existing IP address, RFC 1195 suggests that the System ID is based on = the System’s IP address. The hex value "02 00" is used prepended to the IP = address of the router.

However I could see that Cisco claims that most ISPs do it in another = way. Each of the four bytes of the IP address is prepended by zeros if necessary. = Then, the resulting 12 decimal digits are re-divided into three groups of 4 = decimal digits, each group occupying 2 bytes.

Since the mapping needs to be defined coherently network wide, I would = like to know which of the methods is the common and used one, and maybe other = methods are in use.

Thanks in advance,
Nurit.

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

------_=_NextPart_001_01C4C5C1.D7A1DBB0-- --===============1986629947== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1986629947==-- From isis-wg-bounces@ietf.org Tue Nov 9 11:57:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19764 for ; Tue, 9 Nov 2004 11:57:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZDu-00066Z-UC; Tue, 09 Nov 2004 11:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZ9W-0004cZ-Vk for isis-wg@megatron.ietf.org; Tue, 09 Nov 2004 11:47:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18543 for ; Tue, 9 Nov 2004 11:47:26 -0500 (EST) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRZAH-0000Gz-F6 for isis-wg@ietf.org; Tue, 09 Nov 2004 11:48:17 -0500 Received: from [192.168.1.3] (c-67-161-68-71.client.comcast.net[67.161.68.71]) by comcast.net (sccrmhc11) with SMTP id <2004110916464301100avb5qe> (Authid: li.tony); Tue, 9 Nov 2004 16:46:47 +0000 In-Reply-To: <6FAB860EC6AE3C4EB327204DEC33A528E54196@wombat.seabridge.co.il> References: <6FAB860EC6AE3C4EB327204DEC33A528E54196@wombat.seabridge.co.il> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Tony Li Subject: Re: [Isis-wg] Addressing Routers in IS-IS Packets Date: Tue, 9 Nov 2004 08:46:41 -0800 To: "Nurit Sprecher" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: isis-wg@ietf.org, Jeff Parker X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable There is currently no such global requirement. Thus, this remains a=20 local matter. Tony On Nov 8, 2004, at 10:36 AM, Nurit Sprecher wrote: > Thanks Jeff for your response. > > Your answer is correct as long as the OSI style address is=20 > administratively configured. In such a case it is the ISP's=20 > responsibility to guarantee the uniqueness. But if iit is required=20 > from the network element to map between IP address and the OSI style=20= > address it is matter. This should be done in a consistent way by all=20= > network elements. > > =A0 > > Nurit. > > =A0 > > > From: Jeff Parker [mailto:jparker@world.std.com] > Sent: Thursday, November 04, 2004 7:30 PM > To: Nurit Sprecher; isis-wg@ietf.org > Subject: Re: [Isis-wg] Addressing Routers in IS-IS Packets > > =A0 > > Nurit - > =A0=A0=A0=A0The short answer is that it doesn=92t matter. =A0 > =A0=A0=A0=A0If these addresses, IS-IS System IDs, were visible = outside an=20 > ISP, it would matter. =A0But as long as the values are unique within = the=20 > domain, which is typically interior to an ISP, it doesn=92t matter how=20= > they are allocated. =A0 > > - jeff parker > > > On 11/4/04 6:31 AM, "Nurit Sprecher"=20 > wrote: > > Hi, > =A0 > I have a question on the OSI-style addresses of IP routers, and I'll=20= > appreciate a response. > =A0 > RFC 1195 suggests two ways in which NSAP addresses may be obtained=20 > for use with the IS-IS protocol. > When using the algorithmically generating a valid OSI style address=20= > from existing IP address, RFC 1195 suggests that the System ID is=20 > based on the System=92s IP address. The hex value "02 00" is used=20 > prepended to the IP address of the router. > =A0 > However I could see that Cisco claims that most ISPs do it in another=20= > way. Each of the four bytes of the IP address is prepended by zeros if=20= > necessary. Then, the resulting 12 decimal digits are re-divided into=20= > three groups of 4 decimal digits, each group occupying 2 bytes. =A0 > =A0 > Since the mapping needs to be defined coherently network wide, I=20 > would like to know which of the methods is the common and used one,=20 > and maybe other methods are in use. > =A0 > Thanks in advance, > Nurit. > =A0 > =A0 > =A0 > =A0 > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > > =A0 > _______________________________________________ > 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-bounces@ietf.org Tue Nov 9 12:24:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22123 for ; Tue, 9 Nov 2004 12:24:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZOL-0007du-VO; Tue, 09 Nov 2004 12:02:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZDx-00067y-UE for isis-wg@megatron.ietf.org; Tue, 09 Nov 2004 11:52:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19149 for ; Tue, 9 Nov 2004 11:52:02 -0500 (EST) Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRZEk-0000Rt-3a for isis-wg@ietf.org; Tue, 09 Nov 2004 11:52:54 -0500 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Nov 2004 16:51:16 -0000 Message-ID: <37701240971DD31193970000F6CCB9F7050427B5@duke.datcon.co.uk> From: Jonathan Harrison To: "'jparker@world.std.com'" , "'jeffp@middlebury.edu'" Date: Tue, 9 Nov 2004 16:51:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: isis-wg@ietf.org Subject: [Isis-wg] isisCircLevelIDOctet in the WG MIB X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Jeff, I've got a concern over the usability of the isisCircLevelIDOctet object defined in the isisCircLevelTable. isisCircLevelIDOctet OBJECT-TYPE SYNTAX Integer32(0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "A one byte identifier that can be used in protocol packets to identify a circuit. Values of isisCircLevelIDOctet do not need to be unique. They are only required to differ on LANs where the Intermediate System is the Designated Intermediate System." ::= { isisCircLevelEntry 5 } There are the following issues with this. - The properties of the object are different for point-to-point circuits and for LAN circuits. For a point-to-point circuit, the value 0 is acceptable, and could be used as a sensible default. On the other hand, for a broadcast circuit, the value 0 cannot be used if the IS-IS instance could become DIS on the LAN, and there is no sensible default value (due to the uniqueness requirement). - As a general point, it would be good for all read-create objects in the isisCircLevel table to have MIB defined default values. Currently, the IDOctet is the only non-defaultable value, and since the IDOctet is used in IIH PDUs, a value must be chosen for this object before a circuit can be activated via the MIB. Circuit configuration would be much simpler if it only required the creation of a row in the isisCircuitTable, without the modification of any objects in the isisCircLevel table. - The reason for making the value level specific, was to allow support for the "Maintaining more than 255 circuits in IS-IS" draft (draft-ietf-isis-wg-255adj). However, if this draft is supported, then a unique value for the IDOctet object is chosen by the IS-IS instance when it becomes DIS on a LAN, and so it makes more sense for the MIB object to be read-only. These points suggest that the usability of the MIB would be improved by splitting this object into two separate objects. - The object for point-to-point circuits is read-create, with the default value of zero. Although this object could move to the isisCircTable, it probably makes more sense to leave it in the isisCircLevel table (since it should be kept with isisCircLevelID). - The object for broadcast circuits is read-only, and reflects the value chosen by the IS-IS instance. Since it is level specific, it must remain in the isisCircLevelTable. What do you think? If you agree, I'm happy to suggest some text. Thanks, Jon _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Nov 9 12:31:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22922 for ; Tue, 9 Nov 2004 12:31:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZjI-0004js-R1; Tue, 09 Nov 2004 12:24:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZOi-0007m8-1A for isis-wg@megatron.ietf.org; Tue, 09 Nov 2004 12:03:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20168 for ; Tue, 9 Nov 2004 12:03:09 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRZPS-0000kP-NB for isis-wg@ietf.org; Tue, 09 Nov 2004 12:04:01 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id iA9H2a988436; Tue, 9 Nov 2004 09:02:36 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id iA9H2Ue77023; Tue, 9 Nov 2004 09:02:30 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <6FAB860EC6AE3C4EB327204DEC33A528E54196@wombat.seabridge.co.il> References: <6FAB860EC6AE3C4EB327204DEC33A528E54196@wombat.seabridge.co.il> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <23DE0BC0-3271-11D9-9509-000D93298656@juniper.net> Content-Transfer-Encoding: quoted-printable From: Dave Katz Subject: Re: [Isis-wg] Addressing Routers in IS-IS Packets Date: Tue, 9 Nov 2004 09:02:29 -0800 To: "Nurit Sprecher" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: isis-wg@ietf.org, Jeff Parker X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable It is never "required" of the network element to do the address=20 mapping. If a vendor chooses to provide such a function, it is=20 nonstandard, and of course there is some risk of address collision. In=20= general this would, at best, be silly, as there is so much other=20 configuration information necessary for a router that providing a=20 function so that one less line of configuration is required would not=20 provide significant return. On Nov 8, 2004, at 10:36 AM, Nurit Sprecher wrote: > Thanks Jeff for your response. > > Your answer is correct as long as the OSI style address is=20 > administratively configured. In such a case it is the ISP's=20 > responsibility to guarantee the uniqueness. But if iit is required=20 > from the network element to map between IP address and the OSI style=20= > address it is matter. This should be done in a consistent way by all=20= > network elements. > > =A0 > > Nurit. > > =A0 > > > From: Jeff Parker [mailto:jparker@world.std.com] > Sent: Thursday, November 04, 2004 7:30 PM > To: Nurit Sprecher; isis-wg@ietf.org > Subject: Re: [Isis-wg] Addressing Routers in IS-IS Packets > > =A0 > > Nurit - > =A0=A0=A0=A0The short answer is that it doesn=92t matter. =A0 > =A0=A0=A0=A0If these addresses, IS-IS System IDs, were visible = outside an=20 > ISP, it would matter. =A0But as long as the values are unique within = the=20 > domain, which is typically interior to an ISP, it doesn=92t matter how=20= > they are allocated. =A0 > > - jeff parker > > > On 11/4/04 6:31 AM, "Nurit Sprecher"=20 > wrote: > > Hi, > =A0 > I have a question on the OSI-style addresses of IP routers, and I'll=20= > appreciate a response. > =A0 > RFC 1195 suggests two ways in which NSAP addresses may be obtained=20 > for use with the IS-IS protocol. > When using the algorithmically generating a valid OSI style address=20= > from existing IP address, RFC 1195 suggests that the System ID is=20 > based on the System=92s IP address. The hex value "02 00" is used=20 > prepended to the IP address of the router. > =A0 > However I could see that Cisco claims that most ISPs do it in another=20= > way. Each of the four bytes of the IP address is prepended by zeros if=20= > necessary. Then, the resulting 12 decimal digits are re-divided into=20= > three groups of 4 decimal digits, each group occupying 2 bytes. =A0 > =A0 > Since the mapping needs to be defined coherently network wide, I=20 > would like to know which of the methods is the common and used one,=20 > and maybe other methods are in use. > =A0 > Thanks in advance, > Nurit. > =A0 > =A0 > =A0 > =A0 > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > > =A0 > _______________________________________________ > 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-bounces@ietf.org Tue Nov 9 12:37:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23424 for ; Tue, 9 Nov 2004 12:37:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZtx-0007EK-P1; Tue, 09 Nov 2004 12:35:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZnv-0005d9-Ly for isis-wg@megatron.ietf.org; Tue, 09 Nov 2004 12:29:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22723 for ; Tue, 9 Nov 2004 12:29:12 -0500 (EST) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRZoh-0001SJ-Ux for isis-wg@ietf.org; Tue, 09 Nov 2004 12:30:04 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.30 ; Tue, 9 Nov 2004 12:28:42 -0500 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Nov 2004 12:28:42 -0500 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.127 140.233.20.127 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 09 Nov 2004 12:28:40 -0500 From: "Parker, Jeff" To: Jonathan Harrison , Jeff Parker Message-ID: In-Reply-To: <37701240971DD31193970000F6CCB9F7050427B5@duke.datcon.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Nov 2004 17:28:42.0197 (UTC) FILETIME=[8ECB1050:01C4C681] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org Subject: [Isis-wg] Re: isisCircLevelIDOctet in the WG MIB X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Jonathan - I see your point, but wonder if the importance of a default value outweighs the confusion of having two names for this byte. - jeff parker On 11/9/04 11:51 AM, "Jonathan Harrison" wrote: > Jeff, > > I've got a concern over the usability of the isisCircLevelIDOctet object > defined in the isisCircLevelTable. > > isisCircLevelIDOctet OBJECT-TYPE > SYNTAX Integer32(0..255) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "A one byte identifier that can be used in protocol packets > to identify a circuit. Values of isisCircLevelIDOctet > do not need to be unique. They are only required to > differ on LANs where the Intermediate System is the > Designated Intermediate System." > ::= { isisCircLevelEntry 5 } > > There are the following issues with this. > > - The properties of the object are different for point-to-point circuits > and for LAN circuits. For a point-to-point circuit, the value 0 is > acceptable, and could be used as a sensible default. On the other hand, for > a broadcast circuit, the value 0 cannot be used if the IS-IS instance could > become DIS on the LAN, and there is no sensible default value (due to the > uniqueness requirement). > > - As a general point, it would be good for all read-create objects in the > isisCircLevel table to have MIB defined default values. Currently, the > IDOctet is the only non-defaultable value, and since the IDOctet is used in > IIH PDUs, a value must be chosen for this object before a circuit can be > activated via the MIB. Circuit configuration would be much simpler if it > only required the creation of a row in the isisCircuitTable, without the > modification of any objects in the isisCircLevel table. > > - The reason for making the value level specific, was to allow support for > the "Maintaining more than 255 circuits in IS-IS" draft > (draft-ietf-isis-wg-255adj). However, if this draft is supported, then a > unique value for the IDOctet object is chosen by the IS-IS instance when it > becomes DIS on a LAN, and so it makes more sense for the MIB object to be > read-only. > > These points suggest that the usability of the MIB would be improved by > splitting this object into two separate objects. > > - The object for point-to-point circuits is read-create, with the default > value of zero. Although this object could move to the isisCircTable, it > probably makes more sense to leave it in the isisCircLevel table (since it > should be kept with isisCircLevelID). > > - The object for broadcast circuits is read-only, and reflects the value > chosen by the IS-IS instance. Since it is level specific, it must remain in > the isisCircLevelTable. > > What do you think? If you agree, I'm happy to suggest some text. > > Thanks, > Jon _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Nov 10 16:13:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03962 for ; Wed, 10 Nov 2004 16:13:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzVv-0000Eb-De; Wed, 10 Nov 2004 15:56:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzI6-0005pO-Uu for isis-wg@megatron.ietf.org; Wed, 10 Nov 2004 15:42:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26766 for ; Wed, 10 Nov 2004 15:42:04 -0500 (EST) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzIy-0005EU-Hk for isis-wg@ietf.org; Wed, 10 Nov 2004 15:43:10 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 3B5D43DCC8C for ; Wed, 10 Nov 2004 12:41:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ISIS-WG (E-mail) From: Christian Hopps Date: Wed, 10 Nov 2004 15:41:17 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Subject: [Isis-wg] isis wg meeting canceled. X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Given that no agenda items were submitted for the meeting have canceled the meeting for this IETF. Chris. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Nov 10 16:18:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04684 for ; Wed, 10 Nov 2004 16:18:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzZ8-0002s3-Kf; Wed, 10 Nov 2004 15:59:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzO5-0001cD-BM for isis-wg@megatron.ietf.org; Wed, 10 Nov 2004 15:48:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28827 for ; Wed, 10 Nov 2004 15:48:15 -0500 (EST) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzP6-0005uB-SJ for isis-wg@ietf.org; Wed, 10 Nov 2004 15:49:21 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 261F13DCC8C for ; Wed, 10 Nov 2004 12:47:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ISIS-WG (E-mail) From: Christian Hopps Date: Wed, 10 Nov 2004 15:47:37 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Proposed WG documents. X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit The following documents raised no objection for becoming WG documents at the previous IETF. 1) draft-harrison-isis-ipv6-te-00.txt 2) draft-vasseur-isis-caps-00.txt 3) draft-vasseur-isis-te-caps-00.txt Lacking objection in the next 30 days, we will move these to working group documents. Chris. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Nov 10 16:21:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05346 for ; Wed, 10 Nov 2004 16:21:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzmX-0001Qa-15; Wed, 10 Nov 2004 16:13:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzW6-0000OQ-UE for isis-wg@megatron.ietf.org; Wed, 10 Nov 2004 15:56:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01286 for ; Wed, 10 Nov 2004 15:56:32 -0500 (EST) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzX7-0006iT-DD for isis-wg@ietf.org; Wed, 10 Nov 2004 15:57:38 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id D9C663DCC8C for ; Wed, 10 Nov 2004 12:55:57 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ISIS-WG (E-mail) From: Christian Hopps Date: Wed, 10 Nov 2004 15:55:54 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] draft-ietf-isis-wg-multi-topology-07.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit A concern was raised at the previous IETF that the current MT draft may not describe deployed implementations. I have received some verification that this is *not* the case, and the only change of substance was with some wording and a clarification of the use of the overload bit. I would ask people with implementations to please verify that this is indeed the case. Lacking any issues this draft will be IETF last called. Chris. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Nov 10 17:31:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12347 for ; Wed, 10 Nov 2004 17:31:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0qU-0001V5-3Z; Wed, 10 Nov 2004 17:21:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0kD-0008HO-Or for isis-wg@megatron.ietf.org; Wed, 10 Nov 2004 17:15:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10983 for ; Wed, 10 Nov 2004 17:15:10 -0500 (EST) Received: from 67.111.75.190.ptr.us.xo.net ([67.111.75.190] helo=BCNW02.bcn-inc.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0lE-0000bf-Sv for isis-wg@ietf.org; Wed, 10 Nov 2004 17:16:18 -0500 Received: from bcn-inc.net ([10.10.20.60]) by BCNW02.bcn-inc.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 10 Nov 2004 14:14:44 -0800 Message-ID: <4192928B.2080703@bcn-inc.net> Date: Wed, 10 Nov 2004 14:13:31 -0800 From: Naiming Shen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Hopps Subject: Re: [Isis-wg] draft-ietf-isis-wg-multi-topology-07.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2004 22:14:44.0968 (UTC) FILETIME=[AF03D680:01C4C772] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: "ISIS-WG \(E-mail\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Chris, I'm not aware of any deployed implementation not conforming to the document. thanks. - Naiming Christian Hopps wrote: > A concern was raised at the previous IETF that the current MT draft may > not describe deployed implementations. I have received some verification > that this is *not* the case, and the only change of substance was with > some wording and a clarification of the use of the overload bit. > > I would ask people with implementations to please verify that this is > indeed the case. Lacking any issues this draft will be IETF last called. > > Chris. > > > _______________________________________________ > 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-bounces@ietf.org Fri Nov 12 09:21:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05295 for ; Fri, 12 Nov 2004 09:21:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScAj-0003Qn-E0; Fri, 12 Nov 2004 09:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSGnt-0006hy-37 for isis-wg@megatron.ietf.org; Thu, 11 Nov 2004 10:24:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21982 for ; Thu, 11 Nov 2004 10:24:03 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSGp3-0004gW-Ps for isis-wg@ietf.org; Thu, 11 Nov 2004 10:25:19 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 11 Nov 2004 07:35:33 -0800 Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iABFNTcp003159; Thu, 11 Nov 2004 07:23:29 -0800 (PST) Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA22404; Thu, 11 Nov 2004 09:23:30 -0600 (CST) Date: Thu, 11 Nov 2004 09:23:29 -0600 From: David Ward To: isis-wg@ietf.org, Christian E Hopps , dward@cisco.com Message-ID: <20041111092329.D20061@cfcentral.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Fri, 12 Nov 2004 09:13:03 -0500 Subject: [Isis-wg] Another doc for WG acceptance X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org All - We left a doc off our list yesterday for consideration for becoming a WG doc. http://www.ietf.org/internet-drafts/draft-vasseur-isis-link-attr-01.txt Unless there is objection, it will be accepted as a WG document in 30 days. DWard and CHopps _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Nov 17 15:05:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06451 for ; Wed, 17 Nov 2004 15:05:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUVpc-0003Ok-Vj; Wed, 17 Nov 2004 14:51:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUVnK-0002QD-KS for isis-wg@megatron.ietf.org; Wed, 17 Nov 2004 14:48:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05070 for ; Wed, 17 Nov 2004 14:48:44 -0500 (EST) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUVpc-0001ey-9t for isis-wg@ietf.org; Wed, 17 Nov 2004 14:51:20 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.30 ; Wed, 17 Nov 2004 14:48:02 -0500 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Nov 2004 14:48:01 -0500 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.127 140.233.20.127 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 17 Nov 2004 14:48:01 -0500 Subject: Re: [Isis-wg] On draft version 17 of the IS-IS MIB From: "Parker, Jeff" To: Sundar Ramachandran Message-ID: In-Reply-To: <4.3.2.7.2.20041116123524.025e0eb0@codc-mira-1.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Nov 2004 19:48:01.0869 (UTC) FILETIME=[58D9C7D0:01C4CCDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Content-Transfer-Encoding: 7bit Cc: "ISIS-WG \(E-mail\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Sundar - Thanks for the suggestions. I will wait a week or two for other comments and respin the draft. - jeff parker On 11/16/04 4:09 AM, "Sundar Ramachandran" wrote: > Hello Jeff, > > A few more suggestions (very minor) in the draft version of the IS-IS MIB. > Some of these are based on internal review comments from MIB experts, > so you don't have to worry about the correctness or reasoning behind the > comments! :) > > - Some Counter32 objects use an explicit UNITS clause "frames" to indicate > that the count refers to the total number of frames. It's better to > rephrase the > description for such objects using the phrase "Number of frames.." where > appropriate. For e.g., "Number of corrupted in-memory LSP frames" or > "Number of frames with authentication type mismatches". > > - I'd raised a point about the conflict between TimeTicks used as a SYNTAX > along with a UNITS description of "seconds". For such MIB objects, I believe > it is better to remove the UNITS clause so that there will be consistency > between > the TimeTicks definition and sysUpTime (since we're dealing with "hundredths > of a second" and not "seconds"). This is better than modifying the UNITS > clause as "hundredths of a second" which would make it redundant since > that is understood from the definition of TimeTicks. > > - Also, there are still a few cases where the DESCRIPTION clause does not > distinguish between enum values and normal words. For instance, on => 'on', > or False => 'false'. > > - I'd like to clarify the access of MIB objects in isisCircLevelTable. Many > of the > objects are defined with "read-create" permissions. Is this based on the > RowStatus SYNTAX for isisCircIndex which is used as INDEX into this table? > Otherwise, the access would be read-write for these objects, so I just want to > make sure! > > Hope you can spare a few minutes to elaborate on these. If it takes some time, > I'll understand! > > thanks, > Sundar. > >> Date: Sat, 30 Oct 2004 19:07:33 +0530 >> To: "Parker, Jeff" >> From: Sundar Ramachandran >> Subject: Re: [Isis-wg] On draft version 17 of the IS-IS MIB >> >> Jeff, >> >> Thanks. As I wait for your response, I found some minor issues in some of the >> "DESCRIPTION" clauses; some typos in the MIB that I believe were missed >> while renaming objects in the MIB as it progressed to its current state. >> These >> make it hard to distinguish between the names of TLVs, ISO definitions and >> actual MIB objects! >> >> - isisSysLevelOrigLSPBuffSize: This MIB object is referenced in 2 places >> in the >> description of isisSysReceiveLSPBufferSize as "isisSysOrigLSPBuffSize", >> giving >> the impression that it's still associated with the isisSysObject family. >> This needs >> to be changed in the description of isisPduOriginatingBufferSize too. >> >> - There also seems to be some confusion in the description of >> isisOrigLSPBuffSizeMismatch. It has "isisOriginatingBufferSize" all over >> the place! >> Since it no longer has that name, a reference to it in the description of >> isisOrigLSPBuffSizeMismatch is not correct. >> >> The existing description is as follows: >> "A notification sent when a Level 1 LSP or Level >> 2 LSP is received which is larger than the local >> value for isisOriginatingBufferSize, or when an >> LSP is received containing the isisOriginatingBufferSize >> option and the value in the PDU option field does >> not match the local value for isisOriginatingBufferSize...." >> >> I think it should read as follows: >> "A notification sent when a Level 1 LSP or Level >> 2 LSP is received which is larger than the local >> value for isisSysLevelOrigBuffSize, or when an >> LSP is received containing the originatingLSPBufferSize >> option and the value in the PDU option field does >> not match the local value for isisSysLevelOrigBuffSize...." >> >> I really hope that I'm right and not confusing you, because this is what I >> end up with >> when I match it up with the ISO/IEC 10589:2002 standard definition. The >> "option" >> field is the originatingLSPBufferSize TLV on which the check is performed, >> right? >> Here's a snippet from the ISO definition of this notification: >> "originatingLSPBufferSizeMismatch: >> Generated when a Level 1 LSP or Level 2 LSP is received which is larger >> than the local value for >> originatingL1LSPBufferSize or originatingL2LSPBufferSize respectively or >> when a Level 1 LSP or Level2 LSP is >> received containing the originatingLSPBufferSize option and the value in >> the PDU option field does not match the >> local value for originatingL1LSPBufferSize or originatingL2LSPBufferSize >> respectively." >> >> - In draft version 17, the description of isisManualAddressDrops still has a >> reference to isisManAreaAddr even though this object has been removed. >> >> I also want to make sure I understand correctly the need for a zero-length >> valued OCTET STRING for IsisLinkStatePDUID. i.e. SIZE(0|8). Is this to >> indicate that the Decision Process does not process any LSPs, i.e. when >> it's unable to split a single incoming LSP into separate PDUs? >> >> That's it for now! Thanks for your time. >> >> - Sundar. >> P.S.: I was involved with the IS-IS MIB (and IS-IS itself!) pretty late >> during it's >> evolution, so haven't really had a chance to share my understanding on any >> major or minor issues in the contents of the MIB prior to this. >> >> At 10:38 AM 10/29/2004 -0400, you wrote: >>> Thanks for your careful review. There were a large number of changes that >>> went into this update, and these got missed. >>> >>> I will review and report back. >>> >>> - jeff parker >>> >>> >>> On 10/29/04 9:44 AM, "Sundar Ramachandran" wrote: >>> >>>> Hello Jeff, >>>> >>>> Some concerns on the latest yet-to-be-approved draft revision of the MIB: >>>> >>>> 1. There were some comments earlier in the month from Jonathan Harrison >>>> about minor bugs in draft version 16 of the MIB. One of them related >>> to the >>>> inconsistent textual definition of "seconds" for objects using the syntax >>>> TimeTicks. As he pointed out, TimeTicks represents the time (4294967296) >>>> in hundredths of a second since an epoch. I see from the latest draft >>> revision >>>> 17 that some of the objects previously using TimeTicks have been modified >>>> as follows: >>>> e.g., >>>> isisSysLevelSetOverloadUntil OBJECT-TYPE >>>> SYNTAX Unsigned32(1..4294967295) >>>> UNITS "seconds" >>>> MAX-ACCESS read-write >>>> STATUS current >>>> DESCRIPTION >>>> "If isisSysLevelSetOverload is true, the overload >>>> bit should be set at startup, and cleared after >>>> sysUpTime exceeds this value." >>>> ::= { isisSysLevelEntry 6 } >>>> But the description indicates that the determination of it's value >>> depends on >>>> sysUpTime, which is encoded based on TimeTicks. So do we have an >>>> inconsistency here? I mean, do we maintain the SYNTAX as TimeTicks and >>>> change the UNITS, or should it remain as you've modified it? >>>> Moreover, I find that not all similar definitions have been corrected. >>>> For instance, you still have: >>>> isisCircLastUpTime OBJECT-TYPE >>>> SYNTAX TimeTicks >>>> UNITS "seconds" >>>> MAX-ACCESS read-only >>>> STATUS current >>>> DESCRIPTION >>>> "If the circuit is enabled, the value of sysUpTime >>>> when isisCircAdminState most recently entered >>>> the state on. If the circuit is not on, >>>> the value of sysUpTime when the circuit last >>>> entered state on, 0 if the circuit has never >>>> been on." >>>> ::= { isisCircEntry 13 } >>>> and >>>> isisISAdjLastUpTime OBJECT-TYPE >>>> SYNTAX TimeTicks >>>> UNITS "seconds" >>>> MAX-ACCESS read-only >>>> STATUS current >>>> DESCRIPTION >>>> "If the isisISAdjState is in state 'up', the value >>>> of sysUpTime when the adjacency most recently >>>> entered the state 'up', or 0 if it has never >>>> been in state 'up'." >>>> ::= { isisISAdjEntry 11 } >>>> >>>> So I believe the inconsistency still remains. Correct me if I'm wrong. >>>> >>>> 2. The isisOrigLSPBuffSizeMismatch notification is generated for two >>>> conditions: >>>> a) When the received L1 or L2 LSP is larger than the local value of >>>> isisOriginatingBufferSize, >>>> b) When there's a mismatch between the value in the PDU of the >>>> received LSP (with the isisOriginatingBufferSize field present) and the >>>> local isisOriginatingBufferSize value. >>>> In the description of this notification, it is mentioned that: >>>> " We pass up the size from the option field or the >>>> size of the LSP that exceeds our configuration." >>>> >>>> So is it possible to tell whether the trap was generated as a result of >>>> condition >>>> "a" or "b" above? ISO/IEC 10589:2002 uses the notificationLSPHeader >>> parameter >>>> to report the contents of the LSP header and this is part of the >>> equivalent >>>> OSI >>>> notification, thus helping to identify the cause of the trap event. I >>> don't >>>> think >>>> PduLspId, SysLevelIndex and CircIfIndex will be sufficient to >>> determine which >>>> condition caused the trap generation. It's useful to indicate which >>> condition >>>> resulted in a buff. size mismatch. I'd like to know what you think. >>>> >>>> 3. I also need clarification on something not very specific to the >>> current MIB >>>> revision. This has to do with the SIZE 0 for OSINSAddress: >>>> SYNTAX OCTET STRING (SIZE(0..20)) >>>> I'd like to know when a string object with zero-length value will be >>>> applicable >>>> considering that this TC is used to encode isisAreaAddr, >>>> isisISAdjNeighSNPAAddress, isisISAdjAreaAddress, isisRASNPAAddress, >>>> isisRASNPAMask and isisRASNPAPrefix? My guess is that it applies in >>>> situations when no address is configured. For example, when we have no >>> area >>>> address configured, or we have no neighbor SNPA addresses? Or is there a >>>> different reason? The DEFVAL of ' 'H (the empty string) is provided >>> only for >>>> isisRASNPAAddress and isisIPRASNPAAddress, so it's not very clear. I just >>>> want to make sure that it's valid to use OSINSAddress as SYNTAX with the >>>> prescribed size restriction for all the respective MIB objects. >>>> >>>> 4. Finally, based on my earlier post with queries on draft 16, I'd like to >>>> know >>>> if it's useful enough to define or make provisions in the MIB for an >>>> initial activity >>>> period where traps are suppressed, much along the lines of the RFC1850 >>>> OSPF-MIB definition. >>>> >>>> Hope to hear suggestions and corrections where necessary! >>>> Thanks for your time. >>>> - Sundar. >>>> >>>> >>>> _______________________________________________ >>>> 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-bounces@ietf.org Tue Nov 23 11:27:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27290 for ; Tue, 23 Nov 2004 11:27:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdLV-0006BA-LO; Tue, 23 Nov 2004 11:16:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdBh-0003Hs-R1 for isis-wg@megatron.ietf.org; Tue, 23 Nov 2004 11:06:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25091 for ; Tue, 23 Nov 2004 11:06:39 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdFO-0004ZC-Ec for isis-wg@ietf.org; Tue, 23 Nov 2004 11:10:30 -0500 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Nov 2004 16:06:01 -0000 Message-ID: <37701240971DD31193970000F6CCB9F70453CA2A@duke.datcon.co.uk> From: Mike Bartlett To: "'isis-wg@ietf.org'" , Jeff Parker , jeffp@middlebury.edu Date: Tue, 23 Nov 2004 16:06:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [Isis-wg] Concerns about isisSysLevelTable in IS-IS MIB draft 16 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi Jeff, I have two concerns about the IS-IS MIB draft, revision 16. 1. I have a concern about the isisSysLevelMetricStyle object defined in the isisSysLevelTable. isisSysLevelMetricStyle OBJECT-TYPE SYNTAX MetricStyle MAX-ACCESS read-create STATUS current DESCRIPTION "Which style of Metric do we generate in our LSPs at this level? This object follows the replaceOnlyWhileDisabled behavior." DEFVAL { narrow } ::= { isisSysLevelEntry 7 } My concern is that the object follows replaceOnlyWhileDisabled behavior. There does not seem to be any compelling reason for this behavior (which is not shared by the related isisSysLevelSPFConsiders object), and it does not fit well with the narrow->wide metric style migration defined as follows in RFC3787 (section 5.1). To facilitate a smooth transition between the use of narrow metrics exclusively to the use of wide metrics exclusively, the following steps must be taken, in the order below. (1) All routers advertise Narrow Metrics as defined in ISO 10589, and consider narrow metrics only in their SPF computation. (2) Each system is configured in turn to send wide metrics as well as narrow metrics. The two metrics for the same link or IP prefix SHOULD agree. (3) When all systems are advertising wide metrics, make any changes necessary on each system to consider Wide Metrics during the SPF, and change MaxPathMetric to 0xFE000000. (4) Each system is configured in turn to stop advertising narrow metrics. (5) When the network is only using wide metrics, metrics on individual links may be rescaled to take advantage of the larger metric. Taking these two documents together, every router must be deactivated and reactivated twice (in steps 2 and 4) when migrating a network. Even if the routers are able to use graceful restart procedures, this seems like a large and unnecessary overhead on the network as a whole. I would therefore like the description for this object to say only "Which style of Metric do we generate in our LSPs at this level?". ---------------- 2. I have a related (but more minor) concern about using the replaceOnlyWhileDisabled behavior at all in object descriptions on the isisSysLevelTable, because it does not really make sense here. This affects the isisSysLevelOrigLSPBuffSize object (and currently the isisSysLevelMetricStyle object, though as stated above I hope this will disappear anyway). ReplaceOnlyWhileDisabled behavior is defined as follows. "This object may not be modified while the corresponding table row's variable of type AdminState is in state on." Usually the "corresponding table row" relates to the *same* MIB table containing the object that the behavior relates to. However, in this case, the isisSysLevel table does not even have an AdminState variable. While it is fairly obvious that in this case the important variable is the AdminState in the isisSystem table, this could probably be stated more clearly. How about the following text for the description of the isisSysLevelOrigLSPBuffSize object? "The maximum size of LSPs and SNPs originated by this Intermediate System at this level. This object may not be modified while the isisSysAdminState variable is in state 'on' for this Intermediate System." ---------------- Please let me know what you think on these two points. Many thanks, Mike Bartlett ------------------------------------------- Mike Bartlett Network Protocols Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: mb@dataconnection.com Web: http://www.dataconnection.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Nov 23 11:51:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29507 for ; Tue, 23 Nov 2004 11:51:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdod-0006Xo-FH; Tue, 23 Nov 2004 11:46:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdbh-0002fN-OE for isis-wg@megatron.ietf.org; Tue, 23 Nov 2004 11:33:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28101 for ; Tue, 23 Nov 2004 11:33:30 -0500 (EST) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdfO-0008Jl-5o for isis-wg@ietf.org; Tue, 23 Nov 2004 11:37:22 -0500 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.31 ; Tue, 23 Nov 2004 11:33:00 -0500 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Nov 2004 11:32:59 -0500 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.127 140.233.20.127 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 23 Nov 2004 11:32:57 -0500 From: "Parker, Jeff" To: Mike Bartlett , "'isis-wg@ietf.org'" , Jeff Parker Message-ID: In-Reply-To: <37701240971DD31193970000F6CCB9F70453CA2A@duke.datcon.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Nov 2004 16:32:59.0975 (UTC) FILETIME=[1874F570:01C4D17A] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Re: Concerns about isisSysLevelTable in IS-IS MIB draft 16 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Mike - Thanks for your note. There have been a few other suggestions, and I plan to respin shortly. If anyone would like to review the changes before they are resubmitted, I'd be happy to include them on the short list of reviewers. I will send out a list of deltas to the group. - jeff parker On 11/23/04 11:06 AM, "Mike Bartlett" wrote: > Hi Jeff, > > I have two concerns about the IS-IS MIB draft, revision 16. > > 1. I have a concern about the isisSysLevelMetricStyle object defined in the > isisSysLevelTable. > > isisSysLevelMetricStyle OBJECT-TYPE > SYNTAX MetricStyle > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Which style of Metric do we generate in our LSPs > at this level? This object follows the > replaceOnlyWhileDisabled behavior." > DEFVAL { narrow } > ::= { isisSysLevelEntry 7 } > > My concern is that the object follows replaceOnlyWhileDisabled behavior. > There does not seem to be any compelling reason for this behavior (which is > not shared by the related isisSysLevelSPFConsiders object), and it does not > fit well with the narrow->wide metric style migration defined as follows in > RFC3787 (section 5.1). Depends on which bloke you choose to believe, I suppose. I agree that there is no need to restart everything here, though there is clearly the possibility that there will be major changes in the Route Table. > I would therefore like the description for this object to say only > > "Which style of Metric do we generate in our LSPs at > this level?". > > 2. I have a related (but more minor) concern about using the > replaceOnlyWhileDisabled behavior at all in object descriptions on the > isisSysLevelTable, because it does not really make sense here. This affects > the isisSysLevelOrigLSPBuffSize object (and currently the > isisSysLevelMetricStyle object, though as stated above I hope this will > disappear anyway). > > ReplaceOnlyWhileDisabled behavior is defined as follows. > > "This object may not be modified while the > corresponding table row's variable of type AdminState is in state on." > > Usually the "corresponding table row" relates to the *same* MIB table > containing the object that the behavior relates to. However, in this case, > the isisSysLevel table does not even have an AdminState variable. While it > is fairly obvious that in this case the important variable is the AdminState > in the isisSystem table, this could probably be stated more clearly. How > about the following text for the description of the > isisSysLevelOrigLSPBuffSize object? > > "The maximum size of LSPs and SNPs originated by > this Intermediate System at this level. This object may not be modified > while the isisSysAdminState variable is in state 'on' for this Intermediate > System." > > Please let me know what you think on these two points. > > Many thanks, > > Mike Bartlett I will fold in both suggestions. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg